comp.lang.ada
 help / color / mirror / Atom feed
From: Mark Johnson <mark_h_johnson@raytheon.com>
Subject: Re: Is this a GNAT bug???
Date: Thu, 02 May 2002 16:55:28 -0500
Date: 2002-05-02T16:55:28-05:00	[thread overview]
Message-ID: <3CD1B5D0.9C81D65C@raytheon.com> (raw)
In-Reply-To: 3cd18c55.86305947@news.blueyonder.co.uk

Nick Roberts wrote:
> 
> I wasn't trying to show values as loaded into registers, Mark. I was
> trying to show the difference in the ways in which big-endian and
> little-endian machines store their integers in memory. The Bit?H/L
> rows were intended to show the bit numberings of the data as it would
> be numbered if loaded from memory into a register (8, 16, or 32-bit).
> 
I guess I look at the problem differently - I either...
 - care what order the bits and bytes are in memory OR
 - care what order the bits and bytes are in a register
I generally don't care what the register values look like in memory -
after all, I only manipulate them using registers. If I do a byte swap
at the interface to convert a 16 or 32 bit value from big to little
endian format, I get the appropriate value when loaded into a register.

I almost always care what format data is in memory when dealing with an
external interface - hence the emphasis on getting representation
clauses with bits and bytes correct in those cases. When the compiler
manipulates that data in registers, it hides the details from me.

> [snip]
> For those who may be wondering, Streams.Stream_Element'Size could of
> course be something other than 8, 16, or 32. But then on such a
> machine the issue of being big-endian or little-endian is irrelevant
> (as the machine will be neither).
> 
Not quite true. The PDP-10 was a big endian 36 bit machine (page 2-15,
PDP-10 System Reference Manual). The byte manipulation functions on that
system used bit zero as the most significant bit and allowed you to
extract "S" bits at an offset of "P" (actually 36-P). There were load
and deposit byte instructions w/ and w/o increment of the byte pointer.
You could easily manipulate a stream of 8 bit bytes (e.g., from mag
tape) but text was more often stored as five 7 bit bytes (one bit pad)
in each word.

I am not sure for other 36 bit machines what they used - I think Multics
(Honeywell DPS8/M) was also a big endian machine, but I couldn't find a
good reference at http://www.multicians.org/ to confirm that. Multics
stored text by the way as 9 bit bytes.

> [snip]
> Finally, I believe big-endian bit numbering conventionally starts from
> 1 (rather than 0), and I wanted to show this. (Of course, this is only
> a convention. I think it is widespread, but certainly not universal.
Sorry, the same example - the PDP-10 System Reference numbers bits in a
word from zero through 35. Actually, I think it depends more on the
original developer - were they a "C" or "Pascal" type of person :-).

  --Mark



  reply	other threads:[~2002-05-02 21:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-26 16:36 Is this a GNAT bug??? Robert Quinn
2002-04-26 17:48 ` Mark Johnson
2002-04-26 22:20   ` Robert Dewar
2002-04-29 15:45   ` Robert Quinn
2002-04-30  2:44     ` Robert Dewar
2002-04-30 14:15       ` Larry Kilgallen
2002-04-30 16:41       ` Robert Quinn
2002-04-30 18:20         ` tmoran
2002-05-01  1:31           ` Robert Quinn
2002-05-01 17:08             ` Ted Dennison
2002-05-02  1:55               ` Larry Kilgallen
2002-05-02 14:04                 ` Mark Johnson
2002-05-02 15:25                   ` Larry Kilgallen
2002-04-30 21:55         ` Mark Johnson
2002-05-01 22:59           ` Nick Roberts
2002-05-02 13:56             ` Mark Johnson
2002-05-02 20:19               ` Nick Roberts
2002-05-02 21:55                 ` Mark Johnson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-09-20 22:50 Is this a gnat bug? Waldek Hebisch
2003-09-20 23:09 ` Ludovic Brenta
2003-09-21  2:37 ` Waldek Hebisch
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox