• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Lode

Endianness and physical bits

6 posts in this topic

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... Edited by Lode
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[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.
[/quote]

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? Edited by Lode
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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. Edited by TheChubu
0

Share this post


Link to post
Share on other sites
[quote name='Lode' timestamp='1355693227' post='5011359']
[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.
[/quote]

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.

[quote name='Lode' timestamp='1355693227' post='5011359']
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.
[/quote]
That is entirely up to how the specific chips were manufactured.

[quote name='Lode' timestamp='1355693227' post='5011359']
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).
[/quote]
"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.

[quote name='Lode' timestamp='1355693227' post='5011359']
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?
[/quote]
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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0