On 2008-04-30, Paul Keinanen <keinanen@sci.fi> wrote:
>>IIRC, 32-bit values on the PDP-11 were traditionally handled
>>that way: the word order was different than the byte order
>>within the words.
>
> While the PDP-11 was little endian, the 32 bit operand for MUL, DIV
> and ASHC instructions had the most significant part in R0 (or R2 or
> R4) and the least significant 16 bit value in R1 (or R3 or R5), so in
> a sense the "wrong" way around. However, no 32 move instructions
> existed, so you had to move R0 and R1 with two separate MOV
> instructions from/to memory, so it was up to the compiler or assembler
> programmer into which order the registers were loaded in memory.
Right, and my foggy recollection was that the convention was to
store the most significant word at <addr> and the least
significant word at <addr+2>. I wouldn't be surprised if I've
conflated the 32-bit integer layout with the (odd, IMO)
floating point layout you described.
--
Grant Edwards grante Yow! I'm changing the
at CHANNEL ... But all I get
visi.com is commercials for "RONCO
MIRACLE BAMBOO STEAMERS"!
Reply by Paul Keinanen●April 30, 20082008-04-30
On Tue, 29 Apr 2008 13:09:56 -0500, Grant Edwards <grante@visi.com>
wrote:
>On 2008-04-29, Paul Keinanen <keinanen@sci.fi> wrote:
>> On Tue, 29 Apr 2008 00:07:01 -0400, Robert Adsett
>><sub2@aeolusdevelopment.com> wrote:
>>
>>
>>>I vaguely remember seeing a protocol that exhibited both little and big
>>>endian elements but that may simply be "an undigested piece of meat".
>>
>> I have seen Modbus implementations, in which the 16 bit registers are
>> (by definition) big endian, but when trying to represent 32 bit
>> integers or 32 bit floating point values, the least significant part
>> is in the lower register.
>
>IIRC, 32-bit values on the PDP-11 were traditionally handled
>that way: the word order was different than the byte order
>within the words.
While the PDP-11 was little endian, the 32 bit operand for MUL, DIV
and ASHC instructions had the most significant part in R0 (or R2 or
R4) and the least significant 16 bit value in R1 (or R3 or R5), so in
a sense the "wrong" way around. However, no 32 move instructions
existed, so you had to move R0 and R1 with two separate MOV
instructions from/to memory, so it was up to the compiler or assembler
programmer into which order the registers were loaded in memory.
However, the PDP-11/VAX floating point format looks strange in memory.
The first 16 bit word contained the sign, exponent and the most
significant part of mantissa and the following word(s) contained the
less significant part(s) of the mantissa. In the first 16 bit word,
the sign was at the leftmost portion, followed by the 8 bit exponent
and 7 bit of the mantissa at the right end.
When storing a 32 bit float in memory and viewing it by sequential
byte addresses, the first byte contained the last bit of exponent, the
7 most significant part of mantissa. The second byte contained the
sign and 7 most significant part of exponent. The third byte contained
the least significant bits of the mantissa and the 4th byte the middle
bits from the mantissa.
Paul
Reply by Robert Adsett●April 29, 20082008-04-29
In article <fv7uk8$1j6$00$1@news.t-online.com>, Hans-Bernhard Br�ker
says...
> Robert Adsett wrote:
> > In article <fv5m05$jqj$03$1@news.t-online.com>, Hans-Bernhard Br�ker
> > says...
> >> Robert Adsett wrote:
>
> >>> How do you have a byte oriented protocol w/o using byte accesses?
>
> [...]
>
> >> you use something like
> >>
> >> myByte = myInt;
> >> fwrite(&myByte, 1, 1, file);
> >> myByte = myInt >> 8;
> >> fwrite(&myByte, 1, 1, file);
>
> > Looks like byte access to me.
>
> Looks like you're letting prejudice block your way to understanding, to me.
fwrite(&myByte, 1, 1, file); still looks likw byte access to me.
> There is no byte inside myInt being accessed here. There's not even a
> computation of the address of such a byte.
Agreed, never said otherwise.
> > I agree, this is what whould be done. I don't agree that this
> > eliminates endianess. It matches the endianess of the processor to the
> > endianess of the file/transport mechanism.
>
> No. The above code doesn't even know what the endianness of the
> processor is, so it obviously can't match it to anything.
No, but it does know the endianess of the file format. It's a technique
to match the unknown endianess of the processor to the known endianess
of the file format.
> > Also it's unlikely to work with a floating point number. To break it up
> > is likely to require either ASCII or detailed format information
> > including endianess.
>
> It doesn't. It only requires frexp() and some use of the macros in
> <float.h>.
I thought of that as well. That does still leave you with a floating
point number although its more limited range may be of significant help.
> > You still have to know the endianess of the wire transmission.
>
> No. You have to know which byte of a larger integer value goes where in
> the transmitted data.
That would be called endianess.
> It's when there's multiple addresses are accessed
> in a single shot, without you getting control what goes where that
> you're experiencing endianness.
And here is where we disagree. That's too narrow a definition as far as
I'm concerned.
Robert
** Posted from http://www.teranews.com **
Reply by Robert Adsett●April 29, 20082008-04-29
In article <VOKdnUHNT7zp-YrVnZ2dnUVZ_vzinZ2d@visi>, Grant Edwards
says...
> On 2008-04-29, Paul Keinanen <keinanen@sci.fi> wrote:
> > On Tue, 29 Apr 2008 00:07:01 -0400, Robert Adsett
> ><sub2@aeolusdevelopment.com> wrote:
> >
> >
> >>I vaguely remember seeing a protocol that exhibited both little and big
> >>endian elements but that may simply be "an undigested piece of meat".
> >
> > I have seen Modbus implementations, in which the 16 bit registers are
> > (by definition) big endian, but when trying to represent 32 bit
> > integers or 32 bit floating point values, the least significant part
> > is in the lower register.
>
> IIRC, 32-bit values on the PDP-11 were traditionally handled
> that way: the word order was different than the byte order
> within the words.
Didn't National do something similar with the 32000 as well? Or am I
mis-remembering the introductory material I saw?
Robert
** Posted from http://www.teranews.com **
Reply by ●April 29, 20082008-04-29
Robert Adsett wrote:
> In article <fv5m05$jqj$03$1@news.t-online.com>, Hans-Bernhard Br�ker
> says...
>> Robert Adsett wrote:
>>> How do you have a byte oriented protocol w/o using byte accesses?
[...]
>> you use something like
>>
>> myByte = myInt;
>> fwrite(&myByte, 1, 1, file);
>> myByte = myInt >> 8;
>> fwrite(&myByte, 1, 1, file);
> Looks like byte access to me.
Looks like you're letting prejudice block your way to understanding, to me.
There is no byte inside myInt being accessed here. There's not even a
computation of the address of such a byte.
> I agree, this is what whould be done. I don't agree that this
> eliminates endianess. It matches the endianess of the processor to the
> endianess of the file/transport mechanism.
No. The above code doesn't even know what the endianness of the
processor is, so it obviously can't match it to anything.
> Also it's unlikely to work with a floating point number. To break it up
> is likely to require either ASCII or detailed format information
> including endianess.
It doesn't. It only requires frexp() and some use of the macros in
<float.h>.
> You still have to know the endianess of the wire transmission.
No. You have to know which byte of a larger integer value goes where in
the transmitted data. It's when there's multiple addresses are accessed
in a single shot, without you getting control what goes where that
you're experiencing endianness.
Reply by Grant Edwards●April 29, 20082008-04-29
On 2008-04-29, Paul Keinanen <keinanen@sci.fi> wrote:
> On Tue, 29 Apr 2008 00:07:01 -0400, Robert Adsett
><sub2@aeolusdevelopment.com> wrote:
>
>
>>I vaguely remember seeing a protocol that exhibited both little and big
>>endian elements but that may simply be "an undigested piece of meat".
>
> I have seen Modbus implementations, in which the 16 bit registers are
> (by definition) big endian, but when trying to represent 32 bit
> integers or 32 bit floating point values, the least significant part
> is in the lower register.
IIRC, 32-bit values on the PDP-11 were traditionally handled
that way: the word order was different than the byte order
within the words.
--
Grant Edwards grante Yow! I want to dress you
at up as TALLULAH BANKHEAD and
visi.com cover you with VASELINE and
WHEAT THINS ...
>What comms was the OP using? Regardless, endianess is still not an
>issue with byte oriented protocols as long as you don't use byte
>memory accesses.
I have written a protocol for a PLC by Alfa Laval, in which you had to
reverse the bit order in a register (not just byte swap).
My initial assumption was that they had wired the UART data pins the
wrong way around, but since the protocol otherwise looked like a
sensible serial line protocol, this could not be the case.
Paul
Reply by Paul Keinanen●April 29, 20082008-04-29
On Tue, 29 Apr 2008 00:07:01 -0400, Robert Adsett
<sub2@aeolusdevelopment.com> wrote:
>I vaguely remember seeing a protocol that exhibited both little and big
>endian elements but that may simply be "an undigested piece of meat".
I have seen Modbus implementations, in which the 16 bit registers are
(by definition) big endian, but when trying to represent 32 bit
integers or 32 bit floating point values, the least significant part
is in the lower register.
Paul
Reply by Robert Adsett●April 29, 20082008-04-29
In article <fv5m05$jqj$03$1@news.t-online.com>, Hans-Bernhard Br�ker
says...
> Robert Adsett wrote:
>
> > How do you have a byte oriented protocol w/o using byte accesses?
>
> By splitting larger-than-byte values into bytes by _value_, rather than
> by pointer voodoo. E.g. instead of
>
> fwrite(&myInt, sizeof(int), 1, file); // don't do this!
>
> you use something like
>
> myByte = myInt;
> fwrite(&myByte, 1, 1, file);
> myByte = myInt >> 8;
> fwrite(&myByte, 1, 1, file);
Looks like byte access to me.
I agree, this is what whould be done. I don't agree that this
eliminates endianess. It matches the endianess of the processor to the
endianess of the file/transport mechanism.
Also it's unlikely to work with a floating point number. To break it up
is likely to require either ASCII or detailed format information
including endianess.
> > Absolutely. But endianess does matter across the wire
>
> No. What matters is that the definition of what goes over the wire is
> written such that you don't even have to know what endianness is.
You still have to know the endianess of the wire transmission.
Endianess as strictly a processor property strikes me as a very narrow
definition. File formats and transmission protocol defintions also
exhibit endianess as do some I/O peripherals.
I vaguely remember seeing a protocol that exhibited both little and big
endian elements but that may simply be "an undigested piece of meat".
Robert
** Posted from http://www.teranews.com **
Reply by ●April 28, 20082008-04-28
Robert Adsett wrote:
> How do you have a byte oriented protocol w/o using byte accesses?
By splitting larger-than-byte values into bytes by _value_, rather than
by pointer voodoo. E.g. instead of
fwrite(&myInt, sizeof(int), 1, file); // don't do this!
you use something like
myByte = myInt;
fwrite(&myByte, 1, 1, file);
myByte = myInt >> 8;
fwrite(&myByte, 1, 1, file);
> Absolutely. But endianess does matter across the wire
No. What matters is that the definition of what goes over the wire is
written such that you don't even have to know what endianness is.