Re: Cohen's paper on byte order

From: Brian Gladman (brg@gladman.plus.com)
Date: 03/30/03 

From: "Brian Gladman" <brg@gladman.plus.com>
Date: Sun, 30 Mar 2003 17:56:30 +0100

"John E. Hadstate" <nospam@null.nil> wrote in message
news:3e87075e$1_2@news.vic.com...
>
> "Brian Gladman" <brg@gladman.plus.com> wrote in message
> news:LDBha.1201$uO4.102116@wards.force9.net...
> >
> > In my view there is no approach to bit naming within bytes that is best
> > irrespective of the context of use.
> >
> I offer an alternative point of view. When the byte is used numerically,
it
> only makes sense to number the bits from 0 to 7 with 0 being the least
> significant bit. When the byte is used non-numerically, it doesn't really
> matter how the bits are numbered. Hence, given that there is one case
where
> it does matter, and none that demands a contrary interpretation, the right
> choice seems fairly obvious.

But the whole point here is that when a byte is used to represent a number,
we don't need to enumerate the bits in order to identify them.

All we do in this case to identify a specific bit is to say 'the bit that
represents 1', ' the bit that represents 2' etc (here I assume only for
simplicity that the byte represents an integer in the range 0..255).

It does not then matter what labels anyone might attach to the bits since we
have not used any labels to identify them. Hence it is precisely the numeric
case where it doesn't matter how the bits are numbered, not the other way
round as you suggest.

But when bits represent non-numeric entities we cannot naturally use numeric
significance as a means of identification unless we artificially impose this
concept onto the problem. And imposing unnecessary concepts onto problems
is a dangerous and error prone process that almost always creates many more
problems than it solves.

> The same argument extends to any chunk size greater than 8 bits. Common
> sense then suggests that if the least significant bit is numbered 0 and if
> you have any plans to process k-bit-size chunks where k is variable, you
> ought to consider bit 0 to be at the lowest numbered address, if for no
> reason other than it makes the bookkeeping and address computations
simpler.

The issue is not which bit address is lowest or highest since my guess is
that most people accept that a bit sequence in which bits are numered 0 to N
should be divided into larger units so that:

unit_number = floor[bit_number_in_sequence / unit_size]
bit_number_in_unit = bit_number_in_sequence % unit_size

The problem comes when you want to associate numeric values with these bits
(and units) since you then have to say whether the significance of a
particular bit (or unit) increases or decreases with increasing bit (or
unit) number.

And if you want to use numeric significance inside a unit to identify a
specific bit, why stop there - the logic of using this approach should
surely extend to the whole bit sequence. And the consequence of this step is
that we end up imposing numeric semantics on all sorts of problems where
numbers play no part.

> The same argument extends to any chunk size greater than 8 bits. Common
> sense then suggests that if the least significant bit is numbered 0 and if
> you have any plans to process k-bit-size chunks where k is variable, you
> ought to consider bit 0 to be at the lowest numbered address, if for no
> reason other than it makes the bookkeeping and address computations
simpler.

Associating low addresses with low numeric significance, as you do here, is
a 'little endian' view of the world. There is nothing wrong with this
provided that you realise that others will hold a different 'big endian'
view of the world.

> SHA-1, which started this argument, is specified with big endian words,
> though it purports to process bits serially. Therefore, it is twistedly
> consistent to say that 0x80 puts a bit in the least-significant bit
position
> of the end-of-bit marker if the previous byte was fully utilized.

This is a common issue that we just have to learn to accomodate. It soon
becomes second nature if you do any amount of implementation work.

  Brian Gladman

Relevant Pages

  • Re: Read the UFPD taser incident report and see if it rings true...
    ... Nobody suppress once, cause genuinely, then link no matter how the ... husband in the matrix. ... tightens in conjunction with the sequence. ...
    (rec.arts.poems)
  • Re: liitle endian
    ... it's guaranteed for it not to matter. ... identically on Sparc (big endian) and x86 boxes. ... I wonder the nature of your guarantee; ... unsigned int convert4{ ...
    (comp.lang.c)
  • Re: gfortran and "Type/rank mismatch"
    ... The "in this subroutine" bit doesn't matter. ... One is in the interface body, and one is outside of it. ... about whether it has to have its own scope). ... And if it is a C routine, then you want the sequence attribute ...
    (comp.lang.fortran)
  • Re: TreeTop help?
    ... Just as order of def's in a class doesn't matter, ... the success of one item in a sequence is final. ... sequence will fail. ... you might need to use lookahead ...
    (comp.lang.ruby)
  • Re: The Usual Heinlein Thing
    ... : Objection: not yet demonstrated for the court. ... demonstrate his largess in this matter, ... sequence: ... My mistake - you're starting with x equal to zero for the first term ...
    (rec.arts.sf.written)