Conditional compilation inside asm and enum declarations

Julian Salazar julian at ifeelrandom.com
Mon Jul 13 16:09:50 PDT 2009


"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:h3fu36$22hl$1 at digitalmars.com...
> Welcome!

A welcome from the guy who actually created the D language - thanks!

> The request to do it for enums has been thrashed about before. 
> Essentially, version works at the declaration and statement level, not at 
> the expression level or in between tokens, etc. The reason for this is to 
> encourage a more modular approach to versioning than the typical C method 
> of doing it at the lowest level.

That makes sense. I realize that enums aren't structures of data per se, but 
simply integers with a range of defined values, which of course should 
defined and parsed as one expression. And the comma separator in a list 
doesn't lend itself well to being separated by different expressions (in 
fact, I recently filed issue 3063 where DSSS goes out-of-memory because of 
an extra comma in D2's std.dateparse - not your fault but it'd be nice to 
use DSSS again without editing the library source).

> Let me illustrate by a current example. The linker (optlink) is written 
> 100% in assembler. This makes it rather intractable. It's also loaded up 
> with line-by-line nested conditional assembly (and a lot of macros). It's 
> so hard to see what is *actually* being compiled that I'll assemble it, 
> run OBJ2ASM on the output, and work off of the disassembled code.

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

> 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...
    }
)

> 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.

Thanks to everyone for the positive response! 




More information about the Digitalmars-d mailing list