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