home .. forth .. misc mail list archive ..

Re: Chucks address

Jaap van Ganswijk wrote:
> At 23:10 20000613 -0600, Mark Walker wrote:
> >Jaap van Ganswijk wrote:
> Maximum performance is reached by using
> hard coded hardware designs. Being able to
> control the part using a program is already a
> severe speed-compromise. I'm just saying that
> because software writing is expensive the
> hardware should facilitate it at the cost of
> some speed even. Especially since the hardware
> techniques may evolve, but the architecture
> must stay compatible in future.

Sorry to pick on your example, but programmable
CPUs are the subject of the discussion.  

(Mostly) everything is relative.  In the patterns case,
CPU performance is incrementally improved, but I
don't think this was the point in the design choice.
I believe the real issue was correct hardware function
with a reduced transistor count.

I agree with the principle that design choices
should be made with the full range of use/application
being considered.  I also think those hardware
designs are pretty expensive too.

I don't believe the issues many take with MISC are
actually significant, and I would gladly work with
a little wierdness like patterns since the alternative
might be some mess like a segmented memory model.
By comparison, the pattern thing is invisible.

In fact, anyone who has bothered to understand direct
or indirect threaded code and the Forth interpreter
should sluff off patterns without a second thought.
 
> The design goals for MISC were if I recall correctly:
> - small
> - quick
> - cheap

I think Jeff is there if the chip were mass produced.

> But implicit goals are always:
> - easy to use

This is in the eye of the beholder.  We are talking
Forth after all.

> - available
> - well documented

I live in glass house on these as does anyone that
isn't putting thier effort where their mouth is on
MISC design.  I don't see any other two man shows
that can touch what Jeff and Chuck have done.  Ting
deserves lots of credit in this area also.

> Just focusing on speed isn't wise. Anyway, with

I don't believe this was ever the case with MISC.
Spectators just focus on speedup issues.  It's easy;
they don't actually have to think about what's really
going on.
 
> At the moment of the birth of the MISC the 486 was
> already around so there was already a lot doable.

Neither Forth or MISC are about more of the same.
They are a hunt for another path, a more direct or
fruitful path.

I can't believe people won't check their preconceived
notions at the door when entering Chuck Moore land.
If the old baggage must come along there isn't much
of a point in taking the trip.

> I understood from postings here that people were
> confronted with this problem in software. I wouldn't
> mind if the hardware were completely transparent.

Jeff has repeatedly clarified that the pattern
thing is only an issue in a couple of situations,
mainly when cross compiling for the MISC from
another architecture.

> I don't understand you. Do you compare 'memory to
> register' to RISC or against a stack-machine?

No, I was trying to reinforce the idea of hardware, software
and market forces not necessarily getting us what we want
or even good CPUs.

> I think that, as the RISC philosophy acknowledges,
> new CPU architectures should be jointly designed
> by hardware and software people. As regards the
> software people, compiler builders, OS writers
> and application writers should have their say or
> at least the interests of the later two should should
> be given consideration.

This is what I believe I saw in MISC.  It was just
a one man show and the guy likes to hammer away from
first principles.  I can't think of anyone more in
tune with the hardware/software tradeoff for Forth
than CM.

On the flip side, the VAX architecture claimed
to come from just such a collaboration.

> The AMD 29000 series for example has an array
> of 128 registers, which are a software regulated
> cache on the stack. However since it has to be
> arranged in software it's very expensive and task
> switches become very expensive. That's probably
> why the Am29000 flopped as a general processor.
> It later also flopped as an embedded processor and
> AMD stopped supporting it in favor of their embedded
> 186 family.

You know, I think bit-slice just fell to scaling,
real estate and COTS issues.  Why design at the
bit-slice level when adequate performance was available
in a single package with a much smaller footprint and
less power dissipation.

10K MECL was the stuff I wanted to fool around with.

> Haha, you'll never hear me defend the x86. The NS320xx

8^)

> is from around the same time and it's completely build
> on orthogonality and has no segmentation etc. Intel
> has never built a nice processor except perhaps the i960.

One more strike against the future of MISC.  Good
designs finish last.

> I agree, but all too often the hardware designers
> ignore practical software demands.
 
I had to can one once because he insisted in taking
working code and speeding it up without maintaining
boundary tests.

> Yes, it was nice and interesting for a couple of years.

Like many "forums" on the Internet, most of this list
is traffic from "armchairs".  I tend to ignore
most of what comes from the non-principals on the list.
Consider the on-chip memory threads for example.

Forth hasn't really ever gotten anywhere either, but
I'm glad I've known and used it.  The MISC hardware
effort has been intellectual exercise, and all who
participated have benefited whether they realize it
or not.

If the chip thing actually happens it'll be gravy and
a total fluke.  How many commercial chip efforts
have failed to fly in the market place?  *21 was going
to do better?

So, my claim is: MISC is hacker research into
IC CPU design.  Why would anyone expect commercial type
results?  Why wouldn't each of us see the-story-so-far
as a success?  

-- Mark Walker <mw@swcp.com>

   If it stinks, it's chemistry. If it moves, it's biology.
   If it does not work, it's computer science.

                            -- Laurent Bardi <lolo@ipbs.fr>