Well, I don't like wasted silicon, and although granted the price of x86 cpu's is set more by the market than the manufacturing cost, today's cpu's are essentially recompiling the code from an archaic cisc instruction set with 8 (x86) or 16 (amd64) registers and riddled with exceptions, to a vliw type risc instruction set with many more registers, and doing it on the fly with all the disadvantages that that involves such as not knowing what is ahead in the instruction stream until it happens so that nearly everything is speculative, dealing with restartable instructions, etc, etc... when a compiler which knows the difference between code and data, and can perform reasonable static analysis, could do so much of a better job... granted (1) vliw is a waste of space, but for applications where that matters you can just code in java and run on a hotspot vm and (2) certain runtime information is available to the on-the-fly x86 translator that improves performance and can't be derived by static analysis, but this can be gathered by profiling and fed to the optimizing compiler. so to sum up, in my opinion there is a need for a highly orthogonal risc-like isa to free up lots of silicon to be used for extra math units etc, and/or save cpu cost by moving functionality from hardware to software, improve reliability and shorten cpu design cycles (because extra complexity = more potential for bugs). one other point that remains to be mentioned is that the x86 isa acts like an abstraction layer that gives chip designers the freedom to radically change the chip internals without breaking compatibility and this is a Very Good Thing, hence i propose that the mentioned vliw risc orthogonal isa not be set in stone, i.e. bitfields are assigned or deleted, to control whatever functional units, registers, buses etc are present in each release of the chip, so any binary releases of software packages would have to be in an intermediate format such as llvm or similar. (java bytecode is maybe too high level for stuff like linux kernel, etc). just my 2c worth :)
cheers, Mixk
> What I'd like is a new 64 bit PDP-11. That assembler was wonderful to
> read and write, only a short distance from C.
True.
> x86 makes me puke. MIPS and Alpha aren't much better
Dunno if this is the right forum, but I have to wonder about the fact
that many old-time Unix and Plan 9 folks rant and rave about different
architectures. (I mean, I know people who are *still* pining for the
DEC-10 with TOPS-10 and TOPS-20.)
IF you are not writing the compiler or the low level OS routines, what
freaking difference does it make? I've been doing C, Unix, C++, Linux,
etc., for over 30 years, and what matters to me more are things like
what facilities are in my C library, how standards compliant a system is,
whether the library and OS behave like they should (cf MirBSD, which is
brain dead on at least 2 counts), and so on.
The only assembly language I ever learned was the PDP-11, and that was
on a Univac system using an assembler and simulator written in Algol-W
circa 1979. And I agree, the architecture was beautiful.
But even though my home systems and much of my work has been on x86 Linux
for close to 20 years, I don't find myself constantly moaning and groaning
that the underlying instruction set isn't clean and elegant.
So other than the curmudgeon credit, what am I missing?
Arnold
_______________________________________________
TUHS mailing list
TUHS@minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs