[TUHS] curmudgeon credit

[downing.nick+tuhs@gmail.com (Nick Downing)]

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
On Apr 28, 2013 4:33 PM, "Aharon Robbins" <arnold at skeeve.com> wrote:

> > 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130428/2654dbf5/attachment.html>