D Design Could Be Improved

Aleksey S. Skidan al.skidan at gmail.com
Sun Dec 17 07:09:26 PST 2006


The inline assembler seems to be a weak point in the language design.
I do like the GCC inline assembler and can't understand the reasons
why not to use it. The current implementation of D's inline assembler
is IMNHO not good.
Let's consider the following example:
asm{ di 2+3; }
The code won't ever be compiled. Just because the assembler consider 2+3 not
to be a constant expression. But it certainly is (it depends on 2 constants).
The other ugly thing is Intel syntax. There's a lot of software written in
AT&T syntax. I guess both the Intel and AT&T syntaxes must be available.
The weakness of current inline assembler makes the language (i mean D) not
fitable for system programming.
I noticed that there's no ability to name a symbol in a way like that:
void foo() asm("bar"); Please, note that this kind of naming is very handy for
embeded systems and a lot of stuff like that. Yep, there's extern(C) but why
does it underscore? There must be a switch that turns underscoring off. The
next disappointment is that one can't specify where to put a symbol. I mean
one can't say to put "foo" into .some_section instead of .text section.
I do agree with the point that bit fields are BAD things. But the bit array
you introduced isn't better. You must at least specify the way the bit array
is stored in the memory: is it BE LE or what. The next thing about them is
that they don't really save the memory. I mean that the bit[8] blah; is 32
bits long. But then the better way to write the same thing is: enum{ B0, B1,
..., B7 }; char blah;

My best regards, Aleksey.



More information about the Digitalmars-d mailing list