Floating point numbers and endian ness??

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?

Regards, s.subbarayan

Reply to
ssubbarayan
Loading thread data ...

Op Fri, 25 Apr 2008 13:56:36 +0200 schreef ssubbarayan :

By dealing with that on the application level. Most programming languages and CPU's allow you to split the binary representation of the number into octects (bytes) and to transfer them in any order.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

ssubbarayan schrieb:

As far as I know the recommended way is to split the float-number into exponent and mantissa and transfer these using the native endianess.

For the C-language there is a function to do the decomposition defined in math.h I think. I don't remember it's name because I never had a reason to call it though.

Nils

Reply to
Nils

They work by defining the format of the data they are sending and encoding / decoding appropriately.

Using ASN.1 BER encoding is one way, but simply defining the floating point format and byte order will work. Another option is conversion to a decimal floating point string.

--
Thad
Reply to
Thad Smith

In the days of hundreds different floating point representations and the only means of communication between computers from different manufacturers was the 1/2 inch ANSI labeled tape, the floating point values were usually simply converted to ASCII (or EBCDIC) characters.

You may loose one or two bits of precession, this was not an issue at least for double precession.

While IEEE 754 simplified things a lot, the ASCII numeric transfer is still a viable option, especially if all partners in a communication systems are not well informed about endianess and bit representation issues.

Paul

Reply to
Paul Keinanen

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.

Rick

Reply to
rickman

Other than common memory are there any transfer mechanisms that son't use a byte or smaller as their organization across a communications channel?

Robert

** Posted from
formatting link
**
Reply to
Robert Adsett

Op Sat, 26 Apr 2008 08:32:42 +0200 schreef Paul Keinanen :

formatting link

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

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. 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.

Reply to
rickman

How do you have a byte oriented protocol w/o using byte accesses?

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 from
formatting link
**
Reply to
Robert Adsett

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.

Reply to
rickman

Of course, that's what this discussion has been about. Transferring data between processors(*).

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.

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
formatting link
**
Reply to
Robert Adsett

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);

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.

Reply to
Hans-Bernhard Bröker

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.

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
formatting link
**
Reply to
Robert Adsett

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 to
Paul Keinanen

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 to
Paul Keinanen

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
 Click to see the full signature
Reply to
Grant Edwards

[...]

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.

No. The above code doesn't even know what the endianness of the processor is, so it obviously can't match it to anything.

It doesn't. It only requires frexp() and some use of the macros in .

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 to
Hans-Bernhard Bröker

Didn't National do something similar with the 32000 as well? Or am I mis-remembering the introductory material I saw?

Robert

** Posted from
formatting link
**
Reply to
Robert Adsett

fwrite(&myByte, 1, 1, file); still looks likw byte access to me.

Agreed, never said otherwise.

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.

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.

That would be called endianess.

And here is where we disagree. That's too narrow a definition as far as I'm concerned.

Robert

** Posted from
formatting link
**
Reply to
Robert Adsett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.