On Apr 28, 10:47 am, Robert Adsett <s...@aeolusdevelopment.com> wrote:> In article <4eb60be1-7337-48f9-9ee4- > a09b0cd6b...@m44g2000hsc.googlegroups.com>, rickman says... > > > > > On Apr 26, 8:07 pm, Robert Adsett <s...@aeolusdevelopment.com> wrote: > > > In article <cc92c027-c9c8-4404-b8b4- > > > a79564908...@l42g2000hsc.googlegroups.com>, rickman says... > > > > > On Apr 25, 7:56 am, ssubbarayan <ssu...@gmail.com> wrote: > > > > > Hi, > > > > > I was going through wikipedia about endians.I got the below > > > > > description with respect to floating point numbers: > > > > > "On some machines, while integers were represented in little-endian > > > > > form, floating-point numbers were represented in big-endian form. [3] > > > > > Because there are many floating formats, and a lack of a standard > > > > > "network" representation, no standard for transferring floating point > > > > > values has been made. This means that floating point data written on > > > > > one machine may not be readable on another, and this is the case even > > > > > if both use IEEE 754 floating point arithmetic since the endian-ness > > > > > of the memory representation is not part of the IEEE specification" > > > > > > Why is it so?How do people who need to work with floating point math > > > > > manage when their application involves communication between two cpus > > > > > of different endians? > > > > > Are you aware that the "endianess" of a processor only matters when it > > > > is accessing larger quantities using smaller transfers, e.g. reading a > > > > 32 bit word one byte at a time. If you are accessing words, you don't > > > > care how the processor would access it as bytes, because that is not > > > > happening. So if you transmit the words as words and not bytes, you > > > > won't care about the endiannss of the processors. > > > > Other than common memory are there any transfer mechanisms that son't > > > use a byte or smaller as their organization across a communications > > > channel? > > > 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. > > How do you have a byte oriented protocol w/o using byte accesses? > > > Read the full word and break it into bytes > > yourself. Then send the bytes in an order agreed to as part of the > > protocol. If the protocol doesn't specify byte order, then you are > > not using the right protocol. If you are depending on the machine or > > the compiler to decide what order the bytes are, then you are not > > doing a good job of programming. > > Absolutely. But endianess does matter across the wire (and it may show > up on the CPU side as well). And when receiving do the reverse taking > care of the endianess on the wire. > > Robert > ** Posted fromhttp://www.teranews.com**When you say, "taking care of the endianness on the wire", you are talking about the protocol. Anytime you have two processors talking, you need to have a protocol. The point is that endianess is only an issue when accessing shared memory and even then only when accessing larger data as bytes. Any other time the order of the bytes or bits or anything else must be explicitly spelled out as the processors don't have a preference.
Floating point numbers and endian ness??
Started by ●April 25, 2008
Reply by ●April 28, 20082008-04-28
Reply by ●April 28, 20082008-04-28
In article <e7bac5d4-1cbe-4bfb-93d7-890d61d96213 @x41g2000hsb.googlegroups.com>, rickman says...> On Apr 28, 10:47 am, Robert Adsett <s...@aeolusdevelopment.com> wrote: > > In article <4eb60be1-7337-48f9-9ee4- > > a09b0cd6b...@m44g2000hsc.googlegroups.com>, rickman says... > > > > > > > > > On Apr 26, 8:07 pm, Robert Adsett <s...@aeolusdevelopment.com> wrote: > > > > In article <cc92c027-c9c8-4404-b8b4- > > > > a79564908...@l42g2000hsc.googlegroups.com>, rickman says... > > > > Other than common memory are there any transfer mechanisms that son't > > > > use a byte or smaller as their organization across a communications > > > > channel? > > > > > 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. > > > > How do you have a byte oriented protocol w/o using byte accesses? > > > > > Read the full word and break it into bytes > > > yourself. Then send the bytes in an order agreed to as part of the > > > protocol. If the protocol doesn't specify byte order, then you are > > > not using the right protocol. If you are depending on the machine or > > > the compiler to decide what order the bytes are, then you are not > > > doing a good job of programming. > > > > Absolutely. But endianess does matter across the wire (and it may show > > up on the CPU side as well). And when receiving do the reverse taking > > care of the endianess on the wire. > > When you say, "taking care of the endianness on the wire", you are > talking about the protocol. Anytime you have two processors talking, > you need to have a protocol.Of course, that's what this discussion has been about. Transferring data between processors(*).> The point is that endianess is only an > issue when accessing shared memory and even then only when accessing > larger data as bytes.And when transferring data across a serial protocol (sometimes we even get down to worrying about bit order) the order obviously matters as it does when transferring by file. This even though the data is often avaialable from the communications channel in chunks larger than bytes. Oh and since the original question was about floating point, it's very likely the size of the data of the OP requires multiple access to load and endianness pops up again.> Any other time the order of the bytes or bits > or anything else must be explicitly spelled out as the processors > don't have a preference.Sure they do. Some processors (notably 8bit) only acccess a single size but any processor with a native size larger than a byte that allows byte addressability shows a definite preference. It certainly shows up everytime I write/use a communications protocol. Now if the processors at either end happen to share endianess than it can be conveniently ignored, but that way lies perdition. You seem to be taking a rather narrower view of endianess and we have ended up talking at cross purposes. Robert * The same issues arise transferring off processor to some peripherals as well. ** 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 wireNo. 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.
Reply by ●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 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 ●April 29, 20082008-04-29
On Mon, 28 Apr 2008 06:22:03 -0700 (PDT), rickman <gnuarm@gmail.com> wrote:>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 ●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 ...
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 ●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
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 **
