Xref: utzoo comp.sys.ibm.pc.misc:1480 comp.os.msdos.programmer:803
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!wuarchive!emory!mephisto!mcnc!rti!bcw
From: bcw@rti.rti.org (Bruce Wright)
Newsgroups: comp.sys.ibm.pc.misc,comp.os.msdos.programmer
Subject: Re: Inline assembly code possible with any compiler
Summary: Inline assembly in HLL's
Message-ID: <4052@rtifs1.UUCP>
Date: 7 Sep 90 04:23:44 GMT
References: <1990Sep3.220503.21586@ucselx.sdsu.edu> <1990Sep4.100511.10686@uokmax.uucp>
Followup-To: comp.os.msdos.programmer
Organization: Research Triangle Institute, RTP, NC
Lines: 56

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