Re: Does Ada support endiannes?

[csampson@inetworld.net (Charles H. Sampson)]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

> On Mon, 12 Dec 2011 09:07:24 -0800, Charles H. Sampson wrote:
> 
> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> > 
> >> On Mon, 12 Dec 2011 04:46:22 -0800 (PST), Gerd wrote:
> >> 
> >>> On 12 Dez., 12:27, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> >>> wrote:
> >>> 
> >>> Any suggestion on how to convert, others than using "/" and "mod"?
> >> 
> >> Why not to use them? It would be a bad idea trying to avoid them.
> >> 
> >> It won't give you much performance, because memory mapping would require
> >> unpacking, alignment, checksum evaluation, stuff which would turn into
> >> extra copying. So why not just:
> >> 
> >>    type Octet is new Unsigned_8;
> >>    type Word is new Unsigned_16;
> >>    type Octet_Array is array (Positive range <>) of Octet;
> >> 
> >>    procedure Get_Little_Endian (Data : Octet_Array; Index : in out Integer;
> >>       Value : out Word) is -- No extra copying
> >>    begin
> >>       Value := Word (Data (Index)) + Word (Data (Index + 1)) * 256;
> >>       Index := Index + 2;
> >>    end Get_Little_Endian;
> >> 
> >> ...
> > 
> >      Don't you think this approach obscures what's going on, Dmitry,
> > thereby negating one of the design goals of Ada?
> 
> No. The Ada's design goal was to allow the programmer to describe the
> semantics the data types involved and to program in that terms.
> Representation clauses rather defeat that idea than support it. The number
> read from the wire must look and feel as a number rather than some messy
> record, which cannot be a numeric parameter of a generic, has no 'Image, no
> meaningful literals etc...

     I think I see the place where we have the greatest disagreement in
concept.  To me, in general, data coming "over a wire" are just a stream
of bits until we have interpreted them and found out what they mean.
(The primary, and maybe the only, exception would be a homogenous data
stream.  No interpretation is required.)  So for me, again in general,
there is no such idea as reading a number from such data.  As a result,
I need all sorts of ways of converting bit streams to various internal
data types.

> > Sure, most of us who
> > have bit-twiddled in the bad old days can figure out what's going on, or
> > at least convince ourselves that we've figured out what's going on, but
> > I much prefer the clarity of something like
> > 
> >    type Single_Precision is -- old IBM single-precision
> >       record
> >          Negative : Boolean;
> >          Characteristic : Seven_Bit_Integer;
> >          Mantissa : Twenty_Four_Bit_Fixed_Point;
> >       end record;
> > 
> >    A_Variable : Single_Precision;
> 
> And defining all arithmetic on it? Elementary functions including? I don't
> remember the IBM layout, but are you sure that you have got the order of
> fields right? What about the literals?

     If the a bit stream is interpreted as a target machine native
number, then I have to use two views into each variable of that numeric
type.  One view looks at it as a native number and the other view would
show its component structure.   All the number's operations and
elementary functions are available by using the native number view.

     These two views are a form of aliasing, which I don't like very
much at all.  This can be minimized through the use of conversion
functions, limiting the aliasing to the body of the functions.  There's
no execution penalty to this approach because the conversion functions
are easily inlined.

     At that requires a bit mor writing than your approach, Dmitry, but
that's o. k. with me.  The design of Ada was permitted to require
"extra" writing for the purpose of clarity of code.  If I'm willing to
write voluminous comments to document the source code, and I am, I don't
begrudge a few keystroke when writing code itself.

     I'm 99.97% sure that I have the IBM single-precision layout
correct, including the order, but it doesn't matter.  In practice I
would always use a representation specification.  I always use rep specs
when I'm defining a type whose bit layout (or encoding, for an
enumeration type) has been specified.  In the case of an enumeration
type I do that even if the specification is the LRM-defined one.  My
coding style is that a rep spec means that the layout or encoding has
been specified somewhere.  If it hasn't been, I'm pretty rigorous about
letting the compiler choose the representation.

> No, I would never do it this way. In a comparable case:
> 
>    http://www.dmitry-kazakov.de/ada/components.htm#IEEE_754
> 
> I read IEEE 754 representations into the native floating point rather than
> messing up with representation clauses, even if the machine is natively
> IEEE 754. I just don't care.
> 
> Granted, defining IEEE 754 as a record (Unchecked_Union?), denormalized
> numbers, NaN, +/-Inf, hidden mantissa bit, must be a HUGE fun! 

     I did it and it wasn't a big deal at all.

                        Charlie
-- 
[A certain TV newsreader] had a role to play: presenter of the Other
Side of the Argument, to whom fair-minded people were obligated to
pay heed, no matter what nonsense he spouted.
Charlie Pierce, Idiot America