Endian


Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,307
Age
41
Location
Cleveland OH
I ask because I was looking at the specsheet for the recently announced OMAP35xx line of chips, and was surprised to find that their Cortex-A8's are big endian. Will it be the same for Pandora, or is that private information?

It'd be good to know for the few of us this will affect, so we're prepared to make the necessary modifications.
 
And the Cortex-A8 manual says that instructions can only be little endian (which is highly relevant to those with dynarecs), so it makes me wonder exactly how the OMAP35xx can have big endian ARMs, unless they were only referring to the CPU itself.

I've also poked around and it seems like OMAP3430 will have 16/16KB L1 cache like the 35xx's. That's too bad, I was hoping it'd have 32/32 like most recent ARMs have. It should have 256KB of L2 since the 35xx's do (and the lowest end one is really quite cheap, only a little over $30 in quantity of 100) so I expect the 3430 to have that. That's good, 2x what I expected, but if I had to choose I'd pick 64/128KB L1/L2 over 32/256KB.
 
Squidge said:
I believe it's LE, same as the GP2X.
Hm, if you say so it must be. You'd probably know if endian was changed when porting a 68k emulator. It could be done endian neutral but I don't see why someone would when specifying endian would be so much better.
 
Last edited by a moderator:
Exophase said:
And the Cortex-A8 manual says that instructions can only be little endian (which is highly relevant to those with dynarecs), so it makes me wonder exactly how the OMAP35xx can have big endian ARMs, unless they were only referring to the CPU itself.

Even if your ARM is hardware configured as little endian, you can still make some software configuration to make it load data as big endian (ref: C-A8 TRM section 4.3). But don't get over excited about this: it can only be set by the kernel, and you wouldn't want to change it while something is already running such as the kernel itself :)
 
Last edited by a moderator:
Laurent said:
Even if your ARM is hardware configured as little endian, you can still make some software configuration to make it load data as big endian (ref: C-A8 TRM section 4.3). But don't get over excited about this: it can only be set by the kernel, and you wouldn't want to change it while something is already running such as the kernel itself :)
But the instructions are always little endian (same section indicates this). Maybe the kernel could be aware of which endian a process is, and switch for them (and of course switch back to little endian for kernel stuff). I wonder if the switch is expensive, like if it happens external to cache and must invalidate it.
 
Last edited by a moderator:
Exophase said:
But the instructions are always little endian (same section indicates this). Maybe the kernel could be aware of which endian a process is, and switch for them (and of course switch back to little endian for kernel stuff). I wonder if the switch is expensive, like if it happens external to cache and must invalidate it.
The switch is only a matter of writing a bit in a cp15 register so let's say two dozen of cycles (this is the kind of instruction that flushes the instruction pipeline for obvious reasons :)). The problem is that as soon as you do this all data load would become BE. So the scheduler would have to be careful not to load any data before jumping to the user process. It probably can be done, since for instance Thumb2 processes can be run on an ARM kernel. But then you would have to be extremely careful for system calls that need some user data in memory.
 
Last edited by a moderator:
Okay, MWeston says they're using OMAP3530 which TI is clearly calling big endian (for the ARM). Why is ARM setting an endian instead of calling it configurable?

It's about as strange as them making something big endian in the first place. Who actually wants a big endian ARM..
 
The only reason to like little endian is out of experience with using it, I personally hate little-endian. Why should the bytes be ordered the opposite way round that the bits are, it makes no sense.
That being said it would make porting stuff a helluva lot easier if it was LE I suppose and most of the time it is of little consequence.
 
flatmush said:
The only reason to like little endian is out of experience with using it, I personally hate little-endian. Why should the bytes be ordered the opposite way round that the bits are, it makes no sense.
That being said it would make porting stuff a helluva lot easier if it was LE I suppose and most of the time it is of little consequence.
sometimes I would like people to have a deeper reflection about the origin of digits. They are Arabic and you write the most significant digit to the left and the least significant digit to the right. Why ? is it because Arabic people write them from the right to left ? starting with the least significant digit and ending with the most significant digit ? I wonder, I would like someone speaking Arabic can tell me if they write digits this way or like us, that is writing by starting with the most significant digit and ending with the least significant digit ?

Let's have an experience : try to speech this number 89726438924787342780938949347368291098734567123, i'm pretty sure you'll remember the last two digits (twenty three) better the other previous digits. Well, if we should remember something it should be at least the most significant digit, not the least significant digit. Why not this way ? probably because we read those digits from the left to the right as we read our words, and maybe not from the right to the left as it should be ?

Anyway, I feel there is something wrong in our way to read digits. So it would be the same for those big vs. little endianness wars... and kinda futile.

NOTE: i took the wrong quote :)
 
Last edited by a moderator:
Exophase said:
Okay, MWeston says they're using OMAP3530 which TI is clearly calling big endian (for the ARM). Why is ARM setting an endian instead of calling it configurable?

It's about as strange as them making something big endian in the first place. Who actually wants a big endian ARM..
Well, we can run code compiled for the gp2x on the Pandora, so that to me says the Pandora is LE, just like the GP2X...
 
Last edited by a moderator:
QUOTE
Anyway, I feel there is something wrong in our way to read digits. So it would be the same for those big vs. little endianness wars... and kinda futile.

Well it's not just that, we choose a byte as our smallest unit in computing. The bits within that byte are always stored in big endian format so why would you store the bytes differently.

Say I split a number into 3 digits as is done in normal counting using a comma.
Big endian would be 123,456,789 where as little-endian would be 789,456,123 which is the wrong order no matter how you view it.

If the individual bytes were stored in little-endian I wouldn't mind, also it becomes really annoying when working with colours where components go over the boundary.

But most of all the general argument is that it's more important to know the order of the number before you know it's exact value.
 
flatmush said:
The bits within that byte are always stored in big endian format so why would you store the bytes differently.

Since a bit in itself is not addressable how can you say that? If you mean that bit are described in a given way by processors manual, then look at how IBM describes bits in PowerPC :lol:
 
Last edited by a moderator:
Laurent said:
flatmush said:
The bits within that byte are always stored in big endian format so why would you store the bytes differently.

Since a bit in itself is not addressable how can you say that? If you mean that bit are described in a given way by processors manual, then look at how IBM describes bits in PowerPC :lol:

Good point, but when you export the byte to a different piece of big-endian hardware you will see the bits are the same order and bytes are not.
I'm of course assuming that a big-endian graphics unit I used on the psp stores the colours in the bitwise order it says it does (RGBA) but I can't see any reason why it wouldn't.
And I'm pretty sure that the bit ordering is standard across most devices as bit-ordering is not defined for files.
 
Last edited by a moderator:
flatmush said:
Good point, but when you export the byte to a different piece of big-endian hardware you will see the bits are the same order and bytes are not.
I'm of course assuming that a big-endian graphics unit I used on the psp stores the colours in the bitwise order it says it does (RGBA) but I can't see any reason why it wouldn't.
And I'm pretty sure that the bit ordering is standard across most devices as bit-ordering is not defined for files.
Bit order doesn't exist very much at all on modern platforms because they don't address memory by bits to begin with. However, in convention where bit numbers are used it's almost always the case that the least significant bit starts at 0, not the other way around. The only reason confusion arises is because in most western languages words are read left to right and numbers are written with most significant digits first. This mainly just throws off people looking at little endian numbers in a hex editor. Writing left to right is actually superior to writing right to left because most people are right handed and writing right to left means covering up what you're writing as you're writing it.

Still, in and of itself endian is almost entirely immaterial, the choice more matters based on how it relates to other existing platforms, for communication, porting, and emulation. Since all ARMs I've ever heard of were configured to be little endian it hurts porting from ARM, and since most current CPUs (such as x86..) are little endian it hurts communication, not to mention that file formats with a fixed endian tend to be little endian because they were developed on PC. Most platforms being emulated are little endian (x86, 65xx, z80, ARM, some MIPS), with the major exceptions of anything 68k based and N64's big endian MIPS R4k CPU.

Given that they're probably interested in compatibility with existing ARM programs, going big endian makes no sense.
 
Last edited by a moderator:
Ah, thanks for clearing that up. One thing that always confused me is that left-shifts always make the number bigger and right the other way round, on a true little-endian machine then it should be different.
All programming languages that I know of use the right and left shift operands as if it was big endian, write numbers as if they're big endian and all computer science stuff uses big endian when explaining binary.
If so many platforms didn't already use little endian then the only real choice would be big endian but as you said it makes more sense to use little-endian for emulation and porting.
 
flatmush said:
Ah, thanks for clearing that up. One thing that always confused me is that left-shifts always make the number bigger and right the other way round, on a true little-endian machine then it should be different.
All programming languages that I know of use the right and left shift operands as if it was big endian, write numbers as if they're big endian and all computer science stuff uses big endian when explaining binary.
If so many platforms didn't already use little endian then the only real choice would be big endian but as you said it makes more sense to use little-endian for emulation and porting.
The shifting only looks that way to you because you're laying the bits out from left to right in ascending order, while CPU descriptions do the opposite, ie:

MSBs LSBs
31 30 29 ... 3 2 1

If you were to pick top to bottom or bottom to top for laying out memory in a diagram you might pick the former, but actually the latter is usually how things are drawn.
 
Last edited by a moderator:
Exophase said:
The shifting only looks that way to you because you're laying the bits out from left to right in ascending order, while CPU descriptions do the opposite, ie:

MSBs LSBs
31 30 29 ... 3 2 1

As I said the PowerPC docs (at least the CELL ones) do it the other way around. Why? Can't say, perhaps they want to really look different :lol:
 
Last edited by a moderator:
Laurent said:
Exophase said:
The shifting only looks that way to you because you're laying the bits out from left to right in ascending order, while CPU descriptions do the opposite, ie:

MSBs LSBs
31 30 29 ... 3 2 1

As I said the PowerPC docs (at least the CELL ones) do it the other way around. Why? Can't say, perhaps they want to really look different :lol:
I think big companies (IBM, Intel, Microsoft) sometimes have the urge to do things arbitrarily different just because they know they can :(
 
Last edited by a moderator:
Exophase said:
I think big companies (IBM, Intel, Microsoft) sometimes have the urge to do things arbitrarily different just because they know they can :(
I think thats one of the main reasons, kind like format wars( i.e. blue ray vs hddvd).
I think Motorola is BE supporter.
 
Last edited by a moderator:
Back
Top