Re: Cohen's paper on byte order

From: Mok-Kong Shen (mok-kong.shen_at_t-online.de)
Date: 04/27/03


Date: Sun, 27 Apr 2003 11:16:36 +0200


"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > http://whatis.techtarget.com/definition/0,,sid9_gci211659,00.html
> > 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.
>
> It has already been pointed out that that is wrong.

What is then the 'right' situation? The opposite?
(I am not aware of any reference supporting that.)
If it is indeed the opposite case, then we could,
based on that fact, 'correspondingly' choose a
'reference' hardware, couldn't we?

Note that what I proposed isn't any magical way
of 'eliminating' the difficulty. It doesn't reduce
the conversion work that would otherwise be needed
to null. In fact, the data transfer issue (due to
different formats written by different architecture)
can be dealt with in two different ways:

(a) Provide information of how the data has been
written. Using the notation I employed in a previous
post, this would be (X, x) and further the word size
U. Now a recipient with an arbitrary different (Y, y)
and word size W knows how to do the proper conversion
such that he can read in the file to do further
processing on his machine in the usual way there.
(This conversion work can of course also be done by
the sender for the benefit of the recipient, if he
knows the constellation of the recipient.)

(b) Adopt a common convention, e.g. employing (B, b)
as the 'reference' hardware and generate a file
for that (i.e. 'assuming' the recipient has (B, b)).
Compared to (a), no additional information is provided.
As said in a previous post, the word size plays no
role in this case. Now the recipient with an arbitrary
(Y, y) and word size W knows how to do the proper
conversion such that he can read in the file to do
further processing on his machine in the usual way
there.

Comparing the two, one sees that the matter is, as
I said, analogous to accepting the convention that
one always posts in English to the group. If I don't
know English, I still have to find a translator
to make the stuffs readable for me. But hopefully,
the convention has been chosen in such a way that
it is convenient for the majority.

I think that there is also an aesthetic reason for
preferring (B, b) as the 'reference' hardware, for
that effectively means that a block of 128 bits on
the physical medium is a mirror image of what is
depicted in Fig. 2.

M. K. Shen



Relevant Pages

  • RE: SendObject (send an unique query to each of a list of recipien
    ... Problem could be that you may need to set up a reference to the DAO object ... So if your query name is: ... eMail subject is: Data from Alison ... (data to be sent to the recipient). ...
    (microsoft.public.access.modulesdaovba)
  • Re: Controlling Outlook 2003 with excel
    ... ' requires a reference to the Microsoft Outlook 8.0 Object Library ... Set olMailItem = OLF.Items.Add ' creates a new e-mail message ...
    (microsoft.public.excel.programming)
  • Re: Carbon Copies in Email Merge
    ... I am not a programmer either and all that I know about visual basic has been ... learned by reference to the Visual Basic Help file and trial and error. ... Dim myccrecipient as Recipient ...
    (microsoft.public.word.mailmerge.fields)
  • RE: SendObject (send an unique query to each of a list of recipients)
    ... Sorry - forgot to poit out that you have to create a reference to the ... outlook object model - in the Access VBA IDE go to Tools references and then ... Each recipient must have have thier attachment, ... Table A. I need the query that filters by the same unique identifier as the ...
    (microsoft.public.access.modulesdaovba)