Hi,
There's something I'm wondering about and I find it hard to find the answer.
Say you have a 16-bit number with decimal value:
57514
In binary, this is, as a human would write it:
1110000010101010
In Intel's little endian order this becomes:
1010101011100000
These bits, when represented in RAM, caches, ..., are, I guess, physically stored next to each other.
The question is: in what order are these bits physically laid out on RAM, and in the CPU caches? Same question for 32-bit, 64-bit integers, and floating point numbers.
It could be any of the following (mirroring still matters, e.g. if two numbers are stored next to each other...):
1110000010101010
1010101011100000
0101010100000111
0000011101010101
E.g. say some archeolisist in the far future would uncover a piece of RAM that was in the freezer all that time and look at it in a microscope that can somehow show the bit values, in what order would he see the bits compared to the numbers they represent?
Just a philosophical thing I'm wondering, nothing more
EDIT: removed parts about "hard disk", after all there it's file format dependent. But in RAM it's not, I'm talking about C code using primitive types like shorts, longs, floats, etc...
Endianness and physical bits
It sounds to me that your confusion here is mostly what endianness really is, what it does, and how binary integers are treated by a processor. Endianness is only a logical problem when you have to split a multi-byte integer into several distinct parts that occupy different memory addresses; different parts go to different addresses. So it doesn't make any sense to say that some integer has different binary layout in different endianness, because that is not what endianness is about.
You example with the integer 57514 is therefore incorrect, because it always has the binary representation 1110000010101010 no matter what the endianness is and no matter what the actual storage is. For example, your list of four different interpretations makes no sense; the low order bits for three of them are 1, implying an odd number, even though the value 57514 is even. Endianness is only about which eight bits go to the low and the high memory addresses when split into two parts for storage.
How the bits are physically stored depends on the medium of course, and there is a physical representation somewhere. But it is not relevant because no matter how, say, a hard drive actually stores the bits, it will read the bits correctly and present the correct sequence of bits in the correct order. It is not like, for example, if a hard drive stores the bits in some "left-to-right" order and the RAM stores it in some "right-to-left" order, that the hard drive and the RAM are then incompatible since they have different physical storage order. No matter how the hard drive stores a binary value, it always has a low-order bit and a high-order bit, and the low-order bit always goes to the low-order bit into the RAM. Similarily, and the low-order bit always goes into the low-order bit into the processor if you read from the RAM into a register.
If you want to know how exactly a specific type of storage works, then you can of course read up on the details, but based on what I get from reading your post between the lines, that isn't really what you want to know. As in your archeology question, this could vary entirely. Different manufacturers could very well have physically designed their chips differently. As long as the electrical specification of the memory chip is given, you can (basically) provide a memory address and it returns the bits stored at that address. How, exactly, that happens is not relevant and could vary greatly. Consider std::vector as a software example; it has a specific interface, but there are many different implementations of it but they all follow the common interface.
The physical storage on a hard drive is relevant only to the manufacturer of the hard drive itself. If you're not writing the firmware for the controller on the hard drive itself, you will never know, nor will you ever need to know. Once the drive has read the bits and sent them on the wire (the SATA, or the ATA for example), the bits are no longer dictated by the hard drive, but by the specification that dictates how data is transmitted on a SATA or ATA cable.
You example with the integer 57514 is therefore incorrect, because it always has the binary representation 1110000010101010 no matter what the endianness is and no matter what the actual storage is. For example, your list of four different interpretations makes no sense; the low order bits for three of them are 1, implying an odd number, even though the value 57514 is even. Endianness is only about which eight bits go to the low and the high memory addresses when split into two parts for storage.
How the bits are physically stored depends on the medium of course, and there is a physical representation somewhere. But it is not relevant because no matter how, say, a hard drive actually stores the bits, it will read the bits correctly and present the correct sequence of bits in the correct order. It is not like, for example, if a hard drive stores the bits in some "left-to-right" order and the RAM stores it in some "right-to-left" order, that the hard drive and the RAM are then incompatible since they have different physical storage order. No matter how the hard drive stores a binary value, it always has a low-order bit and a high-order bit, and the low-order bit always goes to the low-order bit into the RAM. Similarily, and the low-order bit always goes into the low-order bit into the processor if you read from the RAM into a register.
If you want to know how exactly a specific type of storage works, then you can of course read up on the details, but based on what I get from reading your post between the lines, that isn't really what you want to know. As in your archeology question, this could vary entirely. Different manufacturers could very well have physically designed their chips differently. As long as the electrical specification of the memory chip is given, you can (basically) provide a memory address and it returns the bits stored at that address. How, exactly, that happens is not relevant and could vary greatly. Consider std::vector as a software example; it has a specific interface, but there are many different implementations of it but they all follow the common interface.
The physical storage on a hard drive is relevant only to the manufacturer of the hard drive itself. If you're not writing the firmware for the controller on the hard drive itself, you will never know, nor will you ever need to know. Once the drive has read the bits and sent them on the wire (the SATA, or the ATA for example), the bits are no longer dictated by the hard drive, but by the specification that dictates how data is transmitted on a SATA or ATA cable.
Depends on whatever whoever designed the chip thought was more convenient. There is absolutely no relation between how the bits are stored and how software gets to see it.
Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.
It sounds to me that your confusion here is mostly what endianness really is, what it does, and how binary integers are treated by a processor.
I do know that quite well, at least better than you apparently think. But still an interesting reply though!
My question was actually mainly hardware related: you have a 16-bit integer created as a short in C++, on a typical x86 platform where a short is a 16-bit integer and the CPU is little endian.
Now you run that program and zoom in on your typical DDR3 RAM chip, looking at the bits of that RAM chip that happen to be used for said 16-bit number.
Physically, these bits are next to each other and have a linear order (at least I assume so, unless they put them in a different way on the chip, but I guess at least it's safe to assume the bits are near each other and have some sort of physical ordering).
The question is, from left to right (where left is the side addressed with a lower address), what's the electrical values of each bit?
As Bob said, how it is stored electronically may vary from MFG to MFG; they MIGHT write them from high-order to low-order for some optimization purpose, but as long as they read it out in the correct order, it doesn't matter. If you want details, you'll probably have to read how the specific MFG has decided to implement it.
My Gamedev Journal: 2D Game Making, the Easy Way
---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)
Little endian: Least significant byte first, then follow with the rest in that order.
Big endian: Most significant byte first, then follow with the rest in that order.
16 bit integer, two bytes. Say, 45F8h. Your number is composed of byte 1 (45h, most significant byte) and byte 2 (F8h, least significant byte).
LE: F8 45
BE: 45 F8
If you had a number like 45F8FF01h
LE: 01 FF F8 45
BE: 45 F8 FF 01
As far as I'm aware, in 8086 ISA (thats all the assembler I know) you did operate with LE in CPUs registers and in RAM. But it didn't mattered much since you'd read entire numbers (operating on pair of registers) so each number, no matter the ordering, was fetched correctly. You'd need to watch out while storing registers in the stack though, or if you operated on a single register that was part of a pair of registers that represented a number.
Big endian: Most significant byte first, then follow with the rest in that order.
16 bit integer, two bytes. Say, 45F8h. Your number is composed of byte 1 (45h, most significant byte) and byte 2 (F8h, least significant byte).
LE: F8 45
BE: 45 F8
If you had a number like 45F8FF01h
LE: 01 FF F8 45
BE: 45 F8 FF 01
As far as I'm aware, in 8086 ISA (thats all the assembler I know) you did operate with LE in CPUs registers and in RAM. But it didn't mattered much since you'd read entire numbers (operating on pair of registers) so each number, no matter the ordering, was fetched correctly. You'd need to watch out while storing registers in the stack though, or if you operated on a single register that was part of a pair of registers that represented a number.
"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"
My journals: dustArtemis ECS framework and Making a Terrain Generator
[quote name='Brother Bob' timestamp='1355691795' post='5011354']
It sounds to me that your confusion here is mostly what endianness really is, what it does, and how binary integers are treated by a processor.
I do know that quite well, at least better than you apparently think. But still an interesting reply though!
[/quote]
It just made me wonder when you asked about endianness and physical storage; they are not related at all.
My question was actually mainly hardware related: you have a 16-bit integer created as a short in C++, on a typical x86 platform where a short is a 16-bit integer and the CPU is little endian.
Now you run that program and zoom in on your typical DDR3 RAM chip, looking at the bits of that RAM chip that happen to be used for said 16-bit number.
That is entirely up to how the specific chips were manufactured.
Physically, these bits are next to each other and have a linear order (at least I assume so, unless they put them in a different way on the chip, but I guess at least it's safe to assume the bits are near each other and have some sort of physical ordering).
"Next to each other" implies that bits are physically stored on a line. That may or may not be the case. For what it's worth, the physical circuitry holding the individual bits of a byte can have any physical arrangement that the manufacturer decides is best for their design. Who knows, there may not even be individual bits at all, but four-state circuitry representing two bits, or something even more exotic.
The question is, from left to right (where left is the side addressed with a lower address), what's the electrical values of each bit?
There is no "left to right" jusy as there is no "next to each other"; it implies that there is bits are physically stored on a line which may or may not be the case.
You will have to look at the design of the individual chips to see how the charge storage circuitry is physically layed out on the die for a particular chip.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement