D Design Could Be Improved

[Alexander Panek]

Aleksey S. Skidan wrote:
> 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.

This might be a good point, but then again you can still use actual 
assembler files in AT&T syntax to accomplish that. IMHO, this should be 
done for large portions of assembler sources, anyways. You can interface 
D with assembler without *any* problems (been there, done that - with 
both, nasm and gas).

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

What exactly do you mean with that? Would that imply foo() being mangled 
as "bar"? If so, I think this could be a great feature, yes.

> Yep, there's extern(C) but why
> does it underscore? There must be a switch that turns underscoring off.

I don't have any underscores here..? I've used normal extern(C) foo(){} 
+ call foo in assembler, and it works.

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

Mh, right.

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

Bit fields are really BAD, as you said. Apart from that, in most cases 
you just use bit operations to alter bits in a variable. If there's a 
need for a datatype that supports "bit fields" and is not like BitArray, 
  just give me a hint. I was thinking about implementing one too, 
somewhen. Apart from that, do you have a specific of how such a datatype 
should look like?

> 
> My best regards, Aleksey.

Thanks for your comments, D is way too little used in the embedded 
sector, yet, so every constructive comment just can help!

I am experimenting a bit with OS development in D. If you want to take a 
look at what I've got so far: http://trac.brainsware.org/ocd/browser/

Best regards,
Alex