Little Endian -> Big Endian (Ada95 / GNAT)

Little Endian -> Big Endian (Ada95 / GNAT)

[James Amor]

Hi,

At present I am writing a tool to create a file which contains various
extracted ELF symbols. The output data structure, a list of unsigned
32's, is to be used as part of an image on a PowerPC target.

Problem: As it is compiled on Wintel the tool is producing an output
in little endian and PowerPC is big endian!

Question: How do I modify my code to write the output in big endian
format?

Thanks in advance for any help offerred,
James

Re: Little Endian -> Big Endian (Ada95 / GNAT)

[David C. Hoos]

"James Amor" <jamesamor@hotmail.com> wrote in message
news:bac31daa.0402250138.fc4ed92@posting.google.com...
> Hi,
>
> At present I am writing a tool to create a file which contains various
> extracted ELF symbols. The output data structure, a list of unsigned
> 32's, is to be used as part of an image on a PowerPC target.
>
> Problem: As it is compiled on Wintel the tool is producing an output
> in little endian and PowerPC is big endian!
>
> Question: How do I modify my code to write the output in big endian
> format?

If you use Stream IO to write the data, then you can take advantage of
the solution the GNAT folks created for Distributed Systems (Annex E
of the Ada Lanuage Reference Manual).

This solution is embodied in the glade supplement to gant.

For example, if you're using gant-3.15p, the corresponding glade can
be found at ftp://ftp.cs.nyu.edu/pub/gnat/3.15p/glade

Then, replace the file s-stratt.adb in your standard gnat distribution
with the one from the same version of glade, and re-compile and
rebuild the library files (.a), and you have what you want.  Now, as
long as your types are declared the same on both platforms (with no
representation clauses) you will have platform-independence.

I'm not sure why GNAT didn't do this from the beginning -- perhaps because
they didn't provide an implementation of the Distributed Systems Annex at
the beginning.  Also, there is a small performance penalty paid for
shuffling bits around to achieve platform independence.

Hope this helps.

Re: Little Endian -> Big Endian (Ada95 / GNAT)

[James Amor]

Thanks for that, I'll have a look into that at some point. In the
meantime I have implemented (some might say hacked) a conversion
utility to rearrange the layout of the output, it seems to work ok!

James


"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message news:<Cr0%b.13685$0k2.7465@bignews4.bellsouth.net>...
> "James Amor" <jamesamor@hotmail.com> wrote in message
> news:bac31daa.0402250138.fc4ed92@posting.google.com...
> > Hi,
> >
> > At present I am writing a tool to create a file which contains various
> > extracted ELF symbols. The output data structure, a list of unsigned
> > 32's, is to be used as part of an image on a PowerPC target.
> >
> > Problem: As it is compiled on Wintel the tool is producing an output
> > in little endian and PowerPC is big endian!
> >
> > Question: How do I modify my code to write the output in big endian
> > format?
> 
> If you use Stream IO to write the data, then you can take advantage of
> the solution the GNAT folks created for Distributed Systems (Annex E
> of the Ada Lanuage Reference Manual).
> 
> This solution is embodied in the glade supplement to gant.
> 
> For example, if you're using gant-3.15p, the corresponding glade can
> be found at ftp://ftp.cs.nyu.edu/pub/gnat/3.15p/glade
> 
> Then, replace the file s-stratt.adb in your standard gnat distribution
> with the one from the same version of glade, and re-compile and
> rebuild the library files (.a), and you have what you want.  Now, as
> long as your types are declared the same on both platforms (with no
> representation clauses) you will have platform-independence.
> 
> I'm not sure why GNAT didn't do this from the beginning -- perhaps because
> they didn't provide an implementation of the Distributed Systems Annex at
> the beginning.  Also, there is a small performance penalty paid for
> shuffling bits around to achieve platform independence.
> 
> Hope this helps.

Re: Little Endian -> Big Endian (Ada95 / GNAT)

[Simon Wright]

jamesamor@hotmail.com (James Amor) writes:

> At present I am writing a tool to create a file which contains various
> extracted ELF symbols. The output data structure, a list of unsigned
> 32's, is to be used as part of an image on a PowerPC target.

If you output source code in your language of choice (C for this part
of the job, even!) you could compile it with the target compiler.

> Problem: As it is compiled on Wintel the tool is producing an output
> in little endian and PowerPC is big endian!
> 
> Question: How do I modify my code to write the output in big endian
> format?

Roughly,

with Ada.Streams;
with Ada.Unchecked_Conversion;
with Interfaces;
with System;

function To_Big_Endian
  (N : Interfaces.Unsigned_32) return Interfaces.Unsigned_32 is
begin
   if System."=" (System.Default_Bit_Order, System.Low_Order_First) then
      declare
         subtype Bytes is Ada.Streams.Stream_Element_Array (1 .. 4);
         function To_Bytes is new Ada.Unchecked_Conversion
           (Interfaces.Unsigned_32, Bytes);
         function From_Bytes is new Ada.Unchecked_Conversion
           (Bytes, Interfaces.Unsigned_32);
         B : constant Bytes := To_Bytes (N);
      begin
         return From_Bytes ((1 => B (4),
                             2 => B (3),
                             3 => B (2),
                             4 => B (1)));
      end;
   else
      return N;
   end if;
end To_Big_Endian;

(compiled but not tested)

-- 
Simon Wright                               100% Ada, no bugs.

Re: Little Endian -> Big Endian (Ada95 / GNAT)

[Guillaume Foliard]

Hi,

On a x86 with GNAT, a slightly modified version would look like :

with Interfaces;
with System.Machine_Code; use System.Machine_Code;

function To_Big_Endian
  (N : Interfaces.Unsigned_32) return Interfaces.Unsigned_32 is
      Result : Integer;
begin
      Asm ("bswap %0",
           Inputs  => Integer'Asm_Input ("a", N),
           Outputs => Integer'Asm_Output ("=a", Result));
      return Result;
end To_Big_Endian;

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Joachim Schr�er]

A short question:

It's not so simple with floating point types, just swapping bytes, or is it?
One has to swap all the bits or?
Interfaces.IEEE_Float_32 has 1 bit sign, 23 bit mantissa and 8 bit exponent,
Interfaces.IEEE_Float_64 has 1 bit sign, 52 bit mantissa and 11 bit exponent
when I remember correctly.


    Achim

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Simon Wright]

"Joachim Schr�er" <joachim.schroeer@web.de> writes:

> A short question:
> 
> It's not so simple with floating point types, just swapping bytes,
> or is it?  One has to swap all the bits or?
> Interfaces.IEEE_Float_32 has 1 bit sign, 23 bit mantissa and 8 bit
> exponent, Interfaces.IEEE_Float_64 has 1 bit sign, 52 bit mantissa
> and 11 bit exponent when I remember correctly.

Swapping seems to work just fine here ... even though if you look at
GNAT's xdr support it is much more complicated.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[pburnand0-news]

Joachim Schrļæ½er wrote:

> A short question:
> 
> It's not so simple with floating point types, just swapping bytes, or is
> it? One has to swap all the bits or?
> Interfaces.IEEE_Float_32 has 1 bit sign, 23 bit mantissa and 8 bit
> exponent, Interfaces.IEEE_Float_64 has 1 bit sign, 52 bit mantissa and 11
> bit exponent when I remember correctly.
> 
> 
>     Achim

That's not easy because floats are really machine dependant.  That's not a 
simple endianess question.

The universal solution for this is to store your floating point number in 
ASCII in a string and then store the string.  That takes more place, but 
there is no portability problems since in every case, a float converted to 
a string always from left to right.  Then it's even possible to use the 
number using a different format or precision...

This way of doing is massively used in the database world...

Re: Little Endian -> Big Endian (Ada95 / GNAT),Whats with floating point types?

[David C. Hoos]

<pburnand0-news@yahoo.com> wrote in message news:4046b474_1@127.0.0.1...
> Joachim Schrļæ½er wrote:
>
> > A short question:
> >
> > It's not so simple with floating point types, just swapping bytes, or is
> > it? One has to swap all the bits or?
> > Interfaces.IEEE_Float_32 has 1 bit sign, 23 bit mantissa and 8 bit
> > exponent, Interfaces.IEEE_Float_64 has 1 bit sign, 52 bit mantissa and
11
> > bit exponent when I remember correctly.
> >
> >
> >     Achim
>
> That's not easy because floats are really machine dependant.  That's not a
> simple endianess question.
>
> The universal solution for this is to store your floating point number in
> ASCII in a string and then store the string.  That takes more place, but
> there is no portability problems since in every case, a float converted to
> a string always from left to right.  Then it's even possible to use the
> number using a different format or precision...
>
There's certainly more than one "universal solution."  One supplied by the
compiler manufacturer is likely to be a good one, viz.:

If you use Stream IO to write the data, then you can take advantage of
the solution the GNAT folks created for Distributed Systems (Annex E
of the Ada Language Reference Manual).

This solution is embodied in the glade supplement to gnat.

For example, if you're using gnat-3.15p, the corresponding glade can
be found at ftp://ftp.cs.nyu.edu/pub/gnat/3.15p/glade

Then, replace the file s-stratt.adb in your standard gnat distribution
with the one from the same version of glade, and re-compile and
rebuild the library files (.a), and you have what you want.  Now, as
long as your types are declared the same on both platforms (with no
representation clauses) you will have platform-independence.

I'm not sure why GNAT didn't do this from the beginning -- perhaps because
they didn't provide an implementation of the Distributed Systems Annex at
the beginning.  Also, there is a small performance penalty paid for
shuffling bits around to achieve platform independence.

Hope this helps.

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Marius Amado Alves]

> ... Also, there is a small performance penalty paid for
> shuffling bits around to achieve platform independence.

But surely less than converting to an ASCII image and back. (I suspect that, 
contrary to what has been indicated, the significant performance loss in the 
ASCII solution is of time, not space.)

But the ASCII solution is a nice, safe one if you don't have the time or the 
will or the possibility to learn to use or just to use the compiler's. 
Remember Ada has the wonderful 'Image and 'Value attributes which take care 
of the conversion for you.

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Warren W. Gay VE3WWG]

Marius Amado Alves wrote:

>>... Also, there is a small performance penalty paid for
>>shuffling bits around to achieve platform independence.
> 
> 
> But surely less than converting to an ASCII image and back. (I suspect that, 
> contrary to what has been indicated, the significant performance loss in the 
> ASCII solution is of time, not space.)
> 
> But the ASCII solution is a nice, safe one if you don't have the time or the 
> will or the possibility to learn to use or just to use the compiler's. 
> Remember Ada has the wonderful 'Image and 'Value attributes which take care 
> of the conversion for you.

I'm no floating point numeric expert, but by converting to
a standard, say IEEE floating point format, you can still
represent a machine dependant number with repeating decimal
places in a IEEE floating point format (I assume).  Mind
you, this depends heavily upon the differences between the
two formats.

By converting to ASCII, you lose that, unless you encode
the fact that the last digit repeats, in some way (like
the number "1.33333*", where * might represent "repeat").

If they don't do that, then the number has been rounded,
and thus does not quite represent the original value any
more ;-)   (at a minimum, it is less faithful than it
could be).

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> you can still represent a machine dependant number with
 > repeating decimal places

There are no such numbers (on any common hardware). Whether
it's IEEE, VAX, or any of a variety of other forms of hardware
floating point representation, all of them can be written
exactly as a finite length decimal number (not counting the
bit patterns which do not represent numbers, of course).

> If they don't do that, then the number has been rounded,
> and thus does not quite represent the original value any
> more ;-)   (at a minimum, it is less faithful than it
> could be).

The OP was converting out of and back into the same representation.
Given that, there are a pair of published algorithms which ensure
completely faithful translation. One algoritm takes a decimal
representation and converts it to the binary representation closest
in value (coin flip for ties) and the other finds a shortest decimal
representation for a binary number which will convert back exactly to
that binary.

The algorithms were both published in Proceedings of the ACM SIGPLAN
'90 Conference on Programming Language Design and Implementation.

     G. L. Steele Jr. and J. L. White.
     How to Print Floating Point Numbers Accurately.

     W. D. Clinger
     How to Read Floating Point Numbers Accurately

You can find free implementations of these algorithms in C at
<http://www.netlib.org/fp/>.

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:

> Warren W. Gay VE3WWG wrote:
>> you can still represent a machine dependant number with
>  > repeating decimal places
> 
> There are no such numbers (on any common hardware). 

Because I am not in a position here and now to
say "here is one", all I can do is say "I _think_ you're
incorrect about this". I seem to recall one or more
machine formats that keep one bit of state that says
this is a repeating digit (perhaps I am thinking of
a FPU register, but I do know that I have seen
it somewhere).

> Whether
> it's IEEE, VAX, or any of a variety of other forms of hardware
> floating point representation, all of them can be written
> exactly as a finite length decimal number (not counting the
> bit patterns which do not represent numbers, of course).

So lacking any representation sources at the moment, are you
saying that there is absolutely no bit that indicates that
a digit repeats?  I am not sure that you are wrong - but I
seem to recall differently.  Perhaps, someone can provide
the relevant details.

>> If they don't do that, then the number has been rounded,
>> and thus does not quite represent the original value any
>> more ;-)   (at a minimum, it is less faithful than it
>> could be).
> 
> The OP was converting out of and back into the same representation.
> Given that, there are a pair of published algorithms which ensure
> completely faithful translation. 

And one such piece of information might be that the digit
repeats (1 bit, unless a group repeats).

> One algoritm takes a decimal
> representation and converts it to the binary representation closest
> in value (coin flip for ties) and the other finds a shortest decimal
> representation for a binary number which will convert back exactly to
> that binary.

None of that is new to me ;-)

> The algorithms were both published in Proceedings of the ACM SIGPLAN
> '90 Conference on Programming Language Design and Implementation.
> 
>     G. L. Steele Jr. and J. L. White.
>     How to Print Floating Point Numbers Accurately.
> 
>     W. D. Clinger
>     How to Read Floating Point Numbers Accurately
> 
> You can find free implementations of these algorithms in C at
> <http://www.netlib.org/fp/>.

Can you point me/us to an online IEEE format description? I'd
like to check my memory for parity errors ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Warren W. Gay VE3WWG]

I am going to reply to my own post here, since after
reading and posting, I decided to satisfy my
curiosity and ...

Warren W. Gay VE3WWG wrote:

> Hyman Rosen wrote:
> 
>> Warren W. Gay VE3WWG wrote:
>>
>>> you can still represent a machine dependant number with
>>
>>  > repeating decimal places
>>
>> There are no such numbers (on any common hardware). 
> 
> Because I am not in a position here and now to
> say "here is one", all I can do is say "I _think_ you're
> incorrect about this". I seem to recall one or more
> machine formats that keep one bit of state that says
> this is a repeating digit (perhaps I am thinking of
> a FPU register, but I do know that I have seen
> it somewhere).

Clearly the IEEE format does not include any concept of
a repeating bit. I have to wonder where I saw this now,
and can only guess that I saw it as part of a FPU
state bit or something.

>> Whether
>> it's IEEE, VAX, or any of a variety of other forms of hardware
>> floating point representation, all of them can be written
>> exactly as a finite length decimal number (not counting the
>> bit patterns which do not represent numbers, of course).
> 
> So lacking any representation sources at the moment, are you
> saying that there is absolutely no bit that indicates that
> a digit repeats?  I am not sure that you are wrong - but I
> seem to recall differently.  Perhaps, someone can provide
> the relevant details.

I'll save everyone the trouble (thanks Google - I should have
done this first). One source is:

http://www.csit.fsu.edu/~burkardt/papers/ieee.html

There is clearly no allowance for any "repeating bit".

...
>> The algorithms were both published in Proceedings of the ACM SIGPLAN
>> '90 Conference on Programming Language Design and Implementation.
>>
>>     G. L. Steele Jr. and J. L. White.
>>     How to Print Floating Point Numbers Accurately.
>>
>>     W. D. Clinger
>>     How to Read Floating Point Numbers Accurately
>>
>> You can find free implementations of these algorithms in C at
>> <http://www.netlib.org/fp/>.
> 
> Can you point me/us to an online IEEE format description? I'd
> like to check my memory for parity errors ;-)

No need now.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[pburnand0-news]

Warren W. Gay VE3WWG wrote:

> Marius Amado Alves wrote:
> 
>>>... Also, there is a small performance penalty paid for
>>>shuffling bits around to achieve platform independence.
>> 
>> 
>> But surely less than converting to an ASCII image and back. (I suspect
>> that, contrary to what has been indicated, the significant performance
>> loss in the ASCII solution is of time, not space.)
>> 
>> But the ASCII solution is a nice, safe one if you don't have the time or
>> the will or the possibility to learn to use or just to use the
>> compiler's. Remember Ada has the wonderful 'Image and 'Value attributes
>> which take care of the conversion for you.
> 
> I'm no floating point numeric expert, but by converting to
> a standard, say IEEE floating point format, you can still
> represent a machine dependant number with repeating decimal
> places in a IEEE floating point format (I assume).  Mind
> you, this depends heavily upon the differences between the
> two formats.

Even if there is a standard format, using binary format, there is always the 
problem of the byteorder and such...

Using ASCII is cool, because a number is always read from left to right...
So you can write a floating point number in Ada on Linux and read it in a C 
program on Windows to store it in a double or a float.  All combinations 
are possible...


> By converting to ASCII, you lose that, unless you encode
> the fact that the last digit repeats, in some way (like
> the number "1.33333*", where * might represent "repeat").

There are always losses.  If you want to keep the number as exact as 
possible, you should use your Ada packages in a way to print the maximal 
number of decimals.  You should always be able to control the format of the 
output.

So there should be no numer so short as "1.33333", even with the lowest 
precision format...


> If they don't do that, then the number has been rounded,
> and thus does not quite represent the original value any
> more ;-)   (at a minimum, it is less faithful than it
> could be).

The floating point numbers are always rounded even in an FPU.  No software, 
no hardware can handle an infinite number of digits...

Doing exactly the same calculation on different computer systems can even 
give largely different results.
Let's take an example:
You need to calculate
1.0000000009789847 ** 1.000000087437987e+18
If you have a large enough precision, you should find a quite large number.
If you use a low precision FPU or format, the very same calculation becomes
1.000000e+00 ** 1.000000e+18 which gives 1.0e+00...

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Warren W. Gay VE3WWG]

pburnand0-news@yahoo.com wrote:
> Warren W. Gay VE3WWG wrote:
>>Marius Amado Alves wrote:
>>>>... Also, there is a small performance penalty paid for
>>>>shuffling bits around to achieve platform independence.
>>>But surely less than converting to an ASCII image and back. (I suspect
>>>that, contrary to what has been indicated, the significant performance
>>>loss in the ASCII solution is of time, not space.)
>>>
>>>But the ASCII solution is a nice, safe one if you don't have the time or
>>>the will or the possibility to learn to use or just to use the
>>>compiler's. Remember Ada has the wonderful 'Image and 'Value attributes
>>>which take care of the conversion for you.
>>
>>I'm no floating point numeric expert, but by converting to
>>a standard, say IEEE floating point format, you can still
>>represent a machine dependant number with repeating decimal
>>places in a IEEE floating point format (I assume).  Mind
>>you, this depends heavily upon the differences between the
>>two formats.
> 
> Even if there is a standard format, using binary format, there is always the 
> problem of the byteorder and such...

Of course, but that was not my point.

> Using ASCII is cool, because a number is always read from left to right...
> So you can write a floating point number in Ada on Linux and read it in a C 
> program on Windows to store it in a double or a float.  All combinations 
> are possible...

ASCII is also more expensive in time and space. Not much
of a consequence when you transmitting a few numbers,
but is much different if you are transmitting millions
of them. It makes to plan for the worst case in some
of these situations.

>>By converting to ASCII, you lose that, unless you encode
>>the fact that the last digit repeats, in some way (like
>>the number "1.33333*", where * might represent "repeat").
> 
> There are always losses.  

Agreed.

> If you want to keep the number as exact as 
> possible, you should use your Ada packages in a way to print the maximal 
> number of decimals.  You should always be able to control the format of the 
> output.
> 
> So there should be no numer so short as "1.33333", even with the lowest 
> precision format...

I think you missed my point (repeating decimals).

>>If they don't do that, then the number has been rounded,
>>and thus does not quite represent the original value any
>>more ;-)   (at a minimum, it is less faithful than it
>>could be).
> 
> The floating point numbers are always rounded even in an FPU.  No software, 
> no hardware can handle an infinite number of digits...

Of course. But my point was that some hardware does keep
a bit (IIRC), that indicates that this is a repeating
digit (binary/decimal).  The point of this is to reduce
error.

> Doing exactly the same calculation on different computer systems can even 
> give largely different results.

No kidding.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[Warren W. Gay VE3WWG]

I'll follow up to my other post as well...

Warren W. Gay VE3WWG wrote:

> pburnand0-news@yahoo.com wrote:
>> Warren W. Gay VE3WWG wrote:
>>> Marius Amado Alves wrote:
>>>
>>>>> ... Also, there is a small performance penalty paid for
>>>>> shuffling bits around to achieve platform independence.
>>>>
>>>> But surely less than converting to an ASCII image and back. (I suspect
>>>> that, contrary to what has been indicated, the significant performance
>>>> loss in the ASCII solution is of time, not space.)
>>>>
>>>> But the ASCII solution is a nice, safe one if you don't have the 
>>>> time or
>>>> the will or the possibility to learn to use or just to use the
>>>> compiler's. Remember Ada has the wonderful 'Image and 'Value attributes
>>>> which take care of the conversion for you.
>>>
>>> I'm no floating point numeric expert, but by converting to
>>> a standard, say IEEE floating point format, you can still
>>> represent a machine dependant number with repeating decimal
>>> places in a IEEE floating point format (I assume).  Mind
>>> you, this depends heavily upon the differences between the
>>> two formats.
...
>> The floating point numbers are always rounded even in an FPU.  No 
>> software, no hardware can handle an infinite number of digits...
> 
> Of course. But my point was that some hardware does keep
> a bit (IIRC), that indicates that this is a repeating
> digit (binary/decimal).  The point of this is to reduce
> error.

According to :

   http://www.csit.fsu.edu/~burkardt/papers/ieee.html

there is no concept of a "repeating bit", as I vaguely
remembered it. In fact, its possible that 1 bit cannot do
this anyway, because you can have a group of digits
repeat (to represent this, requires more than 1 bit).

I can only guess that I recall some state information from
a FPU design somewhere.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types?

[pburnand0-news]

Marius Amado Alves wrote:

>> ... Also, there is a small performance penalty paid for
>> shuffling bits around to achieve platform independence.
> 
> But surely less than converting to an ASCII image and back. (I suspect
> that, contrary to what has been indicated, the significant performance
> loss in the ASCII solution is of time, not space.)

It could be, but it depends largely of the numbers to represent...
If you represent the number "1.0", it requires 4 bytes (with string 
terminator).
If you have the number "1.33333333333333333333333e+05", it could need 30 or 
more characters to store...

About the time penalty, it's usually not a problem.  If someone wants to 
pass numbers between different environnments, it's usually necessary to 
write them to a file, to send them through a network connection, or 
something else.  In such a case, the time needed to convert the number is 
negligible regarding to the time needed by IO operations...