MISC

[Fare Rideau]

>> [Fast hardware is simple hardware]
>
> Yes. Hardware "optimisations" - pipelining, branch prediction, etc.
> are all "softwareish" operations being done in hardware! And they
> get repeated each time around the loop... isn't that why people
> moved from interpreters to compilers in the first place...
>
That's why for 10Million transistors, they get less
than 100 times the power of a 10000-transistor MISC CPU.
Of course, they also use the latest silicium technology,
whereas the MISC CPU runs in cheap 20MHz technology
(but still achieve 80 MISC-MIPS).
For the same number of similarly hi-tech transistors,
imagine the power of 1000 MISC CPUs each running on 200MHz technology
for 1 MISC GIPS!
Of course, if you want them to run software given as byte/wordcode
for a low-level VM following the Von Neuman model,
you won't get very far...

MISC is the future of hardware.
LispOS and TUNES have the opportunity of supporting it,
when traditional OSes designers just don't have a clue,
because they were lobotomized by the C programming model.


> The problem, as always, is memory bandwidth.
>
Exactly. The largest the memory, the slowest;
so that when technology improves, the speed of CPUs
grows much faster than the speed of memory.
MISC processors are so small they'd come as an extension to RAM chips,
so each has a small amount of extra fast RAM,
instead of huge amounts of slow RAM, keeping RAM and CPU speed adapted
to each other.
Yet Von Neuman model hypists would have more and more bloated
CPUs manage more and more RAM.
   The VonN hypist are even trying to make us believe
that client/server is great, i.e.
having an expensive failable centralized sequential machine do everything,
instead of using redundant distributed software on cheap hardware.
   Down with VonN VM's!
   If reality hadn't caught them already, the dream of IBM
would still be to replace all of the Internet by their own unique
giant centralized computer that'd do all the computations in the world
(in COBOL, FORTRAN and JCL, of course).


> A MISC-like system, in fact veritably VLIW,
>
Uh??? Current MISC processors have 5bit/instruction,
as compared to 128bit/instruction on a VLIW processor.
For a similarly-wide instruction but,
this means 25 times more instructions can execute
per slow memory fetch.
Of course, the tradeoffs of MISC vs VLIW are completely different;
but the whole idea of MISC is to move intelligence into software,
whereas VLIW failed to move intelligence into hardware,
and for a same compiler complexity as MISC,
only require more expensive hardware.


A reason I have against a CL-based OS, to me,
is that it wouldn't fit the model of having clusters of cheapo MISC chips,
each with a limited amount (a few hundreds KW) of on-chip RAM.
If a CL core would have to fit every host,
there would be no space for user memory!
[Reminds me of those useless clusters of intel i860
with half of each CPU's 16MB core being taken by OSF/1].

Not that CL doesn't have a place of choice in a LispOS;
just that I'd rather have CL built on top of LispOS
than LispOS built on top of CL...


I'd rather go base the OS on a minimal Lisp,
that we would extend with an elaborate module and functor system.
CL, Scheme, and whatever Lisp flavor,
could be built on top of it. For instance,
hbaker (pinch me! My favorite Lisp demigod -- why is he still on netcom?)
just suggested on the list
that bignums could be Lisp-implemented in terms of fixnums.
I quite agree. Let's move as much as possible
out of the C/asm implementation; let's break the huge CL blackbox.
Let's produce a *fine-grained* system.


Actually, while actively supporting modules and functors
as constructive patterns,
I'd like to promote a reflective model,
through which you'd be able to use objects of semantics you define
without having to unnecessarily tying the actual implementation to
the construction of the semantic specification.
Current software technology is ridden with
static tradeoffs and compromises due to this forced relation,
that prevent people from having software both well-defined and efficient.
Reflection would allow us to marry safety and efficiency.


> [...]
> ARGON, BTW, is a /standard/ like POSIX rather than an actual bit
              ^^
Well, "will be" ;-> -- much like Tunes, actually )-8
NB: I've tried to cut the Tunes&Argon hype, too...

#f

TUNES is a Useful, Not Expedient System
http://www.eleves.ens.fr:8080/home/rideau/Tunes/