Portable "asm" (Was: The D Programming Language)

[David Keppel]

In article <915 at PT.CS.CMU.EDU> edw at IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
>>  - we should assume that compilers for this language are going to
>>    do a great deal of optimisation; in particular, they will optimise
>>    across entire compilations, not just single files.
>
>    Which brings up a question, what happens to the asm statement then.
>If you have the write you code such that you have no idea
>where variables are stored, how can you reliable use assemble statement
>that play with storage.  I think the conclusion will be trash asm.

I think not.  I think it will be to change the semantics of asm into a
varargs function (which may even have the register allocator at its
disposal?):

    void
dumb_function( doit_to )
    int		*splat;
{
    enum Labels { START = 1, LOOP, DONE };
    extern int	splodge;
    int		r1, r2;

    _reg_alloc(2);
    asm( START, "movl", ADDR, &splodge, REG, r1 = _register() );
    asm( 0, "clrl", REG, r2 = _register() );
    asm( LOOP, "tstl", REG, r2 );
    asm( 0, "bgeq" LAB, DONE );
    asm( 0, "addl", ADDR, sizeof( some_type ), REG, r1 );
    asm( 0, "subl", ADDR, sizeof( some_type ), ADDR, splat );
    asm( 0, "brb", LOOP );
    asm( DONE, NULL );
    _reg_unalloc();
    /* r1 is just thrown away ... */
}

Alternatively, the opcode could specify the format of the arguments that
it takes (much as printf works), but I think this is unnatural, since if
you had a bunch of typedefs, you couldn't just do:

#ifdef VAX
#define	ADD	"addl"
#else
#define ADD	"add"
#endif

(or something slightly less sick, but I hope this puts the idea across).

No, I haven't thought to closely about this, there may be some fatal flaw.
The worst thing is that this is almost portable ;->

	;-D on  (Well, C is just portable SNOBOL ;-)  Pardo