More Chuck news
MarkWills
TPL claim they own the patents. Chuck claims they were 'assigned' to
TPL, which is not the same as owning them.
http://www.colorforth.com/assignment.htm
Mark
Dennis Ruffer
S40.htm):
"TPL fired SEAForth employees in January 2009 and thus terminated the
project."
Misinformed?
DaR
Greg Bailey
The chips exist and TPL should be willing to ship them if anyone is
interested
in using any. The business entity called IntellaSys still asserts ownership
of
the trademarks SEAforth and so on, and all the chips marked with that trade-
mark. IntellaSys still exists, TPL still exists and asserts sole ownership
of
IntellaSys, and one man still exists and asserts sole ownership of TPL along
with everything else his eyes behold.
"Closed Doors" means does not exist, cannot be reached, and will not do
business. Unless something has changed radically in the last few days, it
is
misinformation to state that the Doors are Closed at IntellaSys.
My assumption in answering this question was that people here were concerned
that this tiff might make the S40 unavailable.
Inasmuch as when we left TPL had roughly 14000 packaged chips on hand,
and 20 wafers (roughly 66,000 die) offshore waiting to be packaged, there
should be no availability problems unless someone is planning to make a
major product from them. In which case TPL would probably be willing
to make a lot of money generating more.
If instead this discussion is about gossip and stuff, rather than about the
actual chips themselves, their availability, and other technical matters,
then
I regret my misunderstanding. In reviewing the thread I see that it is
likely
more about the former than the latter but maybe someone out there is
actually interested in *using* our chips - hell, if no one is, why are we
bothering to design the damn things, and why does anyone here give a
damn either?
Greg Bailey, formerly VP Engineering at IntellaSys
"Dennis Ruffer" <dru...@worldnet.att.net> wrote in message
news:e7394018-eb62-41de...@z1g2000yqn.googlegroups.com...
Jason Damisch
"IntellaSys - Under Construction"
Silicon Designs EU http://www.silicondesigneu.com/
"Please contact us for delivery information." When you try to order
chips.
Words from Chuck 4/4/90 http://www.colorforth.com/S40.htm
"he confiscated the inventory"
"The status and future of S40 chips is unclear."
"he unpackaged inventory is deteriorating while in Leckrone's
possession."
"He is wasting yet another of his investments."
"I'm dismayed that this wonderful chip may not see the market."
My fave
"So I will not conceal the existence of a chip of which I'm proud."
THANK YOU CHUCK FOR SHARING WITH US!
Jason
MarkWills
Wow. I see his page got 48,00 hits yesterday. Crikey.
I hope he doesn't disclose *too* much and end up hurting his own
chances if it goes to court.
Mark
John Passaniti
> "Closed Doors" means does not exist, cannot be reached, and will
> not do business. Unless something has changed radically in the
> last few days, it is misinformation to state that the Doors are
> Closed at IntellaSys.
I must have missed that claim. I thought the claim was the staff
specifically connected to the SEAforth project was fired and that
*those* doors were closed. I don't remember seeing a claim that all
of IntellaSys (which apparently had other units that produce other
products) had closed their doors.
> My assumption in answering this question was that people here
> were concerned that this tiff might make the S40 unavailable.
Superficially, yes. There are a few people (like myself) who have
more than a hobbyist's interest in the SEAforth chips. But most of us
figured out a long time ago that unless we were looking at ordering
quantities of a zillion, IntellaSys had no real interest in us.
Further as suggested by Elizabeth Rather, the model IntellaSys was
interested in was to (at least initially) do the development
themselves and release turn-key products. That model suggests either
a seriously wacky chip (which raises questions about time-to-market)
or a less-than compelling level of support services.
So yes, there are some here who cared about the S40 (and S24)
professionally and some others who cared about it on a hobbyist
level. But most... well, that goes back to a long-standing
fascination with all things Charles Moore.
> If instead this discussion is about gossip and stuff, rather
> than about the actual chips themselves, their availability,
> and other technical matters, then I regret my misunderstanding.
> In reviewing the thread I see that it is likely more about the
> former than the latter but maybe someone out there is
> actually interested in *using* our chips - hell, if no one is,
> why are we bothering to design the damn things, and why does
> anyone here give a damn either?
It's bad form to answer a question with a question. It's probably
even worse form to answer a question with multiple questions:
1. Was/is IntellaSys interested in selling chips to (and supporting)
customers that would use 100 chips per month. If the answer is no,
what is the threshold at which IntellaSys begins to care?
2. With the news that SEAforth-related staff have been fired, what
engineering support services exist?
3. Is it true that the SEAforth-related staff at IntellaSys preferred
to do the development themselves and release the result as a turn-key
product?
Elizabeth D Rather
...
> Superficially, yes. There are a few people (like myself) who have
> more than a hobbyist's interest in the SEAforth chips. But most of us
> figured out a long time ago that unless we were looking at ordering
> quantities of a zillion, IntellaSys had no real interest in us.
> Further as suggested by Elizabeth Rather, the model IntellaSys was
> interested in was to (at least initially) do the development
> themselves and release turn-key products. That model suggests either
> a seriously wacky chip (which raises questions about time-to-market)
> or a less-than compelling level of support services.
The chip is hardly "seriously wacky", but as you and others have noted,
designing an application to make full use of an array of 24, 40, or
however many tiny processors is a challenge for which few engineers are
prepared by experience with parts currently on the market. At some
point, there will probably emerge design tools that facilitate that, but
the presence of a team of highly skilled engineers who at this point
have several years' experience addressing exactly this challenge is an
asset not to be dismissed likely.
Pursuing high-volume customers is a strategy that most manufacturers
follow with new chips (often new products aren't even announced publicly
until several projects with early-stage customers are completed or well
under way).
It is my understanding that most of the former Intellasys engineers are
still working on this technology, pending resolution of legal issues
with TPL.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Dennis Ruffer
I never meant to imply that nobody was still working on the chips.
Even I am still working on them, in my own small way. My choice of
terms was, perhaps, unfortunate and I shouldn't post to clf so early
in the morning. However, if no one speaks up, then gossip and rumor
are inevitable. In many ways, I accomplished my purpose, to draw out
more information. Thank you for playing. ;)
I think you will find that there are a few of us who do "give a damn",
and I sense that there are many emotions that will come out in a forum
like this. Especially when we see Chuck go through this legal
nonsense, once again. I know I am re-evaluation my role in this
insanity.
I applaud Chuck for talking about it publicly, and I am relieved to
hear that it wasn't his choice to stop. No matter how hard you try,
you can not keep these kinds of things hidden, for I truly believe the
saying that we are only as sick as we are secret.
Yes, I'm sure some customers are probably turned away by this news,
but I'm also sure that some are more concerned with the future of this
technology than with how many S40's are in stock. The investment
someone needs to make to use these chips exceeds the value of any one
project.
I hope Chuck can make it through the legal process with his courage
and integrity intact. It is foolish to speculate on the outcome,
other than to acknowledge that some things will change, and hopefully,
we will all learn to do it better the next time.
DaR
Jeff Fox
> I must have missed that claim. I thought the claim was the staff
> specifically connected to the SEAforth project was fired and that
> *those* doors were closed.
IntellaSys did nothing but SEAforth. All IntellaSys projects
were SEAforth related. Chuck stated that his project,
development of new chips, was shut down and that the
development of various new chips at IntellaSys had stopped.
S24 and S40 were not the only chips designed and fabbed.
There are new chips that have been designed and sent to fab
since IntellaSys stopped doing that development behind their
doors. There are other new chips in the family in
development.
After all the idea is a family of products based on c18 core
not to one particular XxY size family member. It is a simple
idea after all. Not all FPGA are the same size or offer the
same number of logic gates either or they wouldn't be very
useful. To be more useful and cover a wider range of
applications a wider range of chip options are done. While
chip development behind IntellaSys doors has not continued
it has still continued.
IntellaSys also did announce that ongoing projects using the
S24 and S40 designs were continuing. Chuck said that chip
development at IntellaSys had been canceled. Since then
IntellaSys has released a little more information about
the ongoing projects there with SEAforth designs rather
than give people the impression that they were canceled.
Again, all IntellaSys employees were doing work related to
SEAforth, but chip development there has stopped and
moved out.
> I don't remember seeing a claim that all
> of IntellaSys (which apparently had other units that produce other
> products) had closed their doors.
TPL did buy several other companies like Onspec and has other
company divisions that many people confused for IntellaSys.
But IntellaSys was and remains SEAforth only. But you are
right they did keep some development projects going, have
chips to be tested and sold, etc. Perhaps the wafers that
haven't been sent to wafer scale testing or diced into chips
are not being stored in an oxygen free environment at this
time because Chuck seems to have a concern that the
unpackaged chips are deteriorating. If they sit on a
shelf the yield will be reduced.
> > My assumption in answering this question was that people here
> > were concerned that this tiff might make the S40 unavailable.
Yes. It was good that Greg cleared up some confusion with a few
facts.
> Superficially, yes. There are a few people (like myself) who have
> more than a hobbyist's interest in the SEAforth chips. But most of us
> figured out a long time ago that unless we were looking at ordering
> quantities of a zillion, IntellaSys had no real interest in us.
I know IntellaSys prioritized potential customers. They did have
and probably will have a way for people to get one, or a hundred or
five hundred chips a month or whatever. But that's not their first
priority. They had staff for support too and that included support
for individuals who asked for it. I doubt if there is much support
at the moment however. Hopefully that will change, but who knows.
I wouldn't go so far as to say "no interest in you." I remember one
time when people from the marketing department came to me and asked
me, "Do you know who this John Passiniti person who seems obsessed
with us is?" You generated enough interest that they knew your name.
I said, "Sure, don't worry about him. He makes some good suggestions
that match what you are really doing. And he was told that his
suggestions were good."
"But his hobby isn't Forth it is talking trash about Chuck or "all
things Chuck" so don't worry about him too much. He is the only
person who was ever able to troll Chuck into going to c.l.f to tell
him that he was wrong about Forth and that he didn't understand what
Chuck was doing. So don't worry about his trolling. If he is
really bugging the marketing staff and causing you serious problems
that are impacting business you might consider assigning me as his
contact here and I will happy to answer his questions and keep him
informed."
They said, "No, we don't need that. Your work is more important.
We just wondered why he had so much time to be talking about us all
the time. We just wondered who he was and why he cares."
I said, "He has a lot of opinions about Forth and Chuck. He insisted
for years that Chuck's work was all snake oil, that people who just
read about it became cultists by default, and has insisted that he
was right about everything despite being proven wrong again and
again. He is kind of backed into a corner now and still out there
trying his best to make trouble for Chuck to try to prove that he
was right all along about Chuck being wrong. He is probably still
mad at Chuck for saying he was wrong about Forth. But he is just
a little fish in a little Forth newsgroup who doesn't like Chuck's
work and is very vocal about it. Don't worry too much about him.
But now you might understand why he complained so much in public
about having to register his name at the IntellaSys site."
They said, "OK. We won't worry about him."
> Further as suggested by Elizabeth Rather, the model IntellaSys was
> interested in was to (at least initially) do the development
> themselves and release turn-key products.
That has been Chuck's favored model and still is. But IntellaSys
also had staff developing and offering tools outside of colorforth
for the public. Some clients have been interested in doing
development themselves so they have had people sent out to teach
them more than they could pick up by using the public tools to
develop without any support. Some support has also gone out to
individuals developing applications outside IntellaSys with the
public tools. They were doing some development for clients and
supporting outside development too.
IntellaSys does still project development going on and Chuck
has project development and chip development going on. It is
not like there is only one chip or one project or something
like that as indicated by most postings in c.l.f about how it
all about one chip size. But I don't think IntellaSys now has
the support staff that they had and I haven't heard what
their plans are and wouldn't know if they change.
I have read the rumors in c.l.f too but don't follow when
people make the jump from the chip development group split off
and various projects are continuing to 'dead dead dead.' But
I do realize that people wanting to spread rumors like that
are going to do so anyway. Hopefully people who have a little
more real information will keep us informed from time to time.
> That model suggests either
> a seriously wacky chip (which raises questions about time-to-market)
In reality there are several support models.
: Forth seriously wacky ; \ gospel according to John
> or a less-than compelling level of support services.
Less-than compelling level in one place might mean
more compelling level somewhere else like a third party.
Indeed.
That has always been Chuck's favored model, but not the
IntellaSys model as they had more than one. Whether that
will be the IntellaSys model in the future is not known
at this time by me.
> So yes, there are some here who cared about the S40 (and S24)
> professionally and some others who cared about it on a hobbyist
> level. But most... well, that goes back to a long-standing
> fascination with all things Charles Moore.
That's what I said to marketing. They thought it flattering.
I let it stand at that because it sounded nice.
> > If instead this discussion is about gossip and stuff, rather
> > than about the actual chips themselves, their availability,
> > and other technical matters, then I regret my misunderstanding.
Well people do enjoy talking politics and posting their guesses
on usenet. It is nice to see that someone in the know can
inject a few facts from time to time about Forth related
subjects.
> > In reviewing the thread I see that it is likely more about the
> > former than the latter but maybe someone out there is
> > actually interested in *using* our chips - hell, if no one is,
> > why are we bothering to design the damn things, and why does
> > anyone here give a damn either?
I think Greg was just being diplomatic about the difference between
being interested in chips, Forth progress, or just enjoying gossip.
(The reason for Greg posted the facts about what has really been
going on to c.l.f is because he just wants to be talked down to
and insulted. ;-)
> It's bad form to answer a question with a question. It's probably
> even worse form to answer a question with multiple questions:
>
> 1. Was/is IntellaSys interested in selling chips to (and supporting)
> customers that would use 100 chips per month. If the answer is no,
> what is the threshold at which IntellaSys begins to care?
Was? Yes. That's what they said very clearly. The only evidence to
the contrary has been speculation from the "nay sayers" in direct
conflict with what IntellaSys said.
Is? Who knows? The recent changes resulting in fewer employees
without
the support staff they had before makes one question what direction
IntellaSys will take.
I know they have people who would want to continue to provide support
for the large and the small but as Bohr said, "Prediction is
difficult, especially about the future."
> 2. With the news that SEAforth-related staff have been fired, what
> engineering support services exist?
Chip development, tool development and support, project hardware and
software development, marketing, customer support, etc. were not all
the same department. Some things split off and some didn't abd
where things will go isn't clear.
From what I can see support is split three ways, IntellaSys, the
new company, and third party. It might mean that it is now a lot
easier to get engineering support services. That's the argument
I would favor.
> 3. Is it true that the SEAforth-related staff at IntellaSys preferred
> to do the development themselves and release the result as a turn-key
> product?
Chuck prefers to use colorforth and thinks developing software is
easy.
He prefers the model that hardware and software be bundled as
packages.
The TPL licensing arm prefered the idea of licensing software bundles
with hardware purchases since that's what they do. They probably
still do favor that and will continue to prefer those sorts of deals.
The marketing and support prefered the idea that tools should be
made available to the public and that people's questions about them
should be answered. That's what they do. They think support for
both large and small should be offered. And those same people
would pretty much offer that same support to people interested
in Forth anyway so it shouldn't be a big deal.
Of course they are also well aware that hobbiests can be a problem
for small companies. Hobbiests will do things like complain that a
$500 development kit is too expensive and say all they want to order
is one chip. But they also want a hundred hours of free support
to get all they need to design their own board. Then they will want
to write their own compiler and will want another few more
hundreds of hours of company support etc. for their original $25
purchase.
Marketing support can't afford to give out hundreds of hours of
free support for every single chip purchase unless they raise the
price of single chips considerably. It isn't an IntellaSys thing,
just a business thing.
I remember reading complaints in c.l.f about how Patriot only
offered a few dozen hours of free support for someone who only
bought one $10 chip and how angry he became that a single chip
did not include infinite free hardware and software support.
I also think that it is nice mechanism for people who want
to cause trouble or who are backed into a corner having bet
that there will not enough IntellaSys support to go around.
If they can make enough stink to become a concern of the
support staff then they have done their job to cause
problems and reduce support for other people.
Now that things have split it seems that there should be more
options, but accurate predictions of the future remain
difficult. It has always been very easy for some people
to come up with the sort of fearless predictions that have
always been proven wrong in the past. But we are all
guessing about the future.
Best Wishes
Jacko
I'm all into my http://nibz.googlecode.com and so do not see me
ordering any SEAforth chips in the near future. Not that I would
refuse to buy in product chips, but cash is tight. I make do with the
cheap MAXII devkit, and even that was purchased by someone else.
I do understand the technical support aspect, and have no real issues
with lack of technical design support, I can see how for example 'ball
grid array bond' production issues might be useful to advise on, while
hobby one offs (low volume) does not draw immediate if much or at all
profit.
So to the 3 parties split.
1. If 'chuck chips' is the new company, what fab services for non
chucky designs could be offered, and would lower DISCO-FET mask layers
be available?
2. Of intel-a-sys, you really should not put silicon in an oxygen
environment. Me thinks passivationation. Letting expensive stuff,
although thin go to waste like that. Production of such things is a
ramp down affair on pure safety grounds.
3. Of third party, well, hope you have some nice jewels of tools for
the future systems too.
cheers jacko
Jacko
Jacko
> 'Chuck Chips' - "A real grip on processing technology"
: poe try When the anthopological origional war of 'ma bitches and
resource ug,
do fighty fighy' becomes abstracted into a profit and its force,
where
body parts are not under threat, and resource exceeds personal need,
then a funny perverse species evolves. And not funny ha,ha, but funny
pants-que-lear.
The lack of evapouration of the natural competiton, is contra to the
assumption of monopoly. Hence via the escapements of the playboy
island, and the selector bitches having a cahoot of a time, fuzz
force
one lines up for his pie slip a better man than I.
Along came the wanton, doubting of the cake, and then the pie slip
rummble surely became fake. Was it not for jesus how held us in our
moral. The cup cake and the fondu would have never palital.
For those who chose to trust, beyond the bounds of logic, faith upon
the market man has solute a trojik.
cheers jacko
;
Albert van der Horst
Jeff Fox <f...@ultratechnology.com> wrote:
<SNIP>
Everybody in his right mind can see that John is very knowledgeable
and contributes important insights to this group. Everything
he says makes sense, and almost everything is at least a valuable
point of view.
<SNIP>
>
>Of course they are also well aware that hobbiests can be a problem
>for small companies. Hobbiests will do things like complain that a
>$500 development kit is too expensive and say all they want to order
>is one chip. But they also want a hundred hours of free support
>to get all they need to design their own board. Then they will want
>to write their own compiler and will want another few more
>hundreds of hours of company support etc. for their original $25
>purchase.
I had some nice experiences with Renesas/GLYN over a EURO 50 kit
with free development tools. They didn't spend 100 hours on me
(nobody expects such).
<SNIP>
>
>I remember reading complaints in c.l.f about how Patriot only
>offered a few dozen hours of free support for someone who only
>bought one $10 chip and how angry he became that a single chip
>did not include infinite free hardware and software support.
I remember Patriot having a feature article in Elektuur (now
Elektor). Then I found out that nobody in Europe would sell the
kit that was described to me.
>
>Best Wishes
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Bernd Paysan
>>Of course they are also well aware that hobbiests can be a problem
>>for small companies. Hobbiests will do things like complain that a
>>$500 development kit is too expensive and say all they want to order
>>is one chip. But they also want a hundred hours of free support
>>to get all they need to design their own board. Then they will want
>>to write their own compiler and will want another few more
>>hundreds of hours of company support etc. for their original $25
>>purchase.
>
> I had some nice experiences with Renesas/GLYN over a EURO 50 kit
> with free development tools. They didn't spend 100 hours on me
> (nobody expects such).
Well, maybe there is one or the other who expects such a thing. The
answer is of course: Don't support them that way. Create a "community
platform", which means some wiki+blog+forum, and a place for downloads,
and direct anybody with tougher questions to this platform (usually,
there are ready-to-use PHP CMSes that support all these features, just
drop them on your web server, fill them with the initial material like
manual and simulator/debugger, give them your corporate identity, and
off you go).
The Forth-Gesellschaft started a new "Forth chips in FPGA" project this
year, and since the FPGA demo board we use (DE1 from Altera) is way
larger than a single Forth chip, we plan to build something like "a sea
of b16s" or so inside. This is a purely driven-by-fun project, so don't
expect any real silicon.
The good about a driven-by-fun project is that you don't have any
secretive corporation behind you which doesn't let you do what you want.
And you don't have any obligations.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Jeff Fox
wrote:
> Everybody in his right mind can see that John is very knowledgeable
> and contributes important insights to this group. Everything
> he says makes sense, and almost everything is at least a valuable
> point of view.
I saw your posting to the colorforth mailing list also
claiming that Chuck's work is all just a patent scam.
People don't all have to have the same opinions to be
in their right minds. ;-)
> I had some nice experiences with Renesas/GLYN over a EURO 50 kit
> with free development tools. They didn't spend 100 hours on me
> (nobody expects such).
If you happy with Renasas that's great. Things tend to be a
little different in a startup. I would say it is a simpler
explanation than that it is all a patent scam as you claim.
> I remember Patriot having a feature article in Elektuur (now
> Elektor). Then I found out that nobody in Europe would sell the
> kit that was described to me.
When they first claimed that Chuck's name on the patents
entitled him to nothing I choose not to support their effort.
I know other people did. They have returned to the position
that Chuck deserves nothing again.
Best Wishes
Bernd Paysan
> When they first claimed that Chuck's name on the patents
> entitled him to nothing I choose not to support their effort.
Well, I think we here in Europe agree that TPL is a patent troll
group (the name probably expands to "Troll patent litigators"). Then,
there are two other questions: Is Chuck's work valuable (one side),
and are the patents extracted from the ShBoom leftovers worth the
paper they are written on (other side). My point: Chuck's work is
valuable, and the patents aren't worth the paper they are printed on.
It is a shame that these patents exist and that outsiders to Forth
know Chuck only through this "Moore patent portfolio".
The latter has a lot more to do with the quality of the patent system
(not only limited to the US), and this system is in a very sad state.
E.g. one of Chuck's patent is about fetching several instructions in
one go, and executing them sequentially. All I know is that this was
an invention at some point in time, but that point had definitely
passed when the Burroughs B5000 saw light. This was 1961. At that
time, all these concepts like stack instructions, packing multiple
instructions in one word and so on where revolutionary (the Zuse Z22,
ready at about the same time, had similar inventions), but since
1961, a lot of time has passed.
Another of Chuck's patents claims that a CPU runs with a different
internal clock than IO clock. This is probably the main source of
income for the TPL, because virtually every CPU does that. The point
however is: They always did; they certainly did it back when the
B5000 was first made.
So in effect, what happened with Chuck's ShBoom leftovers was that
some patent lawyer went over it and extracted everything he could
barely understand and though it might have been new, and the USPTO
happily grants whatever bullshit you bring in as patent - after
breaking it down to meaningless little bits of "innovation". And
then, it is so expensive to fight off such a patent lawsuit that it's
cheaper to pay some millions to these trolls, instead of invalidating
the patents (which is far from trivial in the US - e.g. the obnoxious
Microsoft FAT patent got reinstated in 2006, while in Germany, the
same patent was thrown over in 2007 for
a) not being new (Rock Ridge cited as prior art)
b) obvious and
c) not even containing a proper teaching).
Insofar, the TPL is probably right that Chuck did not contribute
anything to these patents - in so far that these patents are not
inventions, anyway. These people are highwaymen, they are not
concerned about innovation and engineering, they want to rob as many
people as possible. The engineers who's work was the sources of the
patents included.
John Passaniti
> TPL did buy several other companies like Onspec and has other
> company divisions that many people confused for IntellaSys.
> But IntellaSys was and remains SEAforth only. But you are
> right they did keep some development projects going, have
> chips to be tested and sold, etc. Perhaps the wafers that
> haven't been sent to wafer scale testing or diced into chips
> are not being stored in an oxygen free environment at this
> time because Chuck seems to have a concern that the
> unpackaged chips are deteriorating. If they sit on a
> shelf the yield will be reduced.
I think that's my confusion; I distinctly remember mention of the
"secure content processor" and "secure storage controllers" on the very
same page as SEAforth. But now, when I look at the IntellaSys web page,
that information is no longer there.
> I wouldn't go so far as to say "no interest in you." I remember one
> time when people from the marketing department came to me and asked
> me, "Do you know who this John Passiniti person who seems obsessed
> with us is?" You generated enough interest that they knew your name.
How odd. I have both of the two messages I wrote to IntellaSys asking
for more information. I briefly described the kinds of applications I'm
involved in, my interest in the chip, and the desire for more
information. That's it. So I seriously doubt anyone could have gotten
"obsessed" from that.
So frankly, I think you're lying-- or at best seriously embellishing--
probably for effect.
> "But his hobby isn't Forth it is talking trash about Chuck or
> "all things Chuck" so don't worry about him too much. He is
> the only person who was ever able to troll Chuck into going to
> c.l.f to tell him that he was wrong about Forth and that he
> didn't understand what Chuck was doing.
Really. Please point to that message. Not your characterization of the
message, but the actual message.
> I said, "He has a lot of opinions about Forth and Chuck. He insisted
> for years that Chuck's work was all snake oil, that people who just
> read about it became cultists by default, and has insisted that he
> was right about everything despite being proven wrong again and
> again. He is kind of backed into a corner now and still out there
> trying his best to make trouble for Chuck to try to prove that he
> was right all along about Chuck being wrong. He is probably still
> mad at Chuck for saying he was wrong about Forth. But he is just
> a little fish in a little Forth newsgroup who doesn't like Chuck's
> work and is very vocal about it. Don't worry too much about him.
> But now you might understand why he complained so much in public
> about having to register his name at the IntellaSys site."
I find this hilarious, but it's the standard kind of wild distortion
you've whipped up as part of your persecution complex. At worst, I've
asked critical questions that any engineer would and should ask. But to
claim I think Moore's work is "snake oil" is just wild exaggeration.
Wow, you've got issues.
>> That model suggests either
>> a seriously wacky chip (which raises questions about time-to-market)
>
> In reality there are several support models.
>
> : Forth seriously wacky ; \ gospel according to John
Glimpses into your mind are both amusing and terrifying at the same
time. I stated that I found it odd that a chip manufacturer would
prefer to write the application code for those chips. I thought that
suggested that the chip was so difficult to work with that they wanted
to bring that in-house. You somehow turn that into that I think Forth
itself is "seriously wacky." The way you conflate things is just bizarre.
What's even more fascinating is how your mind recycles bits and pieces.
I have no doubt that in the future, you're going to claim that I state
that Forth is "seriously wacky." Each and every time I bother to go
back into comp.lang.forth history to find the source of one of your
outrageous claims, I find it was you doing the mix-and-match thing in
your head, and synthesizing new nonsense.
>> 1. Was/is IntellaSys interested in selling chips to (and supporting)
>> customers that would use 100 chips per month. If the answer is no,
>> what is the threshold at which IntellaSys begins to care?
>
> Was? Yes. That's what they said very clearly. The only evidence to
> the contrary has been speculation from the "nay sayers" in direct
> conflict with what IntellaSys said.
Do (or did) you not count as an official IntellaSys spokesperson? When
I first asked this question, it was *you* who stated that IntellaSys
cared more about serving customers who would buying huge quantities.
>> 3. Is it true that the SEAforth-related staff at IntellaSys preferred
>> to do the development themselves and release the result as a turn-key
>> product?
>
> Chuck prefers to use colorforth and thinks developing software is
> easy.
> He prefers the model that hardware and software be bundled as
> packages.
But as a business model, that would seem to require that IntellaSys
found a small number of very high volume customers. A small number
since regardless of easy Moore thinks software is to develop, there is
going to be ongoing support.
> Of course they are also well aware that hobbiests can be a problem
> for small companies. Hobbiests will do things like complain that a
> $500 development kit is too expensive and say all they want to order
> is one chip. But they also want a hundred hours of free support
> to get all they need to design their own board. Then they will want
> to write their own compiler and will want another few more
> hundreds of hours of company support etc. for their original $25
> purchase.
I'm not really that concerned about the hobbyists here. Most of them
want a SEAforth chip but can't articulate why or describe an actual
application for it. Hell, as I remember from a press release about the
24-core SEAforth chip, the packaging was a BGA. I doubt most hobbyists
can deal with BGA chips.
> Now that things have split it seems that there should be more
> options, but accurate predictions of the future remain
> difficult. It has always been very easy for some people
> to come up with the sort of fearless predictions that have
> always been proven wrong in the past. But we are all
> guessing about the future.
As I've written all along, I hope nothing but the best for IntellaSys.
You probably have a hard time believing that because you've concocted an
elaborate persecution complex around me, and seem to have a mindset that
sees conspiracy lurking everywhere.
John Passaniti
> The chip is hardly "seriously wacky",
My concern is this: When a client comes to us to design their next
product, one of the first things we do is to decide what microprocessor
we'll use. The evaluation process can sometimes be short-circuited by
the client who demands a specific processor. But more often, we make
the decision by considering cost, availability, tools, past experience
with the chip, expected ramp-up time if its unfamiliar, etc.
When I hear that a chip manufacturer would prefer to do the software and
hardware development in-house, it is at a minimum odd and leads to some
questions.
Forth, Inc.'s web site states you also provide hardware engineering
services. How would you feel about designing in a microcontroller from
a manufacturer that said, "we would prefer to do the software and
hardware for you." What would be the first few things that went through
your head?
Jacko
> services. How would you feel about designing in a microcontroller from
> a manufacturer that said, "we would prefer to do the software and
> hardware for you." What would be the first few things that went through
> your head?
In my head:
"Secret Crypto Cash Dividends -- TV Per View??"
"You'd do it wrong, and we'll get the flak."
"Little kids might take our jobs and profit, just for kicks."
cheers jacko
Albert van der Horst
>claiming that Chuck's work is all just a patent scam.
>People don't all have to have the same opinions to be
>in their right minds. ;-)
What I said amounted to that Chuck Moore is the victim of a patent
scam. Not quite the same.
Elizabeth D Rather
The Intellasys parts are radically different from current
microcontrollers. They offer some unusual opportunities, but are
clearly not ideal for a lot of mainstream embedded projects. If we were
dealing with a project for which these parts are appropriate, we would
be facing some unusual design challenges, and would definitely welcome
the participation of engineers who have confronted these challenges.
As time passes, it will be possible to capture more of their experience
in manuals and design tools. Some people will prefer to wait until that
happens. Early adopters, willing to seize the opportunity sooner rather
than later in order to gain a competitive advantage, will prefer to work
with experts now.
MarkWills
Well said Bernd, I couldn't agree more.
Here's what worries me about TPL:
1) You buy 500,000 chips from IntellaSys to build into your next
product, let's say it's a TV set-top box.
2) You design the product
3) You put it in production
4) TPL come after you with the lawyers in full sue mode, waving the
Moore portfolio, and demanding a licence because other aspects of your
design infringe it!
Shafted.
van...@vsta.org
> The Intellasys parts are radically different from current
> microcontrollers.
They are a radical departure from how software is constructed on any
other processor I can think of. They also have no public design wins
which can be studied by enough people in enough depth to make their
application well understood. My intuition after studying the part is
that they didn't hit the right blend of technology yet--in particular, I
don't think there's enough state (i.e., RAM) on each node. But that's
exactly the sort of question which gets settled when actual applications
happen.
Any radical technology needs to get over this bootstrap. One way is to
connect the technology with the "grass roots" people who can afford to
risk adopting it. The other is to carefully select some initial
customers so you can over-support them to maximize the chances of
success. I'm a big believer in the former, and it seems to me that
Intellasys was aimed more towards the latter. Perhaps when this legal
bump in the road is behind us it'll be easier for early individual
adopters to play a part in Chuck's technology.
Andy Valencia
John Passaniti
> The Intellasys parts are radically different from current
> microcontrollers.
You used the phrase "radically different" and I used the phrase
"seriously wacky." Was your objection before that my phrase was less
polished and nuanced than yours? They sound more the same than
different to me.
> They offer some unusual opportunities, but are
> clearly not ideal for a lot of mainstream embedded projects. If we
> were dealing with a project for which these parts are appropriate, we
> would be facing some unusual design challenges, and would definitely
> welcome the participation of engineers who have confronted these
> challenges.
Did you answer my question? The phrase "welcome the participation"
doesn't sound at all like "hand the specs to IntellaSys and have them
deliver a turn-key product for you."
> As time passes, it will be possible to capture more of their experience
> in manuals and design tools. Some people will prefer to wait until that
> happens. Early adopters, willing to seize the opportunity sooner rather
> than later in order to gain a competitive advantage, will prefer to work
> with experts now.
Perhaps. Or perhaps those companies who have internal engineering
departments and/or trusted partners who they work with will question
going to a new chip that is apparently so "radically different" that
their own staff and/or partners can't program the thing.
van...@vsta.org
>> The Intellasys parts are radically different from current
>> microcontrollers.
> You used the phrase "radically different" and I used the phrase
> "seriously wacky." Was your objection before that my phrase was less
> polished and nuanced than yours? They sound more the same than
> different to me.
I use the word "wacky" when I think something is probably not useful in
a practical sense. I get cautious about that conclusion when the
subject in question is so different that my past experience in software
architecture doesn't easily apply.
I also don't want to dump on an architecture when it's really an initial
instantiation which gives me a pause. I'm not sure about designs in the
space of 20-40 nodes at 32-128 words per node. I have practical
experience with 8 nodes and 2k CPU RAM (plus a global bus with access to
64k RAM)--a Propeller, and I can easily do a wide range of solutions in
that configuration.
An S40 with 2k of RAM per node would tear the head off a Propeller--even
if easy access to a global RAM bus weren't provided. Add on a system
standard global bus which is routed in parallel with the existing
neighbor interface I/O ports, and all of a sudden I really know how to
code on it.
But there's the rub. Have I missed the point of how to cook code for
it, and in my cluelessness am just demanding that the CPU architecture
morph back into what it isn't? Or has SEAForth made something so
esoteric that each application requires a new breakthrough of genius?
All I really hope is that the world will afford an opportunity for this
question to be fairly answered.
Andy Valencia
Elizabeth D Rather
> Elizabeth D Rather wrote:
>> The Intellasys parts are radically different from current
>> microcontrollers.
>
> You used the phrase "radically different" and I used the phrase
> "seriously wacky." Was your objection before that my phrase was less
> polished and nuanced than yours? They sound more the same than
> different to me.
As Andy says, "I use the word "wacky" when I think something is probably
not useful in a practical sense." I interpret it the same way. There
are already some serious projects in various stages for this chip, none
of which sound the least big "wacky" to me, and all very ambitious in
appropriate ways.
> > They offer some unusual opportunities, but are
>> clearly not ideal for a lot of mainstream embedded projects. If we
> > were dealing with a project for which these parts are appropriate, we
> > would be facing some unusual design challenges, and would definitely
> > welcome the participation of engineers who have confronted these
> > challenges.
>
> Did you answer my question? The phrase "welcome the participation"
> doesn't sound at all like "hand the specs to IntellaSys and have them
> deliver a turn-key product for you."
I don't think the intent is that someone should throw a spec over the
transom and hope for the best... any contract development project should
involve intensive collaboration. I'm sorry if I gave any other impression.
>> As time passes, it will be possible to capture more of their
>> experience in manuals and design tools. Some people will prefer to
>> wait until that happens. Early adopters, willing to seize the
>> opportunity sooner rather than later in order to gain a competitive
>> advantage, will prefer to work with experts now.
>
> Perhaps. Or perhaps those companies who have internal engineering
> departments and/or trusted partners who they work with will question
> going to a new chip that is apparently so "radically different" that
> their own staff and/or partners can't program the thing.
Well, we've worked with a lot of companies who didn't have Forth
programmers on staff when the project started, who expected us to write
all or virtually all the code. Some wanted to be positioned to take
over maintenance of the software after acceptance, and some didn't.
Some companies want to design and market new products but prefer to
contract out software development, sometimes even the hardware design as
well. That's a perfectly reasonable business model. It certainly
requires good communication between the parties, but can be quite
successful.
Anton Ertl
>They are a radical departure from how software is constructed on any
>other processor I can think of. They also have no public design wins
>which can be studied by enough people in enough depth to make their
>application well understood.
I think that's a good reason for suggesting letting the chip developer
work or at least help with the software. Anyone else will spend quite
a bit of time coming to grips with the architecture.
> My intuition after studying the part is
>that they didn't hit the right blend of technology yet--in particular, I
>don't think there's enough state (i.e., RAM) on each node.
I think that, on the contrary, the lack of per-node RAM helps avoid a
pitfall I see for this architecture: creating a design that relies on
sophisticated software in the nodes; the implementation of such a
design would probably never get finished, because nobody knows how to
do program such things.
By having little RAM per-node, the design has to be such that each
node is dedicated to a simple thing, and the scope of the distributed
processing will be small enough that it can be tackled as a relatively
small project, which has a much better chance at succeeding.
The kind of application I envision for the nodes without direct
external RAM access is something that would normally be done in
hardware, not something you would normally do with a CPU.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
John Passaniti
> As Andy says, "I use the word "wacky" when I think something is probably
> not useful in a practical sense." I interpret it the same way. There
> are already some serious projects in various stages for this chip, none
> of which sound the least big "wacky" to me, and all very ambitious in
> appropriate ways.
Damn English with it's multiple meanings for words. I always associated
the word "wacky" with synonyms like unusual, odd, strange, eccentric,
unorthodox. Of course, if one chooses to take a negative interpretation
of the word, that's up to them. Maybe Esperanto would help?
>> Did you answer my question? The phrase "welcome the participation"
>> doesn't sound at all like "hand the specs to IntellaSys and have them
>> deliver a turn-key product for you."
>
> I don't think the intent is that someone should throw a spec over the
> transom and hope for the best... any contract development project should
> involve intensive collaboration. I'm sorry if I gave any other impression.
Saying that IntellaSys preferred to deliver turn-key solutions (or words
to that effect) certainly suggests to me that the majority of the
hardware and software would be by IntellaSys. And Jeff hinted that is
how Moore would prefer to work.
Jonah Thomas
> Elizabeth D Rather wrote:
> > As Andy says, "I use the word "wacky" when I think something is
> > probably not useful in a practical sense." I interpret it the same
> > way.
>
> Damn English with it's multiple meanings for words. I always
> associated the word "wacky" with synonyms like unusual, odd, strange,
> eccentric, unorthodox. Of course, if one chooses to take a negative
> interpretation of the word, that's up to them. Maybe Esperanto would
> help?
Hasn't 'wacky' usually had a negative connotation in a business context?
Not so much in entertainment, cf "Lucille Ball and her wacky
adventures".
> >> Did you answer my question? The phrase "welcome the participation"
> >> doesn't sound at all like "hand the specs to IntellaSys and have
> >> them deliver a turn-key product for you."
> >
> > I don't think the intent is that someone should throw a spec over
> > the transom and hope for the best... any contract development
> > project should involve intensive collaboration. I'm sorry if I gave
> > any other impression.
>
> Saying that IntellaSys preferred to deliver turn-key solutions (or
> words to that effect) certainly suggests to me that the majority of
> the hardware and software would be by IntellaSys. And Jeff hinted
> that is how Moore would prefer to work.
Since the development tools and teaching tools have to lag the product
some, doesn't it make sense for some of the people who already know how
to design some early projects and bring in early money?
Jacko
bounds, cricket ball or other object and sometimes other subject.
Wacky: of a far out nature. Plus various other out there synonimous
wordage.
Wack job: A seriously mental individual in need of anger management.
etc.
cheers jacko
Jacko
from aircraft to avoid sceptic tank scenario.
Jacko
> 'jobie weeker' - See famous comedian in reference to thrower of turds
> from aircraft to avoid sceptic tank scenario.
Billy Connolly
'belly wack' : stomach ache
Jason Damisch
stuff.
Jason
Elizabeth D Rather
> Elizabeth D Rather wrote:
>>> Did you answer my question? The phrase "welcome the participation"
>>> doesn't sound at all like "hand the specs to IntellaSys and have them
>>> deliver a turn-key product for you."
>>
>> I don't think the intent is that someone should throw a spec over the
>> transom and hope for the best... any contract development project
>> should involve intensive collaboration. I'm sorry if I gave any other
>> impression.
>
> Saying that IntellaSys preferred to deliver turn-key solutions (or words
> to that effect) certainly suggests to me that the majority of the
> hardware and software would be by IntellaSys. And Jeff hinted that is
> how Moore would prefer to work.
Sure. But a "turn-key solution" doesn't in any sense rule out active
participation by the customer, if only at the design level. I don't
presume to know what Jeff was "hinting" at, but as I have a fairly close
relationship with the IntellaSys folks (both pre- and post- the recent
events, however one characterizes them) I know that the customers
they're presently working with are working pretty closely with them.
And Chuck is deeply involved in designing next-generation chips, less
personally involved with anyone's application.
John Passaniti
> Hasn't 'wacky' usually had a negative connotation in a business context?
> Not so much in entertainment, cf "Lucille Ball and her wacky
> adventures".
Shouldn't the intent of the writer using a word be considered before
others choose to inject their meaning into it. Here's a crazy idea--
before assuming that I or anyone's word choice means something, you
could... ask.
> Since the development tools and teaching tools have to lag the product
> some, doesn't it make sense for some of the people who already know how
> to design some early projects and bring in early money?
Who says the tools have to lag the product? Who says they can't be
developed concurrently (especially since as Jeff constantly reminds us
that Mr. Moore has been working with the tools and variations on the
chips for *years*).
Jacko
> Jonah Thomas wrote:
> > Hasn't 'wacky' usually had a negative connotation in a business context?
> > Not so much in entertainment, cf "Lucille Ball and her wacky
> > adventures".
>
> Shouldn't the intent of the writer using a word be considered before
> others choose to inject their meaning into it. Here's a crazy idea--
> before assuming that I or anyone's word choice means something, you
> could... ask.
A writer considers choosing a word, and people read it implying a
communcation intent. Other peoples injection of meaning, are to obtain
a common meaning, as the purpose of communication would seem to be
information transfer. I never implyed any meaning from it and ignored
the word to start due to the obvious use of the word 'seriously' ...
and joke joke.
> > Since the development tools and teaching tools have to lag the product
> > some, doesn't it make sense for some of the people who already know how
> > to design some early projects and bring in early money?
>
> Who says the tools have to lag the product? Who says they can't be
> developed concurrently (especially since as Jeff constantly reminds us
> that Mr. Moore has been working with the tools and variations on the
> chips for *years*).
The tools can preceed the product, and are potential salable products
themselves.
cheers jacko
p.s. the definition of wacky is inimportant, but a good definition of
intent on the word seriously would be more informative.
Jonah Thomas
> Jonah Thomas wrote:
> > Hasn't 'wacky' usually had a negative connotation in a business
> > context? Not so much in entertainment, cf "Lucille Ball and her
> > wacky adventures".
>
> Shouldn't the intent of the writer using a word be considered before
> others choose to inject their meaning into it. Here's a crazy idea--
> before assuming that I or anyone's word choice means something, you
> could... ask.
As usual, that's pretty much what happened. You came up with a clumsy
word choice and when people asked you what you meant you said that your
intention was not the way it came across No big deal, except you keep
trying to put the burden of communication on the people you're trying to
communicate with.
> > Since the development tools and teaching tools have to lag the
> > product some, doesn't it make sense for some of the people who
> > already know how to design some early projects and bring in early
> > money?
>
> Who says the tools have to lag the product? Who says they can't be
> developed concurrently (especially since as Jeff constantly reminds us
> that Mr. Moore has been working with the tools and variations on the
> chips for *years*).
OK, I won't say it has to be that way, but doesn't it very often
happen that way?
Stephen Pelc
<nn...@JapanIsShinto.com> wrote:
>Saying that IntellaSys preferred to deliver turn-key solutions (or words
>to that effect) certainly suggests to me that the majority of the
>hardware and software would be by IntellaSys. And Jeff hinted that is
>how Moore would prefer to work.
In the early phase of any chip family, it is the norm that much
of the application work is done by the silicon vendor. All silicon
vendors need an income stream between development and volume
production. After volume production starts, they typically yield
this work to third parties.
In this respect IntellaSys/TPL are no different from the majority
of silicon vendors.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Jacko
> On Tue, 07 Apr 2009 12:44:25 -0400, John Passaniti
>
> <n...@JapanIsShinto.com> wrote:
> >Saying that IntellaSys preferred to deliver turn-key solutions (or words
> >to that effect) certainly suggests to me that the majority of the
> >hardware and software would be by IntellaSys. And Jeff hinted that is
> >how Moore would prefer to work.
>
> In the early phase of any chip family, it is the norm that much
> of the application work is done by the silicon vendor. All silicon
> vendors need an income stream between development and volume
> production. After volume production starts, they typically yield
> this work to third parties.
>
> In this respect IntellaSys/TPL are no different from the majority
> of silicon vendors.
I could see how preprogrammed CPLD vendors could do it differently,
but yes, dem der crystaline taster and those impurates and de mini
photo shrinkido and no pocket change enterprise.
Elizabeth D Rather
> Jonah Thomas wrote:
...
>
>> Since the development tools and teaching tools have to lag the product
>> some, doesn't it make sense for some of the people who already know how
>> to design some early projects and bring in early money?
>
> Who says the tools have to lag the product? Who says they can't be
> developed concurrently (especially since as Jeff constantly reminds us
> that Mr. Moore has been working with the tools and variations on the
> chips for *years*).
Since this chip is "radically different" (did we agree on that
description?) there's an extra challenge. Indeed, they prepared manuals
on both hardware and software tools prior to release last summer (I
wrote the latter).
But the fact is, *everyone* is still learning how to master advanced
*design strategies* for it. Until there's been a certain amount of
trial and error, and commensurate learning, there cannot be a credible
design guide produced. I discussed this with them at length last year.
Everyone agreed on the need for such a document, and everyone also
agreed they weren't yet prepared to provide it.
As of last summer, there were several fairly modest demo apps, and this
winter they have been working on some serious commercial projects.
These experiences will be invaluable. I can see you're going to point
out, "what company would sign up for such raw technology?" And you're
quite right, it isn't for everyone. Fortunately, there are a couple of
companies who know enough about the technology and the personnel
involved that they are prepared to be the guinea pigs. Both stand to
gain significant market advantages as well as significant cost
reductions, and are (appropriately) regarding this as an R&D effort.
There will be more.
Roger Ivie
> The kind of application I envision for the nodes without direct
> external RAM access is something that would normally be done in
> hardware, not something you would normally do with a CPU.
Would it be fair to say that you see it competing more with small FPGAs
than other CPUs?
--
roger ivie
ri...@ridgenet.net
Elizabeth D Rather
In a sense. I know one company who is actively working on a project
with Chuck et al. has a product line that normally takes ~30,000 8051's
and they expect it to be done with about 1000 S40's.
Appropriate target apps are I/O-intensive with concurrent internal
processing and benefit from low-power.
Anton Ertl
Something like that. I think there are application where SeaForth can
work and FPGAs are too slow, and vice versa, but yes, I see the
SeaForth applications much closer to FPGAs than to normal CPUs, except
for the node that can access the external RAM.
Jeff Fox
> I use the word "wacky" when I think something is probably not useful in
> a practical sense. I get cautious about that conclusion when the
> subject in question is so different that my past experience in software
> architecture doesn't easily apply.
dictionary.com wacky is an adjective, slang, meaning:
odd or irrational; crazy
Maybe you didn't intend the common meanings of "irrational" and
"crazy."
> I also don't want to dump on an architecture when it's really an initial
> instantiation which gives me a pause. I'm not sure about designs in the
> space of 20-40 nodes at 32-128 words per node. I have practical
> experience with 8 nodes and 2k CPU RAM (plus a global bus with access to
> 64k RAM)--a Propeller, and I can easily do a wide range of solutions in
> that configuration.
32 words per node? I haven't see that on any models.
I like the Propeller. It reminded me very much of F21 in terms of
capabilities and power except that it doesn't have pins to have
a big external memory bus. A propeller can generate a video signal,
generate sound, do communications with the outside world, talk
to a keyboard, and run a mouse or do all this running inside of
a mouse and run an application with video and sound and networking
and user I/O just like an F21. It can generate a GUI and desktop
and host personal computer apps.
So I could do a "toy workstation in a mouse" and get a few similar
performance numbers to what an F21 would get with its coprocessors
a decade ago. The main difference would be the 64K vs 4MB of
memory and room for a lot more or a lot bigger applications
on the workstation desktop and more pixels and that I can't order
Propeller chips for $0.80 each in quantity or resell them for $1.
The other big difference is that propeller was not done in the
days of 10-400MHz PC ten years ago and competes against newer
things today. SEAforth chips have had a much larger external
memory bus capability than F21 or propeller thanks to more pins.
Propeller's total processing power is 160 Propeller MIPS which
isn't quite as high as an old F21 CPU but after you factor in
sharing memory with coprocessors on F21 things sort of even out.
But it is long ways off from a few K or M Forth MIPS.
There is less similarity to SEAforth design despite the fact
that they were all intended as parallel designs. And programming
Propeller is more like other microcontrollers unless you are
a Forth person. You can even treat propeller nodes as BASIC
stamps so you are right that they are far more conventional to
non-Forth people.
SEAforth is a different style of parallelism than propeller,
more like a transputer with Occam or more like an FPGA.
SEAforth is a lot more like a low power alternative things
where FPGA performance is required. It is more like an FPGA
than like a Propeller.
> An S40 with 2k of RAM per node would tear the head off a Propeller--even
> if easy access to a global RAM bus weren't provided.
I think it would be bigger than Propeller then too. Now each node is
about 1/4 memory with 128 words. So 2k would be about as big as 8
nodes now and if you still had 40 of them it would be as big as
an S320 would be now. IntellaSys marketing made the decision to
position product in the market based on power use not on low cost
so they set the cost below $1 per core but nowhere near manufacture,
packaging, and distribution cost.
Basically you are suggesting a chip about ten times as large and
power hungry. SEAforth is a multiprocessor that doesn't need a
fan to cool it. It you make things a order of magnitude larger
it would likely need a fan and become as big and expensive
and power hungry as lots of other chips. There is already
quite a choice in things big enough to cost hundreds or need
fans for cooling.
If FPGA only came in one size it would be hard to fit them to very
many problems. That's why one should probably think of S... where
... is a row in the family chart which can be selected with things
like other I/O and memory options. I won't detail what combinations
that have been designed or fabbed so far but I wouldn't want to
have to select from a family with only one or two members.
> Add on a system standard global bus which is routed in parallel
> with the existing neighbor interface I/O ports,
There's an external bus, routed in parallel but it's not global.
You can't pump it faster than a couple gigabits anyway so there
would be diminishing returns for the costs.
There's off-chip neighbor ports but only two 400+ mbps off-chip
neighbor ports on S24 and S40. But they have been improved and
more should be on some designs. I would expect to see some
designs with expanded RAM in place of some previous nodes etc.
But nothing has been made available yet, and one can only guess
about future releases.
> and all of a sudden I really know how to
> code on it.
>
> But there's the rub. Have I missed the point of how to cook code for
> it, and in my cluelessness am just demanding that the CPU architecture
> morph back into what it isn't?
It is the Forth processor it is. If you intend to cook the code
you need to know how to cook. That's all. I don't think it will
morph back into what it wasn't. (?)
> Or has SEAForth made something so
> esoteric that each application requires a new breakthrough of genius?
Now from what I have seen. I have seen students just out of school,
older programmers and people with no programming experience, even
managers who had never seen Forth before do it pretty quickly.
I'm not talking about the drag and drop GUI interface that works
with messaging objects or the other high level tools people have
developed for floor planning and things. Clearly the idea of all
that is accessibilty to more non-genius people. I mean low level
programming does not require a new breakthrough of genius. I've
seem people doing it for decades and think kids can learn to do
it.
On the other hand, in some applications every little bit of coding
skill may be important. With 128 words of memory the advice that
no one cares about memory size of code speed that is all that some
people repeat isn't going to apply.
On the third hand, more widespread use of a drag and drop
type interfaces with some object libraries does bring
the programming down to a level where it is accessible to
more people. There should be choices there too.
> All I really hope is that the world will afford an opportunity
> for this question to be fairly answered.
And on a large scale and for more people would be nice too!
Best Wishes
Jeff Fox
> How odd. I have both of the two messages I wrote to IntellaSys asking
> for more information. I briefly described the kinds of applications I'm
> involved in, my interest in the chip, and the desire for more
> information. That's it. So I seriously doubt anyone could have gotten
> "obsessed" from that.
As to the first point you jumped to the wrong conclusion:
It wasn't your email to IntellaSys marketing that brought them to
me to ask about you. You made a lot of comments in c.l.f about what
you thought IntellaSys marketing should do that they then said were
good ideas and that they would try to follow. It was that you had
a lot more to say about them after that that made them wonder why
you cared so much about them.
As I said, I told them that we agreed that you had posted some
good advice but that you had a lot of opinions. When I offered to
be your contact I knew I would then know if you were getting all
of your questions answered from where support got their answers.
Since they declined my offer I assumed that you weren't a problem
to marketing support staff and that they just wondered if I knew
who you were since I know a lot of people involved in Forth. They
wondered why you were obsessed with them and didn't realize it
was just 'all things Chuck' as you say.
> So frankly, I think you're lying-- or at best seriously embellishing--
> probably for effect.
I did think you would find it amusing at the time. You were just
mistaken here if you didn't realize it was your postings to c.l.f
not your email to marketing that was their concern. Sorry if
you thought I meant that you had been making a pest of yourself
in emails or phone calls to IntellaSys marketing.
On the second subject of your posting, trolling for Chuck:
> Really. Please point to that message. Not your characterization of the
> message, but the actual message.
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/
909804d14e34c67c/805604d6bb729528?hl=en&q=%22job+well+done%22+group:
comp.lang.forth#805604d6bb729528
Chuck's May 99 c.l.f response about Forth:
"You're correct to observe that good code is expensive. Quick and
dirty has its place. However, programming cost is incurred once.
Memory and time costs are paid at run time.
And there are other than economic values:
The satisfaction of a job well done.
The consolation of experience gained.
The joy of insight."
It is the only time in the history of Forth that I know of that
the inventor of Forth was drawn into a discussion to tell anyone
that they were wrong about Forth. It was certainly the only one
ever on usenet and you were given credit at the time by others.
The concepts he stated are very alien to your oft expressed
philosophy that Forth is about a misguided obsession for code
size and speed or that it is a great cultist conspiracy and
that reality is all about the economics of quick and dirty.
It is no wonder you insult people by calling such simple but
valuable explanations of Forth 'koans.' Most people call it
logic.
They are pretty simple ideas to most people. When other
craftsman express admiration of the high quality craftsmanship
involved or that they like one period of the artists work
more than another period you say that they are committing
the sin of 'idolatry' against your true religion of hate! ;-)
> I find this hilarious, but it's the standard kind of wild distortion
> you've whipped up as part of your persecution complex. At worst, I've
> asked critical questions that any engineer would and should ask. But to
> claim I think Moore's work is "snake oil" is just wild exaggeration.
On the third subject of your latest absurd claim that you have never
said "snake oil-salesman" etc., and more 'wild distortion' by quoting
again what you really have said: ;-)
On Dec 1 2001 Jeff Fox had written and I quote:
> So apparently John went to my website and
> felt that he had hit the jackpot. He
> then proceeded to target me. He called
> me "liar" "cultist" "snake-oil salesman"
>"mindless sicophant" "parrot" and long
> lists of other names over and over. Those
> are direct quotes.
John Passaniti replied, and I quote:
"Yep, and sometimes you are. You have lied (about me), you do
exhibit some of the properties of a cultist (such as an
unwillingness to consider anything outside your world view), you
have been a "snake-oil salesman" in that you have released
misleading spec sheets on chips (such a theoretical instruction
rates instead of actual measured rates on real-world hardware)
and engaged in apples-to-oranges comparisons that are misleading."
Since I was just giving real numbers from Chuck's and my testing
of real chips, the real numbers on real hardware have all been
proven real since then and republished by other people you were
wrong again.
Since the 'snake-oil' came only from Chuck and I you were also
saying that Chuck was lying and selling snake-oil. After all
there were disagreements between he and I about those facts.
Chuck and I at the time were a pretty small group to target as
conspiring cultists and snake-oil salesmen in your mind.
On the fourth subject of whether I said IntellaSys prioritized
customers by importance:
> Do (or did) you not count as an official IntellaSys spokesperson? When
> I first asked this question, it was *you* who stated that IntellaSys
> cared more about serving customers who would buying huge quantities.
I was not acting as an official representative of IntellaSys
marketing, but I was correct that they cared 'more' about higher
priority customers. "Prioritized" is was what I said.
And 'more' doesn't mean that 'less' has to be zero as you assume. ;-)
Best Wishes
Jeff Fox
> Since the 'snake-oil' came only from Chuck and I you were also
> saying that Chuck was lying and selling snake-oil. After all
> there were disagreements between he and I about those facts.
Unknown
> Since the 'snake-oil' came only from Chuck and I you were also
> saying that Chuck was lying and selling snake-oil. After all
> there were disagreements between he and I about those facts.
Bad grammar. Correct:
from Chuck and me
between him and me
rickman
wrote:
> Roger Ivie <ri...@ridgenet.net> writes:
> >On 2009-04-07, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> The kind of application I envision for the nodes without direct
> >> external RAM access is something that would normally be done in
> >> hardware, not something you would normally do with a CPU.
>
> >Would it be fair to say that you see it competing more with small FPGAs
> >than other CPUs?
>
> Something like that. I think there are application where SeaForth can
> work and FPGAs are too slow, and vice versa, but yes, I see the
> SeaForth applications much closer to FPGAs than to normal CPUs, except
> for the node that can access the external RAM.
It is hard to imagine an application where an FPGA can be too slow. I
can see them being too expensive perhaps, but too slow? With an FPGA
you can always throw more hardware at it to speed it up. Parallel is
the name of the game in FPGAs.
I can see the idea of a Seaforth chip being considered as a form of
FPGA that is very coarse grained and programmed with software rather
than at the routing level. But that pretty much negates everything
that distinguishes an FPGA from processors. In reality this is just
another MIMD processor like some of the earliest computers made. The
departure from the norm is actually economic.
The SeaForth processors are made very simple and small with a very
limited amount of storage per node. This allows the chip to be made
very inexpensively. The problem with putting 40 MIPs cores or 40 i86
cores on a single chip is that it would be a *huge* chip and cost far
too much to be practical for more than a very small number of apps. A
40 core chip going for under $20 or so will find a large number of
sockets in embedded apps as long as people are willing to deal with
the problems of programming parallel apps and the very small memory.
Rick
Jacko
the rights of patents, will not make then own the patents (issued to
the inventor), but only the patent rights. (i.e. the right to extract
cash off immitations).
> The SeaForth processors are made very simple and small with a very
> limited amount of storage per node. This allows the chip to be made
> very inexpensively. The problem with putting 40 MIPs cores or 40 i86
> cores on a single chip is that it would be a *huge* chip and cost far
> too much to be practical for more than a very small number of apps. A
> 40 core chip going for under $20 or so will find a large number of
> sockets in embedded apps as long as people are willing to deal with
> the problems of programming parallel apps and the very small memory.
>
> Rick
The FPGA/CPLD paradigm is at some level to fine in programmable
granularity for certain process specific jobs. Including multiplier
units on cyclone is case in point. The licencing of CPUs as hard-wired/
soft-routed entities on such devices raises logic density, improves
power consuption, and lowers eventual cost. Copmact cores are the
future.
cheers jacko
John Passaniti
> On Apr 6, 11:29 am, John Passaniti <n...@JapanIsShinto.com> wrote:
>> How odd. I have both of the two messages I wrote to IntellaSys asking
>> for more information. I briefly described the kinds of applications I'm
>> involved in, my interest in the chip, and the desire for more
>> information. That's it. So I seriously doubt anyone could have gotten
>> "obsessed" from that.
>
> As to the first point you jumped to the wrong conclusion:
Hmmm, then maybe you should have been more specific.
> It wasn't your email to IntellaSys marketing that brought them to
> me to ask about you. You made a lot of comments in c.l.f about what
> you thought IntellaSys marketing should do that they then said were
> good ideas and that they would try to follow. It was that you had
> a lot more to say about them after that that made them wonder why
> you cared so much about them.
Gosh, I thought that was clear on that. First, I work for a company
that constantly evaluates leading-edge chips for the work we do. On
that and that alone, I had an interest. Second, in both my current job
and past employment, I have had the opportunity to work with some really
great chips that ultimately crashed and burned because they couldn't
reach a critical mass in the industry. So some of my observations
(especially about the quality of tools, documentation, and support) were
driven by past disappointment in other companies who had a "if you build
it, they will come" mindset. Third, I was independently fascinated by
the architecture of the SEAforth chips, but unlike most of the fan-boys
in comp.lang.forth who will reflexively rah-rah anything with Moore's
name on it, I started to think about how I would spread an application
across the chip's cores. And in the process of doing that, I found (at
least initially) poor documentation. I also started to think about what
kind of tools and support I would want, and expressed that.
I'm sure in your mind I had other motivations. But that gets to the
next point:
> As I said, I told them that we agreed that you had posted some
> good advice but that you had a lot of opinions. When I offered to
> be your contact I knew I would then know if you were getting all
> of your questions answered from where support got their answers.
The thought of you acting as a "contact" for me is bizarre. For as long
as we've been exchanging messages, you have consistently misrepresented
my positions, twisted my words, and distorted my opinions through a
crazy fun-house mirror. So thanks, but if you feel the need to
represent me, please don't.
> On the second subject of your posting, trolling for Chuck:
>
>> Really. Please point to that message. Not your characterization of the
>> message, but the actual message.
>
> http://groups.google.com/group/comp.lang.forth/browse_thread/thread/
> 909804d14e34c67c/805604d6bb729528?hl=en&q=%22job+well+done%22+group:
> comp.lang.forth#805604d6bb729528
>
> Chuck's May 99 c.l.f response about Forth:
>
> "You're correct to observe that good code is expensive. Quick and
> dirty has its place. However, programming cost is incurred once.
> Memory and time costs are paid at run time.
>
> And there are other than economic values:
> The satisfaction of a job well done.
> The consolation of experience gained.
> The joy of insight."
THIS is supposedly the stunning shocker of a message that Mr. Moore
wrote to claim I was wrong about Forth? Where exactly is the part about
Forth that I got wrong? The first paragraph is a generic statement
about the costs of programming that doesn't in any way disagree with
anything I had written in that thread. The second paragraph is a set of
feel-good statements about writing code. Neither paragraph is about
Forth specifically, and neither cites what I supposedly got wrong.
> The concepts he stated are very alien to your oft expressed
> philosophy that Forth is about a misguided obsession for code
> size and speed or that it is a great cultist conspiracy and
> that reality is all about the economics of quick and dirty.
> It is no wonder you insult people by calling such simple but
> valuable explanations of Forth 'koans.' Most people call it
> logic.
Ah, now I think I see what likely happened here. Mr. Moore hasn't read
what I wrote. Instead, he got it filtered to him through the Jeff Fox
Fun-House Mirror.
> On Dec 1 2001 Jeff Fox had written and I quote:
>
>> So apparently John went to my website and
>> felt that he had hit the jackpot. He
>> then proceeded to target me. He called
>> me "liar" "cultist" "snake-oil salesman"
>> "mindless sicophant" "parrot" and long
>> lists of other names over and over. Those
>> are direct quotes.
What you didn't quote from my reply at the time that I challenged you to
take the message that I supposedly wrote and post it unedited online for
everyone to see what I actually wrote. Let others judge it on the merit
not on your fun-house distortions, but on the complete and unedited
statements I wrote. Oddly, you never did that, but you still delight in
recycling this nonsense.
You see Jeff, I have absolutely no problem taking responsibility for
anything I have ever written or said. What I will not take
responsibility for is other's tossing my words in a blender, picking the
juicy bits out, and having them regurgitated back without context.
This isn't the first time I've written this. It's a recurring pattern
for you. You seem to have a real fear for taking my words, unedited,
and letting them stand on face value. You always have to inject
commentary, selectively quote, or just make shit up.
But don't let that stop you. As you know, if you repeat something
enough times, maybe people will believe it.
Jonah Thomas
> http://groups.google.com/group/comp.lang.forth/browse_thread/thread/
> 909804d14e34c67c/805604d6bb729528?hl=en&q=%22job+well+done%22+group:
> comp.lang.forth#805604d6bb729528
Thank you. That reminded me to look back at Chuck Moore's 1999 talk.
http://www.ultratechnology.com/1xforth.htm
I had forgotten some of the details.
"The words that manipulate that stack are DUP, DROP and OVER period.
There's no ..., well SWAP is very convenient and you want it, but it
isn't a machine instruction. But no PICK no ROLL, none of the complex
operators to let you index down into the stack. This is the only part of
the stack, these first two elements, that you have any business worrying
about. [....]
"The others are on the stack because you put them there and you are
going to use them later after the stack falls back to their position.
They are not there because you're using them now. You don't want too
many of those things on the stack because you are going to forget what
they are.
"So people who draw stack diagrams or pictures of things on the stack
should immediately realize that they are doing something wrong. Even the
little parameter pictures that are so popular. You know if you are
defining a word and then you put in a comment showing what the stack
effects are and it indicates F and x and y
F ( x - y )
"I used to appreciate this back in the days when I let my stacks get too
complicated, but no more. We don't need this kind of information. It
should be obvious from the source code or be documented somewhere else."
Beautiful. DUP DROP OVER SWAP . If you need a stack diagram your code is
too complicated.
"You shouldn't nest too deeply. It makes programs impossible to follow.
You can have spaghetti code with calls just as you can with GOTOs. You
have got to keep it simple."
....
"There is a lot of discussion about local variables. That is another
aspect of your application where you can save 100% of the code. I remain
adamant that local variables are not only useless, they are harmful.
"If you are writing code that needs them, you are writing non-optimal
code. Don't use local variables. Don't come up with new syntaxes for
describing them and new schemes for implementing them. You can make
local variables very efficient especially if you have local registers to
store them in, but don't. It's bad. It's wrong."
If you need local variables, does it mean that there's something wrong
with your Forth, that it's too hard to use without locals?
"To me the application du jour is a web browser. If you have run out of
things to do, write a web browser. Netscape did not have the last word
on what it should be or how it should look or what it should do. In fact
Netscape and Microsoft both borrowed heavily from the Mosaic browser. It
is as if there was only one browser written. It is if there was only one
language written, and it's FORTRAN.
"Write a new browser. It's a good application. It gives you access to a
world of information. It's a good application and it's one that I am
trying to focus on in my spare time."
I haven't noticed any web browsers in Forth except the one written
professionally for iTV, that is apparently buried with iTV.
Web servers, yes. A web server needs to do just what you want it to and
you can add to it as you choose. It isn't that hard to write a web
server to do the sorts of things that Forth users are likely to want to
do on websites. Once you know how.
But to write a browser you need to display all the things that the
websites you care about offer. For many purposes that requires CSS,
javascript, maybe java? maybe Flash? Maybe display .pdf? Surely display
graphics, jpegs etc.
Some years ago somebody (I think it was Anton Ertl but sorry if I
remember that wrong) said that he did very well with a web browser that
didn't do anything fancy. Because as soon as he got to a technical site
that required javascript etc, that was a sure sign that the site was a
waste of his time. The technical sites that actually had worthwhile
information tried to present it simply and easily. I'm not sure how true
that is any more.
Anyway, has anybody else built a web browser in Forth? Would it be
worthwhile to implement something like lynx in Forth for a first
attempt? Webbrowsers do currently have a basic similarity, and only part
of that is because it's what users expect. Is there anything that could
be done obviously better, that isn't obvious because everybody expects
what we already have?
Albert van der Horst
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Roger Ivie <ri...@ridgenet.net> writes:
>>On 2009-04-07, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> The kind of application I envision for the nodes without direct
>>> external RAM access is something that would normally be done in
>>> hardware, not something you would normally do with a CPU.
>>
>>Would it be fair to say that you see it competing more with small FPGAs
>>than other CPUs?
>
>Something like that. I think there are application where SeaForth can
>work and FPGAs are too slow, and vice versa, but yes, I see the
>SeaForth applications much closer to FPGAs than to normal CPUs, except
>for the node that can access the external RAM.
I wonder if SEAForth would do a good job for FFT with small blocks.
Another application area would be on the fly encryption.
Comments anyone?
>
>- anton
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
rickman
wrote:
> In article <2009Apr8.120...@mips.complang.tuwien.ac.at>,
>
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >Roger Ivie <ri...@ridgenet.net> writes:
> >>On 2009-04-07, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>> The kind of application I envision for the nodes without direct
> >>> external RAM access is something that would normally be done in
> >>> hardware, not something you would normally do with a CPU.
>
> >>Would it be fair to say that you see it competing more with small FPGAs
> >>than other CPUs?
>
> >Something like that. I think there are application where SeaForth can
> >work and FPGAs are too slow, and vice versa, but yes, I see the
> >SeaForth applications much closer to FPGAs than to normal CPUs, except
> >for the node that can access the external RAM.
>
> I wonder if SEAForth would do a good job for FFT with small blocks.
>
> Another application area would be on the fly encryption.
>
> Comments anyone?
Actually, I am sure there are lots of applications where a chip like
this would excel. A few years ago I worked at a company that made
hand held 2-way radios for military use. These units contained a
special chip which handled the encryption and secure protocols along
with a high end processor (StrongArm) for other tasks. They had part
of a huge contract for developing a new standard unit. In many ways
it was just the same old, same old with a wider range of RF. The
government wanted the designers to come up with some new ideas, so
they offered some R&D money to explore radical approaches to solving
the processor issue, including multiprocessor chips.
I looked at the possibility of using something like the Seaforth chip
in this application and tried discussing this with some people. I
found that no one was interested in departing from their established
ways in terms of software design and certainly not to the extent
required by the SeaForth chip. What they seemed to want was an array
of StrongArm chips which would just exacerbate all the problems of
using even one StrongArm, notably SWAP (Size, Weight and Power).
I don't really know much about the algorithms that needed to be run on
the main processor of a military radio. But they had a lot of time
and money invested in their existing methods and code. I think that
for anyone to consider using such a radically different chip and use
such a radically different language, it would need to use a small
software design, preferably with little existing software, that would
be produced in high volume so that the unit cost advantage of the chip
would dominate the picture.
Otherwise, I think that the mindset of too many designers is that you
pick a chip that runs the Linux code base or is easily programmable in
C or C++. That is why I think they want to code the application
themselves. Not really for technical issues exactly (lack of
programmers trained in Forth, multiprocessing, etc), but the
management issues of of using a *new* design paradigm and abandoning
existing code bases to start from scratch.
So just looking at technical advantages is not enough for a company to
use a radically new chip like the SeaForth. what applications would
be small enough that you wouldn't mind tossing out all existing code
and yet is high enough volume that the cost advantage the SeaForth
chip has over a StrongArm is significant? Where would management be
willing to take the risk of turning their entire development over to a
contractor?
Rick
Leon
> Roger Ivie <ri...@ridgenet.net> writes:
> >On 2009-04-07, Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> The kind of application I envision for the nodes without direct
> >> external RAM access is something that would normally be done in
> >> hardware, not something you would normally do with a CPU.
>
> >Would it be fair to say that you see it competing more with small FPGAs
> >than other CPUs?
>
> Something like that. I think there are application where SeaForth can
> work and FPGAs are too slow, and vice versa, but yes, I see the
> SeaForth applications much closer to FPGAs than to normal CPUs, except
> for the node that can access the external RAM.
FPGA replacement is one of the applications for the XMOS chips - they
only have a maximum of four cores, but with eight hardware threads per
core they may effectively have up to 32 processors running at 50 or
100 MIPs each for a total of 1600 MIPS.
Leon
Jacko
fine, why fix it? ;-)
Yes greater range SWAP issues would be nice as the isolated state gun
man and his less armed politi troops would say.
The main non codec processor just needs to run the display, buttons
and program the control registers of the codec chip. Your average PLL
LW/MW/SW/FM consummer radio with LCD display has enough power in this
respect.
Yes the manager speak of 'he could do that again but slightly
differently' is prefered to 'we will have to ask the software guys'
every profit seeking day of the week.
Something new has to be possible before any change is used.
cheers jacko
van...@vsta.org
I tried to map DES onto it. The problem I ran into was that DES is very
32-bit oriented, so you run into quite a bit of hassle using pairs of 18
bit numbers in doing the math. The tables you need to work against also
don't fit well into the available memory, and by the time you divvy it
up across enough processors to hold the tables, you've used up so many
CPUs that the solution basically isn't parallel any more.
Its single thread performance didn't look like it would be all that
impressive (mostly because of the overhead of doing most things as pairs
of 18-bit operations, plus the overhead of passing decomposed operations
between CPUs). If you had, say, an ARM CPU in the design anyway you'd
probably be ahead of the game to use the budget to up its clock and RAM
a bit and spare yourself a bunch of pain.
Note that I stopped coding before I had a full implementation, but I'm
pretty sure all the state could fit in the CPU local memory. If you
had to spill out to the external RAM, performance would be a good bit
lower again.
Andy Valencia
Bernd Paysan
> Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>> Another application area would be on the fly encryption.
>
> I tried to map DES onto it. The problem I ran into was that DES is very
> 32-bit oriented, so you run into quite a bit of hassle using pairs of 18
> bit numbers in doing the math.
I would guess so. More recent encryption algorithms often are 64-bit-
oriented (to run fast on contemporary desktop processors), and use larger
tables, so it will become even uglier. Encryption is where FPGAs have quite
a head start, because the typical operations are xor, rotate, memory
lookups, and quite often the algorithms are even tailored to the 4-input-
LUTs.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Anton Ertl
>On Apr 8, 6:03 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> work and FPGAs are too slow, and vice versa, but yes, I see the
>> SeaForth applications much closer to FPGAs than to normal CPUs, except
>> for the node that can access the external RAM.
>
>It is hard to imagine an application where an FPGA can be too slow. I
>can see them being too expensive perhaps, but too slow? With an FPGA
>you can always throw more hardware at it to speed it up. Parallel is
>the name of the game in FPGAs.
There are things that have sequential dependencies where parallel
hardware does not help you.
FPGAs are clocked much slower and consume much more power than
full-custom hardware. A trivial example where an FPGA would lose
against a SeaForth chip (in both speed and power) is when implementing
a SeaForth chip. However, the things I was thinking of are
applications where the instruictions and organization available on the
SeaForth chip match the task quite well rather than having to use lots
of instructions to implement some not-too-complex logic formula (FPGAs
would win there hands down).
>I can see the idea of a Seaforth chip being considered as a form of
>FPGA that is very coarse grained and programmed with software rather
>than at the routing level. But that pretty much negates everything
>that distinguishes an FPGA from processors. In reality this is just
>another MIMD processor like some of the earliest computers made.
IMO thinking about it this way will lead to a software disaster. It's
just too hard to program and has too little capabilities to be
programmed as a general-purpose MIMD processor.
It's probably better to think about it as, e.g., an I/O chip where the
behaviour of each pair of pins can be freely programmed with a very
limited program.
Wayne
<john.pa...@gmail.com> wrote:
> 3. Is it true that the SEAforth-related staff at IntellaSys preferred
> to do the development themselves and release the result as a turn-key
> product?
That is rough, a chip in the hand is worth many in the bush. A turnkey
chip out
there, is probably more likely to produce revenue then hunting for some big
pocket to bank it on an unproven product not yet in existence they cannot
even
test. It is better to do both. Many Asian manufacturers (you know the
ones that
saturate the market) buy turn key solutions and implement them re-badged or
customised. A chip in a DVD player for instance, might be manufactured in
full
quantity, then sent to several, or even seventy different manufacturers,
but
hardly any manufacturer will order millions fo them. In ramp up to full
confidence
in a product, a manufacturer might make and manufacturer one or two
products, and
see how it fares before rolling out a part across the range. I don't think
many are
interested in anything they have to get designed and then buy, but it
depends on
what sort of market you are perusing, as some embedded markets it might
not matter
so much. I advised they should concentrate on getting their hobbyist
community to
design/program up open systems that could be used in the sale of the
chips. I was
even going to ask people if anybody was interested in the possibility of
doing a
HDTV receiver suite (given a chip that could handle it).
Wayne
> Yes, misinformed.
>
> The chips exist and TPL should be willing to ship them if anyone is
> interested
> in using any. The business entity called IntellaSys still asserts
> ownership of
> the trademarks SEAforth and so on, and all the chips marked with that
> trade-
> mark. IntellaSys still exists, TPL still exists and asserts sole
> ownership of
> IntellaSys, and one man still exists and asserts sole ownership of TPL
> along
> with everything else his eyes behold.
>
> "Closed Doors" means does not exist, cannot be reached, and will not do
> business. Unless something has changed radically in the last few days,
> it is
> misinformation to state that the Doors are Closed at IntellaSys.
>
> My assumption in answering this question was that people here were
> concerned
> that this tiff might make the S40 unavailable.
>
> Inasmuch as when we left TPL had roughly 14000 packaged chips on hand,
> and 20 wafers (roughly 66,000 die) offshore waiting to be packaged, there
> should be no availability problems unless someone is planning to make a
> major product from them. In which case TPL would probably be willing
> to make a lot of money generating more.
>
> If instead this discussion is about gossip and stuff, rather than about
> the
> actual chips themselves, their availability, and other technical
> matters, then
> I regret my misunderstanding. In reviewing the thread I see that it is
> likely
> more about the former than the latter but maybe someone out there is
> actually interested in *using* our chips - hell, if no one is, why are we
> bothering to design the damn things, and why does anyone here give a
> damn either?
>
> Greg Bailey, formerly VP Engineering at IntellaSys
>
> "Dennis Ruffer" <dru...@worldnet.att.net> wrote in message
> news:e7394018-eb62-41de...@z1g2000yqn.googlegroups.com...
>> Another interesting gem from Chuck's site (http://www.colorforth.com/
>> S40.htm):
>>
>> "TPL fired SEAForth employees in January 2009 and thus terminated the
>> project."
>>
>> Misinformed?
>>
>> DaR
>>
>
So, exactly what happened, who got fired, how has the intellasys focus
changed,
if at all, from the small developer outreach and development kits? In
business,
all these things matter intensely, as they give an idea of the future
stability
before projects are attempted.
I am currently still finishing a few things before starting my work on a
SF based
consumer electronics platform, and a OS system changed to suit the chips.
As such
it is small budget and relies on attracting manufacturers to the package,
so there
won't be any money to redirect a companies attention till second
subsequent rounds
of products.
Wayne
wrote:
> The chip is hardly "seriously wacky", but as you and others have noted,
> designing an application to make full use of an array of 24, 40, or
> however many tiny processors is a challenge for which few engineers are
> prepared by experience with parts currently on the market. At some
> point, there will probably emerge design tools that facilitate that, but
> the presence of a team of highly skilled engineers who at this point
> have several years' experience addressing exactly this challenge is an
> asset not to be dismissed likely.
>
> Cheers,
> Elizabeth
I am yet to get around to grips with all the seaforth information (stilled
snowed under)
but was planing on using my experience with OS design to implement my OS
with a automatic footprint system, and a message passing system that would
make programming the array more similar to a conventional forth processor
and allow a program to be reused on newer chips largely (or completely
unchanged). I have talked about some things here on a primitive level
before, and to the company. But it would be suitable for both cores with
tens of words of ram or large memory spaces and require minimal increased
hardware complexity or loss in efficiencies (when not programmed
inefficiently) and possibly great increases in efficiencies sometimes, and
increases in flexibility. The issue is that a greater range of
programmers would be able to make solutions easier, sometimes to within
percentage points of custom solutions.
I have to find out what mediation solutions you/seaforth are intending for
seaforth development environment to see how it could be slotted in. I was
thinking of approaching the parent company about inclusion and patents on
some of these things, as I still should have a bucket load of patentable
OS related technologies form my old research. But for the SF routines a
lot of implementation integration and testing needs to be done first.
Thanks
Wayne.
gavino
> It's a disagreement between Chuck and TPL about who owns the patents.
> TPL claim they own the patents. Chuck claims they were 'assigned' to
> TPL, which is not the same as owning them.
>
> http://www.colorforth.com/assignment.htm
>
> Mark
dead link
gavino
> On Apr 6, 5:06 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>
>
>
>
>
> > Jeff Fox wrote:
> > > When they first claimed that Chuck's name on the patents
> > > entitled him to nothing I choose not to support their effort.
>
> > Well, I think we here in Europe agree that TPL is a patent troll
> > group (the name probably expands to "Troll patent litigators"). Then,
> > there are two other questions: Is Chuck's work valuable (one side),
> > and are the patents extracted from the ShBoom leftovers worth the
> > paper they are written on (other side). My point: Chuck's work is
> > valuable, and the patents aren't worth the paper they are printed on.
> > It is a shame that these patents exist and that outsiders to Forth
> > know Chuck only through this "Moore patent portfolio".
>
> > The latter has a lot more to do with the quality of the patent system
> > (not only limited to the US), and this system is in a very sad state.
> > E.g. one of Chuck's patent is about fetching several instructions in
> > one go, and executing them sequentially. All I know is that this was
> > an invention at some point in time, but that point had definitely
> > passed when the Burroughs B5000 saw light. This was 1961. At that
> > time, all these concepts like stack instructions, packing multiple
> > instructions in one word and so on where revolutionary (the Zuse Z22,
> > ready at about the same time, had similar inventions), but since
> > 1961, a lot of time has passed.
>
> > Another of Chuck's patents claims that a CPU runs with a different
> > internal clock than IO clock. This is probably the main source of
> > income for the TPL, because virtually every CPU does that. The point
> > however is: They always did; they certainly did it back when the
> > B5000 was first made.
>
> > So in effect, what happened with Chuck's ShBoom leftovers was that
> > some patent lawyer went over it and extracted everything he could
> > barely understand and though it might have been new, and the USPTO
> > happily grants whatever bullshit you bring in as patent - after
> > breaking it down to meaningless little bits of "innovation". And
> > then, it is so expensive to fight off such a patent lawsuit that it's
> > cheaper to pay some millions to these trolls, instead of invalidating
> > the patents (which is far from trivial in the US - e.g. the obnoxious
> > Microsoft FAT patent got reinstated in 2006, while in Germany, the
> > same patent was thrown over in 2007 for
> > a) not being new (Rock Ridge cited as prior art)
> > b) obvious and
> > c) not even containing a proper teaching).
>
> > Insofar, the TPL is probably right that Chuck did not contribute
> > anything to these patents - in so far that these patents are not
> > inventions, anyway. These people are highwaymen, they are not
> > concerned about innovation and engineering, they want to rob as many
> > people as possible. The engineers who's work was the sources of the
> > patents included.
>
> > --
> > Bernd Paysan
> > "If you want it done right, you have to do it yourself"http://www.jwdt.com/~paysan/
>
>
> Here's what worries me about TPL:
>
> 1) You buy 500,000 chips from IntellaSys to build into your next
> product, let's say it's a TV set-top box.
> 2) You design the product
> 3) You put it in production
> 4) TPL come after you with the lawyers in full sue mode, waving the
> Moore portfolio, and demanding a licence because other aspects of your
> design infringe it!
>
> Shafted.
so these TPL guys say they own chuck's designs? That is horrible. Is
like intel funding them?
gavino
> On Apr 6, 3:26 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> wrote:
>
> > Everybody in his right mind can see that John is very knowledgeable
> > and contributes important insights to this group. Everything
> > he says makes sense, and almost everything is at least a valuable
> > point of view.
>
> I saw your posting to the colorforth mailing list also
> claiming that Chuck's work is all just a patent scam.
> People don't all have to have the same opinions to be
> in their right minds. ;-)
>
> > I had some nice experiences with Renesas/GLYN over a EURO 50 kit
> > with free development tools. They didn't spend 100 hours on me
> > (nobody expects such).
>
> If you happy with Renasas that's great. Things tend to be a
> little different in a startup. I would say it is a simpler
> explanation than that it is all a patent scam as you claim.
>
> > I remember Patriot having a feature article in Elektuur (now
> > Elektor). Then I found out that nobody in Europe would sell the
> > kit that was described to me.
>
> When they first claimed that Chuck's name on the patents
> entitled him to nothing I choose not to support their effort.
> that Chuck deserves nothing again.
>
> Best Wishes
I am sad they are trying to take Chuck's ideas. This is really sad.
He is like Goldeneyes Silverhand Dactylos in the Terry Pratchett
novels.
gavino
> > entitled him to nothing I choose not to support their effort.
>
TPL sound like real bastards.
Jacko
Well when english people say hello, the hell and below, and hallowed,
meaning called you little evil one who is definitly going to rome/
frenchie hell (sarcastic) because the same folks probably killed
welcome by a well cum, crack one out in the water supply.
TPL is leachy bastards.
Jacko
are => our
am => implies aim implies aroowtica harrowism
Wayne
wrote:
> Chuck changed his site again, and this time he took down his legal
> stuff.
>
> Jason
But precisely what has happened at intellasys? Who is still working
there, and what are these separate companies?
bit...@gmail.com
wrote:
>
> I wonder if SEAForth would do a good job for FFT with small blocks.
>
multiply operations and a twiddle table or use a CORDIC algorithm. Use
of CORDIC means you don't need the twiddle table. But you still need a
RAM working buffer so you're kind of limited there. OTOH, while the
CORDIC core is doing its thing you could have another core moving data
to/from external memory. So yeah, I think SEAforth could do a
reasonable FFT if you can move the data. You can have several CORDIC
operations running in parallel.
-Brad
Andreas
hwf...@gmail.com
noise. It's an academic question, though. I'm not implementing
anything. Just saying it's possible, and I've made the CORDIC-based
FFT work in VHDL. When using SEAforth, I think a radix-4 butterfly
would beat the CORDIC approach except for the annoying fact that you
don't have a convenient place to store sin/cos lookup tables of any
substantial size.
Jeff Fox
>
Due to the very small amount of local memory only very small
blocks can be supported before data has to be distributed on
more nodes and moved around on parts of the butterfly which
causes efficiency and performance to drop. Before the 36-
bit multiply instruction was added a couple cordic based
FFT were done to compare multiply vs non-multiply based FFT.
After the multiply was upgraded more conventional FFT were
done.
But FFT is just a speed optimized DFT for some architectures.
DFT is easier to parallelize and we are able to get parallel
DFT to go faster than FFT. People willing to refactor their
code to get the same time domain to frequency domain
conversion results but using a more efficient method may
be willing to exchange FFT that they previously exchanged
for DFT back to the original. Some other people will
say that they need to use FFT and that they can't refactor
to match underlying architecture.
Best Wishes
Andreas
For non-academic applications you have to filter your input signal
anyhow. Classic is Butterworth LP. So high-precision sin/cos is not
necessary. Polynomial approximation of sin between 0 and pi/2 may be
sufficient, which could be calculated in a parallel path.