www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Does D support middle endianness?

reply Valentino Giudice <valentino.giudice96 gmail.com> writes:
The only reference I found was this thread from 11 years ago: 
https://forum.dlang.org/post/mailman.1953.1380926372.1719.digitalmars-d puremagic.com

I'd argue that if there aren't many middle endian architecture, 
it'd be worth not supporting them, in exchange for only having to 
deal with two byte orders (rather than all possible 
permutations), so the specification should mandate that either 
LittleEndian or BigEndian be set to true.
Jun 29
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Mon, Jun 30, 2025 at 02:46:03AM +0000, Valentino Giudice via Digitalmars-d
wrote:

 The only reference I found was this thread from 11 years ago:
 https://forum.dlang.org/post/mailman.1953.1380926372.1719.digitalmars-d puremagic.com
 
 I'd argue that if there aren't many middle endian architecture, it'd
 be worth not supporting them, in exchange for only having to deal with
 two byte orders (rather than all possible permutations), so the
 specification should mandate that either LittleEndian or BigEndian be
 set to true.


What is a middle endian architecture?  First time I've heard of it.


--T
Jun 29
next sibling parent Dom DiSc <dominikus scherkl.de> writes:
On Monday, 30 June 2025 at 04:21:16 UTC, H. S. Teoh wrote:

 On Mon, Jun 30, 2025 at 02:46:03AM +0000, Valentino Giudice via 
 Digitalmars-d wrote:

 The only reference I found was this thread from 11 years ago: 
 https://forum.dlang.org/post/mailman.1953.1380926372.1719.digitalmars-d puremagic.com
 
 I'd argue that if there aren't many middle endian 
 architecture, it'd be worth not supporting them, in exchange 
 for only having to deal with two byte orders (rather than all 
 possible permutations), so the specification should mandate 
 that either LittleEndian or BigEndian be set to true.


 What is a middle endian architecture?  First time I've heard of 
 it.


Yeah, sounds more like a late Aprils fool, born from the 
programming style to not put either of big- or little-endian at 
the else path but instead provide a third path with assert(0).
This style doesn't imply that such a third path really exist (as 
a useful case) but only provides a clear error path.
Jun 30
prev sibling parent Derek Fawcus <dfawcus+dlang employees.org> writes:
On Monday, 30 June 2025 at 04:21:16 UTC, H. S. Teoh wrote:

 On Mon, Jun 30, 2025 at 02:46:03AM +0000, Valentino Giudice via 
 Digitalmars-d wrote:

 The only reference I found was this thread from 11 years ago: 
 https://forum.dlang.org/post/mailman.1953.1380926372.1719.digitalmars-d puremagic.com
 
 I'd argue that if there aren't many middle endian 
 architecture, it'd be worth not supporting them, in exchange 
 for only having to deal with two byte orders (rather than all 
 possible permutations), so the specification should mandate 
 that either LittleEndian or BigEndian be set to true.


 What is a middle endian architecture?  First time I've heard of 
 it.


 From memory, it was something that the VAX (or possibly PDP-11) 
did.

For a 32bit value, the in memory representation had two 16bit 
values of one endianess, but their order in memory was the 
opposite of that expected.  Here we go, wikipedia has a reference:

https://en.wikipedia.org/wiki/Endianness#Middle-endian
Jun 30
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, June 29, 2025 8:46:03 PM Mountain Daylight Time Valentino Giudice
via Digitalmars-d wrote:

 The only reference I found was this thread from 11 years ago:
 https://forum.dlang.org/post/mailman.1953.1380926372.1719.digitalmars-d puremagic.com

 I'd argue that if there aren't many middle endian architecture,
 it'd be worth not supporting them, in exchange for only having to
 deal with two byte orders (rather than all possible
 permutations), so the specification should mandate that either
 LittleEndian or BigEndian be set to true.


LittleEndian and BigEndian are version identifiers, not values which are
true or false. If we had a system that we supported which was middle endian,
then we'd need a version identifier for that, and there would be some code
that would need to be updated to use that version identifier, but we don't
have to worry about that unless / until we add support for such a system.

And the only place that I'm aware of where there's any value used as opposed
to a version identifier is std.system.Endian, which is an enum for
endianness with the idea that if a runtime value were needed for some
reason, it could be used

https://dlang.org/phobos/std_system.html#.Endian

So, if we were supporting a system which had endianness other than big or
little, then we'd need to add it to that enum, but that's never come up, and
realistically, code that deals with endianness normally would just use the
appropriate version identifier anyway.

So, we really don't need to worry about middle endian system support. If /
when we ever do add support for such a system, we can worry about it then,
and it wouldn't really simplify anything to say that we're not planning on
supporting such systems. The only gotcha that I'm aware of is that if you
use else with version identifiers - e.g.

version(LittleEndian)
{
}
else
{
}

with the assumption that only big and little endian exist, then there could
be problems if / when we ever added support for a middle endian system, and
arguably, it's more correct to do something like

version(LittleEndian)
{
}
else version(BigEndian)
{
}
else
    static assert(false, "Unsupported endianness");

but that really only affects libraries, not the language itself, and so
little code has to worry about endianness that it doesn't matter much. And
as a general rule, it's usually best practice to use a static assertion like
that with the else branch of a version statement anyway.

So, I think that you're worrying about a total non-issue. We really don't
gain anything by mandating anything about future support for other types of
endianness, and the fact that we could theoretically add support for other
types of endianness at some point in the future really doesn't put any sort
of burden on us right now that could be removed by saying that we're never
going to support other types of endianness.

- Jonathan M Davis
Jul 02