Quote:
Originally Posted by meynaf
Smaller, easier to support in hardware, faster, is to just drop 64-bit support.
|
Smaller: yes. A few percent at most.
Not easier to support in software.
Faster: in a pure speed-demon design, yes. A few percent lower latency in adder path and about one clock lower latency for multiplication (unless a 32x32->64 instruction is supported). In practice no.
And the downside: whenever you want to do additions on 64 bits you need two instructions with an additional clock latency. Or at least 6 instructions to do a 64x64->128 multiplication, this is being overly generous by assuming ternary addition instructions with carry support.
Quote:
Less orthogonal ???
No 64-bit cpu in the world is orthogonal, and for a good reason.
But you can have orthogonal, easy-to-use, 32-bit cpu.
|
Why would 64 bit have anything to do with being orthogonal?
The idea that a 32 bit processor is easier to use than a 64 bit processor is just ludicrous. And you, as usual, don't give any reason why that would be.
Quote:
For 64-bit there are better ways.
For data, merge 2 32-bit instructions together to do a single 64-bit one. As an advantage, your code will run regardless if this is the 32-bit or the 64-bit of your core.
For addresses, use the trick i mentioned before.
|
You want to waste more instruction bytes to do something, you want to complicate hardware making it slower and you don't see the problem.
Quote:
But programming is a pain in the a$$. Sorry, but no.
Having to use 4 or 5 instructions to do the job of one is a no-go today. But there are still people believing in RISC lies...
|
The no-go place that the most popular processor architecture is in?
I wonder what construct would need 4-5 instructions when the 68k only need one? MOVEM possibly. However I can see many common operations where a 68k would need two+ instructions that map to one C/RISC instruction.
And you again doesn't give any example of _why_ it would be a pain in the ass.
Quote:
|
It would just be horrible to code on. Besides, it would have very poor code density.
|
Everything but 68k is apparently horrible.