Portable ASM
Tom Roberts
tjr at ihnet.ATT.COM
Wed Mar 9 02:40:18 AEST 1988
Dave Burton writes:
>> [omitted discussion of #asm ... ]
>>Do *not* mix languages in a single source file.
There ARE times when mixing ASM within a C source file is VERY USEFUL.
The 8086-class of processors, with their segmented architectures,
requires a C compiler to support several different memory models
having different-length pointers. In many development environments
it is difficult to communicate the current memory-model of the C compiler
to the assembler (so ASM code can use IFDEF-s based on memory model).
Thus, it is better to have a C compiler that allows inline ASM code;
for ASM routines you simply declare a C function which contains only
(mostly) ASM code; a good compiler will handle arguments and globals
appropriately.
E.g. Turbo C:
void asm_sum(unsigned long *sum, unsigned int arg1, unsigned int arg2)
{
asm mov ax,arg1
asm mul arg2
asm mov arg1,ax /* lsb */
asm mov arg2,dx /* msb */
*sum += arg1 + (arg2<<16);
}
This program will compile correctly in all memory models (note the careful
mixing of C and ASM - performing the last statement in ASM requires
ASM IFDEF-s on memory model). [program written from memory - actual syntax
may vary slightly - I forgot whether Turbo C can handle a union in ASM code,
so I used that ugly shift - this is an EXAMPLE, not a real program]
Sometimes it is desirable to avoid the function call overhead for this
kind of function - inline ASM allows you to directly use the full resources
of the processor, not just those that the C compiler happens to use.
Clearly, portability suffers, but some of us need PERFORMANCE, not
portability (e.g. the program is inherently written for a given graphics
board).
Tom Roberts
AT&T Bell Laboratories
ihnp4!ihnet!tjr
More information about the Comp.lang.c
mailing list