www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What endiannesses do D support?

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
Some of druntime/phobos code assumes it is one of little/big endianness 
others have `static assert(0)` for third case. Lets clear the situation 
and make a decision.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Oct 04 2013
next sibling parent reply "Alex =?UTF-8?B?UsO4bm5l?= Petersen" <alex lycus.org> writes:
On Friday, 4 October 2013 at 10:59:05 UTC, Denis Shelomovskij 
wrote:
 Some of druntime/phobos code assumes it is one of little/big 
 endianness others have `static assert(0)` for third case. Lets 
 clear the situation and make a decision.
Little endian and big endian must be supported. Little endian PowerPC, for example, is extremely rare (if not entirely extinct), so just supporting little endian is not enough.
Oct 04 2013
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
04.10.2013 15:00, Alex Rønne Petersen пишет:
 On Friday, 4 October 2013 at 10:59:05 UTC, Denis Shelomovskij wrote:
 Some of druntime/phobos code assumes it is one of little/big
 endianness others have `static assert(0)` for third case. Lets clear
 the situation and make a decision.
Little endian and big endian must be supported. Little endian PowerPC, for example, is extremely rare (if not entirely extinct), so just supporting little endian is not enough.
Of course. The question is about "a third case". -- Денис В. Шеломовский Denis V. Shelomovskij
Oct 04 2013
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 04/10/2013 11:59, Denis Shelomovskij wrote:
 Some of druntime/phobos code assumes it is one of little/big endianness others
have
 `static assert(0)` for third case. Lets clear the situation and make a
decision.
Are you thinking of middle-endian orders such as 2,3,0,1? Or just wondering in what situations neither BigEndian nor LittleEndian would be set? I suppose that most, if not all, 32+-bit machines are either big-endian or little-endian. But still, I imagine that the "third-case" is just a safeguard in case it is missed when somebody comes across a middle-endian platform and tries to compile that code on it. Or maybe it was just put in out of belief that it is a good programming practice. Endianness support as far as the D language is concerned doesn't seem to be clear-cut. http://dlang.org/version.html lists LittleEndian and BigEndian, but doesn't state that one of these will always be set. So middle-endian machines, if a D compiler exists for them, would use this "third case". Further work would be needed to determine what particular middle-endian order the machine implements for each size of integer. (Floating points are even more complicated, so I guess you can't rely on any version flag to tell you about the format of these.) OTOH, the platforms on which DMD runs are big-endian or little-endian. If DMD is ported to a middle-endian platform, or the DMD Phobos/druntime code is cribbed for use with a third-party D compiler for a middle-endian machine, then the static assert will fire, thereby drawing attention to this unimplemented functionality rather than silently generating code that won't work because it's written for a little-endian machine, or for a big-endian machine. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Oct 04 2013
parent Brad Roberts <braddr puremagic.com> writes:
On 10/4/13 3:26 PM, Stewart Gordon wrote:
 On 04/10/2013 11:59, Denis Shelomovskij wrote:
 Some of druntime/phobos code assumes it is one of little/big endianness others
have
 `static assert(0)` for third case. Lets clear the situation and make a
decision.
Are you thinking of middle-endian orders such as 2,3,0,1? Or just wondering in what situations neither BigEndian nor LittleEndian would be set? I suppose that most, if not all, 32+-bit machines are either big-endian or little-endian. But still, I imagine that the "third-case" is just a safeguard in case it is missed when somebody comes across a middle-endian platform and tries to compile that code on it. Or maybe it was just put in out of belief that it is a good programming practice. Endianness support as far as the D language is concerned doesn't seem to be clear-cut. http://dlang.org/version.html lists LittleEndian and BigEndian, but doesn't state that one of these will always be set. So middle-endian machines, if a D compiler exists for them, would use this "third case". Further work would be needed to determine what particular middle-endian order the machine implements for each size of integer. (Floating points are even more complicated, so I guess you can't rely on any version flag to tell you about the format of these.) OTOH, the platforms on which DMD runs are big-endian or little-endian. If DMD is ported to a middle-endian platform, or the DMD Phobos/druntime code is cribbed for use with a third-party D compiler for a middle-endian machine, then the static assert will fire, thereby drawing attention to this unimplemented functionality rather than silently generating code that won't work because it's written for a little-endian machine, or for a big-endian machine. Stewart.
Good answer. I'll add only one point: The use of the else static assert is a good way to catch a new platform that's one of little or big but fails to specify. If the code instead did if (little) {...} else {...}, the wrong choice would be potentially made. Better to require explicitness.
Oct 04 2013