[EROS-Arch] number key endianness

[Karp, Alan]

We faced the endian question when designing e-speak.  E-speak from Beta 3.0
onward adopts network byte order.  That means communicating machines must do
the conversion even if they both use the same, but not network byte order,
endianness.

I took a different tack with E-speak through Beta 2.2.  It is based on the
observation that there is an asymmetry in every communication.  One party,
the Listener, waits to be contacted; another, the Initiator, makes contact.
That being the case, I designed a protocol to avoid unnecessary translation.


The first message sent by the Initiator was 4 bytes that encoded its byte
order, integer length, and character encoding.  (I only needed 8 bits, but I
left room for growth.)  The first reply from the Listener was its 4 bytes.
The rule was "Initiator makes right".  In other words, the Initiator was
responsible for any necessary translations.  The Listener could choose to do
the translation by sending the 4 byte code sent by the Initiator.  I found
that being able to rely on the endianness being known at connect time
simplified the rest of the code.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
 

> -----Original Message-----
> From: Charles Landau [mailto:clandau@macslab.com]
> Sent: Monday, February 26, 2001 9:14 PM
> To: Jonathan S. Shapiro
> Cc: eros-arch@eros-os.org
> Subject: Re: [EROS-Arch] number key endianness
> 
> 
> "Jonathan S. Shapiro" wrote:
> 
> > I believe that if you look you'll see that it returns a 
> 3-word struct.
> > Isn't this the same?
> 
> It does return three words. The documentation is wrong. I can 
> fix that.
> 
> We could document that it returns three words, with the low 
> order word first
> as now. On a big endian machine, you'd have to remember that the words
> aren't in the order you'd like for forming bigger numbers (64 
> or 96 bits).
> This will make a difference to the user and kernel when 
> dealing with window
> keys, which I assume will (when implemented) be able to 
> specify offsets as
> 64 bit numbers.
> 
> Or, we could document that it returns the high order word 
> first on a big
> endian architecture. I think this would be equally awkward 
> for window keys,
> since the low-order 64 bits of the 96-bit number would start 
> on the first
> word for little endian, but on the second word for big endian.
> 
> In other words: the endianness of the bytes within a word is 
> that of the
> native architecture; what should be the endianness of the 
> words within the
> 3-word structure?
> 
> > Charles Landau wrote:
> > >
> > > The semantics of the Number key are sensitive to the 
> endianness (big or
> > > little) of the system. The OC_Node_WriteNumber operation 
> writes three
> > > 32-bit integers, and the documentation specifies the order of
> > > significance. The OC_Number_Value operation reads 12 
> bytes of data, and
> > > the documentation says it returns the least significant 
> bytes first.
> > >
> > > I believe the problem would go away if the 
> OC_Number_Value operation
> > > returned three 32-bit integers instead.
> 
>