Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!ihnet!tjr
From: tjr@ihnet.ATT.COM (Tom Roberts)
Newsgroups: comp.lang.c
Subject: Re: Portable ASM
Message-ID: <600@ihnet.ATT.COM>
Date: 8 Mar 88 16:40:18 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 43

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