Re: Chucks address

[Greg Alexander <galexand@xxxxxxx>]

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

We're not focusing on 5%, we're focusing on 5x, or 50x.
7,000 transistors getting 80 MIPS even if the instructions are simple is
not something you can dismiss so easily.

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

I doubt the weaknesses of FORTH: I doubt both that they are worth
overcoming personally, and I doubt that they exist.  See, it's impossible
for me, as a FORTH newbie, to imagine ever becoming comfortable with stack
manipulations: every time I find myself writing DUP ROT ROT I end up
wasting 5 minutes before I realize I could write SWAP OVER.  But I know in
C I felt equally alienated by pointers after I had much more experience
with C than I have with FORTH.  I have a bit of an advantage here, being
young enough that I can clearly remember being a C newbie even though I am
now an experienced C programmer.  So on the one hand I doubt that I will
ever be able to work with the stack effortlessly.  On the other hand,
experience has shown that this doubt is probably not based in reality.

There's no point in doubting the strengths of FORTH.  They are obvious and
they are numerous.  It's fast, it's simple, it's easy to use for small
programs, etc.  The thing to look at is the perceived weaknesses: that it
is hard to read, that it is unusable for large programs.  I'm finding both
of these to be myths as I learn more.

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

hahahha, no.  I can read my code just fine.  When I first wrote my
solitaire program I had two move functions, one to move a single card and
one to move n cards.  Bad move.  So I just straight-up deleted those two
functions.  I knew they were implemented badly and I knew that I would
come up with a better design for that whole side of the system If I
started over.  Sure enough, even my user interface got better.  I replaced
a 5 line function with a 3-line function and 2 1-line functions.  The 3
line function is still difficult to read, though not even close to
unreadable...but the 1-line functions are very readable.  The trick to
FORTH is that FORTH is not the language: we develop a language that should
be easy to write our program in.  The two one-line functions are simple
and writing the other function in them makes it much clearer and simpler.

If your functions are small enough and well-chosen, FORTH is plenty
readable.  I'm going to assume since you don't already know this that you
are merely ignorant.  I can't blame you -- it's not easy to learn a
totally new system when the ones you know are so useful.  C is good enough
for most people, and there are plenty of systems essentially the same that
differ in a lot of ways that you can find a lot of variety just in the C
world.  In FORTH you make your own variety.

>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 would strongly encourage you to use Forth for such things.  For testing
hardware, there's nothing better than an interactive FORTH system running
on your embedded target.  For testing code, there's nothing better than an
interactive FORTH system running on your embedded target.  Further, if you
factor like a mad motherfucker, you will end up with small enough
functions that assuring yourself that they work is easy.

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

Multi-typed?  You seem to care a lot about this 'single-type' aspecct of
Forth.  Think about it: inside the machine, everything has the same
format.  Okay, maybe you also have floating point numbers.  Chuck has
chosen to dismiss them -- I can't say as I blame him, but it is a
limitation, an inconvenience.  In C you spend a lot of time typing in
casts that cast between integers -- why would I want to do that?  An
integer is an integer is an integer!!  That can be a rather mindblowing
statement in C because it comes out as "A character is a pointer is an
integer!!" which sounds quite bizarre.  Why name them differently if they
are the same?  The worst is when you want to do something C won't let you
do.  Ever try to write a macro to get the significand of a floating point
number?  You need to actually allocate memory to the floating point number
so you can cast the pointer without changing the data!!  What an ass pain.

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

I assume by 'real project' you mean 'money maker.'  To me a real project
is putting a P21 in my pocket and a keyboard on one arm and a display on
the other.  Your real project will help millions and earn millions, but
mine, it will help me and I'll enjoy it.  If I'm not a better engineer
when I'm done (if I ever am done), you win.

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

Why do you bother to talk if not to share ideas?  The whole internet is
not here because it's technically possible, it's here because sharing
information is a bit more valuable than the technology itself.

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

haha, yeah it is.  I'll say it again: 7,000 processors, 80 MIPS, and an
assembly language that is only half a step removed from a comfortable
programming language.  Developed by one man in an outdated process.  It is
spectacular.  Anything simple is spectacular.  If your jaw doesn't just
drop at how spectacular the simplifications available in FORTH are then
you really have no view here: your aesthetic sense is essentially
different and, to us, wrong.

We think you can do more with simplicity.  That's important.  But more
important is that we think simplicity is drop dead gorgeous.

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

It is, isn't it?  People take acid for a lot of reasons, but I'm pretty
sure the people who coined the word 'trip' were thinking of it not as
something acid does to you, but something acid helps you do to yourself.

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

Because you don't need the LSD to come up with the profound ideas, it's
only there to help.  I've begun tripping while meditating: does that mean
a meditation class should distribute LSD?  No way.  It's an alternate
means to a vaguely similar ends.  Science is a definite trip.  Fiction can
be trippier than all.  Why bother to distribute acid with a book if the
book itself changes your mind and lets you see new things?

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

No, never.  If it doesn't cost anything in software ($AA XOR while
cross-compiling is free -- I'm not even going to debate about that) to
'work around' it and it would cost anything at all in hardware to not
work around it, why bother?

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

Forth is also right.  *shrug*

>21 bits is also wrong by the way.

The number of bits doesn't matter.  8 bits is wrong only because you can't
address even simple code in just 8 bits.  10 bits is pretty borderline.
16 bits is good enough for most things.  Obviously you wouldn't do the
same things on a 21-bit MISC chip that you would on a 64-bit SGI
PowerChallenge.

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

So therefore the fact that MISC silicon is underdeveloped compared to MISC
ideals is meaningless.  Thanks.

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

What could be worse than Windows?
It's the worst possible thing that could possibly work at all.

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

Lost?  What the hell do you spend all your money that you earn in your
high-paying jobs that involve 'real projects'?  Jeff got what he paid for.
Jeff wasn't expecting to sell it the way that Intel or Motorola sells a
chip, I think he was expecting to sell it like Ting sells chips -- one or
two at a time, maybe a couple bulk deals, but mostly singles to hackers.
Every interesting research needs a proof of concept: that's what Jeff&Ting
are doing.  I think they're succeeding better than anyone else in their
shoes are.  Are you just jealous that you don't have the wherewithall to
design your own silicon?  You seem downright dependent upon the commercial
enterprise for intellectual stimulation.  I bet if you didn't have a job,
you'd be bored.  Well that's not us.