At 07:26 PM 8/7/00 +0100, Tom Hughes wrote:
> From /usr/include/endian.h on my linux box:
>
>#define __LITTLE_ENDIAN 1234
>#define __BIG_ENDIAN4321
>#define __PDP_ENDIAN3412
>
>Basically PDP or middle endian is low byte first within each word
>but high word first in the overall longword.
At 10:53 PM 8/7/00 +0200, Bart Lateur wrote:
>Right. Why you people don't call it "Intel" vs. "Motorola", like the
>rest of the civilised world, I don't know. ;-) See the TIFF spec, for
>example.
>
>Er, in case you were in any doubt: Motorola (from the 68k processors) is
>BigEndian, Intel (x86)
On Mon, 7 Aug 2000 13:52:09 -0400, John Porter wrote:
>Right, VAX is strictly little-endian.
>I.e. the address of a *word is the address of its least significant byte.
>(That's little-endian, isn't it?)
Right. Why you people don't call it "Intel" vs. "Motorola", like the
rest of the civilised w
In message <[EMAIL PROTECTED]>
Glenn Linderman <[EMAIL PROTECTED]> wrote:
> Tom Hughes wrote:
>
> > VAX is either big or little. I can't remember which off the top
> > of my head.
> >
> > You may be getting confused here with the middle-endian system
> > used by the PDP machines which g
> > VAX is either big or little. I can't remember which off the top
> > of my head.
Right, VAX is strictly little-endian.
I.e. the address of a *word is the address of its least significant byte.
(That's little-endian, isn't it?)
--
John Porter
Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Edwin Wiles <[EMAIL PROTECTED]> wrote:
>
> > Endianness:
> >
> > /d - default, whatever your system uses normally
> > /n - network
> > /b - big
> > /l - little
> > /v - vax
> >
> > (??vax is sufficiently different to require it's own?
In message <[EMAIL PROTECTED]>
Edwin Wiles <[EMAIL PROTECTED]> wrote:
> Endianness:
>
> /d - default, whatever your system uses normally
> /n - network
> /b - big
> /l - little
> /v - vax
>
> (??vax is sufficiently different to require it's own?? Or is this to do
> with bit order?)
VA
Edwin Wiles wrote:
> Without them, the programmer must calculate the required length of the reads
> themselves.
Good point. I now want them, rather than being ambivalent.
> >[ 'bar' => 'i', 'baz' => 'i', 'count' => 'i' ]
>
> It is my understanding that "=>" is an indication of a link in a
Glenn, et.al.
I'm going to be combining a number of different comments in here.
Glenn Linderman wrote:
> I was surprised by the read/write operations, but have no objection to them.
> New/get/set and the individual data member access functions are the critical
> pieces, as the I/O could be done
Bart Lateur wrote:
> On Wed, 02 Aug 2000 12:22:09 -0700, Glenn Linderman wrote:
>
> > [ 'bar' => 'integer32', 'baz' => 'integer32', 'count' => 'integer32' ]
> >
> > [ 'var1' => 'int32', 'var2' => 'int16', 'var3' => 'int8' ]
>
> That doesn't reconsider BigEndian vs. LittleEndian, AKA pack/unpack
On Wed, 02 Aug 2000 12:22:09 -0700, Glenn Linderman wrote:
> [ 'bar' => 'integer32', 'baz' => 'integer32', 'count' => 'integer32' ]
>
> [ 'var1' => 'int32', 'var2' => 'int16', 'var3' => 'int8' ]
That doesn't reconsider BigEndian vs. LittleEndian, AKA pack/unpack 'N'
vs. pack/unpack 'V'.
--
Edwin,
This writeup certainly is a great first draft for this RFC. I'll have to track down
those references.
I was surprised by the read/write operations, but have no objection to them.
New/get/set and the individual data member access functions are the critical pieces,
as the I/O could be done
> The existing pack and unpack methods are dependent upon a
> simple yet complex 'format' structure, which is often
>difficult to get right, and which carries no information
> regarding the associated variable names.
I know what you mean, but it reads like "black yet whi
13 matches
Mail list logo
