marmar@mtk.UUCP (Mark Martino) (08/16/89)
I was reading an article by Brian Case in the August issue of "Microprocessor Report". He brought up two issues that bugged me a little. I was wondering what the rest of you think about his ideas. After a fairly even-handed comparison of Forth chips versus RISC chips (with a slight bias towards non-Forth languages), he asserts that using a Forth based system will end up being about as expensive as a RISC based system. I found it hard to disagree with him, even though I would like to use Forth and Forth chips. This reminded me of a question for which I still do not have an answer. Why are the RTX2000 and the SC32 more expensive than RISC chips? Despite the economies of large volume production, I thought that implementing Forth in silicon would be relatively cheap since it takes comparatively fewer gates than previous architectures. I realize everyone likes to make up their R & D costs, but both of these chips had a lot of their design work done before their current developers implemented them. The second issue has to do with the near future of Forth chips. In the last few paragraphs Brian concludes that in order to operate at clock rates greater than the current 10-12 MHZ, Forth chips will have to fall back to using pipelining as do RISC chips. He then says that Forth chips will look very much like RISC chips anyway. Will this really be necessary? Has anyone else seen this article? What do you think about his arguements?
olorin@walt.cc.utexas.edu (Dave Weinstein) (08/16/89)
In article <893@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: >[...] Brian concludes that in order to operate at clock rates greater >than the current 10-12 MHZ, Forth chips will have to fall back to using >pipelining as do RISC chips. NO!!! Bearing in mind that the designed use for most of these Forth chips is in Realtime applications, adding pipelines is one of the worst things you can do! Realtime applications need to be predictable (i.e. take the same number of cycles to do the same thing each time), and throwing in pipelines destroys that predictability (you get greater *overall* throughput but actual mileage may vary). I don't believe Harris will do this (they have been touting the predictability of the RTX family throughout their literature. --Dave -- Dave Weinstein olorin@walt.cc.utexas.edu (512) 339-4407 Home GEnie: DHWEINSTEIN My employers never agree with me anyway.
tim@cayman.amd.com (Tim Olson) (08/17/89)
In article <17173@ut-emx.UUCP> olorin@walt.cc.utexas.edu (Dave Weinstein) writes: | In article <893@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: | >[...] Brian concludes that in order to operate at clock rates greater | >than the current 10-12 MHZ, Forth chips will have to fall back to using | >pipelining as do RISC chips. | | NO!!! Bearing in mind that the designed use for most of these Forth | chips is in Realtime applications, adding pipelines is one of the worst | things you can do! Realtime applications need to be predictable (i.e. take | the same number of cycles to do the same thing each time), and throwing in | pipelines destroys that predictability (you get greater *overall* throughput | but actual mileage may vary). I don't believe Harris will do this (they have | been touting the predictability of the RTX family throughout their literature. This is not true. Pipelining per se does not affect determinism. Things like caches and interlocks on parallel functional units *can* affect it. -- Tim Olson Advanced Micro Devices (tim@amd.com)
bcase@cup.portal.com (Brian bcase Case) (08/17/89)
>I was reading an article by Brian Case in the August issue of "Microprocessor >Report". He brought up two issues that bugged me a little. I was >wondering what the rest of you think about his ideas. Hi. I am the author of that aritcle. I will add some comments in my reply here, but feel free to send me mail if you have short, direct questions. Maybe I can learn something too. >After a fairly even-handed comparison of Forth chips versus RISC chips >(with a slight bias towards non-Forth languages), he asserts that >using a Forth based system will end up being about as expensive as a RISC base d > system. I found it hard to disagree with him, even though I would like to >use Forth and Forth chips. The system cost is highly variable. My comment was based on the cost of CPU chip and SRAMS to make it run. A RISC might require more stuff after that, but so might a FORTH chip. If you are going to use a lot of CPU chips, you might be surprised how much lower the prices for RISCs can go. On the other hand, if you are going to use a lot FORTH chips, you might be able to arrange a really good deal with an independent foundary too. Also, some RISCs are VERY expensive: 88K, i860, e.g. Some are cheap: 29K, i960, and some SPARC implementations. >This reminded me of a question for which I still do not have an answer. >Why are the RTX2000 and the SC32 more expensive than RISC chips? Despite >the economies of large volume production, I thought that implementing Forth >in silicon would be relatively cheap since it takes comparatively fewer >gates than previous architectures. I realize everyone likes to make up their >R & D costs, but both of these chips had a lot of their design work done >before their current developers implemented them. I don't know the true answer to this question (why are FORTH chips as expensive as RISC chips), but I can make some very educated guesses. First, there's volume. Second, a large part of the cost can be in the package, which is the same for almost everyone (the Japanese might have an advantage here). Third, the number of gates in the *processor* of a FORTH chip is small, but the implementations in the RTX and SC32 have some on-chip RAM. Thus, the die sizes are not all that small. Forth, the RISCs are often implemented in 1.2 micro and smaller technology, which the FORTH chips are forced to use available independent technology, which is typically 2 micro. This is another reason die sizes are not that small. Chip cost = Package + die cost + profit_margin. >The second issue has to do with the near future of Forth chips. In the last >few paragraphs Brian concludes that in order to operate at clock rates greater >than the current 10-12 MHZ, Forth chips will have to fall back to using >pipelining as do RISC chips. He then says that Forth chips will look very >much like RISC chips anyway. Will this really be necessary? When I started writing the article in the uP Report, I began by reading the data sheets, skimpy as they were. I was appalled when I added the clock-to-address stable and data setup times together: At 10 MHz, there were 18, yes eightteen, nanoseconds left for RAM access. That means, if you design a system to spec, you need 18 ns RAMs to use the particular chip that that data sheet described (I now forget which it was, probably the SC32). I called Silicon Composers to make sure I wasn't making a mistake; they said, "Oh, yeah, we never noticed that. You are right, but the chips we get are much better than that." Why is such fast RAM required? Because of the chip design: they are probably using generic pad drivers and the clock-to-address-out path includes a lot of on-chip logic. RISCs use custom-designed (optimized) pad drivers to minimize the time to drive signals off-chip, and they use pipelining to take the on-chip logic out of the critical path. The upshot is that at 20 MHz, even with great pad drivers, you might need -10 ns SRAMS for the FORTH chips. The solution? Pipelining. But with pipelining, you can't do single-cycle instruction execution without introducing warts. Without single-cycle instruction execution, the advantages of the FORTH chips are diminished. In short, until the entire memory system can be on-chip (that's coming, but don't hold your breath), the FORTH chips will be second-class citizens in raw performance. However, for the byte counters and cycle counters among you, a FORTH chip can be a good choice: it is easy to say how many bytes and how many cycles something will take (although compiled FORTH makes this harder). If you want the best performance, you need pipelining, caches, registers, and three-address operations. etc. etc. etc. Enough for now. I'll try to answer more questions about my reasoning.
koopman@a.gp.cs.cmu.edu (Philip Koopman) (08/17/89)
I'm not going to bore everyone with a bunch of excerpts, but there has been a conversation about costs and design options for Forth chips that I would like to comment on. System costs for the high-end RISC processors are *much* more expensive than stack-based chips (e.g. about $2500 per chip set for an 88K last time I checked). Don't be fooled by systems that have a reasonable processor cost and then require MMUs before they will work at all. Forth processors can have smaller memories (and therefore system costs) because they introduce a much smaller run-time penalty for heavy subroutine reuse. On the RTX-32P, subroutine calls cost about 0.7 clocks, and subroutine returns about .2 clocks, on the average (if memory serves). Of course the SC32 is expensive now, because they don't have that big a market built up yet. The RTX 2000 can be discounted if you want to order a few thousand. That's the same as with all chips. Although the RTX 2000 has a small core, it also has two on-chip stacks and a hardware multiplier, which run up the die size a lot, and therefore the cost. > > I realize everyone likes to make up their > >R & D costs, but both of these chips had a lot of their design work done > >before their current developers implemented them. 1) Do you think the original designers gave away their work for free? 2) The Novix chip was broken in many respects, and a *lot* of redesign was done. On the topic of memory bandwidth, there is no inherent reason why stack machines should have a memory access problem. The RTX 2000 memory bandwidth bottleneck is a direct result of Chuck Moore's philosophy that fast memory was cheap (since he probably didn't need more than 8K words for any of his programs anyway). I have proved to myself that clock speeds and effective processing rate can be improved by a significant amount, even using the same fabrication process and perhaps even slower memory chips. It's all in how you look at the problem and approach the design. Pipelining does not affect the consistency of response in a real time program, but it does affect the interrupt response latency, since you have all that state to save when processing an interrupt. There is absolutely no requirement to pipeline stack processors in the RISC fashion in order to get significantly higher performance. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
olorin@walt.cc.utexas.edu (Dave Weinstein) (08/17/89)
In article <26801@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes: >In article <17173@ut-emx.UUCP> olorin@walt.cc.utexas.edu (Dave Weinstein) writes: [Pipelines --> Non-deterministic processor] >This is not true. Pipelining per se does not affect determinism. >Things like caches and interlocks on parallel functional units *can* >affect it. Right. (Sigh). I was assuming things not in the question (i.e. the instruction cache along with the pipeline). Now the question is, how useful are pipelines *without* cacheing and interlocks? --Dave -- Dave Weinstein olorin@walt.cc.utexas.edu (512) 339-4407 Home GEnie: DHWEINSTEIN My employers never agree with me anyway.
tim@cayman.amd.com (Tim Olson) (08/17/89)
In article <5882@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: | Pipelining does not affect the consistency of response in | a real time program, but it does affect the interrupt response | latency, since you have all that state to save when processing | an interrupt. What pipeline state do you need to save when responding to an interrupt? Everything in the pipeline before the "commit point" is flushed, while everything after the commit point continues on through the pipeline. This all happens pretty much instantaneously. -- Tim Olson Advanced Micro Devices (tim@amd.com)
tim@cayman.amd.com (Tim Olson) (08/17/89)
In article <17225@ut-emx.UUCP> olorin@walt.cc.utexas.edu (Dave Weinstein) writes: | Now the question is, how useful are pipelines | *without* cacheing and interlocks? Pipelining a processor is one way of helping to reduce the cycle time and increase performance. It does not require caches or other speedup techniques to be useful. One problem with pipelining is that conditional jumps tend to break the pipe, reducing the advantage of pipelining in programs that have many conditional non-sequential fetches. However, most of the non-sequential fetches in FORTH are unconditional (following the thread of control). -- Tim Olson Advanced Micro Devices (tim@amd.com)
mef@aplcen.apl.jhu.edu (Marty Fraeman) (08/18/89)
In article <893@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: >I was reading an article by Brian Case in the August issue of "Microprocessor >Report". He brought up two issues that bugged me a little. ... > >This reminded me of a question for which I still do not have an answer. >Why are the RTX2000 and the SC32 more expensive than RISC chips? Despite >the economies of large volume production, I thought that implementing Forth >in silicon would be relatively cheap since it takes comparatively fewer >gates than previous architectures. I realize everyone likes to make up their >R & D costs, but both of these chips had a lot of their design work done >before their current developers implemented them. Perhaps John Hayes (sitting here next to me even as I type this) and I (two thirds of the engineering team that designed the SC32) can supply some technical information about it. I believe the major factor effecting cost is die size. The SC32 was designed with the Genesil silicon compiler and is big (about 10mm on a side) when built on a 2 micron fab line. Even though transistor count is fairly modest (35,000 for the SC32) you still can't get many chips that size on a wafer. I think if we redid the SC32 with full custom we'd get the area down 25-50%. Note that a 1 micron version of chip would be about 5mm on a side so in high volume production it should cost less. The RTX2000 is a standard cell design and I believe its almost as large as the SC32. > >The second issue has to do with the near future of Forth chips. In the last >few paragraphs Brian concludes that in order to operate at clock rates greater >than the current 10-12 MHZ, Forth chips will have to fall back to using >pipelining as do RISC chips. He then says that Forth chips will look very >much like RISC chips anyway. Will this really be necessary? > I tend to agree with this conclusion. The reason we didn't pipeline the SC32 was because of the characteristics of Forth. Frequent access to the the top few stack locations will cause resource conflicts that need extra hardware to resolve. The high frequency of branches in Forth will generate lots of delay slots that need filling. At the time we didn't see how to do a good job of that and even if we did, the volume of application object code would greatly increase. >Has anyone else seen this article? What do you think about his >arguements? Generally we found the article technically accurate although there were some minor points that we had problems with. The last paragraph of the section "Why Choose a Forth Chip" was pretty good. I'd quote it here if I wasn't scared to death of the copyright police -). Except for the comment about one person software teams, it nicely summarized our goals when we designed the chip. Marty Fraeman mef@aplcen.apl.jhu.edu 301-953-5000, x8360 JHU/Applied Physics Laboratory Johns Hopkins Road Laurel, Md. 20707
jax@well.UUCP (Jack J. Woehr) (08/18/89)
In article <893@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: ( in re: sc32, rtx, and cost of same) ... >I realize everyone likes to make up their >R & D costs, but both of these chips had a lot of their design work done >before their current developers implemented them. There are costs, costs, and more costs involved in introducing a chip. It ain't mass production that makes them cheaper, it's mass BUYING of them that makes 'em cheaper. There is tons of documentation to write, testing, bug fixing, etc etc etc marketing, etc ... it's endless. Did you know that there are only about 100 SC32's in existence? {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{} {} {} {} jax@well ." Sysop, Realtime Control and Forth Board" FIG {} {} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {} {} JAX on GEnie ." Tell them JAX sent you!" Coordinator {} {} {} {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
koopman@a.gp.cs.cmu.edu (Philip Koopman) (08/18/89)
In article <26815@amdcad.AMD.COM>, tim@cayman.amd.com (Tim Olson) writes: > What pipeline state do you need to save when responding to an interrupt? > Everything in the pipeline before the "commit point" is flushed, while > everything after the commit point continues on through the pipeline. > This all happens pretty much instantaneously. If you choose to flush your pipeline because it is cheaper than saving the state of it (which makes a bit of sense), you still have an interrupt latency that reflects the time spent refilling the pipeline. AND, you have a built-in latency for processing the interrupt that reflects the time it takes for the interrupt service instructions to get through the pipeline. Now, if a few microseconds for an interrupt latency is OK, then pipelining works fine. But, if you want faster interrupt response, you have a problem. The RTX 2000 takes 4 clock cycles (400 ns) between the time an interrupt is asserted on a pin until it is actually executing the first interrupt service instruction. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
tim@cayman.amd.com (Tim Olson) (08/19/89)
In article <5902@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: | Now, if a few microseconds for an interrupt latency is OK, then | pipelining works fine. But, if you want faster interrupt response, | you have a problem. The RTX 2000 takes 4 clock cycles (400 ns) between the | time an interrupt is asserted on a pin until it is actually executing | the first interrupt service instruction. The Am29000, a pipelined RISC processor, takes 7 cycles worst case from assertion of an interrupt pin to the first instruction of the interrupt handler entering the execute stage (using single-cycle external memory). At 40ns/cycle this is 280ns. Best case (hit in Branch Target Cache, array of interrupt handlers) can be as small as 3 cycles. This illustrates how pipelining can help -- the cycle time can be lowered enough that the resultant processor can be faster even if more cycles are required for exceptional conditions. -- Tim Olson Advanced Micro Devices (tim@amd.com)
marmar@mtk.UUCP (Mark Martino) (08/19/89)
Thanks to all who responded to my question concerning the cost of currently available Forth chips. I wanted to respond directly to the articles, but somehow our system just won't let me. I hadn't considered how much die size and package size affect price. So, when do they get reduced?
marmar@mtk.UUCP (Mark Martino) (08/21/89)
In article <13199@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: >In article <893@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: > >( in re: sc32, rtx, and cost of same) >... >>I realize everyone likes to make up their >>R & D costs, but both of these chips had a lot of their design work done >>before their current developers implemented them. > > There are costs, costs, and more costs involved in introducing >a chip. It ain't mass production that makes them cheaper, it's mass BUYING >of them that makes 'em cheaper. There is tons of documentation to write, >testing, bug fixing, etc etc etc marketing, etc ... it's endless. Did >you know that there are only about 100 SC32's in existence? > Okay, okay. I've been an engineer long enought to know that. What I didn't know was how few chips have been sold. Which brings me to my next point. I've seen quite a few articles in magazines and here on the net that demonstrate a lot of interest in Forth from outside the engineering community (and I use the word loosely). Forth is easy for non-technical people to understand. It's only drawback, until the Forth chips came out, was that it was slower than C. So, although I am glad to see that Harris is making a big push to Forth in machine control, I think there would be a bigger market if they'd build a board to go into a computer that could be sold to non-technical people. It would be much more of a "computer for the rest of us" than the Mac because it would be easier to understand from the ground up. As much as I like the Mac interface, there's an awful lot of software to support it. Most of this software is dedicated to maintaining the integrity of the "metaphors" the Mac is based on. Forth is simple to understand. The only metaphor you need is the stack which is easy to understand even without a metaphor. An artist, musician, theatre technician, bookkeeper, shopkeeper, or anyone else without formal training in computers can learn it enough to do what they want or need to do. I realize that Harris and Silicon Composers do not have distribution for these sorts of markets, but maybe should get them or get a company that has them or can develop them. This would sell chips galore. Most non-technical people like to stick with what they find comfortable. Once Harris or SC made some inroads into these markets, they'd have customers for life. I know a little bit about all this because I've been an electronic/software engineer for five years (and yes I do have a BSEE). Until I was thirty years old, I was a graphic artist with no background in science or engineering to speak of. I know what it's like to have techno-babble hurled at you in answer to what you thought was a simple request. I got so fed up with it, that I studied the stuff myself. Not everyone is going to react the way I did, but the point is this: Computers should help ordinary people do their jobs better and faster. Forth is the shortest path to this end. There's money to be made in matching people with Forth-based computers.
RAYBRO%UTRC@utrcgw.utc.COM ("William R Brohinsky", ay) (08/22/89)
I am in complete agreement with the sentiment that the time has come for the FORTH chip makers to put out boards. Look at what the KIM-1 did for MosTechnologies (which is now the captive foundry for Commodore). The 6502 was a real johnny-come-lately in the field, with the 8080 and the 6800 THERE for some time. The number of engineers who could get a KIM-1 (for $350, when I got mine) was large because MT committed themselves to mass producing a board for which there was no demand...at first. These boards ended up in finished products, mastering prototypes, and in general, fostering a love for the 6502 that raised it to equal usage with the intel 8-bit chips in consumer applications. At one time, I read in numerous tech mags (EDN, EP, Electronic Design, amoung others) that the 2 most used chips were 8080/8085 and 6502, the former by companies who had no philosophical problems with getting all their parts from off shore, and the latter by those who wanted all their parts from the USA. I cannot verify this, but I can say that my experience with the 6502 spoiled me against the intel chips (to this day) and prepared me for the 68000, and that none of this would have been possible without the KIM-1. For those of you who are too young to remember... The Kim-1 was a single-board computer in the finest sense of the term. It had a hex keyboard, 6 7-segment displays (4 for the 16-bit address, 2 for 8-bit data) which displayed numbers and the first 5 letters for Hex in the following manner: A b C d E F. It had the 6502, and a pair of RAM-ROM- TIMER chips (my memory gets foggy on these) with the KIM (Keyboard Input Monitor) software in the rom. The board's buffering was minimal, but as Hal Chamberlin prooved, the 6502 unbuffered drove more memory than a common (S-100) 8080 support bus could handle buffered! The timers were pressed into service to run a cassette interface (1200hz-2400hz nrz, I believe). Some third party developers got into the act and made add-on boards for the KIM-1 bus, and made some software for it (like PLEASE, which gave you the ability to banner messages on the 6 displays in an almost-readable-alphanumeric 7-segment output!). Like I said, I got this in 1976, for $350. It needed a power supply, which I built from a kit. It came with two manuals, one of which was vexing in its opacity to the uninitiated (me). But it allowed me to "bootstrap" myself by trial and error and a lot of independant study, so I am now desigining hardware, programming, troubleshooting the lot, and making a good living. This means more to me than lower chip prices (which it engendered). It means more designers who used the chip, who might never have started! The going price of an 8080-based computer in 1976 was $1200 or so, and that didn't include the cost of a terminal. They were heavy boat anchors of boxes, with heavily buffered backplanes, lots of slots for the many boards needed to make them work, and rows of front panel switches to talk to them, and rows of front panel lights to listen to them...I'd never have gotten a start! Maybe something with all the I/O (terminal, no matter how simple, and display) memory and processor would be too expensive for a forth chip, and maybe noone sells un-boxed boards anymore, but a KIM-1 style Forth chip demonstrator board which could have the same usefulness that the KIM-1 showed would help market the chips AND help grow the programmers and users to buy them. I think it's time for me to get off the soapbox... -raybro These opinions were formed after years of experience in forming half-baked opinions. Could they yet be termed fully-baked?
jax@well.UUCP (Jack J. Woehr) (08/24/89)
In article <896@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes: ... stuff deleted ... > Forth is simple to understand. The only metaphor you need is the >stack which is easy to understand even without a metaphor. An artist, >musician, theatre technician, bookkeeper, shopkeeper, or anyone else >without formal training in computers can learn it enough to do what they >want or need to do. > I realize that Harris and Silicon Composers do not have distribution >for these sorts of markets, but maybe should get them or get a company that >has them or can develop them. This would sell chips galore. Most >non-technical people like to stick with what they find comfortable. >Once Harris or SC made some inroads into these markets, they'd have >customers for life. ... more stuff ... >but the point is this: Computers should >help ordinary people do their jobs better and faster. Forth is the >shortest path to this end. There's money to be made in matching people >with Forth-based computers. At VESTA TECHNOLOGY INC. we agree with you. That's what we do for a living, we match would-be inventors and garage geniuses with single board Forth computers. Right now it's the 8088 and 80188. I have the 68000 and 68008 on my desk, when the manuals get written we'll sell them. We've tried to convince Harris and SC to see the light as you have seen it; so far, little luck. When the chip prices come down, we'll sell you your single-board RTX or SC-base computer. Are you listening, Harris? :-) {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{} {} {} {} jax@well ." Sysop, Realtime Control and Forth Board" FIG {} {} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {} {} JAX on GEnie ." Tell them JAX sent you!" Coordinator {} {} {} {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
koopman@a.gp.cs.cmu.edu (Philip Koopman) (08/24/89)
In article <13306@well.UUCP>, jax@well.UUCP (Jack J. Woehr) writes: > At VESTA TECHNOLOGY INC. we agree with you. That's what we > do for a living, we match would-be inventors and garage geniuses with > single board Forth computers. Right now it's the 8088 and 80188. > I have the 68000 and 68008 on my desk, when the manuals get written > we'll sell them. > We've tried to convince Harris and SC to see the light as you > have seen it; so far, little luck. When the chip prices come down, we'll > sell you your single-board RTX or SC-base computer. > Are you listening, Harris? :-) Some of Harris is listening -- sometimes. Right now, Harris offers the RTX-DS hardware/software package. It comes with a cross-compiled Forth. A ROM-resident Forth that executes on the RTX hardware (i.e. a "real" Forth) is also in the works. So, what's wrong with these? I don't mean to say that they are perfect -- I really want to know what's wrong. Right now Harris management says "we have never had any complaints about the fact that RTXDS is cross-compiled". Somehow, I find that difficult to believe -- I know *I* wouldn't want to use a cross-compiler for Forth! A few dozen complaints via e-mail might help change that. More to the point, who in the user community has a suggestion for what type of development systems would be useful? Do you really think that people would live with a KIM-like interface these days (yes, I have used a KIM, and times are different now)? What about cost -- how expensive or cheap? Remember, you tend to get what you pay for. What about software tools -- they can run up development costs a *lot*? I'm open to suggestions. I can't guarantee that I will influence anything, but it's worth a try. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
icsu6000@caesar.cs.montana.edu (Jaye Mathisen) (08/27/89)
I'm posting this for a friend, please direct comments, flames, remarks to him. His email address is given in his article. >From ieekw Mon Aug 21 12:55:59 1989 >Date: Mon, 21 Aug 89 12:55:51 mdt >From: ieekw (Winters) >To: dali!caesar!indri!aplcen!mef >Subject: Re: Cost of Forth Chips >Newsgroups: comp.lang.forth >In-Reply-To: <2709@aplcen.apl.jhu.edu> >References: <893@mtk.UUCP> >Organization: Montana State University >Cc: ieekw >Status: R > >From an architectural standpoint, I do not see a great cost difference >between Forth and RISC processors. Both have controllers of >tightly constrained complexity, and fairly generic datapaths. Beyond >this, die area depends on the amount of on-die memory desired: cache >memory for RISCs, register space for Berkeley-style RISCs, or stack memory >for Forth processors. It has been pointed out that the greatest difference >in current processors is implementation: most RISCS are full custom >designs while the RTX and SC32 processors are semi-custom. While >Marty Fraeman is correct in emphasizing the importance of die size >(Eldredge's Law: die cost varies with the cube of die area--from the >old Hewlett-Packard school of IC design) while citing potential area >gains from migrating the SC32 to a full custom realization, it should >be pointed out that such gains would likely apply only to the datapath >and controller portions of the processor. The memory modules are >typically assembled from similar compiler tools in either methodology. >I suspect that performance gains would outweigh cost gains in moving >to full custom Forth processors. (Not to discourage anyone, I think >it's still a good idea). > >On the other hand, die costs appear to be much less significant than >marketing considerations in processor pricing. The real question is when >the market for Forth processors will support the low-margin pricing >that RISC producers think about and CISC producers enjoy. > >Kel Winters >Montana State University >ieekw@caesar.cs.montana.edu > >"How do we do it? Volume, Volume, Volume." - David Letterman > >
jax@well.UUCP (Jack J. Woehr) (09/16/89)
In the discussion on the whys and wherefores of the high
price of Forth chips, we erroneously stated that there were only
100 SC32 Forth chips in existence.
We are informed by People Who Know Better that this assertion
is totally erroneous, that the quantity of SC32 chips foundried and
tested is actually much greater. We therefore wish to retract our
previous statement as not only incorrect, but prejudicial to the Noble
Cause of Forth to have such misinformation floating around where boob
journalists can use it to run Forth down.
Those wishing to measure the viability of the Stack Chip
Architecture are advised to do so by putting their finger on one of
the many Pulse Points of that industry, such as Silicon Composers
on California Avenue in Palo Alto, CA; or Harris Semiconductor,
in Melbourne, FL; or George Shaw and Chuck Moore of the SHBOOM effort.
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{} {}
{} jax@well ." Sysop, Realtime Control and Forth Board" FIG {}
{} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {}
{} JAX on GEnie ." Tell them JAX sent you!" Coordinator {}
{} {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}