Re: [colorforth] Intellasys question for Jeff Fox
- Subject: Re: [colorforth] Intellasys question for Jeff Fox
- From: John Drake <jmdrake_98@xxxxxxxxx>
- Date: Mon, 26 May 2008 18:17:35 -0700 (PDT)
----- Original Message ----
From: "gwenhwyfaer@xxxxxxxxx" <gwenhwyfaer@xxxxxxxxx>
To: colorforth@xxxxxxxxxxxxxxxxxx
Sent: Monday, May 26, 2008 12:25:24 PM
Subject: Re: [colorforth] Intellasys question for Jeff Fox
On 26/05/2008, John Drake <jmdrake_98@xxxxxxxxx> wrote:
>> Nonsense.
> That's just plain rude.
You accuse someone else of being evasive and you have the
nerve to call me rude? More nonsense. And you haven't seen
me be rude. I called what you said nonsense and in my opinion
(still) it was. I see no reason to take that personally. I sometimes
say things that are nonsense too.
>> Machine precision for a 386 is obviously up to 32 bits.
> Especially since this is just plain wrong. Jeff cited a 386/387 combination, which implies the use of the 387's transcendental instructions;
The CORDIC algorithm doesn't use transcendental instructions. Now true Jeff mention the 387
but he said nothing about transcendentals so you just made an assumption. I can see how you
made that assumption based off Jeff's post, but what he says on his website looks like he's
comparing CORDIC implementations.
From Jeff's website:
==============================================================================================
Dr. Montvelishsky is currently doing work for Ultra Technology. He has
submitted several routines for the MuP21 and F21 microprocessors under
development at Computer Cowboys by Charles Moore. Dr. Montvelishsky's
CORDIC function executes 50 times faster on MuP21 than on a 387. Here at
Ultra Technology Dr. Montvelishsky will be consulting on the design of
parallel Forth extensions for the F21 Parallel Forth engine, robotics,
scientific programming, and on using Forth to teach computer science.
==============================================================================================
>
>> Machine precision for an F21 would be 20 bits. No "evasion".
> And no apples-to-apples comparison either. That's where the evasiveness comes in; 20-bit CORDIC on an F21 might well be 50 times the speed of a 387, > but what about one that matches the 387's precision? What about the 487, which was actually contemporaneous? What about an integer-only
> implementation for the 486?
What about it? I posted a link to a integer Forth implementation of CORDIC for gforth. Feel free to implement it and run whatever timing
you like. Feel free to implement CORDIC on a SEAForth simulator and check the timings since you're so interested in this.
> The only way the figure is meaningful is as a comparison of two different styles of programming - the style of carefully rethinking everything
> from the ground up and only implementing what you need in precisely the way you need it, compared with the style of starting with as rich
> an environment as possible and hoping whoever implemented it didn't screw up. As comparisons of technology, they're almost meaningless
> without extensive commentary - a point I made in my previous email.
Yes. Wonderful extensive commentary. Good for you. All of this over two chips that at this point aren't in production. You're
looking back I'm looking forward. Great. Wonderful. It takes all kinds.
> (It is possible that I'm actually in what has come to be termed "violent agreement" with Jeff, or even yourself, on this point. But the fact is that stating the > 50:1 ratio as a comparison in itself, without making this clear, has been fuelling the likes of John Passaniti for the last decade; it's just too depressing to > go to c.l.f and see Jeff and John still engaged in the same flamewar I found them fighting 15 years ago. It is transparently clear that the F21 and the 386, > or the C18 and the Core 2, will not do anywhere close to the same things at all; it is also clear that if your application will fit inside a C18, a Core 2 will be > a waste of money - but that if your application doesn't need the speed of a C18, a PIC may be a better bet; it may well be the case that if your application > can use the C18's raw speed - but let's not forget that 1000 MIPS isn't anything special these days, and in any case that's a theoretical peak for a C18,
> not a much more useful sustained rate figure - a Core 2 would be quite inadequate for the task. Perhaps the only appropriate comparison for a C18, for
> those of us without fab access, would be 1/24 of whichever Xilinx or Altera FPGA is closest to the SEAforth-24A in unit cost.)
The only thing I've learned from John Passiniti's commentary over the years is to ignore John Passiniti's commentary. He and others at comp.lang.forth
are often spoiling for a fight. It doesn't matter what you're trying to say. Case in point was when I pointed out that you can do "Hello World" in
ColorForth as easily as you can in any other Forth. Yes it requires first extending ColorForth but then you have several reusable useful words.
That's what Forth is supposed to be about. But some of the "gurus" have nothing better in life than to try to tear down anything that isn't
ANS Forth or some variant. I've learned to forget about them and if you want peace of mind then my suggestion is to do the same.
No matter what interesting result you have someone will try to find some way to minimize it. That's just life.
>> For the record a recent (2 years ago) 16 bit implementation
>> of CORDIC was posted on comp.lang.forth.
>>
>> http://www.complang.tuwien.ac.at/forth/programs/cordic.fs
> That's great, but a 16-word lookup table is a significant chunk of a 64-word memory. Moreover, the great advantage of CORDIC is that it doesn't need
> multiplication - but if you have a single-cycle multiply and a decent amount of memory, you can use a lookup table and linear interpolation and reduce the > cycle count dramatically.
I never suggested that you use this ANS Forth implementation for the SEAForth and that's not the reason I posed it. But this will give you the
"apples to apples" comparison that you want so badly (and least the Pentium apple). All that's left is to implement you own SEAForth
variant or wait for the library release. As for any optimizations you might want to do to the code, remember it's already been optimized
by one of the c.l.f. "gurus". *wink* So if you're really intent on impressing the c.l.f. crowd......
>> So if anyone REALLY cares about benchmarks (I don't)
> That's nice for you, but people deciding which chip to select for their new application need some way of determining whether or not that application can
> even be executed by that chip. Only hobbyists can afford to start with the processor and build outwards; not even Chuck has done that - his processors
> are built to fit their intended applications.
I will apologize in advance for offending you, but the above in nonsense. I never said I didn't care if an application can "even be executed". In
fact if you were paying attention to the original post you'd note that I started this thread specifically to find out what steps could be taken
to help someone else who had asked about getting transcendentals for the SEAForth. In other words I was trying to help someone
"determine whether or not that application can even be executed by that chip." And Jeff has answered the question to the affirmative.
Now we've gotten sidetracked on whether or not you can compare an F21 to a 386/387 and frankly I don't find that interesting but
I'm glad you do.
>>> What was the cheapest that single F21 chips were ever available?
>>
>> You're missing the point. Jeff isn't talking about OTS cost.
> Then Jeff isn't talking about anything useful to anyone without their own fabrication facilities. (Do you have your own fab?) If I were looking for a chip to
> use in my design, I'd be looking at unit costs; a fab cost of "a couple of cents" is pointless to discuss when the unit cost is $40 (or even $4).
Are you considering using an F21 or a 386/387 in your design? If you're seriously considering 386/387 chips I would suggest going to
your local computer scrapyard (although today I think all you'd find are Pentiums of some kind or another.) If you are considering using
an F21 then those chips are for the most part no longer available. And no I don't own a fab. I don't know if Jeff owns one but he certainly
didn't when the F21s were manufactured. If you want to know how to manufacture chips without owning a fab it's called using OPF.
(Other people's fabs.)
I forget who manufactured the F21 but I recall looking up the costs. The more chips you manufactured the cheaper per unit it was.
Now I realize I'm belaboring the obvious but you're dragging this out for some reason. If you wanted genuine 386/387 chips for
some reason it would cost you more per unit to fab them then it would the F21 equivalent. (I don't think you can buy 386s
directly from Intel. There is a company that makes all sorts of old chips even to the old "Z80" but they don't list their prices.)
Now if you are serious about comparing "apples to apples" you could ask how many FPGA gates it would take to make
an F21 equivalent to a 386/387 equivalent. That's not a question I care about but someone else might find it interesting.
Regards,
John M. Drake
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com