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
Okay, here's my first attempt at an RFC, contributing to the community,
and dredging back up my design experience after being forced to hack for
8+ years. I'm not completely familiar with POD format, so I've probably
made mistakes. I'm also not a full-blown perl or C guru, so I've
probably made
14 matches
Mail list logo
