Byte sex confusion

Byte sex confusion

[Steven O'Neill]

I have an interesting problem well known to anyone who has tried to
develop on multiple platforms.  I have binary data that was recorded on
a big-endian machine (SGI) which I am in need of reading on a
little-endian machine (Intel).  The current method involves using C
routines to fread the data into buffers and then casting the data into a
variety of Ada records.  

This is a dangerous practice (its not my code) but it works fine as long
as the layout of the records remain the same and the underlying data
formats are consistent.

What I'm looking for are ideas on how to access this data in an easy anc
consistent fashion on both architectures...  Any ideas?

Thanks,
Steve O'Neill

Re: Byte sex confusion

[Nick Roberts]

Steven O'Neill <oneills@top.monad.net> wrote in article
<33716475.43A9@top.monad.net>...
> I have an interesting problem well known to anyone who has tried to
> develop on multiple platforms.  I have binary data that was recorded on
> a big-endian machine (SGI) which I am in need of reading on a
> little-endian machine (Intel).  The current method involves using C
> routines to fread the data into buffers and then casting the data into a
> variety of Ada records.  
> 
> This is a dangerous practice (its not my code) but it works fine as long
> as the layout of the records remain the same and the underlying data
> formats are consistent.
> 
> What I'm looking for are ideas on how to access this data in an easy anc
> consistent fashion on both architectures...  Any ideas?


I'm currently fascinated by Intel's BSWAP instruction (little things please
little minds, I suppose :-). If you have package Machine_Code available,
maybe this one would solve your problem.

Incidentally, for those readers wondering, the 'sex' in the subject line
refers (I assume, anyway) to the old Intel "sign exchange" instruction,
which they were going to call SEX, but got cold feet just before
publication (and called it CBW/CWD instead - not the same!)

Nick.

Re: Byte sex confusion

[Robert Dewar]

Nick says

<<Incidentally, for those readers wondering, the 'sex' in the subject line
refers (I assume, anyway) to the old Intel "sign exchange" instruction,
which they were going to call SEX, but got cold feet just before
publication (and called it CBW/CWD instead - not the same!)>>

This is urban legend, it has no basis in fact whatsoever (it sure is
amazing how entertaining, but completely false, informatoin of this
kind is so easily spread).

This one is particularly mangled. First, surely the person who originally
made this up meant "sign extension", not "sign exchange" [the latter
phrase is (a) meaningless and (b) has no possible connection with the
instructions in equestion]. Second, sign extension has nothing to do
with endianness.

Re: Byte sex confusion

[Steve Sciance]

Motorola had SEX instruction for sign extend in 6809 chip.
They renamed it EXT for 68000.

In article <dewar.863177374@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Nick says
> 
> <<Incidentally, for those readers wondering, the 'sex' in the subject line
> refers (I assume, anyway) to the old Intel "sign exchange" instruction,
> which they were going to call SEX, but got cold feet just before
> publication (and called it CBW/CWD instead - not the same!)>>
> 
> This is urban legend, it has no basis in fact whatsoever (it sure is
> amazing how entertaining, but completely false, informatoin of this
> kind is so easily spread).
> 
> This one is particularly mangled. First, surely the person who originally
> made this up meant "sign extension", not "sign exchange" [the latter
> phrase is (a) meaningless and (b) has no possible connection with the
> instructions in equestion]. Second, sign extension has nothing to do
> with endianness.
> 
> 

Re: Byte sex confusion

[Roy Grimm]

Nick Roberts wrote:
> Incidentally, for those readers wondering, the 'sex' in the subject line
> refers (I assume, anyway) to the old Intel "sign exchange" instruction,
> which they were going to call SEX, but got cold feet just before
> publication (and called it CBW/CWD instead - not the same!)

The first machine I know of that had reference to a "SEX" instruction
was the PDP-11.  The engineers tried to slip the instruction through but
marketing nixed it at the last minute.  The Intel 8086 came out with a
"sign extend" instruction but the marketers made them use CBW (convert
byte to word) and CWDE (convert word to double word).  Amusingly, the
Intel 8048 (used as a keyboard controller) does not have a SEX
instruction but it does have ORL (logical or) and ANL (logical and). 
The Motorola 6809 actually has a SEX instruction. (I forget exactly what
it is a mnemonic for)  The processor went into some computer sold in the
UK.  The competitor in the states was the Apple II, and its processor
didn't have the SEX instruction.  There was some implied joke that had
to do with the name of the UK system and not being able to have sex with
an apple but the real context excapes me...

-- 
Voicing my own opinion, not speaking as a company representative...

Roy A. Grimm
Rockwell Collins Avionics
Cedar Rapids, Iowa
ragrimm@cca.rockwell.com

Re: Byte sex confusion

[Jeff Carter]

Steven O'Neill wrote:
> 
> I have an interesting problem well known to anyone who has tried to
> develop on multiple platforms.  I have binary data that was recorded on
> a big-endian machine (SGI) which I am in need of reading on a
> little-endian machine (Intel).  The current method involves using C
> routines to fread the data into buffers and then casting the data into a
> variety of Ada records.
> 
> This is a dangerous practice (its not my code) but it works fine as long
> as the layout of the records remain the same and the underlying data
> formats are consistent.
> 
> What I'm looking for are ideas on how to access this data in an easy anc
> consistent fashion on both architectures...  Any ideas?
> 
> Thanks,
> Steve O'Neill

A simple solution is to convert everything into a standard
representation, and have portable conversion routines to and from that
representation.

It is easy to:

Use Unchecked_Conversion to convert your types into a type in Interfaces
that is unsigned and the same size as your type.

Use "and" and Shift_Right to extract the bytes from
Interfaces.Unsigned_X in LSB to MSB order.

Use Shift_Left and "or" to combine these bytes back into an
Interfaces.Unsigned_X.

These operations allow you to easily and portably, entirely in Ada,
create a packed array of Interfaces.Unsigned_8 that can be encoded on
one machine, sent to another, and decoded on the other machine. In
either direction. With the same source code.

This works with GNAT (I've done it Intel-Sparc). It also worked with
another compiler, but it had a deficient version of Interfaces (only
declared Unsigned_32), so I had to do all manipulation using Unsigned_32
instead of a size-appropriate modular type with shift operations.
-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Byte sex confusion

[Robert Dewar]

Jeff Carter says

<<A simple solution is to convert everything into a standard
representation, and have portable conversion routines to and from that
representation.>>

Note that this approach risks stepping on a patent that is held by
the Mark Williams company. The validity of this patent has not been
established by litigation, but my understanding is that it has been
the basis of some significant negotiations.

This is one of many highly surprising patents in the software field.
Pity Greg Aharonian is not around, this is one area that he *does*
know something about :-)

Re: Byte sex confusion

[Oliver Kellogg]

Steven O'Neill wrote:

> A simple solution is to convert everything into a standard
> representation, and have portable conversion routines to and from that
> representation.

> [... proposed solution elided ...]

Or, if you are lucky enough to have both sides of the program under
your control, interface to the network-to-host/host-to-network
functions in the Berkeley-Unix socket library:

	htons() -- network to host short
	ntohs() -- host to network short
	htonl() -- network to host long
	ntohl() -- host to network long

I believe these functions are also included in the forthcoming POSIX
P1003.5c Ada binding standard.

--Oliver

Re: Byte sex confusion

[Matthew Heaney]

In article <33733B21.59E2B600@spam.innocon.com>, Jeff Carter
<carter@spam.innocon.com> wrote:


>A simple solution is to convert everything into a standard
>representation, and have portable conversion routines to and from that
>representation.
>
>It is easy to:
>
>Use Unchecked_Conversion to convert your types into a type in Interfaces
>that is unsigned and the same size as your type.
[snip]

Another way is to use Ada's built-in "change of representation" feature.  A
type and its derived type can have different representations, and type
converting (no Unchecked_Conversion required) between the two types
automatically converts the representation.  This won't automatically
byte-swap integers, though.

Remember that some compilers support the 'Bit_Order attribute too, so that
you can specify the layout of a record on a big-endian machine using a
little-endian bit ordering, and vice versa.  (Gee, I really wish GNAT
supported that attribute. :-)

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271