Re: Chucks address

[Jaap van Ganswijk <ganswijk@xxxxxxxxx>]

At 00:48 20000615 -0600, Mark Walker wrote:
>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.

Reduced transistor count should also have been weighted
against programmer comfort.

>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.

Not when you find the right balance.

>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.

It should be completely invisible.

Please consider that the processor has to compete
against other processors in many respects to become
a success.
One shouldn't focus so much on it using 5% less transistors.

>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.

One shouldn't focus on Forth so much. You guys
have so much in come with a sect.
You can discuss with people who believe in god
as much as you can, but they will never really seriously
discuss the notion that god could not exist.

I have never seen serious discussions here doubting
the strenght of Forth (unless I started them).
 
>> The design goals for MISC were if I recall correctly:
>> - small
>> - quick
>> - cheap
>
>I think Jeff is there if the chip were mass produced.

Yes, if... But other factors prevent that.

>> But implicit goals are always:
>> - easy to use
>
>This is in the eye of the beholder.  We are talking
>Forth after all.

Forth is only easy to use when you're scribbling
down a small program (as for as I know). But even
the programmer itself doesn't understand his own
code anymore after a day let alone that others
can understand it. I large proportion of writing serious
code consists of rereading your own coding and
code of others to check if it might possibly induce
errors.
I was an embedded systems programmer. A large
portion of my time was spend on trying to locate
hardware errors (or getting to know more on
hardware aspects that weren't documented well
enough or were documented incorrectly) a small
portion was spend on just writing things, a large
portion was spend on thinking about concepts,
and a very large portion was spend on checking
code or revising it because of users wishes.
This requires re-re-re and re-reading the code
and therefore it needs to be very rereadable.

I dare you to convince me that (multi-typed)
Forth has that quality.

>> - 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.

If I were interested in buying a microcontroler for
a real project I would be interested in getting real
information about a real product that I could really
use.

You can give me 10 Mbyte of data about something
that's not a real product but it's still data and not
information however much the groupies of the
product like it and thinks it gives them insight in
what their high priests do.

>> 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.

Yes, first I noticed MISC it promised 500 Mips or
such when Intel processors were pushing 100 Mhz.

I have never seen the high priest of MISC place
critical remarks. They liked the flocking of groupies
it seems.

>> 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.

Any sect will use this sentence. I wasn't saying that the
486 is or was perfect, just that the MISC wasn't that
spectacular as regards hi-tech.

>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.

You old hippie really see it as a trip? ;-)

Why doesn't the MISC processor comes with a
small sugar cube of LSD then?

>> 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.

It should be completely transparent.

>> 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.

Forth is wrong.

21 bits is also wrong by the way.

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

So? Check logical thinking. People implementing
a theory wrong means the theory is wrong?

>> 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.

You confuse the Am29000 with the Am2900 which was
indeed bit-slice.

>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.

Not necessarily. Often the best design doesn't win, but
it's seldom that the worst design (which is close to the
non-exisiting design) wins. We're just pissed that a
suboptimal design gets popular.

>> 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, boundary tests... But lets not get into that tangly
and highly philosophical issue... ;-)

>> 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.

Yes, I never felt compelled enough to unsubscribe.

>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?  

I think at least Jeff took it seriously and lost a lot
of money in the process.


Groeten/Greetings,
Jaap

-- Chip Directory
-- http://www.chipdir.com/chipdir/
-- http://www.fh-kl.de/~rscherer/chipdir/ - New in Germany
-- And about 30 other mirror sites world-wide...
--
-- To subscribe to a free 'chip issues, questions and answers'
-- mailing list send a message to listguru@fatcity.com with
-- in the body subscribe chipdir-L