Linus Torvalds (torvalds@osdl.org) on 10/27/06 wrote:
---------------------------
>But hey, dig your head in the sand. It's not my problem
>if you can't just face historical facts. Time and time
>again, people have done architecturally explicit
>optimizations to show the "true power" of the architecture,
>and every single time it's been a total disaster:
>
>- "we don't need byte operations, you're better off with
>faster word operations and manual insertion"
>
>- "we don't need to do IEEE compliant hardware, you're
>better off taking a trap and fixing it up"
>
>- "we don't want precise exceptions, you're better off
>with fast hardware and clever code generation"
>
>- "we don't want to do implicit register renaming, you're
>better off explicitly rotating the register state for
>loop unrolling, and using an explicit register stack,
>allowing for faster hardware"
>
>- "we don't want to support unaligned accesses, you're
>better off with faster hardware and extra code (or
>trapping) to handle the unusual unaligned cases"
>
>- "we don't like variable-sized instructions, so you
>should be happy that we can decode our crappy fixed
>sizes so quickly, and instead use multiple instructions
>for the same thing, because they're so fast"
>
>- and so on.. I've heard them all.
>
>How many times do you have to be wrong because you can
>just admit that you were wrong? EVERY SINGLE
>TIME.

I think you are overestimating one thing: all that you said above is true... in the desktop market. Now let's exit it for 30 seconds. There's an embedded market around the corner and it has a volume which totally eclipses the desktop market with chips in which byte loads/stores might be there, but you're not 100% sure. Unaligned ones on the other hand are rare. FPUs aren't there usually, when they're there they might be single precision only and in most of the case support only a limited subset of IEEE754, the compiler/OS has to do the rest. You're also looking at a lot of RISCs and VLIWs so fixed-sized instruction abound though you might have variable-sized ones, but that's because memory is still costly in the market, not because it is the right way to go. There's a lot of VLIWs around so lots of registers and no renaming, even for RISCs you must be looking at the absolute high-end to see hardware register renaming in hardware.

So if what you said is true, then why the largest market by volume goes in the opposite direction? Money matters in the embedded world and you really don't want to waste (precious) area and power on things you will use rarely.

And then there's another thing. About the unaligned load/store stuff. While this might make the coder's life easier, especially when dealing with hardware / wire protocols and the like one should be well aware that no language I know of supports them directly apart from assembler. C doesn't support unaligned loads/stores, they break the strict aliasing rules so if you're writing C which deliberately unaligns pointers (or accesses unaligned fields, whathever) you must be very much aware that your code is not portable in the best case and plain broken in the worst one. And we're not talking about theory, recent versions of GCC (especially the 4.1.x branch) which are exploiting strict aliasing more and more are starting to break a lot of code even with -O2 ...

Gabriele