Conditional compilation inside asm and enum declarations

[Tomas Lindquist Olsen]

On Mon, Jul 13, 2009 at 8:24 PM, Walter
Bright<newshound1 at digitalmars.com> wrote:
> Julian Salazar wrote:
>>
>> Hi, I'm new here to the community but I've been using D for a while now,
>> and I have to say that it's a great programming language. I'd like to get
>> involved in this community and help shape this language.
>
> Welcome!
>
>
>> I'm just wondering about a minor issue: why are conditional blocks invalid
>> within expressions such as enum and asm? I mean, in trivial cases it's fine,
>> but in instances where code duplication is a big maintainability nightmare,
>> making conditional compilation more flexible would have benefits for
>> developers.
>
> 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.
>
>
>> Something like (I know it's a trivial example, but you get the point):
>>
>> asm {
>>   version(x86) mov EAX, 1;
>>   else version(x86_64) mov EAX, 2;
>> }
>>
>> would trigger an error. Also, though I know enum qualifies as a
>> constant/datatype cross, structs and classes are perfectly fine with
>> conditional compilation. Couldn't the lexical stuff be changed to support it
>> for enum and asm as well?
>
> 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.
>
> 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.
>
>
>> Also, I noticed that there is no formal specification page for x86-64
>> inline assembly. You define a predefined version identifier such as
>> D_InlineAsm_X86_64, but you don't define registers and instructions
>> pertaining to it. In GDC for example, using the RAX register in the D inline
>> ASM syntax is invalid. Not sure what the case is in LDC (they probably do
>> implement it for x86-64), and I know DMD does not have a 64-bit version, but
>> the spec should at least have a definition for compilers that do implement
>> 64-bit support.
>
> 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.
>

LDC implements x86-64 inline asm just like x86-32 inline asm, that is
the syntax is the same, and the only real difference is the new 64bit
registers and opcodes.
Of course a spec would be nice, but they're really so similar that it
might well be a single page if you ask me.