Re: Hobbit again

[Andrew Haley <aph@xxxxxxxxxx>]

> Date: Thu, 21 Mar 1996 09:46:39 +0100
> From: Jaap van Ganswijk <ganswijk@xs4all.nl>
> 
> At 10:44 AM 3/18/96 GMT, you wrote:
> >> Date: Mon, 18 Mar 1996 01:51:54 +0100
> >> From: Jaap van Ganswijk <ganswijk@xs4all.nl>
> >> The Hobbit has (almost) no registers and uses a cache on the stack memory
> >> instead. Compared to Forth engines and other pure stack machines it has a
> >> very orthogonal instruction set however and can manipulate not only the
> top of
> >> the stack but also local variables higher up on the stack. Which helps
> >> compiled C/Pascal/... a lot.
> >> Just see the upper positions on the stack as registers in cache...
> >> .
> >> People try to tell me, that this concept can't be efficient, but I don't see
> >> why...
> >
> >It's less efficient because it makes the datapath in the CPU more
> >complicated.  For example, superscalar execution is inhibited because
> >it's possible that a stack element may be rewritten by a memory
> >reference after it has been issued as a operand to an execution unit.
> >The only way to solve this problem is to heave a complex interlock
> >within the CPU.
> 
> We must learn to live with the fact, that CPU's are complicated
> if we want them to do complicated tasks (quickly).

Erm, no.  This is precisely the opposite of reality.  Interlocks and
MUXes within CPUs cause delays: the way to make a CPU go faster is to
reduce the number of such things.  The RISC lesson is that if you want
a fast computer you make it as simple as possible.

Making local variables appear to be in main memory slows down the
processor's maximum clock rate and the ability to go superscalar.
That's what's wrong with it.

> >With CPUs, simpler is better.  The only advantage of Hobbit is that it
> >allows one to take the address of a stack element: that's a language
> >misfeature.
> 
> I beg to differ:
> The number of spaces in a computer should be as few as possible,
> with a clear optimum of there being only one space.

What do you mean by "optimum"?  Dou you mean from a theoretical point
of view?  It's certainly never going to be the fastest way of doing
it.

> Obviously, this space would be the memory space.
> Other spaces like the register space, the stack space and the
> IO space should be part of this space.
> Since the memory space should allow taking the address of an
> element, any of the other spaces should also allow this...

But that's only possible by having a gazillion read/write ports and
hazard interlocks and MUXes.  Every one of these costs, both in terms
of die size and delays.  Every transistor in the datapath contributes
a delay.

> I realize, that some would like to improve the world by
> forbidding 99% of the languages that the world currently uses,
> but in day-to-day life, if your processor can't handle these
> languages efficiently, you won't sell your processor,
> since the world isn't prepared to (and can't) rewrite all
> the programs it has written so far...

That's right.  And experience has shown that if you want to execute C
quickly you should use a register based RISC CPU.  Using similar
process technologies, Hobbit executes C slower than the ARM, for
example.  And Hobbit is much bigger.

Andrew.