Re: Cohen's paper on byte order

From: Mok-Kong Shen (mok-kong.shen@t-online.de)
Date: 04/16/03 

From: Mok-Kong Shen <mok-kong.shen@t-online.de>
Date: Wed, 16 Apr 2003 18:51:29 +0200

Eugene Starokoltsev wrote:
>
> Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> > Eugene Starokoltsev wrote:
> > >
> > > Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> > > > "Douglas A. Gwyn" wrote:
> > > > >
> > > > > Mok-Kong Shen wrote:
> > > > > > http://whatis.techtarget.com/definition/0,,sid9_gci211659,00.html
> > > > > > Note that within both big-endian and little-endian byte
> > > > > > orders, the bits within each byte are big-endian. That is,
> > > > > > there is no attempt to be big- or little-endian about the
> > > > > > entire bit stream represented by a given number of stored
> > > > > > bytes. For example, whether hexadecimal 4F is put in
> > > > > > storage first or last with other bytes in a given storage
> > > > > > address range, the bit order within the byte will be:
> > > > > > 01001111
> > > > > > It is possible to be big-endian or little-endian about
> > > > > > the bit order, but CPUs and programs are almost always
> > > > > > designed for a big-endian bit order. In data transmission,
> > > > > > however, it is possible to have either bit order.
> > > > >
> > > > > That is wrong (except about the possibility of either bit
> > > > > order in data transmission), and it even contradicts
> > > > > itself: the bits cannot simultaneously be (big-endian)
> > > > > and (neither big- nor little-endian).
> > > > >
> > > > > Hexadecimal notation such as "4F" is understood to be
> > > > > written with the most significant nybble to the left,
> > > > > consistent with decimal notation used throughout most
> > > > > of the planet. However, that is neither-endian, it's
> > > > > just representing a particular integral value (79 as
> > > > > represented in the usual "Arabic" decimal notation).
> > > > > To be "endian" there would have to be an assumed
> > > > > *sequence* imposed on the bits, and there is no
> > > > > particular reason to think that the bit sequence would
> > > > > be left-to-right in the expression 01001111; that
> > > > > could equally well be read right-to-left, just as
> > > > > bytes are within multibyte words in little-endian
> > > > > documentation. Indeed in some cultures text is read
> > > > > from right to left (or even from top to bottom). With
> > > > > no specification for bit sequencing, one simply doesn't
> > > > > know what sequence is meant.
> > > >
> > > > These physical bits must somehow be stored in a
> > > > sequential order, right? What the page said is
> > >
> > > Wrong. It's possible to store them in parallel (on a punched tape, for
> > > example).
> >
> > O.k. But do you give one specific ordering to them
> > when you interpret the group of bits thus parallelly
> > ordered or do you consider them unordered in the sense
> > of a mathematical set? Once you give them an order
> > in the group of 8, the whole bunch of bits on the
> > paper tape is ordered is ordered, isn't it?
>
> Sometimes. For 8-bit punched type there is 40320 different full
> orders of bits. The current discussion is about what order is the
> best. Even if you choose to order bit holes for single character on a
> punched type from the left to the right there is umbiguity still -
> depending on which end of the type is in your handes and which side of
> the type you look on.

That is not my point. You want the 8 bits collectively
to have some meaning, do you? So you have to choose
(in any way you prefer) a 'fixed' way of determining
which bit has significance 2^i. Once that is done,
there exists 'an' ordering of the bits. (It may not be
from left to right or the reverse, but can be 'any'
according to 'your' choice.) Now the tape has a
beginning and so the bytes are ordered and within a
byte the bits are ordered (by you). So the ensemble
of bits are ordered. Isn't that clear?

>
> > > > that 4F is stored as 01001111 (with the first 0
> > > > bit located nearer the lower end of the whole
> > > > memory, i.e. where byte or word 0 is). The endian
> > >
> > > I don't know what is a 'lower end' of a RAM chips. You speak about a
> > > physical storage, don't you?
> > >
> > > BTW meaning of your term 'physical bit' is unclear. How it differ from
> > > an 'abstract bit'?
> >
> > If you identify the abstract bits one to one with
> > the physical bits and implement the AES, i.e. without
> > even taken the 'notion' of octect into consideration,
> > then this would be no problem of the kind being debated
> > in this thread. Otherwise what I meant by an abstract
> > bit is what is depicted in Fig. 2 of the document and
> > people have discussed in this thread the diverse
> > manners in which these are mapped to the bits of an
> > octet. Is that clearer?
>
> Sorry, I've asked you about the difference but I don't see the answer
> in your post. Could you please give a _precise_ definition of termes
> you use? Without such definition it's hard to understand what do you
> mean. I disagree with your post but I can't dispruve unclear
> statements.

I oversaw that you asked about the 'lower end of
RAM chips'. Sorry. By 'lower end' I mean that end that
has the lowest address, namely 0. Any addressible
memory has such a lower end and also a higher end
(namely with the biggest possible address), right?

To the issue of 'abstract' and 'physical', consider
an algorithm given in a book on numerical algorithms.
That's abstract, isn't it? If there is an integer
variable K, I consider it to be 'abstract'. When
one writes a C program with such a variable K, then
on execution of the code there will be a physical
memory space representing that variable. That piece
of memory is the physical counterpart of the abstract
variable. Have I explained sufficiently?

>
> > > > issue is in the 'interpretation' of a sequence of
> > > > bytes as a numerical value (integer) only. If a
> > > > sequence of ,say, 10000 stored bytes are 8-bit
> > > > ASCII, then they will be interpreted character by
> > > > charecter sequentially, in the 'same' way by both
> > > > kinds of machines. The same will occur when this
> > > > sequence of bytes are to be trasmitted over and
> > > > stored. (How does one transport a text file?) In
> > > > crypto we are dealing with 'texts', hence no
> > > > problem should occur.
> > >
> > > I don't understand what do you want to say.
> >
> > A sequence of two bytes (both 8 bit units), when
> > considered as an 'integer' are interpreted on
> > the two architectures differently, i.e. considered
> > to be integers of unequal value. But the issue
> > of big-endian vs little-endian doesn't 'extend'
> > down to the level of bits inside one 'single' byte.
>
> It does extend to the livel inside one 'single' byte when we map this
> byte into bit stream. I know systems with different mappings.
>
> > See also the URL cited. Therefore the bytes in AES
>
> If the dictionary says that it is wrong. But it does not says that.
>
> > (being not collectively considered to be a big integer)
> > are to be considered individually. (This is what
> > I meant by character by character.)
> >
> > >
> > > > Anyway could you cite materials negating what is
> > > > said in the first quoted URL, namely the bits
> > > > in a byte are stored in big-endian order (that is,
> > > > name a hardware that does differently)?
> > >
> > > "almost always designed" - the article. The author of the dictionary
> > > have not wrote "always designed".
> >
> > Fine, then I like to know the name of one. If this
> > is only for a single machine designed e.g. in a
> > lab of university for experimentation purpose and
> > never used in practice, then we could entirely
> > ignore that for the purposes of this thread, right?
>
> Well, Jam Byte-Code Player. Search for it on http://www.altera.com
> It is used for practical tasks by a lot of engineers working with
> modern FPGAs.
>
> This is a piece of source code of it (sources are freely available):
>
> for (i = 0; i < count; i++)
> {
> tdo_bit = jbi_jtag_io(
> (i == count - 1) ? 1 : 0,
> tdi[i >> 3] & (1 << (i & 7)) ? 1 : 0,
> (tdo != NULL) ? 1 : 0);
> ...
>
> Hope it is clear that the bit stream is packed into bytes LSB-first.

I haven't carefully studied the above, but I believe
you. On the other hand, in my more recent arguments
I tried to make it 'independent' of whether in the
physical storage it is LSB-first or LSB-last, namely
I employed the fact that in 'writing' a binary number
on a piece of paper it is the common convention that
the rightmost bit is least-significant and compared
that with Fig. 2 of the document (i.e. I don't care
how the hardware 'order' the bits to realize the
integer value that constitutes the byte/octet). See
my recent follow-up to Douglas Gwyn. (Your comments
would be appreciated in case I am wrong.)

M. K. Shen

Relevant Pages

  • Re: both specifying now, Khalid and Hamza pined the recent tents in search of current notion
    ... equally squeeze Hakeem and Annie's protestant draper. ... rain insights. ... Gawd, I'll project the character. ... it will apparently guide the memory. ...
    (sci.crypt)
  • Re: Dynamic Disassembler (determine main() location at runtime)
    ... The current dead space seems to be 0x00 and 0xCC on ... Windows 2000 allocates Virtual Memory on 64KB boundaries for the ... may see more dead space with a new BYTE fill character. ... I don't see why you would care if there is a jump stub for main or not; ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Read from a file
    ... > I having a problem reading all characters from a file. ... the memory buffer that you want to contain the data read from the file. ... Then, when you want to print that value, it's a single character you ... want to print instead of a string. ...
    (comp.lang.c)
  • Re: Decoding strategy
    ... Does File Stream caches contents of file in memory? ... FileStream does buffer, which is in a sense a kind of caching. ... beginning of character, or maybe end of "previous" character? ...
    (microsoft.public.dotnet.languages.csharp)