The fact that left shift multiplies and right shift divides establishes
the (human) association most significant being left and least right.  This
is what was implied by my assertion that once it is in a register it is
all big endian.

When I reference a string in PL/I as '0000000000000010'B this is stored
in memory with the leftmost bit in the lowest location and proceeding from
there.
Strings are therefore stored in a Big endian fashion, provided you agree
to call the leftmost bit the most significant, and this is the generally
accepted view.  Strings can not be practically stored any other way, varying
strings, for example have a length prefix.

It was for this reason that when PL/I was ported to VAX, special builtin
functions were added to deal with the bit reversal.

You might say that you shouldn't alias, but people do, even in strongly
typed
languages like PL/I.

In my view, little endian was the wrong decision way back when, but you
can't
change that today and continuing the discussion is pointless and fruitless.

>-----Original Message-----
>From: briggs@encompasserve.org [mailto:briggs@encompasserve.org]
>Sent: Tuesday, November 25, 2003 5:53 AM
>To: Info-VAX@Mvb.Saic.Com
>Subject: Re: Backwards File Dump
>
>
>In article <3FC27847.375F8696@istop.com>, JF Mezei
><jfmezei.spamnot@istop.com> writes:
>> briggs@encompasserve.org wrote:
>>>     Registers do not generally even have an endian-ness.  In the absence
>>> of instructions to access individual bits or individual bytes within
>>> a register, there is no sense in which bits going to or coming from a
>>> register can be said to be "reversed".
>>
>> But consider compiler functionality such as shifting bits left
>or right. The
>> general assumption in higher level languages is that the value
>is stored in
>> big-endian. (shift left multiplies by 2)
>
>No.  Big endian and little endian have nothing to do with left and right.
>They have to do with first (low addressed) and last (high addressed)
>storage units when integers are stored in multiple storage units.
>
>Left shift in _HARDWARE_ on a little endian machine will multiply by 2.
>
>Left shift shifts bits toward positions of greater significance.  Always.
>Right shift shifts bits toward positions of lower significance.  Always.
>
>> Consider a longword (4 bytes) located at address 10. From the
>programmer's
>> point of view in a language higher up the food chain than assembler, this
>> number is seen as 4 bytes of 8 bits, with the byte at address 10
>being the
>> most significant, and the leftmost bit of that byte being the
>most significant.
>
>That's a big-endian assumption.  Low addressed = high order.
>
>Again, this has nothing to do with left and right.  There is no left
>and right in memory.
>
>> The compiler shields the programmer from most of those intricacies and
>> presents to the programmer a big endian view of memory, no
>matter what the
>> underlying machine is.
>
>No.  It does not.  It is possible to write C code to determine the
>endian-ness of the architecture you are running upon.  That's because
>C code permits aliasing.
>
>> And unless you are exchanging binary data with a
>> "foreign" machine, the compiler succeeds 100% in sheltering you from this
>> machine's endianness.
>
>To the extent that you refrain from aliasing your longwords as
>arrays of bytes, the compiler can indeed shield you.  And to the
>extent that your strongly typed language prevents you from aliasing,
>it does indeed shield you.  But it does not present a big-endian view.
>It presents no view at all.
>
>If you can't tell whether the high order bits in your longword are
>stored at higher or lower addresses, you can't tell whether the longword
>is big-endian or little-endian.  It is presented to the programmer as
>an abstract integer.
>
>Endian-ness has to do with aliasing.  It has nothing to do with the
>display order of bits in base 2 presentations of machine readable
>binary numbers.
>
>> However my feeling is that once you go into DUMP (or a memory dump), the
>> utility should not try to shelter you from the endianness and
>your present you
>> a real view of a file (or memory).
>
>In real life there is no such thing as left and right in memory.
>
>	John Briggs
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003

In article <CIEJLCMNHNNDLLOOGNJIMEJDIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:
> The fact that left shift multiplies and right shift divides establishes
> the (human) association most significant being left and least right.  This
> is what was implied by my assertion that once it is in a register it is
> all big endian.

That makes your notion of register endian-ness an illusion.  It sits
between your ears rather than inside the CPU cabinet.

> When I reference a string in PL/I as '0000000000000010'B this is stored
> in memory with the leftmost bit in the lowest location and proceeding from
> there.

Yep.  That's fine.  First = left in that presentation convention.

And it's a perfectly sensible convention.  But it's neither big-endian
nor little-endian.  It's a display convention.

> Strings are therefore stored in a Big endian fashion, provided you agree
> to call the leftmost bit the most significant, and this is the generally
> accepted view.

No.  It is not.  Bits within strings do not have significance.  They
have positions.  Bits within integers do not have positions.  They
have significance.

When you treat a bit string as an integer, you have essentially two
ways to map significance to position.  Big endian and little endian.

Note also that with respect to character strings, there are two obvious
choices for the first bit in the string:  The MSB of the first byte or
the LSB of the first byte.  On little-endian systems, implementing bit
strings on byte arrays, you will likely take the low order bit of the
first byte as the first bit in the string.  On big-endian systems,
implementing bit strings on byte arrays, you will likely take the high
order bit of the first byte as the first bit in the string.

It is interesting that you claim that the most signifant bit in a
VAX character string the least significant bit in the first byte of
that string.

> Strings can not be practically stored any other way, varying
> strings, for example have a length prefix.

So what you are saying is that, for strings, the first character
in the string goes in the first byte in memory order.  Yes, I agree.

But that convention is not what is meant by the term "big-endian".

	John Briggs

Tom Linden wrote:
> In my view, little endian was the wrong decision way back when, but you
> can't  change that today and continuing the discussion is pointless and fruitless.


Little endian has advantages though. For instance, if you pass a longword as
an argument that needs a word, the routine will still get its word and just
not look at the extra 2 bytes, and that is possible only in little endian
since the address given for the argument is that of the least significant byte.

It does cause some headaches when you try to figure out how the C compiler
will treat a bit field (will the first bit in the struct be considered most
significant or least significant), and that often requires you write a small
test program to figure it all.