Re: Creating several types from a base type and conversion

[Optikos <ZUERCHER_Andreas@outlook.com>]

On Friday, January 24, 2020 at 3:35:04 AM UTC-6, Ken Roberts wrote:
> On Thursday, January 23, 2020 at 1:39:13 PM UTC-8, Optikos wrote:
> 
> <snip>
> 
> > Instead of depending on a big-language solution of a very-feature-rich compiler, there is a common industrial practice in both Ada and other languages that I mentioned in my 2 replies:  use 2 different packages with same-named identifiers (especially functions or procedures) to link in either the little-endian implementation or big-endian implementation (or any other nonportability that is peculiar to a target ISA or target OS).  This solution is at the heart of VIPER and MVVM software architectures for taming the portability beast quite well (going so far as to tame even radical philosophical departures among the very divergent GUIs/window-managers:  Gnome/GTK, Windows UWP, Win32, KDE/Qt, Tizen).
> 
> <snip>
> 
> It was my understanding that big/little-endian representations were mainly how data was accessed from memory that used 8-bit bytes for physical memory layout.
> 
> Using a 16-bit register as an example:
> 
> register: [first byte][second byte]
> 
> In big-endian format the memory usage would be:
> 
> adx 0: [first byte]
> adx 1: [second byte]
> adx 2: [first byte]
> adx 3: [second byte]
> 
> In little-endian format the memory usage would be:
> 
> adx 0: [second byte]
> adx 1: [first byte]
> adx 2: [second byte]
> adx 3: [first byte]
> 
> Is my understanding off?

Yes, you are correct sort of, depending on how you define “first” and “second”.  If first is low-valued powers of 2 increasing ascendingly up to 16 (or 32), then you have it backwards.  If first is high-valued powers of 2 decreasing descendingly down to 0, then you have it correct.  As AdaMagica also nudged in the better-thinking direction, the terms most-significant byte and least-significant byte and most-significant (16-bit-)word and least-significant word are clearer thinking because they overtly refer to the powers of 2 mathematically.  Ada's bit_order refers to whether the ISA refers to the bits (independent of the bytes and words) in power-of-2 order mathematically where 2⁰ is the origin and usually called bit zero (instead of bit one) or opposite of power-of-2 order anti-mathematically/lexicaly where 2¹⁶ is the origin often called bit one (or more rarely bit zero) in 16-bit words and where 2³² is the origin often called bit one (or more rarely bit zero) in 32-bit words.

But I am focusing on a different debate.  Should a) an all-knowing omniscient compiler feature be the basis of your portability, deferring the responsibility to the language, or b) overt source code that you write in a structured way be the basis of your portability, taking the responsibility on yourself?  The omnsiscent compiler feature needs to present in all compilers across all targets and nonbuggy (or bug-for-bug compatibility) across all targets, whereas the overt source code architecture depends only on having a way to substitute one Ada package for another with same-named identifiers on this target versus that target.  In the overt source-code architecture there are little-endian versions of certain functions (or procedures) and big-endian versions of those same-named functions (or procedures).  Indeed, the this versus that package switcheroo at build-time can be utilized for more portability challenges than mere endianness, but also for this OS versus that OS (e.g., POSIX versus Windows) and this GUI framework versus that GUI framework (e.g., Gnome/Gtk versus Windows UWP versus Win32 versus Carbon versus Cocoa versus CocoaTouch versus Tizen) all of which is far far far beyond the capabilities of any omniscient compiler to hide.  VIPER takes this build-time switcheroo to the Nth degree (but you might not need all of VIPER); MVVM less so than VIPER, but both as a valid stern criticism of MVC's excessive interconnectedness that causes MVC to ruin this degree of portability.  All 3 of VIPER, MVVM, and MVC is a criticism of the omniscient compiler feature trying to accomplish the portability for you intrinsically behind the scenes.