bateman@nsslsun.gcn.uoknor.edu (Monte Bateman) (09/04/90)
It's possible to do in-line assembler with ANY compiler.
This technique was discussed in the "C Users's Journal" for
May, 1990 - author James Kuzdrall.
First, figure out what the machine codes are for the
assembly language you want to execute -
NOTE: The nice thing about this procedure is that it will port
to other processors - say if you had a C compiler that
compiles to 6809 machine code...
finish by converting your opcodes to octal. The author suggests
making a hex-octal conversion table by using printf().
Second, in you C code, do something like
char *x_str; /* declare the executable string */
x_str = "\032\020\071"; /* insert your OCTAL opcodes here */
Third, execute this string, using the incantation:
(*((void (*)()) x_str))();
This should do the trick.
-Monte
Monte Bateman
WB5RZX @ WB5RZX
bateman @ nsslsun.gcn.uoknor.edu
National Severe Storms Laboratory, Norman, OK! 73069kdq@demott.COM (Kevin D. Quitt) (09/04/90)
In article <1990Sep4.100511.10686@uokmax.uucp> bateman@nsslsun.gcn.uoknor.edu (Monte Bateman) writes: >It's possible to do in-line assembler with ANY compiler. [ abominable technique of executing a string of octal constants deleted]. Sorry, that isn't in-line assembly. It's unsupportable, and since there can't be any references to normal variables, mostly useless. The power on in-line assembly is that you *can* get to normal variables, with the linker doing the corrections for you. There's also this idea called "documentation"... -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
res@PacBell.COM (Bob Stockwell) (09/05/90)
-- Bob Stockwell Pacific Bell pacbell.com!ptsfa!res
dgil@pa.reuter.COM (Dave Gillett) (09/06/90)
In <528@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >In article <1990Sep4.100511.10686@uokmax.uucp> bateman@nsslsun.gcn.uoknor.edu (Monte Bateman) writes: >>It's possible to do in-line assembler with ANY compiler. >[ abominable technique of executing a string of octal constants deleted]. > Sorry, that isn't in-line assembly. It's unsupportable, and since >there can't be any references to normal variables, mostly useless. The >power on in-line assembly is that you *can* get to normal variables, with >the linker doing the corrections for you. Technically, it's also not "in-line" because the compiler is generating a *function call* into the octal code, which hopefully ends with a suitable return instruction (near/far or whatever). The main attraction of putting machine instructions in-line instead of linking to an assembly-language routine is to avoid the function call/return overhead, and this method doesn't. Dave
kevin@kosman.UUCP (Kevin O'Gorman) (09/06/90)
kdq@demott.COM (Kevin D. Quitt) writes: >In article <1990Sep4.100511.10686@uokmax.uucp> bateman@nsslsun.gcn.uoknor.edu (Monte Bateman) writes: >>It's possible to do in-line assembler with ANY compiler. >>[ abominable technique of executing a string of octal constants deleted]. > Sorry, that isn't in-line assembly. It's unsupportable, and since > [ other reasons deleted ] Furthermore, it isn't assembly because it is absolute machine code, a related but truly different animal. In particular, it may not be workable on architectures that require absolute addresses for jumps and such. Assembly code takes care of such stuff for you; absolute coding does not. -- Kevin O'Gorman ( kevin@kosman.UUCP, kevin%kosman.uucp@nrc.com ) voice: 805-984-8042 Vital Computer Systems, 5115 Beachcomber, Oxnard, CA 93035 Non-Disclaimer: my boss is me, and he stands behind everything I say.
bcw@rti.rti.org (Bruce Wright) (09/07/90)
In article <1990Sep4.100511.10686@uokmax.uucp>, bateman@nsslsun.gcn.uoknor.edu (Monte Bateman) writes: > It's possible to do in-line assembler with ANY compiler. > (discussion of how to load a binary program into an array > and call it from the HLL code deleted) Actually this is not true, though _most_ compiler systems allow this. For example, some machine architectures would place the data into a different address space which could not be called as code; you would have to have some sort of magic in the form of a small assembler program (or possibly a system call) to move the data to the code space (most compilers wouldn't know how to generate, for example, an instruction to MOVE_TO_CODE_SPACE, a sort of instruction that actually exists on the PDP-11: MFPI/MTPI/ MFPD/MTPD for move to/from previous code/data space). But if you have the assembler you don't need the array hack in the first place ... Also, some compiler systems have a different name space for data objects as opposed to code objects, so that even though the machine would allow the reference the array is in the wrong compiler "space" to be called by the code. Again, this sort of thing can be overcome fairly easily by a small assembler program but why bother ??? C generally does allow this sort of hack. So did many old-style FORTRAN compilers (put the program into COMMON and call it; may need to have the definition and use of COMMON in different modules to keep the compiler from barfing) - I've seen this technique used maybe 18 years ago in old FORTRAN programs, so it's nothing new. But as Kevin pointed out in another article, this isn't a very good idea, and never really has been. About the only reason you would want to do something like this is if you are bootstrapping a language system on a new machine, and the assembler just happens not to have been built yet (! somewhat strange situation but it's possible now with some of the RISC machines which are hardly ever programmed in assembler). Consider: This makes an obscure program, with difficult-to-read binary code, which is likely to break if you even change compilers; you lose the ability to use symbolic names of any kind; and you don't even get efficiency for all your troubles, since part of your binary array has to include some sort of entry and exit effectors for your little "subroutine" and the compiler has no opportunity to do any sort of optimizations based on register and variable usage analysis of the assembly code and its surrounding HLL code. It might be OK as part of a tour de force student hack, but it isn't anything you'd want to see in anything like production code, even if it's just something that you're going to use for yourself. The first time you come back to modify the program after having put it aside for a year or two you will hate yourself. And one of the first things you learn in this business is that even "one- shot" programs have a way of sticking around practically forever. Bruce C. Wright