Supporting BE and LE architectures in an OS ?
Supporting BE and LE architectures in an OS ?
..
Last edited by Perica on Tue Dec 05, 2006 9:29 pm, edited 1 time in total.
Re:Supporting BE and LE architectures in an OS ?
a. You have to be aware of the endianness and swap if necessary.Perica wrote: What major differences does a big endian machine make to programming for the machine? Do you think that the big endian architectures are a lost cause? Which one do you think is better, big endian or little endian? Are the majority of all machines little endian (most computers, gaming consoles, PDAs, etc.)?
b. No, they are not lost. However, neither is better and neither is overruling, so in the near future both will exist.
c. Little endian, I can read it better
d. Little endian, but only because intels are so widespread
Why support both? Well, because there's no real reason not to? Because unicode can be both? Because the entire TCP/IP stack is big-endian and my target platforms are little-endian?
Re:Supporting BE and LE architectures in an OS ?
..
Last edited by Perica on Tue Dec 05, 2006 9:29 pm, edited 1 time in total.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Supporting BE and LE architectures in an OS ?
the problem is actually not the 'endianness' of your architecture, but the required endianness of the external thing, imho.
Take PCI, for instance: if you want to write some 'portable' PCI support, you'll need to "cast" little-endian PCI structures to whatever-endian your system is ... That can be achieved by some macros like pci_get_dword(xx) which will or won't perform endianness conversion as required by the machine.
But i wouldn't worry too much if my little-endian machine cannot load a big-endian-formatted ELF file (while little-endian elves exists aswell)
Take PCI, for instance: if you want to write some 'portable' PCI support, you'll need to "cast" little-endian PCI structures to whatever-endian your system is ... That can be achieved by some macros like pci_get_dword(xx) which will or won't perform endianness conversion as required by the machine.
But i wouldn't worry too much if my little-endian machine cannot load a big-endian-formatted ELF file (while little-endian elves exists aswell)
Re:Supporting BE and LE architectures in an OS ?
..
Last edited by Perica on Tue Dec 05, 2006 9:29 pm, edited 1 time in total.
Re:Supporting BE and LE architectures in an OS ?
Most certainly not. The world ain't only Intel desktops, and most of the rest are big endian, and for a reason.Perica wrote: Do you think that the big endian architectures are a lost cause?
Little endianess was introduced because it provided some advantage back when CPUs had to do multiple accesses to do a single operation. Today, I think their notation is just confusing. (Just as most operating systems available for them. )Which one do you think is better, big endian or little endian?
If you mean desktop machines, then yes, because of the overpowering market share of Intel and compatibles.Are the majority of all machines little endian (most computers, gaming consoles, PDAs, etc.)?
If you mean computing devices, then no... IIRC, no-one makes little-endian CPUs outside the desktop market. (Can anyone confirm / falsify this?) PowerPC, MIPS, ColdFire, ARM are all big-endian.
Programming endianess-independently, in user space, is half as difficult as it sounds. There are only a few places where you have to worry about it at all.
On the OS kernel level... well, if you switch CPUs, you'll have to rewrite significant parts of your kernel anyway.
Every good solution is obvious once you've found it.
Re:Supporting BE and LE architectures in an OS ?
SurePerica wrote:Also, if anybody knows any good links to information about big endian architectures in general (something like the Intel manuals, only for big endian architectures... I know nothing of other processor architectures other than the IA32 PC, so I wouldn't even know where to look...), please post them here.
http://e-www.motorola.com/files/archives/doc/ref_manual/M68000PRM.pdf
This is for the M68K Line of CPUs, their Big Endian.
BTW I was looking at the spec for the 68060 and look at how advanced it was compaired to the x86s of the day (3 instructions per clock cycle!)
I don't know if they fixed this in the 060, but on the 040, the built in FPU only had the most commonly used instructions. Others had to be implemented in software.
Anyway, PCs are only little endian because IBM couldn't afford the M68K line in the original PC! So they used the cheaper Intel (intel and cheap, you don't hear that much any more).
srg
Re:Supporting BE and LE architectures in an OS ?
From the user app point of view. I suspect that quite a few programs rely on little endianness. Because they can use a pointer to a long as a char pointer and get just the bottom byte rather than having to load the long and mask it OR change the pointer
Pete
Pete
Re:Supporting BE and LE architectures in an OS ?
AFAIR, the '060 has even less instructions in hardware than the '040. In any case, the Amiga PC's required a special "68040.library" / "68060.library" to handle this, since they were built to expect the 68882 FPU.srg wrote: I don't know if they fixed this in the 060, but on the 040, the built in FPU only had the most commonly used instructions. Others had to be implemented in software.
Every good solution is obvious once you've found it.
Re:Supporting BE and LE architectures in an OS ?
Thats interesting, weren't the 040 and 060 FPU's code compatible wit the 68882?Solar wrote:AFAIR, the '060 has even less instructions in hardware than the '040. In any case, the Amiga PC's required a special "68040.library" / "68060.library" to handle this, since they were built to expect the 68882 FPU.srg wrote: I don't know if they fixed this in the 060, but on the 040, the built in FPU only had the most commonly used instructions. Others had to be implemented in software.
I wouldn't know as with my Amiga 1200 I stopped at a 50MHz 68030 with 68882 FPU (a Blizzard A1230-IV expansion card).
Also, why didn't Motorolla build in a full blown FPU on these chips like intel did with the 486DX? Surely that would mean then the the CAD and scientific people would rather use the 486DX as it's FPU would be faster.
srg
Re:Supporting BE and LE architectures in an OS ?
Also, I heard once that the DEC Alpha was little endian. Is this true or just a load of tosh?
Actually, I wouldn't mind getting an Alpha one day, maybe an AXPpci 33 (EV4) or PC164 (EV5).
srg
Actually, I wouldn't mind getting an Alpha one day, maybe an AXPpci 33 (EV4) or PC164 (EV5).
srg
Re:Supporting BE and LE architectures in an OS ?
No. The 68040 did not implement the trigonometric functions of the 68882, which made for less transistors -> higher speed at less cost. If the code contained such instructions, the 68040 triggered an exception and the instruction had to be done by software libraries. That's why it is advisable to provide seperate binaries for the 882 and the 040.srg wrote: Thats interesting, weren't the 040 and 060 FPU's code compatible with the 68882?
I couldn't verify the 060 having yet less instructions, though.
Yep, had that one too. I scaled up to the Blizzard 1260 and the Blizzard 603e+ afterwards.I wouldn't know as with my Amiga 1200 I stopped at a 50MHz 68030 with 68882 FPU (a Blizzard A1230-IV expansion card).
Intel's IA32 family always targeted the desktop exclusively. The 68k family was also widely used in embedded systems, where power consumption, price, and size are major issues, too. Hence the "lower brethren" - 68EC0x0 (no MMU), 68LC0x0 (no FPU)...Also, why didn't Motorolla build in a full blown FPU on these chips like intel did with the 486DX?
Also, while Intel went for an all-out CISC design, Motorola tried to cut back on the sheer number of instructions (a RISC-inspired move) which allowed them to seriously speed up their CPUs in other areas. The 68060 easily outperforms any 68882 if fed code compiled for 68060.
The 68060 was a bit too late in the lifecycle of the 68k family to really hit the shelves, but the 040 *was* immensely popular. Both Sun and Apple used them in large numbers.Surely that would mean then the the CAD and scientific people would rather use the 486DX as it's FPU would be faster.
IIRC, it was actually Intel who broke the 68k's neck over some technical / legal issue, instead of "fair" competition. I don't have details ATM though.
Every good solution is obvious once you've found it.
Re:Supporting BE and LE architectures in an OS ?
Typical A***hole Intel, this sort of thing is one reason I refuse to buy their products unless there is no alternative.Solar wrote:IIRC, it was actually Intel who broke the 68k's neck over some technical / legal issue, instead of "fair" competition. I don't have details ATM though.
I got rid of my Amiga a year later, went over the the PC. An AMD K6 of course. It was my time with the Amiga that started my Anti-Intel policy, and so far I've never seen any reason to change it.Yep, had that one too. I scaled up to the Blizzard 1260 and the Blizzard 603e+ afterwards.
Although I have heard that in the PowerPC days, Motorolla havn't been squeaky clean either. Maybe that's why Apple only use IBM PowerPCs now.
srg
Re:Supporting BE and LE architectures in an OS ?
You can't blame 'em for playing the game that won out over communism as best as they can, right?
Serious, Microsoft, IBM et al. are a very good example for the dangers of an unregulated market. Grow to megacorp size or perish, winner takes all, to hell with what people actually want as long as you can sell.
But that's straying from the topic. Just like IBM scrapped the PowerPC variant that could execute x86 code faster than any x86, because Intel wasn't amused.
Serious, Microsoft, IBM et al. are a very good example for the dangers of an unregulated market. Grow to megacorp size or perish, winner takes all, to hell with what people actually want as long as you can sell.
But that's straying from the topic. Just like IBM scrapped the PowerPC variant that could execute x86 code faster than any x86, because Intel wasn't amused.
Every good solution is obvious once you've found it.
Re:Supporting BE and LE architectures in an OS ?
Well if AMD could beat intel in court over a license twice (386 and 486) then surely IBM could beat them over some reverse engineering.Solar wrote: You can't blame 'em for playing the game that won out over communism as best as they can, right?
Serious, Microsoft, IBM et al. are a very good example for the dangers of an unregulated market. Grow to megacorp size or perish, winner takes all, to hell with what people actually want as long as you can sell.
But that's straying from the topic. Just like IBM scrapped the PowerPC variant that could execute x86 code faster than any x86, because Intel wasn't amused.
srg