DarthShader
Regular
No, it says "Very high performance ARM CPU" and that's a big difference.
I thought that difference between endianness was sorta like potato/puhtato. Is there more to it?
Little endian = memory ordering does not depend of word size used to access it
Big Endian = memory ordering does depend of word size used to access it
Basically big endian is at best a pain in the arse when designing hardware.
Interesting. Hadn't thought about it from that POV.
Makes me wonder why almost every RISC went the big endian way when x86 was doing little endian just fine.
Just use decreasing addresses (in effect point at the end of structures/elements instead the beginning) and its the reverse.Little endian = memory ordering does not depend of word size used to access it
Big Endian = memory ordering does depend of word size used to access it
Basically big endian is at best a pain in the arse when designing hardware.
// bigendian:
varint val = 0;
while (hasnextbyte())
val = (val << 8) | nextbyte();
// little endian:
varint val = 0;
int shift = 0;
while (hasnextbyte()) {
val += nextbyte() << shift;
shift += 8;
}
May be the BSD sockets people were hooked onto big endian workstations, that's why.Should explain why everything streaming/network chose bigendian
I'm sure the first targeted use for this is in consoles. A bunch of high powered ARM cpus combined with a huge GPU would be all you need for a fantastic next gen console.
The one thing I don't know about is the effect of having super fast CPU->GPU communication. I read a bit on smallLUXGPU development and it seemed like one of the big bottlenecks was getting data back and forth to the GPU.
However...everything is getting super fragmented right now. Are game developers really going to program for...
-Ps3-Cell processor
-xbox 360-PowerPC
-Nvidia Maxwell/kepler
-Fusion/Sandy Bridge (eg normal x86 + GPU)
Seems like something radical needs to happen in the software space to make this less of a headache.
Little endian = memory ordering does not depend of word size used to access it
Big Endian = memory ordering does depend of word size used to access it
There are no difference. Most RISC CPUs can be configured to either order (with tiny piece of logic)Basically big endian is at best a pain in the arse when designing hardware.
WTFBig endian data is placed in register as it is in memory.
in memory: 11 22 33 44 55 66 77 88
You're just using a writing convention where the lowest byte adress is on the left and the highest is on the right. You could just as well write the bytes vertically, or right-to-left.in memory: 11 22 33 44 55 66 77 88
You could just as well write the bytes vertically, or right-to-left.
If you're from a different culture you can.No you can't, not in a culture where you read from left to right anyway.
No, you have that back the front (at least in typical systems).in memory: 11 22 33 44 55 66 77 88
Reverses relative to what? your assumption that pointers have to address the least important byte(s) (effectively assuming memory ordering has to be LE)? are you depending on undefined behavior of C for your argument?Eh? Big endian order typically reverses bytes within a word for the "convenience" of making them appear the same to a human reader but the memory order _does_ change as a result. What's worse is that memory order changes depending on the word size used. There are even multiple flavours of big endian with different orders within words.
You can use bigger shifts with big endian aswell, and the only thing that matters is memory ordering. but the important thing is that you have the simpler logic whether you read 1,4 or 7 bytes.Npl, bit confused by your example, memory ordering of byte data types is the same in both, further little endian allows you to optimise by using wider word shifts if they're available without worring about the effect that word width has on memory order.