Conditional compilation inside asm and enum declarations

[Walter Bright]

Julian Salazar wrote:
> Maybe it's time for some maintenance? Or a rewrite in a certain 
> higher-level language? ;)

Yes, but to rewrite it requires understanding it, and that means obj2asm.

>> So, in essence, the idea is to push conditional compilation to higher 
>> levels, not lower levels. Ideally, versioning would be done by 
>> abstracting all the version differences into an interface implemented 
>> by different modules.
> 
> You make a valid point. However the issue still remains where two 
> versions for example are inextricably linked. It's understandable that 
> you would keep separate modules when compiling between architectures 
> like x86 and SPARC64, or even Basic and Advanced versions (which usually 
> just involve including functionality). However, when it involves 
> situations such as the x86 & x86-64 which ARE very similar platforms and 
> a full copy with minimal rewrite does not seem justified. Tell that to 
> device driver writers with their C, inline assembly and #ifdefs.
> 
> (Side note: I've worked around the versioning with a slightly more 
> cumbersome syntax.
>    asm {
>        ...code...
>    } // But I can't assure that no code is compiled between the two asm 
> statements =/
>    version(x86) asm  {
>        ...code...
>    }
>    else version(x86_64) asm  {
>        ...code...
>    }
> )

It's been rehashed here several times (not to rag on you, just to point 
out that it isn't something that's been overlooked). To sum up, I've 
worked a lot with both styles - #ifdef, and separating dependencies into 
independent modules. The latter works a lot better. I know it's hard to 
believe if you're used to the #ifdef style. I've been doing some work to 
remove #ifdef's from the dmd compiler source, and the results so far 
have been very satisfactory.


>> The first approximation to the definition is to use the Intel asm 
>> syntax as outlined in their processor data sheets. I haven't written a 
>> spec more detailed than that because it's a lot of work and I'm lazy, 
>> and such work is not terribly exciting. But if you'd like to help with 
>> that, I'd welcome it.
> 
> How would I go about doing that? It seems like all the work that remains 
> to be done is just updating opcodes and the valid registers. Maybe a bit 
> of tightening of the specification and syntax, but other than that the 
> basic outline is there.

For one thing, the valid registers for x86 mode do not include the 64 
bit registers. There's also the grammar for the operands, which is not 
specified in the D spec.