The fabled Amiga X1000 has been spotted in the wild, in the homeliest of places--Station X, a.k.a Bletchley Park. "The AmigaOne X1000 is a custom dual core PowerPC board with plenty of modern ports and I/O interfaces. It runs AmigaOS 4, and is supported by Hyperion, a partner in the project. The most interesting bit, though, is the use of an 500Mhz XCore co-processor, which the X1000's hardware designer describes as a descendant of the transputer - once the great hope of British silicon." With thanks to Jason McGint, 'Richard' and Pascal Papara for submissions.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
Uh? AFAIK nobody had such assumption ever, it's the classical trade-of of size vs speed, let's just say that the x86 chose badly (x86-64 is better).
Not true, 1) if your code wants to use more variable than there are registers exposed, those hidden register don't help, you have to spill to the cache..
2) even heard about Intel's Atom? I heard it's quite popular in NetBooks, and it's in-order..
"Basically the same" as in 16 vs 32??
That said, I agree that the difference in performance is much, much lower..
It sucks because the lack of regularity, lack of registers and stupid choice like little endianness makes it more difficult to program in assembly than it should be..
Member since:2009-10-04
Are you joking? How is little-endian a stupid choice? Admittedly, the way numbers are written in many human languages is big-endian, but for computers, little-endian is simply technically superior.
Personally, I think programming in assembly with little-endian architectures is easier. For example:
mov [eax], 5
mov ebx, [eax]
mov cx, [eax]
ebx and cx will both be 5. This makes many things simpler.
All of this is not that important, but the world would be better off if we settled on one endianness. Little-endian has small technical advantages, and big-endian has cultural advantages that only apply to certain languages. Therefore, little-endian would be the logical choice.
Member since:2009-03-17
Member since:2006-01-10
Fixed 32-bit length instructions, makes determining code boundaries dead simple. x86's variable length instructions may be better for code density but since you're talking modern systems density no longer matters. Also, 32 general purpose registers means that custom ABIs can be used that keep necessary data in registers at all times, completely removing the memory latency (3 clock CAS latency is huge for an address bus that's already 1/3 CPU clock, and I've seen memory sticks, even new ones, that are even much higher than that, in the 5+ latency range).
Additionally, the instruction set itself, aside from being a clean 4 byte width, is clean and, dare I say, beautiful. Yes, that's a bias, but it's my bias, and you were asking why _I_ would pay extra for ppc over x86.
Besides, it's a little bit of geek nostalgia to have something that's different from everyone else like existed before x86 took over everything.
Member since:2005-07-06
Member since:2005-07-23
Member since:
2009-03-17
The 80s are calling and they want their assumption the more registers the better back.
First off, most x86 designs are out-of-order making the number of registers exposed to the programmer irrelevant. Second, the X86_64 doubles the number of general purpose registers anyways. So you get basically the same number of registers exposed to the programmer than in most modern RISC processors.
In the end, the only benefit of having a few more registers is that it may delay when you have to deal with the stack, which you have to use too in a RISC machine since register spills are bound to happen.
If you're so afraid of dealing with the stack, maybe you should not be programming at the assembly level to begin with.
Now for real, what is so awful about X86, or at least X86_64 from people who actually program in assembly in both (RISC and CISC).
Edited 2010-06-23 09:07 UTC