Just for fun: Your dream instruction set for PC

[Cogman]

Lets say, for fun, you were presented the opportunity to completely nuke the defacto standard x86 instruction set, start a fresh (And magically all programs/OSes would be compiled to work with your new instruction set).

What would your new instruction set look like (if you even did an instruction set, maybe you have some more clever way of sending instructions to the CPU).

Would you stick with something like an ARM based instruction set? Or would you try to reinvent the CISC platform?


Personally, for starters I would completely nuke the FPU. That thing was such a bad idea it makes my head spin (Seriously, a stack!). I would make it look more like instructions do today. For most instructions, I would change them from "inst src, dest" to "inst op1, op2, dest, dest2" (for those instructions that need a second destination, IG the division instruction, 3 operands would probably be used for all instructions).

Which brings me to GP registers. I would create around about 64 general purpose registers. I would completely nuke the ah and al type registers.

I would probably stick with a CISC type architecture. One thing you have to give it, it is extensible (though, throw enough bytes into the RISC instruction set and you have, essentially, unlimited growth as well). It allows for infinite breathing room for new instructions.

Not to mention exclude all worthless instructions now present in the x86 library such as enter and leave.

I see my instruction set semi-resembling the x86 instruction set, yet much trimmer and basically getting rid of all the old legacy stuff.

Your turn.

 

[Idontcare]

Wish I could contribute something cerebral to your endeavor Cogman, but alas this is well beyond my area of expertise.

But I did want to ask a question that I think is related, or at least you could deal with it tersely and hopefully without me derailing your thread...what sort of benefits are to come from changing the ISA to a "better" ISA such as the one you opened with in your OP?

Does performance of the end-user computations with the code stand to gain a 50% speedup compared to the same price (die-size, cost standpoint) x86 cpu? A 2x speedup? Or does the hardware not necessary get faster but the software development costs decline so the end-user spends less buying the apps they use, or spend the same amount and get more feature-rich apps?

Also from the perspective of the hardware guys - what would their motivation be to produce a CPU which is compatible with the alternative ISA? Do you foresee a "simpler" ISA resulting in less-expensive architecture development and cheaper cpu manufacturing costs?

Or maybe it is a TAM play? Move to a more readily adoptable ISA so the app potential is all the more prevalent, the elevated volume opportunity (TAM) then makes it all the more lucrative for hardware guys to pursue the market? (kinda like what apple did with iPhone)

 

[Cogman]

Wish I could contribute something cerebral to your endeavor Cogman, but alas this is well beyond my area of expertise.

But I did want to ask a question that I think is related, or at least you could deal with it tersely and hopefully without me derailing your thread...what sort of benefits are to come from changing the ISA to a "better" ISA such as the one you opened with in your OP?

Well first off, trimming off the fat will result in lower power consumption. Useless instructions add lots of complexity and gates to the processor that just don't need to be there. The x86 architecture has a lot of them. Beyond that, a more riscy awe architecture is easier to pipeline. As well, things like loading instructions misaligned just doesn't happen in a risc architecture. (though I still like cisc with all its quirks)

Does performance of the end-user computations with the code stand to gain a 50% speedup compared to the same price (die-size, cost standpoint) x86 cpu? A 2x speedup? Or does the hardware not necessary get faster but the software development costs decline so the end-user spends less buying the apps they use, or spend the same amount and get more feature-rich apps?

It really depends. certainly lower power consumption with higher IPCs would be realized (look at IBMs power series of CPUs or even the ARM architectures). As far as performance, I could see it increasing. More registers would be quite useful for a number of applications. It would reduce the need to push data from the CPU to memory quite significantly. Now, the cache helps with this a lot, but have a GP register would just be that much quicker.

The main benefits will come from a lower power threshold. With lower power requirements comes the ability to do more stuff or run at higher clock speeds. I cant really quantify how that would compare to the x86 as this is all theoretical .

Also from the perspective of the hardware guys - what would their motivation be to produce a CPU which is compatible with the alternative ISA? Do you foresee a "simpler" ISA resulting in less-expensive architecture development and cheaper cpu manufacturing costs?

First. compatibility/legacy, the curse of the hardware world, is simply there because too much stuff already exists for the existing architecture. They don't want to release a product that ends up screwing up every piece of software ever written. It is comparable to the driver model shift that happened from XP to Vista. HUGE nightmare for microsoft. Even with the specs release for something like a year before the product release, they had major issues getting driver writers to adapt to it.

For the second question. A simpler ISA will certainly result in a less-expensive and more extensible architecture. After all, to deepen a pipeline for all instructions involves much less work since you don't have to worry about the state of instruction or what it is currently doing to a register.

Or maybe it is a TAM play? Move to a more readily adoptable ISA so the app potential is all the more prevalent, the elevated volume opportunity (TAM) then makes it all the more lucrative for hardware guys to pursue the market? (kinda like what apple did with iPhone)

I really don't see a new ISA increase the adoption rate of application developers. Most developers never actually see the ISA, only ASM nerds like myself. It would, however, increase application speed. Especially if the compilers adapt to effectively use registers.

 

[gevorg]

<-------- "Highly Technical" forum that way

 

[Cogman]

<-------- "Highly Technical" forum that way

I figured this belonged more in the CPU forum. after all, we spend way too much time here discussing prices and not enough time actually discussion CPUs . Though, if it has to be moved to another forum I would understand.

 

[aigomorla]

LOL

well i would need to wish for a dimorphic die, to wish for a instruction set that can make the:

Cpu -> Gpu -> Ram on fly when one is needed more then the other.

 

[Voo]

Well we all know that won't happen anytime soon, but ha it's always fun

Obviously a RISC architecture.. I mean compiler writers don't need all those complex CISC instructions, the fast L1 i-cache really negates advantages from denser code and the extra decoding hw needed in these times where power efficiency is king? No, never.

But I don't think that two destination addresses really benefit you much, with register renaming it doesn't make much difference anyhow and without it you can probably save a few write ports on the register file.


Although that's still something really conventional, there are some really interesting architectures out there, that would be much more interesting.. a multithreaded architecture based on a risc architecture that's programmed with some language like Multilisp or Cilk - well that would be interesting.

@aigomorla: Well that has not really something to do with the ISA but more with the underlying hw. And with integrated GPUs as well as limited energy budgets it's only a question of time till we get that.. doesn't Intel already do it?

 

[dmens]

Keep CISC + translation so we can keep doing proprietary stuff in the background.