OSDev.org

After a few months of OS devving, I've gotten more used to reading numbers in hex than in decimal. In my debugging output, I always have used the format 0x1234ABCD (with leading '0x' and capital letters), and sometimes just 1234ABCD. I use all caps mostly because it looks more consistent; more like a number. But I've seen many instances where lower case is used (like SHA1 in git), as well as different conventions for denoting that it's hexadecimal.

What is the general consensus on what display looks more aesthetic?

Are there any other forms that are used?

And what about outputting in little-endian format instead of big-endian, for easy cooperation with real binary?

e.g.
0x12345678
becomes
0x87654321

and you count (by 5s, for brevity):
0x0
0x5
0xA
0xF
0x11
0x61
0xB1
etc.

I'm just assuming that this is a minor enough thing not to start a flamewar, but I've been wrong before.

I guess I'm a little strange then...

I like to use 0x1234ABCD in C and ASM except for when using interrupts for which I'll use 1234ABDh. I have no idea why, but I feel it makes it look tidier.

For instructions like MOV and ADD etc, I'll use longer hex because it usually has long operands. Whereas INT (whenever I use it in my OS) I seem to use the suffix "h" because I never use a higher interrupt than 256, which keeps interrupt instructions to a smaller (although only by 1 character) size within the file.

Also, I hate to see code that isn't formatted the same as how I write my code. Whenever my computer science teacher does a code review, I always get commendations for neat, tidy and consistent code and I hate troubleshooting somebody else's code because it just doesn't look right. Call me what you will, I just like my code to be uniform.

Cheers,
James.

I've seen it several ways:

0x12AB
0x12ab
$12AB
$12ab
12ABh
12abh
12AB
12ab

I've listed them more or less in order of preference. I currently always use the first way since it's relatively universal, but back when I very first started programming (z80 ASM) I used either the third or fifth, randomly switching between the two, sometimes even in the same function.

0x1234ABCD in code, but I've noticed that in documentation the 1234ABCDh format seems more common, so that's what I've been using in the wiki.

NickJohnson wrote:And what about outputting in little-endian format instead of big-endian, for easy cooperation with real binary?

e.g.
0x12345678
becomes
0x87654321

and you count (by 5s, for brevity):
0x0
0x5
0xA
0xF
0x11
0x61
0xB1
etc.

Um, regarding little-endian representation: the number 0x12345678 is represented in memory by the bytes: 0x78 0x56 0x34 0x12, which may conceivably be output as 0x78563412, but not 0x87654321

and... 0xF+0x5=0x14...

madeofstaples wrote: Um, regarding little-endian representation: the number 0x12345678 is represented in memory by the bytes: 0x78 0x56 0x34 0x12, which may conceivably be output as 0x78563412, but not 0x87654321

and... 0xF+0x5=0x14...

But that is assuming that the bytes are a quantum representation of data (which they are in computers). However, little endian means that the lowest digit is first. If you are dealing with base 256 (byte by byte), then it would translate like: 120, 101, 67, 33 (a.k.a. 0x78, 0x56, 0x34, 0x12). However, I'm talking about base 16, so it's 0x87654321. If it were base 2, it would be: 00011110011010100010110001001000, which seems like it would be 0x1E6A2C48, but is actually equivalent to 0x87654321 if both are little-endian order. The reason it's weird is that you and the assembler both use big-endian arabic notation within the bytes, but little endian order outside the bytes. This is actually true little endian *hex* - screws with your mind, don't it? Perhaps that's why people hate dealing with little endian stuff in computing: it's both wrong and internally inconsistent to do it in hex.

And that was a complete addition fail.

NickJohnson wrote:But that is assuming that the bytes are a quantum representation of data (which they are in computers). However, little endian means that the lowest digit is first. If you are dealing with base 256 (byte by byte), then it would translate like: 120, 101, 67, 33 (a.k.a. 0x78, 0x56, 0x34, 0x12). However, I'm talking about base 16, so it's 0x87654321. If it were base 2, it would be: 00011110011010100010110001001000, which seems like it would be 0x1E6A2C48, but is actually equivalent to 0x87654321 if both are little-endian order. The reason it's weird is that you and the assembler both use big-endian arabic notation within the bytes, but little endian order outside the bytes. This is actually true little endian *hex* - screws with your mind, don't it? Perhaps that's why people hate dealing with little endian stuff in computing: it's both wrong and internally inconsistent to do it in hex.

Erm, I must've just misunderstood what you meant by "for easy cooperation with real binary"

Big-endian/little-endian usually applies to byte ordering. In a normal computer bit ordering is simply notation, because in a computer you have data bus lines to memory (say D0 through D7 for a byte) that have an unmutable order (D0 is the LSBit). Byte ordering depends on the system because you can read the 4 bytes in a double word (or 2 in a word) seperately at different addresses, and one needs to know which contains the LSByte, MSByte, and everything in between. If each memory address contained two bytes (and all reads were at least two bytes), then there would be no endianess for words, you would just need to wire the data lines (D0 through D15) up consistently.

Memory buses of course contain much more than a byte (or two bytes) of data lines, but that just speeds things up, it doesn't affect the need for endianess.

NickJohnson wrote:quantum representation of data

Do you mean that they are quantized or that they use the principles of quantum mechanics for storage?
I guess both are true in any case.

But my point is that even though the bytes are being described in little/big endian format, the ordering of the hexadecimal for those bytes is always big endian, because that follows traditional arabic numeral order. I know how the computer actually handles it. What I'm saying is that if you follow the definition of little endian vs. big endian, it refers to which *digit* is the least/most significant. Computers, because their quantum representation of data is a byte (not a bit!), operate in base 256, so a (little-endian) number like this:

0x78, 0x56, 0x34, 0x12

means (0x78*256^0)+(0x56*256^1)+(0x34*256^2)+(0x12*256^3)

but a little endian true hexadecimal number like this:

0x87654321

means (0x8*16^0)+(0x7*16^1)+(0x6*16^2)+(0x5*16^3)+(0x4*16^4)+(0x3*16^5)+(0x2*16^6)+(0x1*16^7)

which are actually the same thing. The problem is that in the first example, each byte is represented by a *big endian* (i.e. arabic order) pair of hexadecimal digits, while the order of bytes is *little endian*. That's why it's confusing.

I also mean that the byte is the quantum unit of storage as in it is the smallest piece of information you can manipulate, not that it has anything to do with quantum computing/mechanics.

The advantage of big-endianness is the readability by humans
The advantage of little-endianness is that if you read a different number of bytes, you get the same value

Combuster wrote:The advantage of big-endianness is the readability by humans

That's the reason I think it might be useful for people to write numbers in little endian digit order - so you get the technical advantages of little endianness while also having it be intuitive to humans. Like if we taught people to count 1, 2, 3, 4, 5, 6, 7, 8, 9, 01, 11, 21 *natively*, we would be able to use little endian stuff everywhere with no confusion. It's kind of a crazy idea, but if you somehow got a lot of technical users to understand it (base 10 to base 16 conversion is a similar hurdle, and it's been done), it would make a lot of stuff easier and more logical. Idk, I may try learning little endian hexidecimal arithmetic.

NickJohnson wrote:

Combuster wrote:The advantage of big-endianness is the readability by humans

That's the reason I think it might be useful for people to write numbers in little endian digit order - so you get the technical advantages of little endianness while also having it be intuitive to humans. Like if we taught people to count 1, 2, 3, 4, 5, 6, 7, 8, 9, 01, 11, 21 *natively*, we would be able to use little endian stuff everywhere with no confusion. It's kind of a crazy idea, but if you somehow got a lot of technical users to understand it (base 10 to base 16 conversion is a similar hurdle, and it's been done), it would make a lot of stuff easier and more logical. Idk, I may try learning little endian hexidecimal arithmetic.

You can get around this problem just by being aware that the computer is storing the data in the opposite way that you write it. The only situation where this is an issue is when you look at a binary/hexadecimal dump of memory where the computer has no idea how the bytes are grouped together. Then you have to do a little mental work to convert it to the order that humans are normally taught.
The issue with teaching people to count this way is that it overrides the way most people are taught to count as children, while base 10 to base 16 conversion is a new skill that does not interfere with or obsolete anything we are taught at a much younger and more impresionable age.

I also mean that the byte is the quantum unit of storage as in it is the smallest piece of information you can manipulate, not that it has anything to do with quantum computing/mechanics.

If its the smallest unit that can be manipulated, then I would think that it would be called atomic. A word is still an quantum unit of data in a computer because it has fixed steps between each value, but it is not atomic because it can be broken up into bytes.

JohnnyTheDon wrote:The issue with teaching people to count this way is that it overrides the way most people are taught to count as children, while base 10 to base 16 conversion is a new skill that does not interfere with or obsolete anything we are taught at a much younger and more impresionable age.

To me, base conversion seems a lot more complex than simply reversing the order of digits. You can keep the arithmetic concepts (like adding individual digits) - the only thing that really changes is that you reverse the order of everything. Learning that 6+7=B is much more alien than learning that 6+7 should overflow to the left. Who knows, maybe teaching little kids different bases and endiannesses could make them smarter, like teaching them multiple languages.

JohnnyTheDon wrote:

I also mean that the byte is the quantum unit of storage as in it is the smallest piece of information you can manipulate, not that it has anything to do with quantum computing/mechanics.

If its the smallest unit that can be manipulated, then I would think that it would be called atomic. A word is still an quantum unit of data in a computer because it has fixed steps between each value, but it is not atomic because it can be broken up into bytes.

I usually consider the terms 'atomic' and 'quantum' to be effectively synonymous. To me, quantum usually means the smallest element of something (or the least common divisor of quantity), and atomic means something that cannot be subdivided. For most purposes, that seems to imply the same things. I guess you could also define quantum to mean an integral quantity of something (which is what I think you're saying). But it's all just semantics anyway.

NickJohnson wrote: I usually consider the terms 'atomic' and 'quantum' to be effectively synonymous. To me, quantum usually means the smallest element of something (or the least common divisor of quantity), and atomic means something that cannot be subdivided. For most purposes, that seems to imply the same things. I guess you could also define quantum to mean an integral quantity of something (which is what I think you're saying). But it's all just semantics anyway.

A quick look at the dictionary shows quantum to mean 'something that can be counted', which is what any unit of data in a binary computer would be. A real number would not be quantum, because between any two real numbers that are not equal there is an infinite number of values, while between two binary values there is a finite number of values.

EDIT: To clarify the difference between integral and quantum: A fixed point decimal would still be quantum because there would be a finite number of values between a pair of values.