www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Design Could Be Improved

reply Aleksey S. Skidan <al.skidan gmail.com> writes:
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.
Dec 17 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Aleksey S. Skidan" <al.skidan gmail.com> wrote in message 
news:em3mj6$2s7m$1 digitaldaemon.com...

 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.


bit has not been a datatype in D for quite some time now.  If you're looking 
for a way to make "bitfields", a kind of cheap and easy way to do it is to 
write the appropriate struct in a C header:

typedef struct
{
    unsigned char a : 2;
    unsigned char b : 2;
    unsigned char c : 4;
} Foo;

Then run it through htod.  This will generate a D struct with built in 
setters and getters for the "bitfields", which is really exactly what C does 
for you under the hood.  Using optimization and inlining, those setters and 
getters will probably disappear.
Dec 17 2006
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
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.
 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.



http://digitalmars.com/d/iasm.html
Specifies the this document only describes the x86 implementation of the
inline assembler.  I would suggest it go further and specify that it only
describes DMD's x86 implementation.  Since D is designed to be
cross-platform, anything at the assembly or linking level should be
implementation specific, IMO.  This way, D compilers (even ones with x86
targets) can use whatever asm syntax they like.

Another thought would be implementation-defined attributes.  In C, I've seen
stuff like "__inline__" and "__attribute(something(params))".  It might be
wise for the D spec to define something like "attribute(attr(params))" so
that an embedded D compiler could use:
attribute(section(.bootloader)) void initSerial() {}

-- 
~John Demme
me teqdruid.com
http://www.teqdruid.com/
Dec 17 2006
parent Don Clugston <dac nospam.com.au> writes:
John Demme wrote:

 Specifies the this document only describes the x86 implementation of the
 inline assembler.  I would suggest it go further and specify that it only
 describes DMD's x86 implementation.  Since D is designed to be
 cross-platform, anything at the assembly or linking level should be
 implementation specific, IMO.  This way, D compilers (even ones with x86
 targets) can use whatever asm syntax they like.


Absolutely false. it is very important that the ASM syntax be consistent 
for a single processor. This is another one of those things that C got 
horribly wrong, and that D is getting right.
It's really ridiculous that the GCC syntax for x86 asm even exists.


 Another thought would be implementation-defined attributes.  In C, I've seen
 stuff like "__inline__" and "__attribute(something(params))".  It might be
 wise for the D spec to define something like "attribute(attr(params))" so
 that an embedded D compiler could use:
 attribute(section(.bootloader)) void initSerial() {}
Dec 17 2006
prev sibling next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
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
Dec 17 2006
next sibling parent reply Aleksey S. Skidan <al.skidan gmail.com> writes:
 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.

Exactly.


 I don't have any underscores here..? I've used normal extern(C) foo(){} + call




foo in assembler, and it works.

Linux ya? But not Win. Though MinGW do support -fno-underscore.

As for bit fields and vectors. I said that these are useless at all.
You must have misunderstood me.
Dec 17 2006
parent Alexander Panek <a.panek brainsware.org> writes:
Aleksey S. Skidan wrote:

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

 I don't have any underscores here..? I've used normal extern(C) foo(){} + call




 foo in assembler, and it works.
 
 Linux ya? But not Win. Though MinGW do support -fno-underscore.


Oh well, that might be the problem, yea. :)


 
 As for bit fields and vectors. I said that these are useless at all.
 You must have misunderstood me.


Obviously. BitArray is just a type to satisfy people who miss the bit 
datatype, actually..
Dec 17 2006
prev sibling parent reply Aleksey S. Skidan <al.skidan gmail.com> writes:
Well. One more thing to add:

I think that
void foo()
{
 int x;
 {
   int x;
 }
}

Mustn't be a scoping error. This is a very powerful feature. It helps to avoid
the
names like int x2 or another_x. It makes naming easy. And it is widely used in
select/case blocks.

Regards, Aleksey.
Dec 17 2006
parent Alexander Panek <a.panek brainsware.org> writes:
Aleksey S. Skidan wrote:

 
 Mustn't be a scoping error. This is a very powerful feature. It helps to avoid
the
 names like int x2 or another_x. It makes naming easy. And it is widely used in
 select/case blocks.


I think there have been discussions about that in the past already. The 
fact is, that it /is/ confusing in most cases. I guess that's why D is 
going this way.

Alex
Dec 17 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
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).


Applying basic constant folding to asm blocks doesn't sound like it 
should be too difficult to add.


 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.


Why?  Personally, I'd like to see asm supported as defined in the 
relevant spec, which is what Walter has done.  GCC's asm format is 
particularly ugly--I definitely don't want that.


 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.


I agree that something like this would be nice.  It's already an issue 
when attempting to call C library routines that have the same name as a 
D keyword.  Sure, a C wrapper library can be written to rename these, 
but there should be an in-language alternative.


 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;


Bit arrays don't exist in D any more.  They were dropped as a general 
language facility maybe 40 builds ago.  D's intrinsics do help a bit 
here, however.


Sean
Dec 17 2006