On Mon, Jul 13, 2009 at 8:24 PM, Walter Bright<newshou...@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.