Re: Structured Programming using Forth

J Thomas wrote:
Sure. Even more important, if you come up with a wonderful way to
provide that model, how do you get paid for it? if Intellasys gets a
few dozen customers who buy a few hundred million processors each,
then they do OK. But that isn't a big market for third-party tools,
and it isn't even a big market for Intellasys tools. Hard to avoid
skimping on that.

To answer the first question, semiconductor manufacturers view support and tools and training to be a loss-leader to eventually sell chips. So they get paid for it down the line when an engineer signs off on using their chips.

In the old version that had only one processer per chip, they were
hoping to get the sort of volume that would let them sell for a dollar
a chip. If they can get the cost down now, if the industry has
progressed to the point they can sell for a dollar or two a chip
today, then the issue isn't how to *most efficiently* map your
computation to multiple processors etc.

This statement doesn't make sense to me. You seem to be making some equivalence between getting a bunch of sub-buck processors, inventing the glue and communications scheme between them, working through some means to boot, debug, and test the whole mess... and the SEAforth chip which (presumably) already addresses these issues.

But let's put hardware aside for a moment. There is a simulator, and to the degree that the simulator provides an accurate view of the chip, programmers can work *today* on partitioning their applications and mapping them to a matrix of processors.

The problem is to get your work done. If you see a way to use the
extra 24 processors to improve your result, then go for it. If you see
a way to use a second processor, that's good too. You're under no
obligation whatsoever to optimise your use of 25 processors. Your
first obligation is to get a working product out the door, and if it
turns out to be easiest to do that using 4% of the computing power on
the chip, that's fine. Expand into using more processors as you see
how.

This is very naive.

When I as an engineer am asked to choose a processor for a product, I am expected to choose a processor appropriate for the task. If the task only takes 4% of the processor, then it is not appropriate. That means that 96% of the processor is being wasted and it means I've made a poor choice. The argument that you can later use the other 96% that's free only makes sense if such future extensibility is a requirement. And in the industries I have experience in, it *rarely* is the case.

So you *are* under an obligation to use as many of the processors as you possibly can in the most efficient way you can. Not using 96% of a processor's bandwidth means there is very likely some other solution out there that is less expensive. As an engineer, that is one of my primary roles: to find ways to do more with less.

Everyone is getting excited over the dribbles of information from
Intellasys. I'll get excited when I see the tools, models, and training
that they offer to actually make their hardware live up to the promise.

Sure. It's particularly interesting because Chuck is doing it, and
he's done great things before. Pioneering things. "You can tell the
real pioneers by the arrows in their backs." Chuck doesn't have a
great track record for projects that turn commercially successful
right away.

You don't sell chips because you're a pioneer. You sell chips because you have something more compelling than the other options. You don't sell chips because your name is Mr. Moore and you have 24 processors on a chip. You sell chips because you've not only thought out the hardware but how real-world programmers trying to solve real-world problems will actually use your chips.
.

Relevant Pages

  • Re: Sounds familiar
    ... When I looked over the available documentation for the Tilera chips, one thing that struck me is that like the IntellaSys chips, some aspects of the underlying hardware are exposed to the programmer. ... The difference in the IntellaSys chips-- at least with what's documented on the web site-- is that the programmer must start with a deep awareness of all the quirks and design decisions of the architecture. ...
    (comp.lang.forth)
  • Update on status of IntellaSys and SEAforth
    ... Conditions have changed and I feel that I have a duty to correct the record for the benefit of everyone who read my prior posting, particularly if any of those people are making plans for use of chips provided by IntellaSys. ... Originally, when on 15 January 2009 TPL effectively disbanded IntellaSys by laying off the entire SEAForth team, consisting of Chet Brown, YP Cheng, ... It does not seem likely any longer that we will ever spin IntellaSys or the SEAForth chips out as such, and so it is no longer honorable for us to assist TPL in maintaining the credibility of IntellaSys as a company or SEAForth chips made by IntellaSys as a product beyond what the present truth supports. ...
    (comp.lang.forth)
  • Re: Update on status of IntellaSys and SEAforth
    ... IntellaSys existed and remained a viable source of SEAforth chips. ... when on 15 January 2009 TPL effectively disbanded IntellaSys by ...
    (comp.lang.forth)
  • Re: Sounds familiar
    ... Neither C or Linux means it is "better," but it does mean ... that the learning curve to start using their chips is going to be lower. ... Indeed that is true assuming you assume C programmers, ... IntellaSys says that the native code is Forth so whatever ...
    (comp.lang.forth)
  • Re: More Chuck news
    ... IntellaSys did nothing but SEAforth. ... Chuck stated that his project, ... development of various new chips at IntellaSys had stopped. ... They had staff for support too and that included support ...
    (comp.lang.forth)