www.digitalmars.com         C & C++   DMDScript  

D - An idea: endianness attribute

reply "Samuel Barber" <opendtv yahoo.com> writes:
A feature that I've never seen in a compiler, but which I think would be
useful, is a means to specify the endianness of data. This would mainly be
useful for public data structures (like the alignment attribute).

So if I'm on an x86, and accessing bigendian words, the compiler will
generate nice BSWAP instructions...

Sam
Jul 24 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
This would be very nice, although of course to be used sparingly (as I'm
sure you intend).

"Samuel Barber" <opendtv yahoo.com> wrote in message
news:bfp2vr$156v$1 digitaldaemon.com...
 A feature that I've never seen in a compiler, but which I think would be
 useful, is a means to specify the endianness of data. This would mainly be
 useful for public data structures (like the alignment attribute).

 So if I'm on an x86, and accessing bigendian words, the compiler will
 generate nice BSWAP instructions...

 Sam

Jul 24 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bfq0h4$21c6$1 digitaldaemon.com...
 This would be very nice, although of course to be used sparingly (as I'm
 sure you intend).

Let me think... it would make network byte order transparent to the sockets developer, let me strip the ugliest lines of code out of my ModBus drivers... talk about "sparingly"! :-) OTOH, it is a feature that, if abused, would lead to bigger and less efficient code... but that can be said of just about anything, from floating point to marijuana. Walter, will you give us bigendian and littleendian attributes? Pretty please? :-) (Just to be clear: D *rocks* as it is now. Endianness attributes, though, are too attractive to not dream of them, at least...) Ric P.S.: No, I don't know of any current compiler with marijuana support, though I have seen programs seemingly written by someone on a bad trip :)
Jul 30 2003
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I agree that endianness attributes are a good feature.  However, they 
must be paired with a very well defined way to lay out structs, 
including bitfields.

Riccardo De Agostini wrote:
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bfq0h4$21c6$1 digitaldaemon.com...
 
This would be very nice, although of course to be used sparingly (as I'm
sure you intend).

Let me think... it would make network byte order transparent to the sockets developer, let me strip the ugliest lines of code out of my ModBus drivers... talk about "sparingly"! :-) OTOH, it is a feature that, if abused, would lead to bigger and less efficient code... but that can be said of just about anything, from floating point to marijuana. Walter, will you give us bigendian and littleendian attributes? Pretty please? :-) (Just to be clear: D *rocks* as it is now. Endianness attributes, though, are too attractive to not dream of them, at least...) Ric P.S.: No, I don't know of any current compiler with marijuana support, though I have seen programs seemingly written by someone on a bad trip :)

Jul 30 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> ha scritto nel messaggio
news:bg8l6g$1e3o$2 digitaldaemon.com...
 I agree that endianness attributes are a good feature.  However, they
 must be paired with a very well defined way to lay out structs,
 including bitfields.

As for structure alignment, we have the align keyword and I just can't figure out a situation where it would not be enough. Could you make an example? Bitfields are another story. Walter decided to cut them out of the language specifications because they are "rarely used". I don't agree with that statement: there are lots of places where bitfields come handy. Think of COM's HRESULT type, for instance. Or memory-mapped I/O, should the compiler be ported to CPUs other than Intel's. Or any situation where you have to communicate with external hardware, implement communication protocols... IP packets contain bitfields (talk about rarely used :-) ) and, even if I agree that one usually relies on libsocket or Winsock, what if I wanted to make a D version of WatTCP and contribute it to D's standard library, at least for the 32-bit DOS environment? It surely would look better (and be more easily read and maintained) if I could declare bitfields instead of using masks and shifts. I sincerely hope that Walter have a second thought about them. Ric
Jul 30 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
Bitfields are another story. Walter decided to cut them out of the language
specifications because they are "rarely used". I don't agree with that
statement: there are lots of places where bitfields come handy.

Both of you are right. They are handy but still rarely used. What I think happened with C is that no one got used to bitfields because (a) few know about them and (b) those who did never trusted their compiler to manage them correctly. The raw binary and hex strings being discussed in another thread might cover some of the territory but not all of it. You would also need language primitives to mask and extract, or mask and insert, arbitrary bits N through M. It would be nice to have the language support, yes. Mark
Jul 31 2003
parent reply Mark T <Mark_member pathlink.com> writes:
Both of you are right.  They are handy but still rarely used.  What I think
happened with C is that no one got used to bitfields because (a) few know about
them and (b) those who did never trusted their compiler to manage them
correctly.

I use them fairly often (if the compiler is good) when doing embedded programming to map hardware register bits. Of course, I would like a endian attribute to go with them where I now use a preprocessor #ifdef. The way Ada defines bit fields is far cleaner than C IMHO. This is where Walter's bit type would be handy instead of using it as a boolean. I think that embedded programming is a good candidate for D (if they don't over-feature the base language).
Aug 01 2003
parent Mark Evans <Mark_member pathlink.com> writes:
I think that embedded programming is a good candidate for D (if they don't
over-feature the base language).

Any language that aspires to be a 'systems language' should support embedded programming by definition. I hope that is going to be the case with D. It will take actual testing on new target chips, not just assertions about language portability. Opining that a language should not be over-featured while asking for a new feature is nice diplomacy. I'll remember to do that. ;-) Mark
Aug 01 2003