SEAforth Instruction Set
hubuli
contains 32 opcodes although only 30 are described until now. Most of
them are pretty obvious but some are not:
Can anybody help me understand the proper way to make use of the "!p+"
opcode?
How does the multiply step work? The core promises to produce 36 bit
results. Where will the result occur?
Are multiply-accumulate operations synthesized by fast c18 instructions
only? Is there a different way like memory mapped hardware?
Roberto Waltman
>The new SEAforth instruction set has been published by Intellasys.
Is that in the Intellasys web site? I can not find it.
John Passaniti
> The new SEAforth instruction set has been published by Intellasys.
Please provide a URL.
Keith
Posted here June 13th by John M Drake in the "Interesting IntellaSys
Article" thread.
http://www.elecdesign.com/Articles/Index.cfm?ArticleID=12692&pg=1
The instruction set is shown here:
http://www.elecdesign.com/Files/29/12692/Figure_02.jpg
It should look familiar if you've read papers like
http://dec.bournemouth.ac.uk/forth/euro/ef01/moore01a.pdf before.
Regards,
Keith
hubuli
instruction set table. That can be found there:
The article is a variant of the original text from the Intellasys site.
That table is among the differences.
vandyswa
hubuli wrote:
> Can anybody help me understand the proper way to make use of the "!p+"
> opcode?
Yeah, that one had me scratching my head as well. I guess it'd
optimize implementing a variable-set sort of operation, but reference
the value would be much less optimal. So I join you in being curious
about the method behind its madness.
The chip also has the B register, but without the ability to fetch its
value, nor to post-increment it. So it doesn't help much with memory
copy loops (since you have to keep its current value elsewhere so you
can advance it), thus I'm guessing that it's targeted at memory mapped
inter-CPU registers and such. In this case you can walk A forward
through the block of memory to be transferred, with B pointing at that
interlocked inter-CPU transfer register. Such a transfer should happen
PDQ, I'd think.
When I scoped out the 25x years ago, I found that the 18-bit
architecture along with the single external RAM were a poor fit for
things like crypto (which access lots of data, both source/dest as well
as tables). Networking was a much better potential fit, both layer 2
as well as layer 3, although again you have to be careful how much
state you need to access in order to process packets. The 25x needed
something external to frame GigE, but thereafter it seemed like an
extremely cost effective and flexible way to implement packet
procesing.
$0.02,
Andy Valencia
van...@vsta.org
jmdra...@yahoo.com
hubuli wrote:
> The new SEAforth instruction set has been published by Intellasys. It
> contains 32 opcodes although only 30 are described until now. Most of
> them are pretty obvious but some are not:
>
> Can anybody help me understand the proper way to make use of the "!p+"
> opcode?
According to Jeff, the "p" instructions access the program counter
register. From that I'm guessing that "!p+" takes a number off the
stack and stores it in the address pointed to by the program
counter.
> How does the multiply step work?
The same as it did on the F21.
> The core promises to produce 36 bit
> results. Where will the result occur?
That I don't know. But Forth traditionally puts "double" results into
2
consequtive stack cells.
> Are multiply-accumulate operations synthesized by fast c18 instructions
> only? Is there a different way like memory mapped hardware?
I would think that an 18x18 "hardware multiply" implies an actual
instruction
as opposed to a "multiply subroutine" synthesized by c18 instructions.
Also
note that IntellaSys has released to "product papers". While both
mention
a "18x18 VentureForth multiply", only the SEAforth-24B specificially
mentions
that a "hardware multiply" in the "c18 processor features" section. So
(again
my guess) is that on the 24B this is an actual hardware instruction,
but on
the 24A it may be synthesized.
Regards,
John M. Drake
hubuli
behaves like a puzzle these days ;-).
About "!p+":
I assume that the value of "!p+" comes to play when Forthlets are to be
loaded. The code snippet
@p+ b! @b .
channel-address
for @b !p+ next
should read from a channel being addressed by register b. Gets the
length of a forthlet and copies the forthlet starting in the
instruction word after NEXT. Register p will then point to the first
instruction word after the forthlet. That word needs to be already
preloaded with some reasonable code like
jump start-forthlet
or
@b push ; .
that receives the starting address (of the forthlet) via the channel
and continues execution there.
About copy-loops: Andy seems to be right, this incarnation of c18 does
not to support them well. As quite often with Chuck's designs: the
answer to a question is: you will not neeed it! We really need to
become more familiar with the Forthlet concept in order to understand
the design decisions.
About multiply-step:
Both product flyers 24A and 24B tell about an 18x18->36 multiply
instruction. I assume that this is among the two opcodes that are not
published yet. The 24B tells about a multiply-accumulate feature - this
is possibly an option not available in the 24A. As "+*" is still
available, I expect this as a manadatory feature for all c18
incarnations, even those that will not have the 18x18->36 instructions.
The behaviour I expect is "add S to T if T0=1" as we know it from
previous MISC designs.
Jeff Fox
> The new SEAforth instruction set has been published by Intellasys. It
> contains 32 opcodes although only 30 are described until now. Most of
> them are pretty obvious but some are not:
>
> Can anybody help me understand the proper way to make use of the "!p+"
> opcode?
Geez. Please don't ask that here, now. You are going to just get
false guesses from some people. And then others will guess that some
of the false guesses are true. Then they will repeat them. Then others
will add more falsehoods until it becomes most of what people 'know.'
Please don't invite people to guess and post false gueses.
Jeff Fox
> hubuli wrote:
> > Can anybody help me understand the proper way to make use of the "!p+"
> > opcode?
We said we would explain it. Please don't ask people to give wrong
explanations first instead of wating for the truth.
> Yeah, that one had me scratching my head as well. I guess
guesses posted publicly often get accepted as truth and repeated
for years. Please don't do that to us.
> optimize implementing a variable-set sort of operation, but reference
> the value would be much less optimal. So I join you in being curious
> about the method behind its madness.
If enough madness gets posted before the truth, if enough threads go
off into madness and nonsense the truth will be sufficiently masked
that most people will never figure it out.
> When I scoped out the 25x years ago,
25x years ago was an idea, which after many man years of work
has had many design enhancements in becoming a real chip.
People have made many wrong assumptions not knowing the
details of all of those man years of work by so many people.
It is easy to take a little information from many years in the past,
make many wrong guesses, then jump to many wrong conclusions
about what it will mean regarding a different chip years in the future.
Often when the future arrives all that people remember are all
the false guesses that people made that they remember as facts.
I just wish people would prefer facts to repeating false guesses.
But I do realize that some people prefer to be the source of
information, and if they don't have access to the truth and insist
on being the source of information they can only guess.
I have seen how some people latch on to some people's early
false guesses and continue to argue forever they the false
guesses that they kept repeating were really the truth.
Jeff Fox
> hubuli wrote:
> > Can anybody help me understand the proper way to make use of the "!p+"
> > opcode?
We have said that we will provide an explanation of our chips. I hope
that
I won't have to write off c.l.f as a place where other people prefer to
provide
more false information about our work than we can counter.
> According to Jeff, the "p" instructions access the program counter
> register. From that I'm guessing that "!p+" takes a number off the
> stack and stores it in the address pointed to by the program
> counter.
You are guesses right in this case. But I really wish people won't
guess because as often as not people will repeat the wrong guesses.
> > How does the multiply step work?
>
> The same as it did on the F21.
Not exaclty.
It is true that for the most part standard machineforth, which is older
than ANS, has not changed. We have added some new things and
fine tunes some instructions. +* has changed. It is not the same
as it was on F21. But it is similar.
F21 did a 21-bit version that looked like
: +* dup 1 and if over + then ;
so it required a 2/ after each bit-step
the x-bit x x-bit version with up to a an 18-bit result on c18 does
: +* dup 1 and if over + then 2/ ;
so no 2/ is needed after each bit-step
and a 18x18 version produces a 36-bit of T*S in T and A
and we did one that did 18 steps
I would ask people to please not post guesses.
Even when somone says, "I am only guessing that..." someone else
is likely to declare the guess right and repeat it as if it were true
then
other people repeat it. Before long some people will argue that Chuck
is wrong when he says something that contradicts the false guesses
that people have accepted as true.
Jean-François Michaud
And then the light of Truth, in its most glorious form, shall come out
when least expected to strike down the infamy.
Regards
Jean-Francois Michaud
hubuli
wanted to learn from people who know. So I have to apologize for my
impatience and hope that most of the questions will be answered with
the upcoming release of T18.
Jean-François Michaud
You should not apologize for asking questions. Feel completely free, at
large, to ask them. Pay little attention to those who would prevent you
from doing so.
Your question was perfectly legitimate.
Regards
Jean-Francois Michaud
Jeff Fox
> Thanks for the comments - here are my latest speculations - SEAforth
> behaves like a puzzle these days ;-).
Please don't post more speculations. You asked, but instead of waiting
for a response from anyone who knew the answer you accepted guesses
then post your latest speculations to answer you own questions?
The biggest reason for a puzzle is that people have been encouraging
each other to guess and repeate guesses. A cloud of false guesses
mixed with a little real information makes for quite a puzzle. Please
don't make it a bigger puzzle for people by adding more speculations
or guessing about the accuracy of other people's guesses.
> About "!p+":
> I assume that the value of "!p+" comes to play when Forthlets are to be
> loaded.
You are close and made one right guess.
But I will add that most of what has been posted about Forthlets in
this newsgroup has been completely wrong. I just wish people would
not ask questions and post speculations that other people accept as
truth. I wish they would not delcare other people's false specualtions
as true and repeat them.
What is terrible is that people make a few wrong guesses then
follow a chain of logic to the wrong conclusions. But then they
publish these conclusions and someone else who also has no
valid chain of logic will declare the conclusion valid and repeat it.
> About copy-loops: Andy seems to be right, ...
> this incarnation of c18 does not to ....
Is this based on your guesses about the validity of other
people's guesses? When people are first exposed to all these
sorts of wrong guesses, and not knowing what are guesses and
what are facts, they are likely to never solve the puzzle. And
to this day many people only remember the false guesses from
the past that got posted more often than facts posted by people
with hands-on experience.
And after posting falsehoods about someone else's work people will
sometimes add insult to injury to excuse their posting something
untrue about someone.
> As quite often with Chuck's designs: the answer to a question is:
> you will not neeed it!
Nonsense. Insult to injury.
> We really need to become more familiar with the Forthlet concept
> in order to understand the design decisions.
So far everything posted about Forthlets in c.l.f has been wrong and
missleading and based on people's false assumptions that led to
their posting missinformation. Other people have accepted the
wrong guesses as facts and made more wrong guesses. Your
explanations of Forthlets to this group are contributing to the
problem.
If people continue to create an alternate reality in which there
are an alternate set of facts that reflect the madness that
people think match the false assumptions that they think
are facts then it will become impossible for people in c.l.f
in become familiar with and understand the truth about
Forthlets.
I have read several explanations of Forthlets now in this newsgroup
and each time I think, why is that people who know nothing about
this stuff feel compeled to be the ones to explain it to everyone else
even though they know they are just guessing?
Why are other people compelled to declare these people's false
speculations as truth and then speculate further and spin things off
futher from reality? Why do people prefer that to letting the people
who are doing something explain what they are doing?
To me that is a real puzzle.
vandyswa
> @p+ b! @b .
> channel-address
> for @b !p+ next
Neat! I hadn't thought of looping within a single word, with P ranging
on ahead. I can imagine the header of the first codelet being another
of these constructs, so you could concatenate them before flowing into
the resulting code.
Hey, Jeff, with all respect--lighten up. You pulled the PR lever, and
now you have publicity, which includes discussion. It is NOT an option
to then try to sit on the discussion. I suggest you participate in
some form. And consider the possibility that those of us staggering
around in the dark might actually come up with something new and
useful.
Regards,
Andy Valencia
Jean-François Michaud
Jeff Fox wrote:
> hubuli wrote:
> > Thanks for the comments - here are my latest speculations - SEAforth
> > behaves like a puzzle these days ;-).
>
> Please don't post more speculations. You asked, but instead of waiting
> for a response from anyone who knew the answer you accepted guesses
> then post your latest speculations to answer you own questions?
>
> The biggest reason for a puzzle is that people have been encouraging
> each other to guess and repeate guesses. A cloud of false guesses
> mixed with a little real information makes for quite a puzzle. Please
> don't make it a bigger puzzle for people by adding more speculations
> or guessing about the accuracy of other people's guesses.
I think people on this forum are old enough to make the distinction
between what is speculation and what isn't. If people are having fun
trying to figure out how things work, why not simply let them have
their fun? Things will settle down through discussion. Eventually, the
real deal will surface and the speculations will end. No big deal.
> > About "!p+":
> > I assume that the value of "!p+" comes to play when Forthlets are to be
> > loaded.
>
> You are close and made one right guess.
>
> But I will add that most of what has been posted about Forthlets in
> this newsgroup has been completely wrong. I just wish people would
> not ask questions and post speculations that other people accept as
> truth. I wish they would not delcare other people's false specualtions
> as true and repeat them.
>
> What is terrible
It's never as bad as you make it to be. If everybody followed your
logic, everything would come to a complete stop.
It's not that puzzling. Everybody likes to understand. Speculating and
then testing one's speculations is a way to advance without direct
knowledge of what is truely going on. It is actually the ONLY way to
advance under certain circumstances (akin to reverse engineering). This
is what physicist do to a certain extent when exploring our underlying
reality.
Things will fall in place eventually. If you feel you understand what
you claim others don't then by all means, explain what you understand.
Things will naturally fall in place when the pieces come together.
Bashing others in the head only telling them they are wrong won't bring
anything to the conversation.
Regards
Jean-Francois Michaud
jmdra...@yahoo.com
Jeff Fox wrote:
> > According to Jeff, the "p" instructions access the program counter
> > register. From that I'm guessing that "!p+" takes a number off the
> > stack and stores it in the address pointed to by the program
> > counter.
>
> You are guesses right in this case. But I really wish people won't
> guess because as often as not people will repeat the wrong guesses.
Well I wasn't really "guessing" but merely stating the obvious based
on the available information. I used the word "guess" just as a caveat
in case I got it wrong. ;) Once I knew what "p" was for the
description
"store to address in p; increment" is pretty self evident.
> > > How does the multiply step work?
> >
> > The same as it did on the F21.
>
> Not exaclty.
>
> It is true that for the most part standard machineforth, which is older
>
> than ANS, has not changed. We have added some new things and
> fine tunes some instructions. +* has changed. It is not the same
> as it was on F21. But it is similar.
>
> F21 did a 21-bit version that looked like
>
> : +* dup 1 and if over + then ;
>
> so it required a 2/ after each bit-step
>
> the x-bit x x-bit version with up to a an 18-bit result on c18 does
>
> : +* dup 1 and if over + then 2/ ;
>
> so no 2/ is needed after each bit-step
Ok. My bad. I should have said "there's an instruction with the
same name in the F21". The changes make sense.
> and a 18x18 version produces a 36-bit of T*S in T and A
>
> and we did one that did 18 steps
Just to clarify, the 18x18 version does it in one step and
the other version is for cores without a one step multiply
instruction?
> I would ask people to please not post guesses.
>
> Even when somone says, "I am only guessing that..." someone else
> is likely to declare the guess right and repeat it as if it were true
> then
> other people repeat it. Before long some people will argue that Chuck
> is wrong when he says something that contradicts the false guesses
> that people have accepted as true.
Well I was suprised to see an article (and now two) that showed the
c18 instruction set before prior to the instruction set being posted
at the IntellaSys website. I actually saw this article "electronic
design" article on the #c4th IRC channel even before you posted
it on the ColorForth mailing list. I guess (sorry) what I'm getting
at is I don't how you guys can expect to put this kind of information
out without expecting some kind of comments. Someone on the
#c4th IRC channel made a similair "guess" to the possible
"Forthlet" connection to the "p" instructions that hubili made
(although without going so far as to try and write a code
snippet). I've tried to keep my comments to what (seems)
obvious and away from blanket speculation. But nothing
that I've seen has been malicious. Nobody making rude
comments about "bogomips" and such. (Yes, that might
come later). Anyway, I'm guessing (oops, sorry) that the
average person that reads the articles from Electronic Design
and DSP DesignLine will go to the IntellaSys website for
answers rather than comp.lang.forth. And soon (if all goes
according to plan) they'll be able to download VentureForth
and see how it all works for themselves. Personally I'm
looking forwrd to that!
Regards,
John M. Drake
Jeff Fox
> I think people on this forum are old enough to make the distinction
> between what is speculation and what isn't. If people are having fun
> trying to figure out how things work, why not simply let them have
> their fun? Things will settle down through discussion. Eventually, the
> real deal will surface and the speculations will end. No big deal.
>From what I recall from the past what most people remember are
usually the wrong speculation. I base my opinion on this group in the
past. You have more confidence in them than I.
> It's never as bad as you make it to be.
That's a rather blanket statement. I maintain that it is bad for
everyone when falsehoods replace facts. You may choose to
argue that errors are never as bad as I make them out to be.
But by using the word 'never' your statement is easily disproved
by my giving one case where it as bad as I say it is.
It is just your opinion anyway as to 'how' bad ignorance and
errors are. I think 'how' bad the errors are all depends on context.
The error might involve millions or billions or dollars, or lives.
In that case I would say it was a pretty serious error.
> If everybody followed your
> logic, everything would come to a complete stop.
Yes. That is my logic. The universe must come to a complete stop
or none of my logic makes any sense. That's even sillier than saying
that no amount of money or number of lives is important.
> It's not that puzzling. Everybody likes to understand. Speculating and
> then testing one's speculations is a way to advance without direct
> knowledge of what is truely going on. It is actually the ONLY way to
> advance under certain circumstances (akin to reverse engineering). This
> is what physicist do to a certain extent when exploring our underlying
> reality.
I expect that some people figure that they can piece together the
puzzle based a little information and figure out all the details of
a few hundred man years of work by other people. And a few
probably could, but mostly people would post wrong guesses.
And most people would be handicapped from the beginning because
they would be starting with many assumptions based on the false
guesses that other people offered in the past that they accept as
their starting point for logic.
> Things will fall in place eventually. If you feel you understand what
> you claim others don't then by all means, explain what you understand.
I do feel that I understand more about the history of the development
either
my chip or the seaForth chip and can list the tens of thousands of
hours
of time I have invested working with Chuck on the project. Evolving
the
development tools, using them to design chips, evolving the chips to do
specific things, evolving the tools to develp applicating code for the
chips,
doing the target compilers, and simulators and chaning the architecture
and instruction set over and over improving this and that, and training
many of the other people who have put in the hundreds of man years of
work, writing the ROM BIOS and the Forthlets and working on the
software
development and cad tools does make me 'claim' that I know more about
it that the average person on usenet.
Of course this being usenet, there will always be people who will
tell you that they know more than I or Chuck does about any of
this stuff. And since they are not really doing it they have more time
to post alternate or incorrectly speculative versions.
And it being usenet some people will argue that they would rather read
guesses or write guesses than to allow the author of something to
answer
a question about it.
> Things will naturally fall in place when the pieces come together.
> Bashing others in the head only telling them they are wrong won't bring
> anything to the conversation.
If only. ;-)
Jeff Fox
> Hey, Jeff, with all respect--lighten up. You pulled the PR lever, and
> now you have publicity, which includes discussion.
Well marketing pulled the PR level without a plan to provide answers
to the questions that the teasers generate. I was of the opinion that
there had to be a plan in place of when the answers could be made
public before we teased people into guessing.
I specifically warned that it would lead to people guessing wrong in
c.l.f and things spinning off as they have in the past.
There is a list of facts that one needs, context, to make sense
of exactly how it all works. Without that it looks like nonsense
described in some speculation.
I suppose it is a matter of degree. Is it is good that someone can
guess and get a few percent right? I suppose. Is it bad that they
are going to get most of it wrong? Well maybe. Is it bad if the
majority of information posted is mostly wrong guesses? Well
I doubt if many people will ever sort out wrong from right. On
the subjects of colorforth and Chuck's Forth chips most of the
information posted in c.l.f has been wrong, and I think most
people would fail a test designed to determine if they had
in the past been able to sort out the wrong guesses from the
facts.
> It is NOT an option to then try to sit on the discussion. I suggest
> you participate in some form.
Do you mean like being the VP of software development on the project
who is willing to either answer questions about it or to argue with
the people who would rather explain it wrong first by starting from
everyone's guesses.
> And consider the possibility that those of us staggering
> around in the dark might actually come up with something new and
> useful.
I would just like to help people get out of the dark. I am just trying
to enlighten people with the truth least they be staggering around
in the dark listening to people's wong guesses.
Cursing the darkness may not help, but praising the darkness
doesn't help either. I will offer to try to shed some light in the
darkness and will try to do so.
Elizabeth D Rather
> vandyswa wrote:
>> Hey, Jeff, with all respect--lighten up. You pulled the PR lever, and
>> now you have publicity, which includes discussion.
>
> Well marketing pulled the PR level without a plan to provide answers
> to the questions that the teasers generate. I was of the opinion that
> there had to be a plan in place of when the answers could be made
> public before we teased people into guessing.
>
> I specifically warned that it would lead to people guessing wrong in
> c.l.f and things spinning off as they have in the past.
>
> There is a list of facts that one needs, context, to make sense
> of exactly how it all works. Without that it looks like nonsense
> described in some speculation.
It is in the nature of people to speculate about things they're
interested in, particularly when presented with a tantalizing amt of
information. I have some friends who spend hours spinning theories
about what's going on in 'Lost'. The producers of 'Lost' absolutely
love it, because it means their appetites are whetted for whatever dribs
and drabs of info the next show reveals.
If you don't want people to speculate without adequate basis, provide
the necessary info. If your marketing folks are enjoying teasing people
by only releasing hints, then try to take the generated interest as a
positive sign of interest in your product. Demanding that people stop
speculating is fruitless -- it's equivalent to demanding that they stop
acting like normal humans. And it makes you seem unnecessarily grumpy.
Either get the info released or let the rumor mill take its course.
We're really all pulling for your success, and looking forward to your
technology becoming a reality.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Jean-François Michaud
Jeff Fox wrote:
> Jean-François Michaud wrote:
> > I think people on this forum are old enough to make the distinction
> > between what is speculation and what isn't. If people are having fun
> > trying to figure out how things work, why not simply let them have
> > their fun? Things will settle down through discussion. Eventually, the
> > real deal will surface and the speculations will end. No big deal.
>
> >From what I recall from the past what most people remember are
> usually the wrong speculation. I base my opinion on this group in the
> past. You have more confidence in them than I.
>
> > It's never as bad as you make it to be.
>
> That's a rather blanket statement. I maintain that it is bad for
> everyone when falsehoods replace facts. You may choose to
> argue that errors are never as bad as I make them out to be.
> But by using the word 'never' your statement is easily disproved
> by my giving one case where it as bad as I say it is.
>
> It is just your opinion anyway as to 'how' bad ignorance and
> errors are. I think 'how' bad the errors are all depends on context.
> The error might involve millions or billions or dollars, or lives.
> In that case I would say it was a pretty serious error.
Not "never" in a generic sense, but in a specific sense for this
particular case.
> > If everybody followed your
> > logic, everything would come to a complete stop.
>
> Yes. That is my logic. The universe must come to a complete stop
> or none of my logic makes any sense. That's even sillier than saying
> that no amount of money or number of lives is important.
If everybody stopped speculating then yes, most of human advances would
fall dead in their tracks. It is human nature to speculate. Being so
pedantic about it doesn't help your cause.
> > It's not that puzzling. Everybody likes to understand. Speculating and
> > then testing one's speculations is a way to advance without direct
> > knowledge of what is truely going on. It is actually the ONLY way to
> > advance under certain circumstances (akin to reverse engineering). This
> > is what physicist do to a certain extent when exploring our underlying
> > reality.
>
> I expect that some people figure that they can piece together the
> puzzle based a little information and figure out all the details of
> a few hundred man years of work by other people. And a few
> probably could, but mostly people would post wrong guesses.
>
> And most people would be handicapped from the beginning because
> they would be starting with many assumptions based on the false
> guesses that other people offered in the past that they accept as
> their starting point for logic.
Look, I understand you invested alot of your time in this project, but
acting the way you do doesn't help your cause. It is actually casting a
shadow over your work. My suggestion is to simply lighten up a bit.
Things are going great. This is a great advance in microprocessor
technology; enjoy it, and most importantly, let others enjoy it in
their own way.
> > Things will fall in place eventually. If you feel you understand what
> > you claim others don't then by all means, explain what you understand.
>
> I do feel that I understand more about the history of the development
> either
> my chip or the seaForth chip and can list the tens of thousands of
> hours
> of time I have invested working with Chuck on the project. Evolving
> the
> development tools, using them to design chips, evolving the chips to do
> specific things, evolving the tools to develp applicating code for the
> chips,
> doing the target compilers, and simulators and chaning the architecture
> and instruction set over and over improving this and that, and training
> many of the other people who have put in the hundreds of man years of
> work, writing the ROM BIOS and the Forthlets and working on the
> software
> development and cad tools does make me 'claim' that I know more about
> it that the average person on usenet.
>
> Of course this being usenet, there will always be people who will
> tell you that they know more than I or Chuck does about any of
> this stuff. And since they are not really doing it they have more time
> to post alternate or incorrectly speculative versions.
Let them be then; sensible people will see them for what they are and
will avoid them. Going about acting as the speculation police will not
stop this. The only result you will obtain from such policing services
is general annoyance and shadow casting over your own credit and work.
> And it being usenet some people will argue that they would rather read
> guesses or write guesses than to allow the author of something to
> answer
> a question about it.
>
> > Things will naturally fall in place when the pieces come together.
> > Bashing others in the head only telling them they are wrong won't bring
> > anything to the conversation.
>
> If only. ;-)
In a general sense, things always seem to fall in place. It is an
excruciatingly long process in most cases but it never seems to fail.
Regards
Jean-Francois Michaud
Jeff Fox
> Ok. My bad. I should have said "there's an instruction with the
> same name in the F21". The changes make sense.
It is mostly like F21. So people who learned the MISC instruction
set fifteen years ago understand the way Forth primtives interact
in real programs. And there are people who understand that,
but I know that there are also a lot of people in c.l.f who do
Forth, and want to do Forth, in almost the opposite way. And
I know that they are likely to make a lot of wrong assumptions
and not be able to understand what has happened with this
simply Forth standard that predates ANS.
Take when we were doing i21 at iTV, we did a couple of
dozen prototype chips with different features. It was very
difficult to answer people's questions when the questions
were formed as if all two dozen of them were exactly the
same.
Do you give the answer for A or B? Or do you give the
answer for C,D,E,F,G,H,I,J,K,L,M,N,O,S,T, and V? Do
you go into the detail of how the .... circuit was changed
on each revision?
I could decribe how every opcode and every feature changed
from one version to the next. But when someone says,
'they all do .... and ...' and is just completely wrong about
it it can be very hard to explain exactly how they are wrong.
There are dozen of chips from Intel, and hundreds of features
relating to each chip. We announced that we had prototypes
and would offer different families of chips. When someone
needs to know details of specific chip they look it up in a spec.
But in usenet groups you are likely to see a lot of false 'all Intel
chips have or do such and such" statements. And you are likely
to see people ask questions that don't have a simple answer.
> > and a 18x18 version produces a 36-bit of T*S in T and A
> >
> > and we did one that did 18 steps
>
> Just to clarify, the 18x18 version does it in one step and
> the other version is for cores without a one step multiply
> instruction?
No. I described two variations of a +* step opcode and a
second opcode. More later.
> Well I was suprised to see an article (and now two) that showed the
> c18 instruction set before prior to the instruction set being posted
> at the IntellaSys website.
Also picture how marking asks for a desciption of the instruction
set and engineering says, for the chip we made last year and
are testing now, for the chip that is in fab today, or the one
we sent to fab next week? Marketing picks one. Six months
later a magazine asks for info to publish, so they get the six
month old set. Then it takes the magazine six months to edit
and publish and distribute.
So when most people see those marketing aritlces they know
that it isn't the same as the product that will go out the door.
And they don't expect to find the accurate bit level information
in the marketing releases. Of course it will be more accurate
of what is going on today than documents like Chuck's
presentation on early c18 at EuroForth so many years ago.
People will either get the real info or they go somewhere where
people will guess. And that's fine. And occasionally someone
who isn't guessing will offer more modern and accurate info
and this can can upset the people who were guessing wrong
and may fight and argue for years that their guesses were in
fact all correct.
> I actually saw this article "electronic
> design" article on the #c4th IRC channel even before you posted
> it on the ColorForth mailing list. I guess (sorry) what I'm getting
> at is I don't how you guys can expect to put this kind of information
> out without expecting some kind of comments.
We expect some kind of comments.
Dave Guzeman launched the 4004 and 8080. He did a pretty good
job of it. They did ok. He is not an idiot who puts out web pages
and doesn't expect comments.
And he was warned that c.l.f would have people who would
provide an alternative source of information to anything that he
puts out, and that it being usene that some people would post
stuff that no one would understand.
He knew there were teasers designed to get people wondering
and thinking and that essential information was not included that
makes it all make sense. A staged release of information was
planned. I warned him that c.l.f would be impatient and look to
people who have been happy to speculate in the past and
argue endlessly about their guesses.
> Someone on the
> #c4th IRC channel made a similair "guess" to the possible
> "Forthlet" connection to the "p" instructions that hubili made
Yeah. I saw it. The first speculative comments about Forthlets
in c.l.f and #c4th were mostly wrong. It made me bite my
tongue to see people offering more false assumptions as
starting points for others.
> (although without going so far as to try and write a code
> snippet). I've tried to keep my comments to what (seems)
> obvious and away from blanket speculation. But nothing
> that I've seen has been malicious. Nobody making rude
> comments about "bogomips" and such. (Yes, that might
> come later).
Well I wouldn't want to look too closely at some of what
has been said so far, or argue about what might still
be coming.
> Anyway, I'm guessing (oops, sorry) that the
> average person that reads the articles from Electronic Design
> and DSP DesignLine will go to the IntellaSys website for
> answers rather than comp.lang.forth.
Yes sure as they should. And until more information is posted
people can read and write what other people think in places
like c.l.f and #c4th. They can ask questions or argue about the
guesses about which guesses might be right or wrong instead.
Discussions are fine. But we have said that there are some
questions that we can't answer right now. If people insist
on answering them for us, and giving people wrong answers
despite the fact that we say the right answers are coming
I will just say, c.l.f...
I try to improve the situation, but I have always told people
that the first place to go to get wrong information about
Chuck's work and last place to go to get good information
about it is c.l.f. There are just too many people there who
are too emotional about the fact that Charles Moore calls
Forth does not look like what they do. They see Chuck
going the other way in passing.
And they honestly give you an honest description (most of
them) of what Chuck's backside looked like in their rear
view mirror when he was going in the opposite direction on
the same road as them. And they are happy to guess about
where he was headed in what looked like a backwards direction
to them.
IBut remember when they tell you that they saw
him turn right and drive North that they probably actually
saw him turn left and dirve South, they just were looking
in Kierkergaard's mirror. They may tell you that he was
probably thinking that "no one ever needs to drive South"
when they saw him turn.
Stan Katz
"Jeff Fox" <f...@ultratechnology.com> wrote in message
news:1150899192.5...@g10g2000cwb.googlegroups.com...
> hubuli wrote:
>> Thanks for the comments - here are my latest speculations - SEAforth
>> behaves like a puzzle these days ;-).
>
> Please don't post more speculations. You asked, but instead of waiting
> for a response from anyone who knew the answer you accepted guesses
> then post your latest speculations to answer you own questions?
>
I understand your frustration at people making "incorrect guesses" at what
SEAforth/Intelasys does/means but the only real solution is to provide the
missing information and not to simply complain when people try to make
sense of incomplete or missing information.
If the information was provided then there would be no need for anyone to
speculate, and if the information is not yet available (in a suitable form)
then Intelasys needs to find a way to make it available (like getting
someone
to provide the correct information - as I see you have done on some threads,
and which I do appreciate).
However - complaining that people are speculating when they have no
viable alternative, or schedule as to when the information will be
available, is
counterproductive and irritating - I read your responses to the first few
threads
and was so irritated by you declaring that the speculation was wrong (which
I am
prepared to accept, given your level of access) without actually giving the
correct
information that I almost deleted some other posts from you that actually
provided some of that information.
The solution to misinformation is to provide the correct information.
Stan
Keith
A good start would be to fix the information that's on the Intellasys
website. For example take a close look at the two pdf's:
http://www.intellasys.net/products/24c18/SEAforth-24A-3.pdf
http://www.intellasys.net/products/24c18/SEAforth-24B-3.pdf
In one the B register is connected to the data stack, and in the other
it's connected to teh return stack. Is this correct? There are a lot of
typographical errors in those documents and in the white papers too.
When I see something like "Indivisual" I wonder if it's missing a TM or
if it's a typo.
This is something that you _can_ control, and make much better in short
order. I think that everyone here hopes for your success, because at
the very least it makes things a little more interesting for us.
Regards,
Keith
John Passaniti
> Well marketing pulled the PR level without a plan to provide answers
> to the questions that the teasers generate. I was of the opinion that
> there had to be a plan in place of when the answers could be made
> public before we teased people into guessing.
I really don't understand the problem.
When chip manufacturers like Intel, AMD, Freescale, ARM, Zilog, and so
on are about to release a new chip, there is usually some buzz and
speculation. People cull through press releases making intelligent
guesses about the details. Sometimes they get it right. Sometimes,
they are completely wrong. But *nobody* confuses such speculation as
being authoritative.
I work for a company that would actually be in a position to specify the
SEAforth chips in the projects we take on. And in fact, I've been
reading everything I can to gain clues about the architecture,
programming environment, and other details to know the kinds of
applications we would specify the SEAforth chips in.
So when I read speculation in comp.lang.forth about the chips, I
certainly consider it, but I don't take anything I read here as being
authoritative. Some of it is interesting, but none of it comes direct
from IntellaSys, so I don't consider it in my assessment of your
company's chips. And I don't think that any sane, rational person would
take the word of someone who isn't connected with the company as being
authoritative. That would just be stupid.
So I don't see the big deal in people speculating. Even if they are
100% wrong, everyone with a functioning brain understands it's just
that-- speculation.
Frankly, all of these issues simply go away the moment IntellaSys
publishes real documentation for the chips. Once that happens, there is
no need to speculate-- you just download the PDF file and find the
answer there.
Stop bitching about people speculating and start working at IntellaSys
to start cranking out the kind of documentation that will answer
people's questions and ultimately, sell your chips. You've all teased
us all with juicy bits and pieces of the picture, now fill in the
blanks. If your company doesn't, then don't be surprised when people
try to fill in the blanks themselves.
Put another way, the fact that people are speculating is a statement
that IntellaSys has work to do. Do it.
Jeff Fox
> Can anybody help me understand the proper way to make use of the "!p+"
> opcode?
Let me give you a little background. Of course I am told that most
people have functioning brains so they already know all this because
they were always able to sort out the opinions from the facts in the
past in c.l.f on this subject.
People who followed F21 learned about !p+ ten years ago.
It has changed and evolved, but there is background and context
so forgive me for putting in a few facts for review since you all
already
know all this. Going back about fifteen years...
F21 got some new things including interrupts. It has three sources of
interrupts for the CPU, three of the I/O coprocessors could interrupt
the
CPU. Because of this I insisted that the stacks be expanded so that
I could allocate some space for each type of interrupt and leave the
rest for other tasks and have minimal interrupt processing overhead.
And that worked very nicely, but I also wanted to be able to do a full
context switch from interrupt driven code. And saving and restoring
registers to memory was a bit ugly on F21 despite having two memory
pointers, three if you count the PC. This was because registers and
stacks were 21 bits wide but memory was only 20 bits wide. So
I had to use two cells for each word, and writing it out and reading
it back were a little different.
And I got the best routine that I could write. But I concluded that
I just had to give up three registers and trash them when I did
this context switch. One cell on the return stack is lost by
the interrupt itself, then to save registers to memory you have to
point a register to memory. To do that you have to load an immediate
into T. That means that you overwrite a stack cell. And if you are
not going to trash the memory pointer you are going to have to
save a copy somewhere. So that takes out another stack position.
Thus the minimum complete context switch would trash three registers
and the machine has a minimal number of registers so every one counts.
And I thought about it a lot. At some point it occured to me that
there
was an unused instruction slot on F21 that was symetrical to the
literal
load opcode, we called it # or N at the time, known as @p+ today. I
reasoned that this slot contained the @p+ opcode but with a store
instead of a fetch. I reasoned that the CPU might decode it and execute
it and do the symetical operation to the Forth literal load. And I
reasoned
that if the hardware did decode it and excute it that I could use it on
the context switch.
I could avoid trashing two of those three registers that I was
trashing.
If I used the program counter as the pointer then I didn't have to load
a pointer onto the stack and save a memory pointer that I was already
using. And yes, it worked and it let me go from trashing three
registers
to trashing one.
So I tried it and then went to Chuck and reported that I had figured
out
how to do something on his design that he hadn't thought of. I had
discovered a new instruction and done something useful with it.
He was impressed. It is easy to think that you have though of
something about his design that he hasn't thought of but almost
always when you talk to him he will tell you that he had considered
your idea years ago and give you its long history. So in those
rare cases when you do come up with a new idea that he hasn't
discovered yet you remember it.
I wrote stuff up about it for those staying up with F21 and refered
to it as a discovered opcode that was originally undocumented.
I always suspect that few people in c.l.f remember that sort of
detail about the MISC instruction set. But people here get
angry with me for making that assumption. I think things like
that got lost in all the noise about people's speculation,
theories, guesses and spin in the past. But people get
angry with me when I say I think that. And discussions of F21
rarely got beyond how DUP wasn't really DUP because of standard Forth
or ...
So I hate to insult everyone since you all remembered all this
about !p+ from a decade ago since you were always able to
sort out the authoritative facts in the past from the specutive and
missinformed arguments that people made.
Now there have been many developments in the instruction
set of c18 in the last five years. I will give all the details of
!p+ later, but sometime last year someone said,
"You know given ( fact 1 not yet public about the design )
and given ( fact 2 not yet public about the design )
and given the latest addition of ( fact 3 not yet public about the
design )
we could use that opcode in this new way to make this important code
and make it three times smaller and faster."
And I said, "Great idea!" (I love working with people who can better
my code like that.)
I said it will be fun explaining that to people when we can make it
public.
I said, great, that makes that opcode about ten times as useful
as it was just using it for that other thing. And that was ten time
more
useful than the first thing we considered doing with it.
So when people look at the first thing or the second thing and see
1% or 10% of the value of the thing they are really in the dark. And
they might make the mistake of jumping to certain conclusions
about the relative value of the opcodes like people have done in
this thread about how useful they are or how they are used. And
some other people will likely mistake their mistaken speculation for
facts and conclude that they argee with them about the limited value
of the instruction set based on their extensive evaluation of it, and
as
we have seen that sort of nonsense becomes the popular opinion.
If there isn't too much spin about people saying that they will
not tolerate my answering to these questions in c.l.f for
various reasons I will give you the rest of the answer to your
question about !p+ soon. But I have real work to do and don't have
time to argue with all the people in c.l.f who have nothing better
to do than talk about me.
Jeff Fox
> This is something that you _can_ control, and make much better in short
> order.
I am not sure to whom that remark is directed. Perhaps you refers to
IntellaSys.
rickman
I see that Jeff is posting much, much more in response to the fact that
people are trying to answer questions than he is answering the
questions himself. My suggestion is to do like Kennedy did during the
Cuban missle crisis. In response to a message about the missles, the
US received two messages from Russia. The first was conciliatory and
the later, second message was much more ominous and threatening. They
ignored the second and replied to the first.
When you get something you like from someone, respond to that and ask
for more information. But it is often not useful to tell someone that
you don't like some of what is being said. So just ignore that part.
This will greatly reduce the superflous bandwidth in this newsgroup.
John Passaniti
> Let me give you a little background. Of course I am told that most
> people have functioning brains so they already know all this because
> they were always able to sort out the opinions from the facts in the
> past in c.l.f on this subject.
You really have a problem with this, and I wish I understood why.
Yes Jeff, *everyone* knows the difference, and it takes no effort on
anyone's part. We simply consider the source. If the source doesn't
have a direct connection to the information, then it's speculation.
Show us the evidence of *anyone* who has acted on speculation in
comp.lang.forth. Show us the evidence of *one* sale of past or present
chips that was lost because someone read a comment in comp.lang.forth
that they confused for fact.
I'll save you time-- no such evidence exists.
Jeff Fox
> it's connected to teh return stack. Is this correct?
I don't know. I haven't heard about the 'teh return stack'
I haven't seen that before, very confusing.
> There are a lot of
> typographical errors in those documents and in the white papers too.
> When I see something like "Indivisual" I wonder if it's missing a TM or
> if it's a typo.
I have a theory that a lot of people have very little focus and are
so easily distracted that if you put up a sign that read "Danger, don't
stand
in front of this sine trying to read it or a truck will run over you
and kill you!"
that many people would be frozen in their tracks by the typo and would
stand there like a deer in the headlights until the truck killed them.
They
would be incapable of reading the message that their life was in
danger.
> This is something that you _can_ control, and make much better in short
> order. I think that everyone here hopes for your success, because at
> the very least it makes things a little more interesting for us.
Not my job. Perhaps we could find someone who is capable of
typing 'the' in his complaints about other people's typos making
their messages incomprehensible.
You probably have had more success at launching new products
that people argued were not actually computers like 4004 and 8080
and a real marketing expert who doesn't do typos. I am sure that
you have launched more sucessful chips than those before and
are the real expert on the subject.
I had a fun conversation the other day about how history repeats
itself.
In 1971 I was constantly told that microprocessors were not really
computers because they didn't look mainframes and didn't run
the mainframe software. It was hard, these experts insisted that
you didn't understand computing at all if you didn't think computing
was mainframes.
Now I am constantly told that history had blurred the line between
mainframes and microprocessors because desktop microprocessors
were expanded to run the mainframe software! So Guzeman has
the same problem again in that a different set of people argue that
it isn't a computer at all if it doesn't look like a mainframe.
Long ago they were Cobol and Fortran programmers, now they
tend to be C and Linux or Windows programmers who insist that
real computer hardware and software is designed like the mainframes
of old.
People who start with assumptions that computing is C and computers
are mainframes, that the bottleneck is the single Central processor
and that the only relief from this bottleneck is deep pipelines, layers
of caches, interrupt circuits, event trapping, memory managment,
and lots of general purpose registers and requiring large standardized
one-size-fits-all Operating Systems have as hard a time understanding
tiny multiprocessor chips without the need for complicated deep
pipelines,
without the need for layers of caches, without the need for large
floating
point circuits, without the need for interrupts or event trapping,
without
the need for memory managment or lots of general purpose registers
and will argue with you that the very idea of simple cooperative
hardware
for simple cooperative software is a design error that requires adding
in all the mainframe hardware and software to correct the error.
But in fact most of the people who think mainframes define computing
can see that what we are doing is substantially different. A small
group who define Forth as requiring C hardware and software are the
ones who simply will never accept that Forth hardware and software
can be substantially different than C hardware and software. They
are the ones who will object to anyone trying to explain how being
different than C doesn't mean broken.
When people run out of logical arguments they will start calling
names, or focus on things like finding a typo somewhere like it
is some great thing that they have done. ;-)
John Passaniti
> But in fact most of the people who think mainframes define computing
> can see that what we are doing is substantially different.
The people who believe that aren't doing embedded systems.
Stop creating straw men.
Keith
I obviously don't take newsgroup postings as seriously as I believe
Intellasys should take their published documentation. If you're a team
player with a vested interest in the success of Intellasys, then I
think that you would want Intellasys to produce quality documentation.
If you don't make high-quality documentation available to your
customers, then they will require more support.
I can't believe that you wouldn't care about this. At my company I
wasn't satisfied with the quality of our specifications, and ended up
writing hundreds of pages of documentation as a result even though it
wasn't my job.
Colin MacIntyre
hell (noun) - the place where management is recruited from marketing and
engineers handle PR.
--
Posted via a free Usenet account from http://www.teranews.com
Bernd Paysan
>> Just to clarify, the 18x18 version does it in one step and
>> the other version is for cores without a one step multiply
>> instruction?
>
> No. I described two variations of a +* step opcode and a
> second opcode. More later.
The +* of SEAforth looks remarkable like the one I put into b16. After all,
b16 was done a few months after Chuck Moore gave a presentation on c18 and
x25 on EuroForth - so b16 and c18 did inspire each other (though there's
definitely more inspiration from c18/f21 in b16 than the other way
round ;-).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bernd Paysan
> I just wish people would prefer facts to repeating false guesses.
Oh, shut up and just give us the facts - we love to see them, and will
continue to speculate until they are provided ;-). It can't take sooo long
to provide a complete documentation of SEAforth - after all, it's a MISC.
Haven't you guys written up things while you did the development?
rickman
It looks like there are at least a couple of posters who feel they just
have to continue this pi**ing contest. I guess we could change the
name of the group to comp.lang.forth.JeffFox.JohnPassiniti.bicker. I
seriously doubt that anything I say will change the way these two go at
each other. Why can't they do it with private email?
Dennis Ruffer
> It looks like there are at least a couple of posters who feel they just
> have to continue this pi**ing contest. I guess we could change the
> name of the group to comp.lang.forth.JeffFox.JohnPassiniti.bicker. I
> seriously doubt that anything I say will change the way these two go at
> each other. Why can't they do it with private email?
I keep hoping that this would quiet down and we'd get to see something
useful, but then another day brings more. I'm beginning to wonder why
IntellaSys is letting Jeff be their representative here. No offense
intended Jeff, but your attitude is likely to make your worst fears
come true. There is no question that you know the technical stuff, but
you really need to find another outlet for your frustrations than
beating up the people here. Sure there are going to be detractors, and
if IntellaSys doesn't play their cards right, misinformation will most
certainly persist. However, that will not be the fault of those who
are simply trying to answer questions. The blame will be on
IntellaSys, for not providing timely corrections.
For example, the mistake between the documentation for the 24A and 24B
chips, reported here by Keith on the 20th, is still on the IntellaSys
web site. Rather than complaining about Keith's spelling, you might
want to give him the benefit of the doubt and check out the feedback
he's giving you.
I suspect you all are real tired, and you've all been busting your
butts to get this right, but perhaps you need to step back, and let
someone else be the mouth piece here. I've had a little experience at
this type of communication, if you remember GEnie, and I happen to be
available at the moment. I don't know much about the chips yet, and I
have a couple of problems with ColorForth (a Mac and color blindness),
but if you don't mind a shameless plug for a job, I don't mind taking
the shot at it. ;)
DaR
John Passaniti
> [...] Sure there are going to be detractors, and if IntellaSys
> doesn't play their cards right, misinformation will most certainly
Actually, unless I've missed the messages, I haven't seen any detractors
against IntellaSys or their chips. On the contrary, if you tried to
summarize the kind of responses people here have had, you would use
words like positive, supportive, curious, and hopeful.
And I *still* don't understand the issue of "misinformation." There is
no misinformation. There is at worst uninformed speculation, and in the
last round, we actually got confirmation that most of the speculation
was actually correct.
But even if the speculation here was 100% wrong, what does it matter?
Nobody who is rational and sane is going to use newsgroup posts to
evaluate the worth of IntellaSys's chips. Nobody who might be
considering the chips for use in a product would ever use comments in a
newsgroup from people not even connected to the company to inform a
decision.
Jeff Fox
> Oh, shut up and just give us the facts -
I think that should read, shut up OR give us the facts.
I realize that you want me to shut up because you
don't want people to see more facts that will prove
what you have said in the past was wrong again.
You have a history of arguing against all of this stuff,
except a small confused subset that you spent a little
time copying, so I realize that you probably don't like
the idea that more information is comming that will
prove you wrong again.
I would ask you to shut up and let someone give
people the real facts. But I realize that this is at
cross purposes with making trouble.
> "If you want it done right, you have to do it yourself"
If you want to do it wrong make an embarrrasingly bad copy
of someone else's hardware or software and think you did it right.
Jeff Fox
> hell (noun) - the place where management is recruited from marketing and
> engineers handle PR.
Indeed that sound like c.l.f. It is why managemnt does managment,
marketing does marketing, and engineers do engineering.
In c.l.f some people are experts on everything and engineers provide
marketing sytle information most of the time. Occasionally when
their is a new startup they have marketing information, like everyone
else, before all the engineerring information is released. But in a
place like c.l.f this is just a game for people who want to offer
alternate nonsense no-method-to-the-madness total madness
explanations if they have an axe to grind with anyone in that
startup. It is part of what makes c.l.f such a nasty place.
There are occasional windows where in the absence of real facts
detractors can go nuts with insults and damaging false information.
Hell is where false engineering information is offered by haters
instead
of real information. Anyone trying to offer real information will be
told
to shut up. Is that hell or c.l.f ?
Jeff Fox
> The +* of SEAforth looks remarkable like the one I put into b16.
I am sure it does. Many people's Forth look remarkably like what
Chuck named Forth to them. Many people think they have got it
because they made a embarrasing copy of part of something.
I have seen how if someone does 99% of the work that someone
else can come along and do 1% of the work to make an embarrasing
bad copy, and they will often think that this means that this minimal
exposure gives them an in depth understanding of the issues.
> After all,
> b16 was done a few months after Chuck Moore gave a presentation on c18 and
> x25 on EuroForth -
Yeah no kidding. It is the kind of thing that some people do in a day
or two.
And they learn something from it in a day or two just like Chuck has by
solving the real problems on a daily basis for twenty years. But sure
I know you make one of the embarrasing knock-offs and have confused
people every since with your tiny subset of undertanding of what Mr.
Moore
has been doing all these years.
> so b16 and c18 did inspire each other
I didn't realize that your work is what inspired Mr. Moore. ;-)
Yikes!
Did he also learn Forth from you? You wouldn't be the first person
in c.l.f to claim that.
I suppose that I claimed that I 'inspired' Chuck to do F21 since I had
the idea, paid for, directed the work, and made many of the design
decsions that evolved the instruction set that you copied.
I suppose that I claim that I was the one who 'inspired' Chuck to
do parallel processing and that it took some effort to convince him
of the value of this so many years ago.
But I hadn't heard that you think that b16 inspired c18! That's funny!
> (though there's
> definitely more inspiration from c18/f21 in b16 than the other way
> round ;-).
;-)
That is funny.
Just for reference. Chuck said he wanted to move forward from
only getting 80 MIPS in programmable logic in the 80s. He said
that moving forward meant going to custom VLSI so the the
hardware could be ten times faster and a hundred times cheap
and lower power. Mr. Moore has said that moving forward meant
making the software easier, simpler and faster and making
the hardware and software match more closely.
Many people have suggested that he should abandon this and
go backward. They have shown that it is possible to make the
software harder, more complicated, and slower. They have shown
that it is possible to go to faster programmable logic that should
get many more mips than in the 80s even if it loses the big
gains of lower power and lower cost. And they have shown
that it is also possible to do such a bad job the they only get
a fraction of the performance from the 80s instead.
I find it hard to see that making something orders of magnitudes
slower and orders of magnitudes more expensive and more
power hungry is forward progress. I think it is funny that some
people do think this is forward progress.
But it is really histerical to claim that is was 'inspirational'
to Mr. Moore and let to his current work! That has to be one
of the funniest things ever posted to c.l.f.
Anyone else want to claim that their work is what inspired Chuck
or that he was just copying them instead of the other way around?
It is going to be hard to top Bernd's claim about b16.
Jeff Fox
> I keep hoping that this would quiet down and we'd get to see something
> useful, but then another day brings more. I'm beginning to wonder why
> IntellaSys is letting Jeff be their representative here.
My hands have been tied in certain ways. And that has allowed some
of the haters occasional access to my back.
But they have not told me at work that I am not free to respond to
personal insults and attacks if I choose to do so.
People ask questions here. If I don't answer them I know people
will guess wrong and things will spin off like they have in the past.
And I know that there is a list of people, who greatly outnumber
me, who want to spin it off into personal attacks and stories
about how they really invented Forth or Forth chips etc.
> No offense
> intended Jeff, but your attitude is likely to make your worst fears
> come true.
I realize that when I ask people to not cause trouble that people
who want to cause trouble see an opportunity. And I do realize
that there is a list of people here who don't like me, don't
like Chuck and don't want accurate technical explanations here.
So I know what to expect.
> There is no question that you know the technical stuff, but
> you really need to find another outlet for your frustrations than
> beating up the people here.
I have never beaten up anyone here. You can't beat someone up
on usenet.
The worst you can do is show that they are wrong. And when
people are wrong I do that.
They can cry and say I beat them up by offering some truth,
but they should over it.
> Sure there are going to be detractors, and
> if IntellaSys doesn't play their cards right, misinformation will most
> certainly persist.
Yes, I haven't missed the threats.
> However, that will not be the fault of those who
> are simply trying to answer questions.
Sorry, I can't parse that. I am the fault?
If people think right answers are attacks on people giving
wrong answers that is too bad. Attack the messanger
unless the message is wrong?
> The blame will be on
> IntellaSys, for not providing timely corrections.
I will simply dismiss it as the blame going to the haters
who saw another opportunity to create confusion and
fight very hard to keep things confused and focused
on attacking the source of inforation and encouraging
the source of false information. Par for the course
in c.l.f
Honest information about colorforth or Forth chips
has never been tolerated here. I think it is mostly
just a case that the effort to exclude that stuff from
Forth, ie. the ANS Standard, failed to kill that stuff
completely. The fact that it didn't die is not
acceptable in c.l.f and they are still trying to kill it.
> For example, the mistake between the documentation for the 24A and 24B
> chips, reported here by Keith on the 20th, is still on the IntellaSys
> web site. Rather than complaining about Keith's spelling, you might
> want to give him the benefit of the doubt and check out the feedback
> he's giving you.
You know I am not 100 people. Some of you may think that I do
everything and all the other people do nothing. But that's not how
it works.
I am in engineering.
I am a Forth programmer. I have an interst in Forth and in other
people understanding Forth.
I read comp.lang.forth to learn more about what other people are
doing about Forth.
I like to see what they understand that I don't and what we are
doing that they don't understand.
When someone talks about their Pentium implemation I
learn something. I don't offer wrong guesses as the real facts.
When someone who didn't know anything about my chip or
my software said things about it was not true and did the
disservice to the group of leaving them confused and
unable to sort real facts from false statements by detractors
I have tried to educate people.
Occasional people who don't like their mistakes, or intentionall
efforts to decieve people, correct by easily provable fact they
feel that they have been beaten up. If only.
I do think that sometime the kindest of things you can do to
someone is give them a gentle bash on the head to get their
attention. It might save their life.
But on usenet you can't be that kind to people, and the
best you can do sometimes to get their attention is to
point out that they are wrong.
> have a couple of problems with ColorForth (a Mac and color blindness),
I always wonder why no one ever says
"I have a problem with MacForth!" (because I don't have a mac)
"I have a problem with SwiftForth!" (because I don't have a PC)
or
"I have a problem with Windows!" (because I am blind)
no one ever says that stuff.
No one ever says that they have a problem with MacForth
because a mac isn't for them. No one is intolerant of
MacForth.
So when people say they have 'a problem with colorforth'
it is just a matter of tolerance. For some reason some people
won't even tolerate discussions of colorforth in c.l.f and I
suspect it is just a matter of them being frightened because
it wasn't inspired by their standard and is different.
Jeff Fox
> It is in the nature of people to speculate about things they're
> interested in, particularly when presented with a tantalizing amt of
> information. I have some friends who spend hours spinning theories
> about what's going on in 'Lost'. The producers of 'Lost' absolutely
> love it, because it means their appetites are whetted for whatever dribs
> and drabs of info the next show reveals.
That sound a lot like c.l.f. People would rathter spend hours spinning
theories than anything else. And they don't want that disturbed by
facts.
If the facts prove their theories wrong they feel that someone
beat them up and spoiled their fun at spinning fabulous theories
and fiction.
> And it makes you seem unnecessarily grumpy.
The real problem dwarfs the problem that Dopey questions deserve
no answers or Grumpy answers and that that makes me Happy.
> Either get the info released or let the rumor mill take its course.
Is that a threat? More dopey questions about floating point
opcdoes or hardware needed for mainframe style software?
Jean-François Michaud
Jeff Fox wrote:
> Elizabeth D Rather wrote:
> > It is in the nature of people to speculate about things they're
> > interested in, particularly when presented with a tantalizing amt of
> > information. I have some friends who spend hours spinning theories
> > about what's going on in 'Lost'. The producers of 'Lost' absolutely
> > love it, because it means their appetites are whetted for whatever dribs
> > and drabs of info the next show reveals.
>
> That sound a lot like c.l.f. People would rathter spend hours spinning
> theories than anything else. And they don't want that disturbed by
> facts.
> If the facts prove their theories wrong they feel that someone
> beat them up and spoiled their fun at spinning fabulous theories
> and fiction.
Hahaha, you live on a cloud Jeff. You should calm down a bit. So you're
the only human being on the planet that puts facts in front of
speculations? Seems rational enough to me.
Regards
Jean-Francois Michaud
jmdra...@yahoo.com
Dennis Ruffer wrote:
> I suspect you all are real tired, and you've all been busting your
> butts to get this right, but perhaps you need to step back, and let
> someone else be the mouth piece here. I've had a little experience at
> this type of communication, if you remember GEnie, and I happen to be
> available at the moment. I don't know much about the chips yet, and I
> have a couple of problems with ColorForth (a Mac and color blindness),
> but if you don't mind a shameless plug for a job, I don't mind taking
> the shot at it. ;)
>
> DaR
Hello Dennis,
I've often seen people make the "colorblindness" argument. In fact
I might have once made it myself. Chuck has long pointed out that
font styles could be substituted for color. So far I've not seen
anyone
ask for such a thing. Howerd Oakford's colorforth source viewer has
a "colorblind" mode.
Anyway, I was curious as to how colorforth would look to someone
with colorblindness. I realize there are different levels of
colorblindness,
but in the most common level people can still perceive some color.
There is a website that simulates this. I tested it out for a large
sample of ColorForth source.
http://vischeck.homeip.net/uploads/115108544824767/
Even with this color reduction it's possible for me to distinguish
the requisit colors. "Red" defined words show up as dark brown.
"Green" compiled words show up as light brown. "Yellow"
immediate words are yellow. "Magenta" variables are dark
blue. "Cyan" compiled macros are light blue. "White" comments
are white. It probably wouldn't be too difficult to "tweak"
ColorForth to have different colors that constrasted better
for different people.
As for having a "Mac" There's "Wine" which would let you
run the Windows version of ColorForth. Also Mac's are
about to run QEMU which would let you run a version
of "native" ColorForth.
Of course this really has little to do with IntellaSys anyway.
The tools they've announced on their website run under
GForth (there's a Mac version of that) and SwiftForth
(Windows only, but again there's Wine). I'm hopeful
that there will be a release of a ColorForth version, but
so far nobody has said their definitely would be.
Regards,
John M. Drake
Dennis Ruffer
> Dennis Ruffer wrote:
>> I keep hoping that this would quiet down and we'd get to see something
>> useful, but then another day brings more. I'm beginning to wonder why
>> IntellaSys is letting Jeff be their representative here.
>
> My hands have been tied in certain ways. And that has allowed some
> of the haters occasional access to my back.
>
> But they have not told me at work that I am not free to respond to
> personal insults and attacks if I choose to do so.
>
> People ask questions here. If I don't answer them I know people
> will guess wrong and things will spin off like they have in the past.
> And I know that there is a list of people, who greatly outnumber
> me, who want to spin it off into personal attacks and stories
> about how they really invented Forth or Forth chips etc.
You were almost sounding better today Jeff. I really wish you could
see how your past is affecting your presentation. Most of us have
witnessed the fist fights, but why do you feel the need to give them
power over what you are doing today?
>
>> No offense
>> intended Jeff, but your attitude is likely to make your worst fears
>> come true.
>
> I realize that when I ask people to not cause trouble that people
> who want to cause trouble see an opportunity. And I do realize
> that there is a list of people here who don't like me, don't
> like Chuck and don't want accurate technical explanations here.
> So I know what to expect.
>
>> There is no question that you know the technical stuff, but
>> you really need to find another outlet for your frustrations than
>> beating up the people here.
>
> I have never beaten up anyone here. You can't beat someone up
> on usenet.
>
> The worst you can do is show that they are wrong. And when
> people are wrong I do that.
>
> They can cry and say I beat them up by offering some truth,
> but they should over it.
I'm not crying, but your tone makes me feel like I'm being beat up. I
don't know if it is possible for you to understand what I'm trying to
say here, but if nothing else, I hope you can see that there is another
way.
>
>> Sure there are going to be detractors, and
>> if IntellaSys doesn't play their cards right, misinformation will most
>> certainly persist.
>
> Yes, I haven't missed the threats.
>
>> However, that will not be the fault of those who
>> are simply trying to answer questions.
>
> Sorry, I can't parse that. I am the fault?
>
> If people think right answers are attacks on people giving
> wrong answers that is too bad. Attack the messanger
> unless the message is wrong?
Leave the messenger alone and focus on the message!
>
>> The blame will be on
>> IntellaSys, for not providing timely corrections.
>
> I will simply dismiss it as the blame going to the haters
> who saw another opportunity to create confusion and
> fight very hard to keep things confused and focused
> on attacking the source of inforation and encouraging
> the source of false information. Par for the course
> in c.l.f
Sorry, but it doesn't really matter how you feel. Your future depends
on how the market feels about your message and only you can control
your presentation.
>
> Honest information about colorforth or Forth chips
> has never been tolerated here. I think it is mostly
> just a case that the effort to exclude that stuff from
> Forth, ie. the ANS Standard, failed to kill that stuff
> completely. The fact that it didn't die is not
> acceptable in c.l.f and they are still trying to kill it.
Spilled milk. As you said, get over it.
There are many ways to accomplish that, and negative reinforcement is
rarely the most successful option.
>
>> have a couple of problems with ColorForth (a Mac and color blindness),
>
> I always wonder why no one ever says
> "I have a problem with MacForth!" (because I don't have a mac)
> "I have a problem with SwiftForth!" (because I don't have a PC)
> or
> "I have a problem with Windows!" (because I am blind)
> no one ever says that stuff.
>
> No one ever says that they have a problem with MacForth
> because a mac isn't for them. No one is intolerant of
> MacForth.
>
> So when people say they have 'a problem with colorforth'
> it is just a matter of tolerance. For some reason some people
> won't even tolerate discussions of colorforth in c.l.f and I
> suspect it is just a matter of them being frightened because
> it wasn't inspired by their standard and is different.
I will explain the color issue in response to John Drake's message, but
I have the same problem with SwiftForth that I have with ColorForth,
and I helped write some of SwiftForth. I still consider it to be one
of the best, but I don't use it. If I launch VPC or any emulation
environment, I reduce the efficiency of everything I'm doing. Clearly
not a good use of my time, when I can pop up gforth in a terminal
window with almost no impact on anything else I am doing. I'm really
looking forward to seeing the tools you have promised.
DaR
Dennis Ruffer
> Dennis Ruffer wrote:
>
>> I suspect you all are real tired, and you've all been busting your
>> butts to get this right, but perhaps you need to step back, and let
>> someone else be the mouth piece here. I've had a little experience at
>> this type of communication, if you remember GEnie, and I happen to be
>> available at the moment. I don't know much about the chips yet, and I
>> have a couple of problems with ColorForth (a Mac and color blindness),
>> but if you don't mind a shameless plug for a job, I don't mind taking
>> the shot at it. ;)
>>
>> DaR
>
> Hello Dennis,
>
> I've often seen people make the "colorblindness" argument. In fact
> I might have once made it myself. Chuck has long pointed out that
> font styles could be substituted for color. So far I've not seen
> anyone
> ask for such a thing. Howerd Oakford's colorforth source viewer has
> a "colorblind" mode.
I may simply be reluctance on my part, but I'm having a hard time with
the issue of transporting source code. If I change the colors, or use
fonts rather than colors, doesn't that become an incompatibility issue?
I can't see how to avoid having to publish a translation matrix with
every piece of source code. Perhaps that is why no one is asking. As
long as everyone uses the same matrix, no translation is required.
>
> Anyway, I was curious as to how colorforth would look to someone
> with colorblindness. I realize there are different levels of
> colorblindness,
> but in the most common level people can still perceive some color.
> There is a website that simulates this. I tested it out for a large
> sample of ColorForth source.
>
> http://vischeck.homeip.net/uploads/115108544824767/
>
> Even with this color reduction it's possible for me to distinguish
> the requisit colors. "Red" defined words show up as dark brown.
> "Green" compiled words show up as light brown. "Yellow"
> immediate words are yellow. "Magenta" variables are dark
> blue. "Cyan" compiled macros are light blue. "White" comments
> are white. It probably wouldn't be too difficult to "tweak"
> ColorForth to have different colors that constrasted better
> for different people.
It's really hard to explain what I see, but the technical reality is
that the distinction between red and green is missing. Picture red
apples on an apple tree. I can't unless I am close enough to see the
shape of the apples. That list of source code gets progressively
harder and harder for me to see the color differences.
However, it's deeper than just a color issue. Color has actually lost
a lot of its significance to me. I can't rely on it, so I have learned
to not depend on it. I find ColorForth source to be distracting, and
eventually, annoying. I haven't had to read a lot of it yet, and in
time, the physical discomfort might diminish, but so far, it has just
discourage my participation. Is it valuable enough to discourage 7% of
the male population who are color blind? My cousin is actually black
and white color blind which would force him to use fonts, I guess.
I recently found a wonderful application that has solved some of my
problem. It's called EyePilot from Tenebraex Corp.
(http://www.colorhelper.com/). With just a little bit of testing just
now, I see it's real hard to click on the letters. If the background
also carried a color signature, it might actually be useful with
ColorForth.
I guess it's just another thing I have to get used to and maybe
something I need to figure out how to influence.
>
> As for having a "Mac" There's "Wine" which would let you
> run the Windows version of ColorForth. Also Mac's are
> about to run QEMU which would let you run a version
> of "native" ColorForth.
I have a G4 and VPC (see my reply to Jeff), so I'm not sure these
alternatives will help much.
>
> Of course this really has little to do with IntellaSys anyway.
> The tools they've announced on their website run under
> GForth (there's a Mac version of that) and SwiftForth
> (Windows only, but again there's Wine). I'm hopeful
> that there will be a release of a ColorForth version, but
> so far nobody has said their definitely would be.
I'm looking forward to see the tools. I was tempted to look at making
a C version of ColorForth that would compile in OSX, but I just haven't
gotten around to it yet.
>
> Regards,
>
> John M. Drake
DaR
Jeff Fox
> You were almost sounding better today Jeff. I really wish you could
> see how your past is affecting your presentation. Most of us have
> witnessed the fist fights, but why do you feel the need to give them
> power over what you are doing today?
I fail to understand where these fights that you have witnessed took
place. Fist fights are not possible in newsgroups, we only have
words here.
I don't know who them is since I haven't been in any fist fights.
I don't think I give 'them' power whoever they are.
Someone asked about an instruction set and I gave some answers.
Some people gave wrong answers and I kindly corrected them.
That's what I saw. Well some people did feel that they beat
themselves up when then realized the errors that they had made.
> > I have never beaten up anyone here. You can't beat someone up
> > on usenet.
> >
> > The worst you can do is show that they are wrong. And when
> > people are wrong I do that.
> >
> > They can cry and say I beat them up by offering some truth,
> > but they should over it.
>
> I'm not crying, but your tone makes me feel like I'm being beat up.
If telling you that I haven't been in any fist fights here and haven't
done anything but correct people's errors makes you feel like
you are being beaten up you have my sympathy. Really it
must be terrible to go through life feeling like people are
being beaten up on usenet. Many people like usenet precisely
because they can say stuff that would get them beaten up
in the real world and no one can beat them up.
> don't know if it is possible for you to understand what I'm trying to
> say here, but if nothing else, I hope you can see that there is another
> way.
Sorry if you feel beaten up. Try not to take it personally
if I said something that made you feel bad.
> Sorry, but it doesn't really matter how you feel.
I guess you think that it really doesn't matter how I feel.
But above you wanted me to feel sympatheic for your
feeling like you were somehow beaten up.
I would normally point out the double standard that
you think I should be sympathetic to your feelings but
you declare that my feeling simply don't matter at all.
If you feel bad because you said something that
was so wrong that you felt that you got beaten up
for saying it, then think next time before you write.
But remember it is usenet, you are not really going
to be beaten up but you might feel like it if you
write before you think.
> Your future depends
> on how the market feels about your message and only you can control
> your presentation.
c.l.f is not the market. ;-)
My future does not depend on the people in c.l.f who don't like me.
This group doesn't rule the world. ;-)
> > Honest information about colorforth or Forth chips
> > has never been tolerated here. I think it is mostly
> > just a case that the effort to exclude that stuff from
> > Forth, ie. the ANS Standard, failed to kill that stuff
> > completely. The fact that it didn't die is not
> > acceptable in c.l.f and they are still trying to kill it.
>
> Spilled milk. As you said, get over it.
I have accepted it as fact. I find it amusing.
> > But on usenet you can't be that kind to people, and the
> > best you can do sometimes to get their attention is to
> > point out that they are wrong.
>
> There are many ways to accomplish that, and negative reinforcement is
> rarely the most successful option.
Neither is rewarding stupidity. The best you can do in usenet when
someone says something really dumb is to give em some facts to
think about. And you can only use words to get their attention.
> I will explain the color issue in response to John Drake's message, but
> I have the same problem with SwiftForth that I have with ColorForth,
> and I helped write some of SwiftForth.
colorblindness?
Since colorblind people can see some colors, and since you could
make colorforth use b/w I have never understood the 'problem'
that people talk about.
> I still consider it to be one of the best, but I don't use it.
ok. I have no idea what that has to do with the instruction set of
SEAforth.
> If I launch VPC or any emulation
> environment, I reduce the efficiency of everything I'm doing.
ok.
> Clearly
> not a good use of my time, when I can pop up gforth in a terminal
> window with almost no impact on anything else I am doing. I'm really
> looking forward to seeing the tools you have promised.
ok, I didn't quite follow what SwiftForth, VPC and gForth have to
do with any of this. But thank you anyway.
Bernd Paysan
> Bernd Paysan wrote:
>> The +* of SEAforth looks remarkable like the one I put into b16.
>
> I am sure it does. Many people's Forth look remarkably like what
> Chuck named Forth to them. Many people think they have got it
> because they made a embarrasing copy of part of something.
Jeff, when Chuck made the presentation at EuroForth, he explained that *+
could produce a 9x9 -> 18 bit multiplication, and required to be
interleaved with a bit shift (don't know which direction). I thought that
was a bad idea, and implemented a 16x16->32 bit multiplication in b16,
leaving one half of the result in A, and doing the bit shift at the same
time. And now you are telling me that Chuck invented that, too, and I did
copy it?
> And they learn something from it in a day or two just like Chuck has by
> solving the real problems on a daily basis for twenty years. But sure
> I know you make one of the embarrasing knock-offs and have confused
> people every since with your tiny subset of undertanding of what Mr.
> Moore has been doing all these years.
Jeff, that's teenage fanboy speak.
BTW: Why does IntellaSys use SwiftForth and Gforth as cross compiler
platform, and not ColorForth? You must have gone mad when other people
decided that ;-).
> I find it hard to see that making something orders of magnitudes
> slower and orders of magnitudes more expensive and more
> power hungry is forward progress. I think it is funny that some
> people do think this is forward progress.
What on earth makes you think that my b16 is orders of magnitude slower and
more power hungry or expensive when implemented in comparable silicon than
the c18? The size of my b16 in 0.18µ is <0.1mm², and the speed should be
about 500MHz with a "fast" standard cell approach (which is clearly
suboptimal compared to the full custom approach from Chuck, but takes a lot
less time to get it working).
Bernd Paysan
> Bernd Paysan wrote:
>> Oh, shut up and just give us the facts -
>
> I think that should read, shut up OR give us the facts.
No, I mean you should shut up (because you spend way too much energy in
insulting people here), *and* let someone better suited at the job give us
the facts.
Jeff, we are curious, and we want to know how this thing works. Apart from
Chucks x25-presentation on EuroForth, little information leaked out. We
don't hate you, but we like to discuss things here, and exchange
informations. That's the purpose of a usenet group. If everybody agrees,
and has the same set of informations, no discussion is necessary.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
Jeff Fox
> time. And now you are telling me that Chuck invented that, too, and I did
> copy it?
It amazes me that people can independently discover things that
we worked out so many years ago and think they got their first.
Ok, Chuck didn't implement that until he was asked to do it,
but it was certainly discussed and worked out as an option
long ago.
So you did independently figure out how to put a couple
piece of the puzzle together on your own after copying almost
all of the pieces from Chuck.
OK, you could make a copy. I am impressed. I wasn't much
impressed that the performance was so embarrisingly bad
that you moved backwards past where Chuck was in the
80s with 1980s programmable chip technology. Yes,
progress for you no doubt to have caught up to
performance from 20 years in the past. And it is very
funny that you think you are leading the way by
making copies that go backwards in performance.
> BTW: Why does IntellaSys use SwiftForth and Gforth as cross compiler
> platform, and not ColorForth?
Your question, and insult is based a either a false assumption
because you haven't been paying attention or you enjoy staying
in the dark. I have been very clear that we both stand-alone and
windows based colorforth for both chip development and
cross compiling. We also have other tools that run in ANS
forth and which various people run in SwiftForth and Gforth and
power MacForth. We want to ensure that the code works
on various platforms and different people have different
tastes regarding what computer or software they use.
You are the only person who has said that we don't use
colorforth as a cross compiler and I don't know where you
think you got that from. But ok. People get confused.
> > I find it hard to see that making something orders of magnitudes
> > slower and orders of magnitudes more expensive and more
> > power hungry is forward progress. I think it is funny that some
> > people do think this is forward progress.
>
> What on earth makes you think that my b16 is orders of magnitude slower and
> more power hungry or expensive when implemented in comparable silicon than
> the c18?
I read your web pages and what you wrote in c.l.f.
> The size of my b16 in 0.18µ is <0.1mm², and the speed should be
> about 500MHz with a "fast" standard cell approach (which is clearly
> suboptimal compared to the full custom approach from Chuck, but takes a lot
> less time to get it working).
How much time did it take you to get your fast standard cell copy
working? Or is it a fantasy like newforth?
Jeff Fox
> No, I mean you should shut up
ok you have made yourself clear
You are the inventor, you are the leader,
Chuck is following you, and if people
don't accept that they should shut up.
Did you invent the Forth language too?
Did Chuck copy that from you too?
Tim Clacy
> BTW: Why does IntellaSys use SwiftForth and Gforth as cross compiler
> platform, and not ColorForth? You must have gone mad when other people
> decided that ;-).
Hi Bernd,
"In addition, expect to see a variation called ColorForth developed by-who
else-Chuck Moore. A compact operating system fits in only 2 kbytes of
memory, making it ideal for the SEAforth-24. It was started back in 1996."
http://www.elecdesign.com/Articles/Index.cfm?ArticleID=12692&pg=1
Hi Jeff,
What external interface(s) are there on the SEAforth chips to get bulk data
in, processed and back out? Does 100MB/s sustained throughput sound
feasible?
I got hooked on the videos at UltraTechnolgy recently but quickly got
through all of those that were available. There is mention of making the
remainder available at some point. Will you still be doing that or can they
be got from anywhere else?
Regards
Tim
Albert van der Horst
Jeff Fox <f...@ultratechnology.com> wrote:
>and lower power. Mr. Moore has said that moving forward meant
>making the software easier, simpler and faster and making
>the hardware and software match more closely.
Why do you always say Mr. Moore while everybody else says
Chuck Moore? If you want to express your reverence you better
say master Moore. Mr. only suggest that you don't know somebody
personally, nor would you aspire to (as in Mr. Bush).
Anyway. Can you give a more exact quote where Mr. ( ;-) ) Moore
says he wants to make software easier.
Specifically I wonder in what sense. Personnally I found the
effort expended in writing a "hello world" program in the
colorforth mailing list enormous. Nor did I find any of those
programs simple.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Elizabeth D Rather
> Dennis Ruffer wrote:
> ...
>> I will explain the color issue in response to John Drake's message, but
>> I have the same problem with SwiftForth that I have with ColorForth,
>> and I helped write some of SwiftForth.
>
> colorblindness?
>
> Since colorblind people can see some colors, and since you could
> make colorforth use b/w I have never understood the 'problem'
> that people talk about.
>
>> I still consider it to be one of the best, but I don't use it.
>
> ok. I have no idea what that has to do with the instruction set of
> SEAforth.
>
>> If I launch VPC or any emulation
>> environment, I reduce the efficiency of everything I'm doing.
>
> ok.
>
>> Clearly
>> not a good use of my time, when I can pop up gforth in a terminal
>> window with almost no impact on anything else I am doing. I'm really
>> looking forward to seeing the tools you have promised.
>
> ok, I didn't quite follow what SwiftForth, VPC and gForth have to
> do with any of this. But thank you anyway.
Dennis is merely saying that since he is using an Apple computer, it's
awkward to run Windows programs. He has no problem with your potential
toolset, other than the concern that he would be unable to run it
natively on his Apple without VPC or other emulation environment.
However, he can run a gforth-based program just fine. He is hoping you
will offer gforth-based tools.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
vandyswa
>Chuck Moore? If you want to express your reverence you better
>say master Moore. Mr. only suggest that you don't know somebody
>personally, nor would you aspire to (as in Mr. Bush).
Not "everybody else" calls him "Chuck Moore". To me, that seems to be
taking a liberty to which I have not been invited, thus I am more
comfortable with "Mr. Moore". The prefix "master" is very rarely used
among us Americans.
$0.02,
Andy Valencia
Bernd Paysan
> Bernd Paysan wrote:
>> time. And now you are telling me that Chuck invented that, too, and I did
>> copy it?
>
> It amazes me that people can independently discover things that
> we worked out so many years ago and think they got their first.
> Ok, Chuck didn't implement that until he was asked to do it,
> but it was certainly discussed and worked out as an option
> long ago.
b16 is 4 1/2 years old, it was created 3 months after Chuck gave his
presentation on EuroForth. There was no company behind x25 back then, just
Chuck. You might have discussed internally during the iTV time, but this
wasn't disclosed.
I admit that I think it's a rather obvious idea.
> OK, you could make a copy. I am impressed. I wasn't much
> impressed that the performance was so embarrisingly bad
> that you moved backwards past where Chuck was in the
> 80s with 1980s programmable chip technology.
I don't know what you are speaking about. Yes, the *slowest* Altera FPGA I
could get hands on runs the b16 at "only" 25MHz, but that's already faster
than the Novix 4000. The paper also states that on a TSMC 0.5µ process, it
can run up to 100MHz. What's so embarrassingly bad about this performance?
There's no multicycle + to speed things up further like in i21.
>> BTW: Why does IntellaSys use SwiftForth and Gforth as cross compiler
>> platform, and not ColorForth?
>
> Your question, and insult is based a either a false assumption
> because you haven't been paying attention or you enjoy staying
> in the dark.
I don't enjoy staying in the dark. The IntellaSys side reads just like that.
Your people just don't give us more informations.
> You are the only person who has said that we don't use
> colorforth as a cross compiler and I don't know where you
> think you got that from. But ok. People get confused.
Ok, you recently said that. But I just can't see into the future, and behind
your thick curtains. It's you side that spreads incomplete information, and
by being incomplete, it's prone to misunderstanding.
I'm getting my informations from here:
http://www.intellasys.net/tools/index.php
If you please allow me to be confused by a text that doesn't mention any
ColorForth at all, but ANS Forth, Gforth and SwiftForth.
>> What on earth makes you think that my b16 is orders of magnitude slower
>> and more power hungry or expensive when implemented in comparable silicon
>> than the c18?
>
> I read your web pages and what you wrote in c.l.f.
Oh Jeff, and you tell other people that they should not badmouth you? Or is
this a tit-for-tat revenge? Please tell me exactly where I wrote such
nonsense, so that I can correct it.
>> The size of my b16 in 0.18µ is <0.1mm², and the speed should be
>> about 500MHz with a "fast" standard cell approach (which is clearly
>> suboptimal compared to the full custom approach from Chuck, but takes a
>> lot less time to get it working).
>
> How much time did it take you to get your fast standard cell copy
> working? Or is it a fantasy like newforth?
Oh man, Jeff, you must have a bad day. I'm working as chip designer for 7
years now. Since you read my homepage and what I post here, you should know
that. I have access to all these brain-damaged Cadence tools, and to
horribly padded-up standard cell libraries. It took me two days to make the
b16 work on the FPGA, and a few hours to synthesize it on a standard cell
library.
Since we do customer-specific chips, you won't be able to buy one of them
directly. Yes, we have two working b16 processor variants, the first one
had working silicon about 3 years ago. It regulates a valve within the
exhaust gas regulation system, so it's doing a rather boring job.
Dennis Ruffer
> Dennis Ruffer wrote:
>> You were almost sounding better today Jeff. I really wish you could
>> see how your past is affecting your presentation. Most of us have
>> witnessed the fist fights, but why do you feel the need to give them
>> power over what you are doing today?
>
> I fail to understand where these fights that you have witnessed took
> place. Fist fights are not possible in newsgroups, we only have
> words here.
>
> I don't know who them is since I haven't been in any fist fights.
> I don't think I give 'them' power whoever they are.
>
> Someone asked about an instruction set and I gave some answers.
> Some people gave wrong answers and I kindly corrected them.
> That's what I saw. Well some people did feel that they beat
> themselves up when then realized the errors that they had made.
You appear to have gotten some rest and your posts appear a little less
defensive today. That's progress, I guess. I will simply take your
comment as bait then, since I'm sure you know my use of metaphor.
>
>>> I have never beaten up anyone here. You can't beat someone up
>>> on usenet.
>>>
>>> The worst you can do is show that they are wrong. And when
>>> people are wrong I do that.
>>>
>>> They can cry and say I beat them up by offering some truth,
>>> but they should over it.
>>
>> I'm not crying, but your tone makes me feel like I'm being beat up.
>
> If telling you that I haven't been in any fist fights here and haven't
> done anything but correct people's errors makes you feel like
> you are being beaten up you have my sympathy. Really it
> must be terrible to go through life feeling like people are
> being beaten up on usenet. Many people like usenet precisely
> because they can say stuff that would get them beaten up
> in the real world and no one can beat them up.
And I can tell you are a master.
>
>> don't know if it is possible for you to understand what I'm trying to
>> say here, but if nothing else, I hope you can see that there is another
>> way.
>
> Sorry if you feel beaten up. Try not to take it personally
> if I said something that made you feel bad.
I'm only saddened that IntellaSys has to deal with your communication style.
>
>> Sorry, but it doesn't really matter how you feel.
>
> I guess you think that it really doesn't matter how I feel.
>
> But above you wanted me to feel sympatheic for your
> feeling like you were somehow beaten up.
>
> I would normally point out the double standard that
> you think I should be sympathetic to your feelings but
> you declare that my feeling simply don't matter at all.
>
> If you feel bad because you said something that
> was so wrong that you felt that you got beaten up
> for saying it, then think next time before you write.
> But remember it is usenet, you are not really going
> to be beaten up but you might feel like it if you
> write before you think.
Thank you for your advice, and insight into your point of view.
>
>> Your future depends
>> on how the market feels about your message and only you can control
>> your presentation.
>
> c.l.f is not the market. ;-)
>
> My future does not depend on the people in c.l.f who don't like me.
> This group doesn't rule the world. ;-)
Ah, so you only use this style when you feel you are not liked? Interesting!
>
>>> Honest information about colorforth or Forth chips
>>> has never been tolerated here. I think it is mostly
>>> just a case that the effort to exclude that stuff from
>>> Forth, ie. the ANS Standard, failed to kill that stuff
>>> completely. The fact that it didn't die is not
>>> acceptable in c.l.f and they are still trying to kill it.
>>
>> Spilled milk. As you said, get over it.
>
> I have accepted it as fact. I find it amusing.
Perhaps you could try showing some humor then.
>
>>> But on usenet you can't be that kind to people, and the
>>> best you can do sometimes to get their attention is to
>>> point out that they are wrong.
>>
>> There are many ways to accomplish that, and negative reinforcement is
>> rarely the most successful option.
>
> Neither is rewarding stupidity. The best you can do in usenet when
> someone says something really dumb is to give em some facts to
> think about. And you can only use words to get their attention.
But which words you choose to use are significant.
>
>> I will explain the color issue in response to John Drake's message, but
>> I have the same problem with SwiftForth that I have with ColorForth,
>> and I helped write some of SwiftForth.
>
> colorblindness?
>
> Since colorblind people can see some colors, and since you could
> make colorforth use b/w I have never understood the 'problem'
> that people talk about.
Few people who do not suffer from a disability can understand. I takes
empathy and a desire to learn.
>
>> I still consider it to be one of the best, but I don't use it.
>
> ok. I have no idea what that has to do with the instruction set of
> SEAforth.
>
>> If I launch VPC or any emulation
>> environment, I reduce the efficiency of everything I'm doing.
>
> ok.
>
>> Clearly
>> not a good use of my time, when I can pop up gforth in a terminal
>> window with almost no impact on anything else I am doing. I'm really
>> looking forward to seeing the tools you have promised.
>
> ok, I didn't quite follow what SwiftForth, VPC and gForth have to
> do with any of this. But thank you anyway.
Thank you Elizabeth, for trying to explain.
I will wait to evaluate the IntellaSys gforth toolset before trying to
do much more with all of this.
DaR
Jeff Fox
> Dennis is merely saying that since he is using an Apple computer, it's
> awkward to run Windows programs.
Ok. Thanks. If I didn't understand that his problem was not with
colorforth as a concept but with a colorforth implementation.
Ok. Then what I said may not have been appropriate for what
he was talking about. Sorry for the rant about color-blind
blindness.
> He has no problem with your potential
> toolset, other than the concern that he would be unable to run it
> natively on his Apple without VPC or other emulation environment.
Well it will be a while before any colorforth cad tools are released
as products and most of the cad tools run on PCs not on Macs
anyway. So as one will find with other cad tools the Mac may
not be the right machine to do that.
It would require a Forth programmer to create a version
that would run on a Mac if we want to we can do it.
> However, he can run a gforth-based program just fine. He is hoping you
> will offer gforth-based tools.
We have aimed for ANS portability with a 32-bit or greater dependency
at the moment. That seems to match typical development environments
and provide a very wide range of development platforms. But we haven't
tried things with a great number of ANS Forths.
We might offer a SwiftX front end from Forth Inc. and have mentioned
that the tools we have have been used in gforth and SwiftForth with
a minimum of configuration differences. As for front-ends, we
haven't felt that good front-ends were possible until most of the
details of what goes behind it were ready.
So if I gave a Grump answer before let me apologize and hope that
that that is a more Happy answer and more of what Dennis was
asking about.
Thanks for the help.
Jeff Fox
> You appear to have gotten some rest and your posts appear a little less
> defensive today. That's progress, I guess. I will simply take your
> comment as bait then, since I'm sure you know my use of metaphor.
Thanks.
> > in the real world and no one can beat them up.
>
> And I can tell you are a master.
domo arigato gozaimasu
I am told that I can beat people up at a distance! watch out!
there is no where to hide! ;-)
> I'm only saddened that IntellaSys has to deal with your communication style.
It works pretty well there with most of the people. But some see some
things more like other people here than I do and we sometimes bump
heads, figuratively speaking that is. ;-)
before you write.
> > But remember it is usenet, you are not really going
> > to be beaten up but you might feel like it if you
> > write before you think.
>
> Thank you for your advice, and insight into your point of view.
Except for me. Watch out. There is no where to hide.
Walk out innocently into a scene of me and group of folks
in c.l.f on a bad day and watch out. I might duck and you
might get a torch in the face for no good reason. Or a
piano might fall on you. If you walk into a shut up,
go away, name calling festival be careful what you say or
words might come at you. But the pianos and anvils
are more dangerous.
Some people think I need the interenet to beat people up remotely!
> >> Your future depends
> >> on how the market feels about your message and only you can control
> >> your presentation.
> >
> > c.l.f is not the market. ;-)
> >
> > My future does not depend on the people in c.l.f who don't like me.
> > This group doesn't rule the world. ;-)
>
> Ah, so you only use this style when you feel you are not liked? Interesting!
No. But I think you are close. People don't like me when I use this
style.
But I do find it terribly amusing that there are a very few people who
post
in c.l.f. And they make quite a gaggle. They are always telling me
how
they will determine the future. I am impressed.
If I insulted anyone here who was seriously planning on buying
billions of chips from the company where I work, then wow, I apologize.
I will slap myself silly and beg forgiveness for treating them like a
usenet troll. Hey I am willing to treat anyone on usenet as a troll.
That's mostly what usenet is about except that no one considers
themselves a troll.
> >>> Honest information about colorforth or Forth chips
> >>> has never been tolerated here. I think it is mostly
> >>> just a case that the effort to exclude that stuff from
> >>> Forth, ie. the ANS Standard, failed to kill that stuff
> >>> completely. The fact that it didn't die is not
> >>> acceptable in c.l.f and they are still trying to kill it.
> >>
> >> Spilled milk. As you said, get over it.
> >
> > I have accepted it as fact. I find it amusing.
>
> Perhaps you could try showing some humor then.
Sorry I should put happy faces on most lines.
When I have dialog the best communication is often
quite funny. When someone else reads the same
humor between the lines or in the way your ideas
and their ideas fit together like Who's on First?
it is funny. Most of c.l.f is funny to me.
The fact that most of it appears totally mechanical
and totally predictable make it seem histerical to me.
It is like everyone is writing the same things over
and over reflexively as if they other people don't
know exactly what they are going to say. And usually
the messages pass like ships in the night.
So it all comes back the next day, or month,
and everyone repeats themselves in very slightly
different way. It seems to be a lot like the computer
game with the falling colored rectangles, it seems
to exercise a primtive reflex that keeps people doing
the same thing again and again. Just one more game!
> > ok, I didn't quite follow what SwiftForth, VPC and gForth have to
> > do with any of this. But thank you anyway.
>
> Thank you Elizabeth, for trying to explain.
Indeed. It was like two ships in the night. I guess I missed
your point the first time in a thread had mostly become
shut up and name calling stuff.
> I will wait to evaluate the IntellaSys gforth toolset before trying to
> do much more with all of this.
That is what I would advise. People won't be able to do much
of anything except guess with only the first few web pages to
go on. If I hadn't explained a bunch more of it in detail here
people here would have very very little to go on.
And while I have from time to time posted some information
here about this stuff I don't need to and there are other people
who could but don't bother. They like dealing with smart
professional polite and cooperative folks, not the sort of
dialog (reflexively repeating opinions because you never
think other people understand them or that someone new
will read them this time) that takes place on usenet where
people get very nasty with one another.
If you do have a dialog with me on usenet please try
to be a little insulting so that you won't be labeled a
cultist or worse.
Sorry for the confusion. Sorry that you got beaten up,
sometimes perception is reality.
Dennis Ruffer
> Dennis Ruffer wrote:
>> I'm only saddened that IntellaSys has to deal with your communication style.
>
> It works pretty well there with most of the people. But some see some
> things more like other people here than I do and we sometimes bump
> heads, figuratively speaking that is. ;-)
> before you write.
I too find these cases. ;)
>
>>> But remember it is usenet, you are not really going
>>> to be beaten up but you might feel like it if you
>>> write before you think.
>>
>> Thank you for your advice, and insight into your point of view.
>
> Except for me. Watch out. There is no where to hide.
> Walk out innocently into a scene of me and group of folks
> in c.l.f on a bad day and watch out. I might duck and you
> might get a torch in the face for no good reason. Or a
> piano might fall on you. If you walk into a shut up,
> go away, name calling festival be careful what you say or
> words might come at you. But the pianos and anvils
> are more dangerous.
>
> Some people think I need the interenet to beat people up remotely!
Sorry if I disturbed your exercise in frustration reduction.
>
>>>> Your future depends
>>>> on how the market feels about your message and only you can control
>>>> your presentation.
>>>
>>> c.l.f is not the market. ;-)
>>>
>>> My future does not depend on the people in c.l.f who don't like me.
>>> This group doesn't rule the world. ;-)
>>
>> Ah, so you only use this style when you feel you are not liked? Interesting!
>
> No. But I think you are close. People don't like me when I use this
> style.
>
> But I do find it terribly amusing that there are a very few people who
> post
> in c.l.f. And they make quite a gaggle. They are always telling me
> how
> they will determine the future. I am impressed.
>
> If I insulted anyone here who was seriously planning on buying
> billions of chips from the company where I work, then wow, I apologize.
> I will slap myself silly and beg forgiveness for treating them like a
> usenet troll. Hey I am willing to treat anyone on usenet as a troll.
> That's mostly what usenet is about except that no one considers
> themselves a troll.
There are a lot more people listening than talking and I've never like
the practice of baiting trolls. I don't disagree with its
effectiveness, I just don't like it. I prefer to ignore them
As with most games, it's sometimes better not to dance.
>
>>> ok, I didn't quite follow what SwiftForth, VPC and gForth have to
>>> do with any of this. But thank you anyway.
>>
>> Thank you Elizabeth, for trying to explain.
>
> Indeed. It was like two ships in the night. I guess I missed
> your point the first time in a thread had mostly become
> shut up and name calling stuff.
As you said above, it is the nature of this form of communication.
Sorry that I added to that suggestion. I knew the risk and foolishly
ignored it.
>
>> I will wait to evaluate the IntellaSys gforth toolset before trying to
>> do much more with all of this.
>
> That is what I would advise. People won't be able to do much
> of anything except guess with only the first few web pages to
> go on. If I hadn't explained a bunch more of it in detail here
> people here would have very very little to go on.
>
> And while I have from time to time posted some information
> here about this stuff I don't need to and there are other people
> who could but don't bother. They like dealing with smart
> professional polite and cooperative folks, not the sort of
> dialog (reflexively repeating opinions because you never
> think other people understand them or that someone new
> will read them this time) that takes place on usenet where
> people get very nasty with one another.
>
> If you do have a dialog with me on usenet please try
> to be a little insulting so that you won't be labeled a
> cultist or worse.
I hope we can just remember each other. I choose not to go there.
>
> Sorry for the confusion. Sorry that you got beaten up,
> sometimes perception is reality.
I have a well ingrained asbestos suit. Any reflection of harm was
simply used for illustration. Sorry for assuming that you might need
help or that I knew anything about how to give it.
DaR
Dennis Ruffer
> Elizabeth D Rather wrote:
>> Dennis is merely saying that since he is using an Apple computer, it's
>> awkward to run Windows programs.
>
> Ok. Thanks. If I didn't understand that his problem was not with
> colorforth as a concept but with a colorforth implementation.
>
> Ok. Then what I said may not have been appropriate for what
> he was talking about. Sorry for the rant about color-blind
> blindness.
I didn't do a good job of separating the issues, I guess.
>
>> He has no problem with your potential
>> toolset, other than the concern that he would be unable to run it
>> natively on his Apple without VPC or other emulation environment.
>
> Well it will be a while before any colorforth cad tools are released
> as products and most of the cad tools run on PCs not on Macs
> anyway. So as one will find with other cad tools the Mac may
> not be the right machine to do that.
>
> It would require a Forth programmer to create a version
> that would run on a Mac if we want to we can do it.
Although it would go against everything Chuck believes in, a C version
of ColorForth would be useful for those of us that don't happen to
have, or like (in some cases), PCs. I'm tempted to write it myself,
but it would be better if someone, who understands the original issues
better than I, did it.
>
>> However, he can run a gforth-based program just fine. He is hoping you
>> will offer gforth-based tools.
>
> We have aimed for ANS portability with a 32-bit or greater dependency
> at the moment. That seems to match typical development environments
> and provide a very wide range of development platforms. But we haven't
>
> tried things with a great number of ANS Forths.
>
> We might offer a SwiftX front end from Forth Inc. and have mentioned
> that the tools we have have been used in gforth and SwiftForth with
> a minimum of configuration differences. As for front-ends, we
> haven't felt that good front-ends were possible until most of the
> details of what goes behind it were ready.
>
> So if I gave a Grump answer before let me apologize and hope that
> that that is a more Happy answer and more of what Dennis was
> asking about.
Apology accepted. ;)
DaR
Jean-François Michaud
With all due respect Jeff, It is your attitude that causes most of the
problem. I seldom see people fighting on here except when you
explicitly get involved. You seem to rub people the wrong way, but not
for the reasons you think (which would be, according to you, giving
them facts when all they have are speculations). I do not know if this
is deliberate or not. My guess is that it is not to some extent. If it
were, it would bring you to the same level as the actual usenet trolls
(as opposed to you thinking that "mostly everybody is a usenet troll
and since everybody is trolling, darnit, I might as well do it too
because thats just the nature of usenet").
Regards
Jean-Francois Michaud
John Doty
> Bernd Paysan wrote:
>
>>time. And now you are telling me that Chuck invented that, too, and I did
>>copy it?
>
>
> It amazes me that people can independently discover things that
> we worked out so many years ago and think they got their first.
Credit generally goes to the one who publishes first.
> OK, you could make a copy. I am impressed.
Bernd *published* an *implementation*. From where I sit, that's much
more useful than merely announcing a chip that might be available at
some future date. For some purposes, it's more useful than an available
chip.
> I wasn't much
> impressed that the performance was so embarrisingly bad
> that you moved backwards past where Chuck was in the
> 80s with 1980s programmable chip technology. Yes,
> progress for you no doubt to have caught up to
> performance from 20 years in the past. And it is very
> funny that you think you are leading the way by
> making copies that go backwards in performance.
By what metric do you measure performance? It's application-dependent.
Suppose my metrics are cost for 10 units, radiation tolerance, and
degree of integration with some specialized hardware? I can take Bernd's
design, paste on some specialized peripheral logic, and put the whole
thing into a rad tolerant FPGA. Your approach couldn't come close to
Bernd's in this kind of application (I'm thinking here of a controller
for a scientific instrument on a spacecraft, a kind of work I'm very
familiar with). In in a different application your approach might win
hands down. There are no universal solutions.
--
---
John Doty, Noqsi Aerospace, Ltd.
---
His diagnosis of the hostility ... reflects the willful blindness of the
invader who assures himself that the natives are only made unfriendly by
some other provocation than his own. -Barbara W. Tuchman
Jeff Fox
> Credit generally goes to the one who publishes first.
Sure, that's why I published the instruction set and a history
of the variations with benchmarks and comparisons fifteen years ago.
We did most of the work back then. Then in the several
hundred man years invested since then not all the options
implemented in one way or another and benchmarked and
compared against real code have not been published.
Yes. Bernd appears to have independently found one of the
'fairly obvious' ones as he put it, in his two days of work on it.
> Bernd *published* an *implementation*.
I tend to think that he made a copy of a copy and added a
little more in a few extra hours of work. I believe Ting and Rible
published their p16 and sp16 copies before Bernd's b16 copy
but there might have been other copies before Bernd's.
> By what metric do you measure performance?
real world problem solutions, a combination of hardware and software
often measured against realtime performance requirements as
well as cost, power, and development expense and time requirements.
> It's application-dependent.
Indeed it is. I think it is kind of funny that many people want to
build
a chip or a compiler without having an intended application, or
with application code already written to be used to measure the
peformance of the design. When I see people who design first
without a target space in mind I am not supprised when they
conclude that they couldn't hit the bulls-eye when they selected
a problem domain. Of course we tried the first time, but then
we understood the problem better and got closer on the second
try and the third, and decade later Bernd read about what we
had been doing, saw a presentation and put in a couple of
days work. That's fine. That's a lot more than most people
have invested in understand all those man years of work that
was being copied.
> Suppose my metrics are cost for 10 units, radiation tolerance, and
> degree of integration with some specialized hardware?
ok. I would expect that there will also be other requirements.
> I can take Bernd's
> design, paste on some specialized peripheral logic, and put the whole
> thing into a rad tolerant FPGA.
Sure anyone who know how to push the button can do that.
Sure, I know you can push a button on a photocopy machine also and
copy a dollar bill that you might be able to pass at the local liquor
store.
There would be a bit more involved in it that really just pushing the
button though.
> Your approach couldn't come close to
> Bernd's in this kind of application (I'm thinking here of a controller
> for a scientific instrument on a spacecraft, a kind of work I'm very
> familiar with). In in a different application your approach might win
> hands down. There are no universal solutions.
Yeah, at one time it was Air Force and NASA money from spacecraft
projects that funded a few million dollars worth of development that
Bernd when he copied the copies of a tiny bit of it in a couple of
days.
NASA and the Air Force had very specific and demanding requirements
and then included in addition to radiation tolerance power use and
instruction throughput. Price was not an object and performance
was rather demanding because of the high data rates and low
power limits.
But whether our hundreds of man years of work is a copy of Bernd's
couple of days or work, or if Bernd's couple of days of work of
making the third or fourth generation of copies of copies was more
significant than our work is getting rather off the subject of the
SEAforth instruction set.
Jeff Fox
> Although it would go against everything Chuck believes in, a C version
> of ColorForth would be useful for those of us that don't happen to
> have, or like (in some cases), PCs. I'm tempted to write it myself,
> but it would be better if someone, who understands the original issues
> better than I, did it.
It should be easier to port with only a 1K kernel in assembler and the
rest in high level. That will help.
According to Chuck all a Forth system needs to be a colorforth is for
the compiler to recognize what makes the source visually distinctive
in the editor as compiler directives.
So if your compiler recognizes indendation for instance, that's
colorforth. If you put html tags in your souce that your compiler and
your editor can read, that's colorforth.
You want source in C. Not a big problem although some words
not in the kernel also have assembler definitions now.
> Apology accepted. ;)
Thanks.
Jeff Fox
> With all due respect Jeff, It is your attitude that causes most of the
> problem.
Oddly enough I think most of 'the problem' is that people would rather
lecture me about this sort of thing than discuss the topic. It is a way
to make noise and cause trouble for people who are interested in the
subject.
And to me a useful thing in c.l.f is that people sort themselves out.
Some are sincerely interested in dialog on topics related to Forth
and are intested in questions and answers about things like SEAforth.
So we have threads that clearly mark what people want to disucss.
If you have an interest in the subject of a thread you post about that
subject in that thread. When I have little interest in a thread I
stay out.
I see a lot of people who try to derail thread by taking them off
topic. They most common thing is to try to create a thread of
personal insults to replace the technical thread that they don't
like. They like to play a shrink in usenet and lecture other
people about 'their' problems.
That is in fact 'my problem.'
People who don't want others discussing a thread like "SEAforth
Instruction Set" will try to turn it into a flamewar and say that
the problem is that they can make a problem and if I don't
like that then that is why they make the problem.
I think we are saying the same thing.
I say that when I say I dislike people trying to derail threads by
switching the topic to the way that they can cause a problem
by switching the topic, that yes, I have told them how they
can make a problem if that is their goal.
But again, it lets people sort themseleves out.
Everyone can see if the threads spin off and who tries to
keep them on topic and learn something and who try
to spin them off and prevent that.
> I seldom see people fighting on here except when you
> explicitly get involved.
Yes. When people ask questions about colorforth or Forth
chips and I answer them, the people who don't want that
tell me to shut up and go away. And when enough of
them gather a few new ones always join in. Usenet.
> You seem to rub people the wrong way,
And I wonder for instance why anyone who can't answer
questions about the topic of a thread, and apparently
has on interest in the questions, must only focus on
trying to shut down a discussion that clearly does
interest some people.
So people who contribute nothing but noise and insults
try to hijack the threads. Usenet.
Dealing with professionals is different. This is usenet.
> but not
> for the reasons you think (which would be, according to you, giving
> them facts when all they have are speculations).
I suppose you are 'giving the people the facts' about the SEAforth
instruction set. The reason that I 'think' is the problem here is
that you are off topic and intentionally so.
> I do not know if this is deliberate or not.
It is clearly deliberate on your part. And it is clearly deliberate
on my part to point it out. The 'problem' that I see is that you
would rather talk about personal insults if that can help shut
down other people from learning something you don't like
for some reason.
> My guess is that it is not to some extent. If it
> were, it would bring you to the same level as the actual usenet trolls
There are quite a few trolls in this group. But I think anyone who
tries to derail a thread about Forth with personal insults is just
trolling.
> (as opposed to you thinking that "mostly everybody is a usenet troll
> and since everybody is trolling, darnit, I might as well do it too
> because thats just the nature of usenet").
Sure. It's usenet.
Insult me. I can insult you back.
Hijack a thread to make it about your personal complaints about me.
Fine, I can complain about usenet trolls who want to spin things
off topic and won't allow discussions of Forth in c.l.f.
That doesn't insult anyone who isn't doing that kind of trolling.
If you feel insulted by that and insult me that just tells me that
you identified yourself as the troll that I had complained about.
People sort themselves out. Some will ask questions and answers.
Some will try to stop that and flood the thread with insults.
I find that after the trolls arrive and several of them are determined
to outpost me, it is usually best to move on to new thread so
that we can have a short time on topic before the trolls follow.
That lets the trolls get in the last word on the the threads that
are still only entertaining to trolls.
I think the trolls have taken over this thread and am moving on.
Dennis Ruffer
> Dennis Ruffer wrote:
>> Although it would go against everything Chuck believes in, a C version
>> of ColorForth would be useful for those of us that don't happen to
>> have, or like (in some cases), PCs. I'm tempted to write it myself,
>> but it would be better if someone, who understands the original issues
>> better than I, did it.
>
> It should be easier to port with only a 1K kernel in assembler and the
> rest in high level. That will help.
Not really. I'm pushing portability up to the top priority, so any
machine specific assembly instructions are out.
>
> According to Chuck all a Forth system needs to be a colorforth is for
> the compiler to recognize what makes the source visually distinctive
> in the editor as compiler directives.
>
> So if your compiler recognizes indendation for instance, that's
> colorforth. If you put html tags in your souce that your compiler and
> your editor can read, that's colorforth.
This is going to take a little incubation. It may be that I just can't
get my head around this tight of a coupling between editor and compiler
yet, but this makes me think of VBA in Word, without word processing.
Does that mean colorforth can't exist without the editor? You've
already said the colors can be represented by fonts, and you say here
that html tags would work. Can't that be taken even further to the
point of using any kind of syntax marks, say something like : and ;?
Doesn't that decouple the editor, or has it now, somehow magically,
become something other than colorforth?
I'm probably just going to have to wait to see the tools, because I amy
be improperly assuming that there is some connection between SEAforth
and colorforth. If it doesn't, then my mind is wondering aimlessly. ;)
>
> You want source in C. Not a big problem although some words
> not in the kernel also have assembler definitions now.
By assembler, in this context, do you mean SEAForth instructions?
DaR
Jean-François Michaud
think that the SEAForth chip is a bullseye as far as microprocessors
go. But to be quite frank Jeff, you are polluting the thread with your
negative comments. You are not being persecuted so ****ing knock it
off.
If you would notice (of course you didn't really notice because you are
much too self involved to notice), I did not participate in any of the
discussions involving the Instruction Set because I didn't have
anything pertinent to say about the subject. The plain truth is I'm
gathering information. I did post in an answer to your post very simply
because YOU try to shut people off by preventing them to think and to
emit ideas. You are a rock in the thread and I did not see much
constructive conversation coming from you. You are preventing me from
gathering information peacefully and it annoys me. You post all over
the place with nothing more to say than "don't speculate, I have
millions of man years of experience to back up what I say. But wait, I
wont really participate in the conversation because it would take
billions of man years to explain". Get a ****ing clue. You are no more
special than anybody else on this forum. If you want to discuss
normally, like most people like to do, fine, otherwise, I respectfully
suggest you stop polluting the forum with your junk.
Jean-Francois Michaud
Jeff Fox
> You are not being persecuted so ****ing knock it off.
That's funny. You use profanity but being insulting. ;-)
> Get a ****ing clue. You are no more special than anybody
> else on this forum.
Except perhaps in thread like this where it just might be
possble that I actually do know more about it than you do.
> If you want to discuss
> normally, like most people like to do, fine, otherwise, I respectfully
> suggest you stop polluting the forum with your junk.
Thank your for your lucid discussion of the SEAforth Instruction Set.
I am sure you would do a much better job of explaining it than I
if you could just me to shut up.
Keith
Jeff,
This thread is so large I don't know where to post, but figured that
you are paying attention to this subthread.
When Intellasys releases further details of the SEAforth chips and
tools, will you be making them known to everybody that's interested? Or
will detailed information only be provided to selected individuals and
companies? I'm just curious. I could understand why you might restrict
access just to minimize support issues, but I got the impression that
you might do otherwise given some of the statements on your webpage.
I'm a hardware engineer, so I'm particularly interested in see how one
can interface these chips to the outside world through a combination of
hardware and software. For example on the Intellasys website there are
some references to wireless applications, so I imagine that there is
some support in hardware for using external reference clocks since
radios typically require high precision clocks. (And different
applications have different types of requirements for the clocks - for
example compare 802.11 versus GPS.) I can't imagine that you have
figured out ways of using just the on-chip oscillators for wireless
applications, so it will be interesting to see any reference designs
that you release.
In another thread you also mentioned the potential for generating
analog video on-chip, and that made me wonder how you might be able to
generate high-resolution analog or digital video. With the high-end
resolutions in use today, even 1 GHz doesn't look that fast if you have
to manage everything in pure software including clock synthesis. (It
also doesn't seem to be reasonable to expect your chips to do
everything.)
Also if we have feedback related to the materials on the web, what
method would you prefer for people to give feedback to Intellasys?
One last question - is Nick Tredennick involved on a day to day basis?
I would love to see Nick write some papers about your chips.
Regards,
Keith
John Doty
> John Doty wrote:
>
>>Credit generally goes to the one who publishes first.
>
>
> Sure, that's why I published the instruction set and a history
> of the variations with benchmarks and comparisons fifteen years ago.
And you published a Verilog implementation too? Where is it?
> We did most of the work back then. Then in the several
> hundred man years invested since then not all the options
> implemented in one way or another and benchmarked and
> compared against real code have not been published.
Everything you do in technology depends on millions of man years of
people who've gone before. I once worked with an engineer who kept a
blueprint for a 4-40 screw, with dimensions, angles, tolerances, and
material specified on his office wall. He said it was a reminder that
some engineer had to put in serious work on even the simplest, humblest
piece of technology. But then, the rest of us just go ahead and use it,
take it for granted. That's how it works.
Chiri mo tsumoreba yama to naru.
>
> Yes. Bernd appears to have independently found one of the
> 'fairly obvious' ones as he put it, in his two days of work on it.
>
>
>>Bernd *published* an *implementation*.
>
>
> I tend to think that he made a copy of a copy and added a
> little more in a few extra hours of work. I believe Ting and Rible
> published their p16 and sp16 copies before Bernd's b16 copy
> but there might have been other copies before Bernd's.
Whose Verilog did he copy?
>
>
>>By what metric do you measure performance?
>
>
> real world problem solutions, a combination of hardware and software
> often measured against realtime performance requirements as
> well as cost, power, and development expense and time requirements.
>
>
>>It's application-dependent.
>
>
> Indeed it is. I think it is kind of funny that many people want to
> build
> a chip or a compiler without having an intended application, or
> with application code already written to be used to measure the
> peformance of the design. When I see people who design first
> without a target space in mind I am not supprised when they
> conclude that they couldn't hit the bulls-eye when they selected
> a problem domain.
And yet you constantly criticize all and sundry who use any approach to
Forth but your own, without any clue to their application domain.
> Of course we tried the first time, but then
> we understood the problem better and got closer on the second
> try and the third, and decade later Bernd read about what we
> had been doing, saw a presentation and put in a couple of
> days work. That's fine. That's a lot more than most people
> have invested in understand all those man years of work that
> was being copied.
How many millions of man years of effort do you suppose you've copied?
>
>
>>Suppose my metrics are cost for 10 units, radiation tolerance, and
>>degree of integration with some specialized hardware?
>
>
> ok. I would expect that there will also be other requirements.
>
>
>>I can take Bernd's
>>design, paste on some specialized peripheral logic, and put the whole
>>thing into a rad tolerant FPGA.
>
>
> Sure anyone who know how to push the button can do that.
> Sure, I know you can push a button on a photocopy machine also and
> copy a dollar bill that you might be able to pass at the local liquor
> store.
That would be cheating. But taking Bernd's design and copying it isn't
cheating as long as I abide by his (generous) license terms. And if that
looks like it'll get the job done, I'll do just that. If not, I'll look
for another approach. I'm finishing off a full VLSI design for something
else right now, but I won't go that route again lightly: it's a *lot* of
work.
> There would be a bit more involved in it that really just pushing the
> button though.
>
>
>>Your approach couldn't come close to
>>Bernd's in this kind of application (I'm thinking here of a controller
>>for a scientific instrument on a spacecraft, a kind of work I'm very
>>familiar with). In in a different application your approach might win
>>hands down. There are no universal solutions.
>
>
> Yeah, at one time it was Air Force and NASA money from spacecraft
> projects that funded a few million dollars worth of development that
> Bernd when he copied the copies of a tiny bit of it in a couple of
> days.
Sure. And people have copied the video filters I designed for various
space missions. And part of the idea for the filters came from a 1950's
radar text. And the textbook writer was describing an implementation
somebody else did. And that person probably used Heaviside's work on
dispersionless transmission lines. And on back it goes...
>
> NASA and the Air Force had very specific and demanding requirements
> and then included in addition to radiation tolerance power use and
> instruction throughput. Price was not an object and performance
> was rather demanding because of the high data rates and low
> power limits.
I've worked on a project like that. But many space projects have
demanding budget constraints.
>
> But whether our hundreds of man years of work is a copy of Bernd's
> couple of days or work, or if Bernd's couple of days of work of
> making the third or fourth generation of copies of copies was more
> significant than our work is getting rather off the subject of the
> SEAforth instruction set.
What SEAforth instruction set? "Where's the beef?" At least Bernd's b16
is real: I could send the Verilog to the FPGA designer I work with, give
him additional requirements for peripherals and interfaces, and have a
system in a few weeks. With SEAforth I see nothing real, only hype.
Can't beat something with nothing. When you actually have something I
might very well be interested, but the lack of substance is certainly
not making me optimistic.
Bernd Paysan
> By what metric do you measure performance? It's application-dependent.
> Suppose my metrics are cost for 10 units, radiation tolerance, and
> degree of integration with some specialized hardware? I can take Bernd's
> design, paste on some specialized peripheral logic, and put the whole
> thing into a rad tolerant FPGA. Your approach couldn't come close to
> Bernd's in this kind of application (I'm thinking here of a controller
> for a scientific instrument on a spacecraft, a kind of work I'm very
> familiar with). In in a different application your approach might win
> hands down. There are no universal solutions.
By publishing an implementation, I can provide a much wider variation in
performance and cost. You could get your 10 rad-hardened units for a space
application, you can use it to implement a 20-years-replacement-livetime
solution, and you still can implement it in volume in the fastest
process+library you can afford. None of that is possible with the SEAForth
chip - but there, you can buy a chip that's already done.
In some way, my company is a competitor to the Home theater version of
SEAForth. We develop a digital high-quality 8-channel amplifier ATM.
However, we don't do it wireless. IMHO that's pretty pointless, since
speaker cables aren't that expensive, and unlike power cords, there exist
flat ones which you can hide quite well (e.g. Monitor Gladiator C-2).
Jeff Fox
> And you published a Verilog implementation too? Where is it?
Sure a couple, my site, years ealier.
> > I tend to think that he made a copy of a copy and added a
> > little more in a few extra hours of work. I believe Ting and Rible
> > published their p16 and sp16 copies before Bernd's b16 copy
> > but there might have been other copies before Bernd's.
>
> Whose Verilog did he copy?
Don't know. He might have just made his copy years later without
directly copying the copies from years earlier. He came so late
to the party that he could have copied a half dozen different folks.
> How many millions of man years of effort do you suppose you've copied?
countless, as you point out. Everything is based on the past. But
fortunately for everyone the patent on the wheel has run out.
> I've worked on a project like that. But many space projects have
> demanding budget constraints.
Yeah, but space proejcts are one-of and expensive unless you
get paid a lot less than I expect. Sure there are budget constraints
but to ordinary taxpayers the budgets are incomprehensibly high.
To the engineers doing the work they are minimal.
I know that Intel, and AMD, and Sony, and Fujitsu, and HP, and
Casio are a few of the companies who don't agree with Bernd
and you about the use of copiers. But I will avoid that topic. ;-)
Bernd Paysan
>> Whose Verilog did he copy?
>
> Don't know. He might have just made his copy years later without
> directly copying the copies from years earlier. He came so late
> to the party that he could have copied a half dozen different folks.
The only thing I sort-of-copied is the instruction set. You claim that Chuck
didn't copy my *+ semantics, so to be fair, don't claim that I copied
things I might have copied.
>> How many millions of man years of effort do you suppose you've copied?
>
> countless, as you point out. Everything is based on the past. But
> fortunately for everyone the patent on the wheel has run out.
No, it hasn't. The wheel has been patented in Australia just a few years
ago. Oh, it might be an invalid patent, but if you get sued over it, it
doesn't matter. NTP got half a billion dollars from RIM for RIM infringing
an invalid patent from NTP. It just took longer for the USPTO to invalid
the patent than for the judge to close this case.
> I know that Intel, and AMD, and Sony, and Fujitsu, and HP, and
> Casio are a few of the companies who don't agree with Bernd
> and you about the use of copiers. But I will avoid that topic. ;-)
BTW: AMD once made a point that taking a published instruction set and
creating a competing implementation is 100% legal. Since today, every
ridiculous idea is patented, that might not be true anymore.
Jean-François Michaud
I give up. You obviously can't get a clue. Keep at it Jeff, you're
doing a great job!!!! *Thumbs up*
Jean-Francois Michaud
jmdra...@yahoo.com
Dennis Ruffer wrote:
> I may simply be reluctance on my part, but I'm having a hard time with
> the issue of transporting source code. If I change the colors, or use
> fonts rather than colors, doesn't that become an incompatibility issue?
> I can't see how to avoid having to publish a translation matrix with
> every piece of source code. Perhaps that is why no one is asking. As
> long as everyone uses the same matrix, no translation is required.
You must not understand how ColorForth source works. I gave you
the example of Howard Oakford's DOS based ColorForth source
viewer that allows you to see code in "colorblind" mode. Basically
it takes code that is displayed like this in the ColorForth editor:
<RED>foo </RED> <GREEN> do some stuff ; </GREEN>
And displays it like this:
: foo do some stuff ;
There's no need for any "translation matrix" nonsense. The "color
tokens" are just that. Tokens. They can be interpreted at edit
time to display whatever anyone wants. In the current ColorForth's
it's displayed as color. But if someone wrote their own ColorForth
they could have any other behavior they wanted happen with the
same set of tokens.
> >
> > Anyway, I was curious as to how colorforth would look to someone
> > with colorblindness. I realize there are different levels of
> > colorblindness,
> > but in the most common level people can still perceive some color.
> > There is a website that simulates this. I tested it out for a large
> > sample of ColorForth source.
> >
> > http://vischeck.homeip.net/uploads/115108544824767/
> >
> > Even with this color reduction it's possible for me to distinguish
> > the requisit colors. "Red" defined words show up as dark brown.
> > "Green" compiled words show up as light brown. "Yellow"
> > immediate words are yellow. "Magenta" variables are dark
> > blue. "Cyan" compiled macros are light blue. "White" comments
> > are white. It probably wouldn't be too difficult to "tweak"
> > ColorForth to have different colors that constrasted better
> > for different people.
>
> It's really hard to explain what I see, but the technical reality is
> that the distinction between red and green is missing. Picture red
> apples on an apple tree. I can't unless I am close enough to see the
> shape of the apples. That list of source code gets progressively
> harder and harder for me to see the color differences.
I don't think it's "hard to explain" at all. The weblink I gave
simulated exactly what you're describing. It might be a little
different for you looking at it, because that page already did
a "color reduction", so you, a colorblind person, would be
looking at a page already "reduced". Anyway, the point is
there's still color distinctions for most versions of color
blindness. And there are "hints" that can help you correctly
"guess" the color. For instance RED words are ALWAYS
at the beginning of a line. If you have two red words in a
row, they are on seperate lines. Also you apparently missed
(or ignored) what I said about "tweaking" colors. If the
magenta variables are easier to distiguish there's no real
reason why one ColorForth couldn't be "tweaked" to swap
magenta for red. After all ColorForth code typically spends
much more time defining words than it does defining variables.
And a variable in ColorForth source can be identified without
color due to the fact that it's always followed by its value
(a number).
> However, it's deeper than just a color issue. Color has actually lost
> a lot of its significance to me. I can't rely on it, so I have learned
> to not depend on it. I find ColorForth source to be distracting, and
> eventually, annoying. I haven't had to read a lot of it yet, and in
> time, the physical discomfort might diminish, but so far, it has just
> discourage my participation. Is it valuable enough to discourage 7% of
> the male population who are color blind?
Sorry, but that sounds like a color issue to me.
> My cousin is actually black
> and white color blind which would force him to use fonts, I guess.
And you make it sound like using fonts is a bad thing.
> I recently found a wonderful application that has solved some of my
> problem. It's called EyePilot from Tenebraex Corp.
> (http://www.colorhelper.com/). With just a little bit of testing just
> now, I see it's real hard to click on the letters. If the background
> also carried a color signature, it might actually be useful with
> ColorForth.
>
> I guess it's just another thing I have to get used to and maybe
> something I need to figure out how to influence.
The source code is freely available. Influence away.
> > As for having a "Mac" There's "Wine" which would let you
> > run the Windows version of ColorForth. Also Mac's are
> > about to run QEMU which would let you run a version
> > of "native" ColorForth.
>
> I have a G4 and VPC (see my reply to Jeff), so I'm not sure these
> alternatives will help much.
Wine will run on a G4. Besides, there are MANY places where
you can find a "throwaway" PC. And if you don't want to bother
asking around for one, I'm sure you can find a PC for < $100
at a thrift shop. If you already have VPC I'm wondering why
you even raised this as an issue. VPC should certainly
run Windows ColorForth.
> > Of course this really has little to do with IntellaSys anyway.
> > The tools they've announced on their website run under
> > GForth (there's a Mac version of that) and SwiftForth
> > (Windows only, but again there's Wine). I'm hopeful
> > that there will be a release of a ColorForth version, but
> > so far nobody has said their definitely would be.
>
> I'm looking forward to see the tools. I was tempted to look at making
> a C version of ColorForth that would compile in OSX, but I just haven't
> gotten around to it yet.
> >
> > Regards,
> >
> > John M. Drake
>
> DaR
If that's what you want to do, go for it. If it's so you can
read ColorForth source without color, there are already
other ways to do that. I mentioned Howerd's program.
There's also a C "colorforth-to-html" program. You
could easily change that program to emit tags other
than color. Or you could download ColorForth HTML
pages and do a global search and replace of "bold"
for "red". Or write your own CSS for ColorForth HTML.
If your trying to learn MISC programming, Jeff's F21
simulators are still available. They run under DOS,
but like I said, you can get a "throwaway" PC.
The ColorForth x18 simulator that's available on
the net is too many generations behind the current
c18 core to be of any more learning benifit than
the F21 sims. And the F21 sims have far more
features. There are better ColorForth x18
simulators than what's on the net, but they've
never been released.
Regards,
John M. Drake
jmdra...@yahoo.com
Dennis Ruffer wrote:
> Not really. I'm pushing portability up to the top priority, so any
> machine specific assembly instructions are out.
So...ummmm...what would be the point of this exercise? Part
of the appeal of ColorForth is that it is close to the "bare metal".
The primitives are actual Pentium macros.
See: http://www.colorforth.com/forth.html
Because of this (and a few other things) you get optimal code
without a complex compiler. If you take ColorForth, take out
the color, take out how it's implemented, take out....what's
really left? The kernel is small enough that it shouldn't be
difficult to re-write it for another processor such as the
PowerPC. If your issue is "C like portablity" than you
have more than just booting up ColorForth to think about.
You'd have to change the compiler as well. Instructions
that are now simple Pentium macros would have to
compile to some "imaginary" virtual machine. Then there
would be the "translation matrix" you opined about in
another post to translate either to a PowerPC or a
Pentium or a ..... Why not just use the oh so simple
instruction set as the "translation matrix"?
> >
> > According to Chuck all a Forth system needs to be a colorforth is for
> > the compiler to recognize what makes the source visually distinctive
> > in the editor as compiler directives.
> >
> > So if your compiler recognizes indendation for instance, that's
> > colorforth. If you put html tags in your souce that your compiler and
> > your editor can read, that's colorforth.
>
> This is going to take a little incubation. It may be that I just can't
> get my head around this tight of a coupling between editor and compiler
> yet, but this makes me think of VBA in Word, without word processing.
> Does that mean colorforth can't exist without the editor? You've
> already said the colors can be represented by fonts, and you say here
> that html tags would work. Can't that be taken even further to the
> point of using any kind of syntax marks, say something like : and ;?
> Doesn't that decouple the editor, or has it now, somehow magically,
> become something other than colorforth?
A) ColorForth still uses ";" but not ":"
B) If you take ColorForth, remove the tokenized source, and put back
in the typical Forth compile words you have machineForth.
MachineForth predates ColorForth by a decade or so. Nothing "magical"
about that.
> I'm probably just going to have to wait to see the tools, because I amy
> be improperly assuming that there is some connection between SEAforth
> and colorforth. If it doesn't, then my mind is wondering aimlessly. ;)
I'm "guessing" that this is why IntellaSys announced that SEAForth
tools would be based on gforth and SwiftForth and didn't even mention
ColorForth. They didn't want people going off on tangents about
not being able to use XYZ computer system and/or problems with
colorblindess.
> > You want source in C. Not a big problem although some words
> > not in the kernel also have assembler definitions now.
>
> By assembler, in this context, do you mean SEAForth instructions?
>
> DaR
Pentium assembler. Why would SEAForth instructions be in a kernel
for something designed to run on a PC?
Regards,
John M. Drake
Albert van der Horst
Jeff Fox <f...@ultratechnology.com> wrote:
>Dennis Ruffer wrote:
>> Although it would go against everything Chuck believes in, a C version
>> of ColorForth would be useful for those of us that don't happen to
>> have, or like (in some cases), PCs. I'm tempted to write it myself,
>> but it would be better if someone, who understands the original issues
>> better than I, did it.
>
>It should be easier to port with only a 1K kernel in assembler and the
>rest in high level. That will help.
>
>According to Chuck all a Forth system needs to be a colorforth is for
>the compiler to recognize what makes the source visually distinctive
>in the editor as compiler directives.
>
>So if your compiler recognizes indendation for instance, that's
>colorforth. If you put html tags in your souce that your compiler and
>your editor can read, that's colorforth.
My (re-assemblable) disassembly of colorforth uses single character
prefixes,
like : for define (red) , ] to compile, ( for comment (white),
] to interpret, # to interpret decimal numbers, ]# to compile
them (oops, that is a two character prefix).
It looks even more weird than either Forth or regular colorforth.
>You want source in C. Not a big problem although some words
>not in the kernel also have assembler definitions now.
>
>> Apology accepted. ;)
>
>Thanks.
>
Groetjes Albert
John Doty
> John Doty wrote:
>
>>And you published a Verilog implementation too? Where is it?
>
>
> Sure a couple, my site, years ealier.
Where? I see links to *other* people's Verilog and VHDL, including
Bernd's, but I can't find anything from you.
>>>I tend to think that he made a copy of a copy and added a
>>>little more in a few extra hours of work. I believe Ting and Rible
>>>published their p16 and sp16 copies before Bernd's b16 copy
>>>but there might have been other copies before Bernd's.
>>
>>Whose Verilog did he copy?
>
>
> Don't know. He might have just made his copy years later without
> directly copying the copies from years earlier. He came so late
> to the party that he could have copied a half dozen different folks.
You accuse him of copying but you can't say who he copied.
>>How many millions of man years of effort do you suppose you've copied?
>
>
> countless, as you point out. Everything is based on the past. But
> fortunately for everyone the patent on the wheel has run out.
Yep. And unless you can show that Bernd infringed or plagiarized, you
have no reason to criticize his use of Forth-based ideas.
>>I've worked on a project like that. But many space projects have
>>demanding budget constraints.
>
>
> Yeah, but space proejcts are one-of and expensive unless you
> get paid a lot less than I expect. Sure there are budget constraints
> but to ordinary taxpayers the budgets are incomprehensibly high.
> To the engineers doing the work they are minimal.
Then why do they *always* overrun? The bigger the project, the bigger
the overrun. Why is there *always* whining that the budget is too tight,
"we could do it right if we had more money", no matter how big the
budget is?
> I know that Intel, and AMD, and Sony, and Fujitsu, and HP, and
> Casio are a few of the companies who don't agree with Bernd
> and you about the use of copiers. But I will avoid that topic. ;-)
Depends. Those guys copy any thing they think they can get away with.
Dennis Ruffer
>
> Dennis Ruffer wrote:
>
>> Not really. I'm pushing portability up to the top priority, so any
>> machine specific assembly instructions are out.
>
> So...ummmm...what would be the point of this exercise?
Perhaps the best answer, without going into all the other comments, is
that there is no point at the moment. The only perception of something
missing is my own ignorance. I'll wait to see the tools.
DaR
Jeff Fox
> > I know that Intel, and AMD, and Sony, and Fujitsu, and HP, and
> > Casio are a few of the companies who don't agree with Bernd
> > and you about the use of copiers. But I will avoid that topic. ;-)
>
> Depends. Those guys copy any thing they think they can get away with.
That was my point.
Clever Monkey
> Dennis Ruffer wrote:
>> useful, but then another day brings more. I'm beginning to wonder why
>> IntellaSys is letting Jeff be their representative here.
>
> My hands have been tied in certain ways. And that has allowed some
> of the haters occasional access to my back.
>
Cripes, I am starting to /hate/ this co-opted term from youth culture.
Let's stick to using the term "haters" in our poems and raps, please.
Few of us here grew up in the 'hood. Please save these sorts of poetics
for your first album.
> But they have not told me at work that I am not free to respond to
> personal insults and attacks if I choose to do so.
>
Dude. Seriously. If I didn't know better I would mark you as a troll.
This whole "everyone hates me, I better go eat worms" thing is so old.
Forums like this are fraught with misunderstandings, long histories
and arguments, and sometimes decent discourse. Just run with it.
> People ask questions here. If I don't answer them I know people
> will guess wrong and things will spin off like they have in the past.
> And I know that there is a list of people, who greatly outnumber
> me, who want to spin it off into personal attacks and stories
> about how they really invented Forth or Forth chips etc.
>
I see no evidence for this in this particular context. People,
especially hobbyists and engineers, speculate because this is a normal
and healthy thing for hobbyists and engineers to do. It's fun, harms no
one and is part of the iterative, investigative process. Dude, it's
what we *do*. No working engineer I know actually, you know, makes
critical decisions based on speculation. There is a world of difference
between adding fudge to a schedule while specifications are firming up
and basing a project on preliminary hints.
No engineer will be employed for long doing the latter. People that can
do the former in any sort of reasonable way should be applauded for
their experience and imagination.
Please re-read John Passaniti's latest remarks. He hits the old nail
right on the head.
If it really bothers you so much to see speculation on this product then
stay silent about it. Refrain from dropping any hints, no matter how
much it may keep interest going. Asking hobbyists and engineers not to
hash out possibilities based on pure speculation is like asking them to
stop working. Open forums like this are like oxygen for these folks.
It's unfair of you to even suggest people refrain from talking about
things that seem to originate from the very company you represent. No
one here who is participating has signed an NDA or has a vested interest
like you have. Just take a deep breath and let it go!
If, once the real docs have been released, you see someone here
spreading FUD then choose your battles appropriately. For now, your
constant tilting at these windmills is even tiring me out. How is this
helping the company you represent, exactly?
You cannot control USENET and you cannot control c.l.f. Why carry that
weight around? If your job is to promote this product, then do that.
Telling people to stop speculating on the exact nature of some aspects
of this product is not helping, and actually insults the many years of
experience this newsgroup represents.
Of course, the joke is on me if the whole reason for this thread was to
keep interest in this product high, but just in a weird sort of way.
Brad Eckert
Jerry Avins
> Give this man a banana!
Instead of a box of Snickers?
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
roger...@gmail.com
stumbled upon this thread while looking for the SeaForth instruction
set.
I am utterly disgusted by the behavior of all of you towards Mr. Jeff
Fox, your total irreverance towards all that he and Intellasys is
doing, and your useless speculations. This isn't productive. I feel
sorry for Jeff for having to defend himself so violently but I can
relate to the kind of onslaught that common programmers can pose to
real Forth programmers.
Anyway it doesn't matter. I've gotten the picture (correct me if I'm
wrong, Jeff) from reading the first 1/2 of the thread that Jeff is
talking around the assumption that we all should have realized by now
that documentation CAN'T be given right now because the system is not
finished. In the traditional form, the Forth/hardware combination is
constantly evolving til the very end. You never know what kind of
kinks come up that can be worked out or lead to new innovations.
The most interesting part about the SeaForth chip, to me, is not its
silly old instruction set, all of that is relatively superficial, and i
feel, has a very specific purpose of illustrating what a machine forth
32-instruction set would look like for a parallel processor. I saw it,
and I was a little intrigued, but I moved on. If you're working on
anything worthwhile, you wouldn't CARE what p!+ is really for, because
you are NOT IN THAT WORLD YET. Personally, I sought the instruction
set out because I just recently considered caching the top of my return
stack in a register and I thought "what kinds of new instructions could
take advantage of this?" and maybe you can put together the rest. The
point was, what is already being done in a context similar to mine,
that I can leverage? And I didn't find anything so I will probably
just have to find out through my work if the register will be used in
some new instructions.
I think that speculation is fun, a great social activity. Great for
coming up with your own ideas - in your own sphere. There is a
horrible illusion we have today that the world has vaguely been united
by the internet. And over the course of a couple decades - neat! But
why do you want to speculate about something that is not up to you to
ever decide? It only colors your opinion once you see the final thing,
giving you false reference for judgements. SeaForth is not so
important that everyone absolutely has to know what the instruction
set is before it is even available. What are you goign to do, write
PROGRAMS for it before you even have one??
Keith
"IntellaSys plans to provide a complete set of tools based on its T18
compiler/simulator beginning June 30, 2006. Tools will be free of
charge and available for download here to anyone that has registered on
the site."
Given the above announcement, that's still on the Intellasys website,
and other recent publications there was probably some anticipation of
playing with the simulated processor.
jmdra...@yahoo.com
roger...@gmail.com wrote:
> This is a message from a lone wandering Forth programmer who just
> stumbled upon this thread while looking for the SeaForth instruction
> set.
>
> I am utterly disgusted by the behavior of all of you towards Mr. Jeff
> Fox, your total irreverance towards all that he and Intellasys is
> doing, and your useless speculations. This isn't productive. I feel
> sorry for Jeff for having to defend himself so violently but I can
> relate to the kind of onslaught that common programmers can pose to
> real Forth programmers.
You know, while I'm sure your intentions are honorable, you're doing
the exact same thing you accuse others of, namely "useless
speculation. Case in point:
> Anyway it doesn't matter. I've gotten the picture (correct me if I'm
> wrong, Jeff) from reading the first 1/2 of the thread that Jeff is
> talking around the assumption that we all should have realized by now
> that documentation CAN'T be given right now because the system is not
> finished. In the traditional form, the Forth/hardware combination is
> constantly evolving til the very end. You never know what kind of
> kinks come up that can be worked out or lead to new innovations.
If the system is NOT finished then IntellaSys should have been more
coy about the info they DID release. And I don't know why they gave
themselves the "June 30th" date (which has passed) for releasing a
tools they say they are already using for an unfinished system.
Besides, what do you mean by "finished"? As Jeff has pointed out
there are various versions of the chip. One version has been used
to build a working wireless home theatre system (unless I'm
reading that documentation wrong). So it's "finished". But that
doesn't mean other versions can't/won't be released.
> The most interesting part about the SeaForth chip, to me, is not its
> silly old instruction set, all of that is relatively superficial, and i
> feel, has a very specific purpose of illustrating what a machine forth
> 32-instruction set would look like for a parallel processor.
Huh? You make it sound like this is just some "theoretical"
instruction set. If that was all that was going on, the old c18
documentation served that purpose.
See:
http://dec.bournemouth.ac.uk/forth/euro/ef01/moore01a.pdf
The SEAForth instruction set is supposed to represent what has
been recently going on. I don't know how you can call that
"superficial".
> I saw it,
> and I was a little intrigued, but I moved on. If you're working on
> anything worthwhile, you wouldn't CARE what p!+ is really for, because
> you are NOT IN THAT WORLD YET.
Obvious guy says "maybe you're considering using the SEAForth
chip when it comes out?" I don't know what you call "worthwhile"
but I think it's very worthwhile for someone to look at the instruction
set of a chip that's supposed to be released soon in anticipation of
possibly using it. As Jeff said himself THEY WERE EXPECTING
COMMENTS!
> Personally, I sought the instruction
> set out because I just recently considered caching the top of my return
> stack in a register and I thought "what kinds of new instructions could
> take advantage of this?" and maybe you can put together the rest. The
> point was, what is already being done in a context similar to mine,
> that I can leverage? And I didn't find anything so I will probably
> just have to find out through my work if the register will be used in
> some new instructions.
Ah. So "worthwhile" for you is designing your own chip. That's fine.
But some people are interesting in using the SEAForth chips when
they come out. I see nothing wrong with that. I also see nothing
wrong with asking questions that are OBVIOUSLY prompted by
information IntellaSys has released. And note, this thread had
all but died until your last message. Jeff told everyone "Wait a
week or so." So everybody has basically been waiting.
> I think that speculation is fun, a great social activity. Great for
> coming up with your own ideas - in your own sphere. There is a
> horrible illusion we have today that the world has vaguely been united
> by the internet. And over the course of a couple decades - neat! But
> why do you want to speculate about something that is not up to you to
> ever decide?
What does that have to do with anything?
> It only colors your opinion once you see the final thing,
> giving you false reference for judgements.
And when the "final thing" comes out, people aren't intelligent enough
to read the lastest documentation? Don't insult everyone's
intelligence.
> SeaForth is not so
> important that everyone absolutely has to know what the instruction
> set is before it is even available. What are you goign to do, write
> PROGRAMS for it before you even have one??
Again, IntellaSys RELEASED the instruction set. So why are you
jumping on everyone for asking questions about something that
has been RELEASED? When they released it they knew people
would ask questions and make comments. The obviously WANTED
people to do SOME (though not all) of what's been happening in
this thread. And then the thread died. I fail to see the point of
you bringing it back now just to tell people to stop doing what
they had already stopped doing.
Regards,
John M. Drake
rickman
> The new SEAforth instruction set has been published by Intellasys. It
> contains 32 opcodes although only 30 are described until now. Most of
> them are pretty obvious but some are not:
>
> Can anybody help me understand the proper way to make use of the "!p+"
> opcode?
>
> How does the multiply step work? The core promises to produce 36 bit
> results. Where will the result occur?
>
> Are multiply-accumulate operations synthesized by fast c18 instructions
> only? Is there a different way like memory mapped hardware?
I am curious about the JUMP instructions. They can reside in slots 0
to 2 and use the entire remaining word as the offset/address. So what
happens if the remaining part of the word is not large enough for the
offset or address? I assume the remainder of the word must be filled
with NOPs and the JUMP placed in a new word?
Likewise, the @p+ instruction would seem to also need to ignore the
remainder of the 18 bit instruction word, but I guess that depends.
The processor may be able to continue executing the rest of the current
word before it does a fetch on the IP.
Depending on exactly how these instructions work, they would seem to
mitigate some of the efficiency of the small instruction size.
Have any details been released?
Jerry Avins
...
> The most interesting part about the SeaForth chip, to me, is not its
> silly old instruction set, all of that is relatively superficial, and i
> feel, has a very specific purpose of illustrating what a machine forth
> 32-instruction set would look like for a parallel processor.
The arrangement of pedals, levers, and knobs in a car is not an
illustration of anything: those are the means by which it is controlled.
The instruction set of a processor is hardly one of its superficial
aspects.
> I saw it,
> and I was a little intrigued, but I moved on. If you're working on
> anything worthwhile, you wouldn't CARE what p!+ is really for, because
> you are NOT IN THAT WORLD YET. Personally, I sought the instruction
> set out because I just recently considered caching the top of my return
> stack in a register and I thought "what kinds of new instructions could
> take advantage of this?" and maybe you can put together the rest. The
> point was, what is already being done in a context similar to mine,
> that I can leverage? And I didn't find anything so I will probably
> just have to find out through my work if the register will be used in
> some new instructions.
I guess you just will. Maybe you didn't speculate enough.
> I think that speculation is fun, a great social activity. ... But
> why do you want to speculate about something that is not up to you to
> ever decide? ...
Many of us speculate about how the world might have formed or how life
arose. Some speculate about the origins of ancient civilizations and the
existence of gods. Is that to be decried because nothing can be done
about it?
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Stephen J. Bevan
> SeaForth is not so
> important that everyone absolutely has to know what the instruction
> set is before it is even available. What are you goign to do, write
> PROGRAMS for it before you even have one??
In a word: yes. I've written code for and simulators/emulators for
chips I've never had physical access to.
jacko
roger...@gmail.com
Your reply was the most interesting - I wasn't expecting any response
at all! - but I would like to rebut a few points you made and then
respond.
> You know, while I'm sure your intentions are honorable, you're doing
> the exact same thing you accuse others of, namely "useless
> speculation.
> If the system is NOT finished then IntellaSys should have been more
> coy about the info they DID release. And I don't know why they gave
> themselves the "June 30th" date (which has passed) for releasing a
> tools they say they are already using for an unfinished system.
> Besides, what do you mean by "finished"? As Jeff has pointed out
> there are various versions of the chip. One version has been used
> to build a working wireless home theatre system (unless I'm
> reading that documentation wrong). So it's "finished". But that
> doesn't mean other versions can't/won't be released.
As indicated by Jeff here on June 15, on the colorforth mailing list,
the instruction set was not yet finalized:
"> Article about IntellaSys:
>
> Cores That Share Chores
> http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=12692
>
> instruction set list
> http://www.elecdesign.com/Files/29/12692/Figure_02.jpg
it takes a very long time for things to go to press through
marketing from engineering so consider them preliminary
next should say decrement R to -1 then drop R, not decrement to 0
-if should say jns jump if no sign, ie. msb of T is false
- should say ones complement of T not A, -1 XOR, NOT
drop; drop
It is preliminary, but not quite as preliminary as Chuck's
paper from 2001."
I don't know EXACTLY why Jeff would have gotten so irrate just by
everyone's nudging for more information, if it was not so simple to
just tell what it was, or the direction it was headed in. Still
though, it's almost too obvious to assume that it is not as simple as
saying "it's this way, not that way - period." He may give information
that would only need to be revised later, and almost inevitably refuted
by people who are familiar only with the old information, or worse, the
guesses that people reasoned must be true. It's so common for Forth
vocabularies to go through these kinds of changes, that details like
the exact behaviors of instructions become just what I said -
superficial.
I still think Jeff made an important point. What some have tended to
do is post speculations with varying degrees of pretentious authority,
creating a kind of thick "cloud" of misinformation. This is not
important to the posters, or to the regular readers, but it is
important to consider for newcomers. Furthermore it makes the truth
harder to seperate from non-truth, when attempting to confirm
something. The quality of programming communities is hurt by this
pattern.
> The SEAForth instruction set is supposed to represent what has
> been recently going on. I don't know how you can call that
> "superficial".
I think that a tool is not as important as the things you can do with
it. Instructions are a means to an end, but, since they can change
with the evolution of a project, they shouldn't be "what you're trying
to do." That's why I said "relatively" superficial. There's nothing
wrong with wanting to know, but I think there's a cause for distress
when you rely on details that may or may not be true to help them make
practical decisions. I have been burned many times by this mistake.
> Obvious guy says "maybe you're considering using the SEAForth
> chip when it comes out?" I don't know what you call "worthwhile"
> but I think it's very worthwhile for someone to look at the instruction
> set of a chip that's supposed to be released soon in anticipation of
> possibly using it. As Jeff said himself THEY WERE EXPECTING
> COMMENTS!
Comments are great. The definition of a comment is roughly "a
statement of one's reaction or opinion." In short, how do you feel.
What's been going on in this thread, has been a joke... people wanting
to know an instruction set months before it's available to them? That
seems like some really exxagerated anticipation. I once read that in
Forth, you shouldn't be writing pages of code before compiling
anything.
> Ah. So "worthwhile" for you is designing your own chip. That's fine.
> But some people are interesting in using the SEAForth chips when
> they come out. I see nothing wrong with that. I also see nothing
> wrong with asking questions that are OBVIOUSLY prompted by
> information IntellaSys has released. And note, this thread had
> all but died until your last message. Jeff told everyone "Wait a
> week or so." So everybody has basically been waiting.
I am not designing my own chip. I'm working on a Forth system in
software. I'm also extremely interested in hopefully programming the
SEAForth chip one day.
>> (observation about the internet deleted for length)
> What does that have to do with anything?
I'll try to clarify the point I was trying to make. Speculation is
what you need to do with yourself or with a team to form a view on
things, to have a foundation of belief. Contrast with being able to
know the exact truth, rather than a subjective viewpoint. You can't
have "beliefs" about the truth - the truth is the truth. When a person
who creates a box tells you for your edification that the inside of a
black box is red, to accept that as true, you can't go off and say
"well it's probably not red, but blue, because of x y and z". After
the documentation or verbal information is out from an authority on the
subject, if he didn't make a mistake, that's just the truth. There are
other more important things to form subjective viewpoints on, like the
economy, the environment, the world, the meaning of life, etc. etc.
Speculation about a technical subject has less than no purpose in an
online forum because it leads to something that some people consider
the dark side of the internet: clog. The reasoning behind people
speculating online, I think has to do with loneliness and a need to
believe that everyone is on their side. Of course it all gets mixed up
with the really useful information. In the end, the internet becomes a
big circus, which is why I tend to stay away and try to find out things
for myself instead of relying on other people...
>
> > It only colors your opinion once you see the final thing,
> > giving you false reference for judgements.
>
> And when the "final thing" comes out, people aren't intelligent enough
> to read the lastest documentation? Don't insult everyone's
> intelligence.
You seem to have missed the key word in that last statement ..
"judgements" ... documentation gives you information, but your
judgement of a thing has nothing to do with documentation, and
everything to do with your goals and values.
> Again, IntellaSys RELEASED the instruction set. So why are you
> jumping on everyone for asking questions about something that
> has been RELEASED? When they released it they knew people
> would ask questions and make comments. The obviously WANTED
> people to do SOME (though not all) of what's been happening in
> this thread. And then the thread died. I fail to see the point of
> you bringing it back now just to tell people to stop doing what
> they had already stopped doing.
I don't think Intellasys wanted to see a flame war.
The point was not to get anyone to do anything. It was to express my
reaction and pointing out the things that I thought were important. I
have no interest in getting anyone to do anything, I'm fine enough
controlling what I can myself do.
Only the best programmers will make good use of SEAForth. Everyone
else will apply questionable versions of techniques that already exist.
In taking such an early jump on the process what will you do when you
have the chip and things aren't what you were expecting the whole time?
Thanks for the regards.
Roger
John Passaniti
> I still think Jeff made an important point. What some have tended to
> do is post speculations with varying degrees of pretentious authority,
> creating a kind of thick "cloud" of misinformation.
Name these people. I can't think of *anyone* who would qualify, and
*again*, I struggle to think of what kind of people would take the word
of people who are not connected with IntellaSys as gospel truth.
jmdra...@yahoo.com
roger...@gmail.com wrote:
> John,
>
> Your reply was the most interesting - I wasn't expecting any response
> at all! - but I would like to rebut a few points you made and then
> respond.
>
> > You know, while I'm sure your intentions are honorable, you're doing
> > the exact same thing you accuse others of, namely "useless
> > speculation.
>
> > If the system is NOT finished then IntellaSys should have been more
> > coy about the info they DID release. And I don't know why they gave
> > themselves the "June 30th" date (which has passed) for releasing a
> > tools they say they are already using for an unfinished system.
> > Besides, what do you mean by "finished"? As Jeff has pointed out
> > there are various versions of the chip. One version has been used
> > to build a working wireless home theatre system (unless I'm
> > reading that documentation wrong). So it's "finished". But that
> > doesn't mean other versions can't/won't be released.
>
> As indicated by Jeff here on June 15, on the colorforth mailing list,
> the instruction set was not yet finalized:
Hello Roger. As you know I read the colorForth mailing list. As
you know this was in response to something I posted. So I'm
aware of what Jeff wrote, but I take a VERY different interpretation.
It depends on what you mean by "final". They're CONTINUALLY
tweaking the chip design. (Everybody does that. When Intel
releases the "final" version of the Pentium X they are working
on Pentium X+1.) Now, they produced a version that
worked well for a wireless home theatre system. What happens a
year from now if they get a request from someone to build
a chip for digital camcorder? After doing lots of profiling they
might decide to change something. So what?
The point is, if they made a June 30th target release date then
the design must be stable though it may never be "final". By
"stable" I mean the actual instruction set used in a real chip.
> "> Article about IntellaSys:
> >
> > Cores That Share Chores
> > http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=12692
> >
> > instruction set list
> > http://www.elecdesign.com/Files/29/12692/Figure_02.jpg
>
> it takes a very long time for things to go to press through
> marketing from engineering so consider them preliminary
>
> next should say decrement R to -1 then drop R, not decrement to 0
> -if should say jns jump if no sign, ie. msb of T is false
> - should say ones complement of T not A, -1 XOR, NOT
> drop; drop
>
> It is preliminary, but not quite as preliminary as Chuck's
> paper from 2001."
Right. Jeff corrected a few errors in the paper. But note, these
errors in the paper released by IntellaSys and NOT changes
in the design. If you go back to the 2001 paper you will see
that:
-if says jump to then if T17 is zero
and
- says ones compliment of T
These corrections had nothing to do with the design not
being "final". (Unless they went from a 2001 design to
something that didn't make sense then back to the 2001
design.)
Don't take my word for it. Here's the 2001 paper.
http://dec.bournemouth.ac.uk/forth/euro/ef01/moore01a.pdf
Be careful reading it though if you're one of those people
that can't understand things change over time. ;)
> I don't know EXACTLY why Jeff would have gotten so irrate just by
> everyone's nudging for more information, if it was not so simple to
> just tell what it was, or the direction it was headed in.
Gee. He didn't at all seem irate on the ColorForth mailing list.
In fact he volunteered this information without being asked.
I have been experimenting with a version of the OLD x18
compiler/simulator and Jeff volunteered (a little) info about
what's going on with the new one. And I guess that's my
overall point. The folks at IntellaSys have been the ones
INITIATING the conversation. Nobody sat around and
dreamed up some "theoritical" SEAForth instruction set.
And when Jeff said "I can't say anymore" most of us were
like "Fine. Then don't. We'll wait."
Now as to why Jeff gets irate HERE he can best answer
that. But I suspect it has something to do with the
strange turn threads seem to take at c.l.f. For instance
Bernd's (tounge in cheek I hope) assertion that he's
b16 inspired part of the design for the updated c18.
Stuff like that gets under Jeff's skin. So maybe early
on in such threads he sees a familair pattern about
to emerge. I don't know. Like I said, he could best
answer that.
> Still
> though, it's almost too obvious to assume that it is not as simple as
> saying "it's this way, not that way - period." He may give information
> that would only need to be revised later, and almost inevitably refuted
> by people who are familiar only with the old information, or worse, the
> guesses that people reasoned must be true.
Ummm...So WHAT? Most people are intelligent
enough to realize that if someone says "we made
this change when we went from version 1.0 to
version 1.1" that a change was actually made. And
as for the guesses, is it better for someone to guess
something in their mind and have a wrong assumption,
or to ask a question and get an answer? I think the latter.
In fact, Jeff has OFTEN said that if you want to
understand what Chuck is doing, go back and
look at the old stuff, then follow the changes.
Let's take a specific example. When someone
asked about how the "+*" instruction worked, I
said "like in the F21". Well I was partially right.
I didn't know that the instruction had been optimized
to not need a separate 2/ instruction. But, in
general, the instruction does work in the same
way. Did I insist "it's this way and not that way
- period"? Of course not! Neither did anyone
else. Would I have been better off "secretly"
thinking I knew exactly how it worked based off
of the old documentation? Making a statement
on a public forum and getting that statement
corrected helped me learn and I'm actually thankful
for that.
> It's so common for Forth
> vocabularies to go through these kinds of changes, that details like
> the exact behaviors of instructions become just what I said -
> superficial.
We're not talking about a "Forth vocabulary". We're talking about
an instruction set for a chip. Changing a Forth vocabulary has
zero cost. Changing the instruction set of a chip that has already
gone to fabrication has a LARGE cost. That's not something
that's done "superficially". And like I said, what you thought
was a "change" most likely wasn't a change but was a
documentation error since Jeff's corrections are the same
as the documentation from back in 2001 (and possibly even
before that.)
> I still think Jeff made an important point. What some have tended to
> do is post speculations with varying degrees of pretentious authority,
> creating a kind of thick "cloud" of misinformation.
And your statement that what is obviously a documentation error
was really a "change" in the instruction set doesn't create
misinformation?
> This is not
> important to the posters, or to the regular readers, but it is
> important to consider for newcomers. Furthermore it makes the truth
> harder to seperate from non-truth, when attempting to confirm
> something. The quality of programming communities is hurt by this
> pattern.
If these "newcomers" are so dumb that they can't understand the
statement "we changed this from version 1.0 to 1.1" then they're
hardly worth worrying about.
> Comments are great. The definition of a comment is roughly "a
> statement of one's reaction or opinion." In short, how do you feel.
> What's been going on in this thread, has been a joke... people wanting
> to know an instruction set months before it's available to them?
What I think is a "joke" is your "crusade" against misinformation that
contains your own misinformation.
> I am not designing my own chip. I'm working on a Forth system in
> software. I'm also extremely interested in hopefully programming the
> SEAForth chip one day.
Oh. My mistake. Anyway I was wondering how someone designing
a chip wouldn't understand the difference in cost in changing a Forth
vocabulary and changing an instruction set of a chip that's been
fabricated.
> > And when the "final thing" comes out, people aren't intelligent enough
> > to read the lastest documentation? Don't insult everyone's
> > intelligence.
>
> You seem to have missed the key word in that last statement ..
> "judgements" ... documentation gives you information, but your
> judgement of a thing has nothing to do with documentation, and
> everything to do with your goals and values.
No. I haven't missed any "key words". People aren't so stupid that
they can't change their "judgements" based on new information.
And most people haven't been making any "judgements" about
the chip anyway (except the speculation of who's copying what
design. But that's a seperate issue from the questions
about "p" instructions.)
> > Again, IntellaSys RELEASED the instruction set. So why are you
> > jumping on everyone for asking questions about something that
> > has been RELEASED? When they released it they knew people
> > would ask questions and make comments. The obviously WANTED
> > people to do SOME (though not all) of what's been happening in
> > this thread. And then the thread died. I fail to see the point of
> > you bringing it back now just to tell people to stop doing what
> > they had already stopped doing.
>
> I don't think Intellasys wanted to see a flame war.
So then why are you flaming people? Really, what's the point of
you attacking EVERYONE who participated in the thread? If you
want to flame folks who say "My b16 inspired the SEAForth" that's
one thing. But you're attacking everyone and for no really good
reason. We're doing what IntellaSys expected. You're doing
what you claim they didn't want. Why?
> The point was not to get anyone to do anything. It was to express my
> reaction and pointing out the things that I thought were important. I
> have no interest in getting anyone to do anything, I'm fine enough
> controlling what I can myself do.
So it's fine for you to "express your reaction" and it's wrong for
everyone else to do what IntellaSys expected (and likely wanted)
them to do. Ok.
> Only the best programmers will make good use of SEAForth.
Gee. That's a broad generalization. I'm willing to bet that there
are some great C++ programmers that won't ever even look at
the SEAForth. That doesn't make them "less" of a programmer.
> Everyone
> else will apply questionable versions of techniques that already exist.
> In taking such an early jump on the process what will you do when you
> have the chip and things aren't what you were expecting the whole time?
I'll go back to what Jeff has said multiple times. The best way to
understand what Chuck is doing now is to go back and understand
what he did before. ALL the way back to the Novix, then moving
forward through MuP21, F21 ect. I happen to think Jeff knows
what he's talking about on this. And to me that makes sense.
If you understand, for example, how instructions packed in the
F21 then at least the concept isn't foreign to you when you look
at the c18 like it would be for a Pentium assembly language
programmer. Of course if you're so "stuck" on the F21 that
you can't understand that only certain instructions can go
into slot 3 of the c18 then you have a problem. But so far
I haven't met a single programmer that can't make that kind
of a transition. Now, much of the recent discussion has been
around the "p" instructions. For arguments sake let's assume
they "disappear" in some future version of the SEAForth chip.
Will that mean that someone who understood how the rest of
the chip worked will all of a sudden be "stuck" and unable to
function? I doubt that seriously.
> Thanks for the regards.
>
> Roger
You're welcome.
Regards,
John M. Drake
Bernd Paysan
> If you
> want to flame folks who say "My b16 inspired the SEAForth" that's
> one thing.
What I wanted to say (without tongue in check) is that SEAForth's *+
resembles more my b16's *+ than Chuck's 5 year old c18's *+. Now that can
be independently evolved or not, which I can't proof, nor can Jeff proof
the contrary. I just published my version first, so there is a possibility
of influence in this direction. There are several ways to do a *+ with A+T
register as target and build-in shift, so it's still possible that
SEAForth's *+ is quite different from mine (and I won't say mine is the
best one - it just fit well with the available other parts). Unless it's
published, we can't know. I think it's obvious, because I just wrote the
whole thing down in a few hours + some more hours testing. But that sort of
obviousness doesn't count anything at the patent office - having published
my solution first at least makes me immune from patent-trolling on that
stuff.
What I didn't like was the unfriendly response of Jeff. He acted exacly like
what he hates from other people. He claimed that my b16 was a bloated slow
thing, that I made a "cheap copy", that it was all unreal stuff, that I
don't understand everything but a tiny part of it, and so on. No humor at
all. If this would be a damage to my b16 business model (which it doesn't),
imagine, how much work I would have to spent to undo that damage? On the
other hand: How much damage does a flame-bait like that cause to
Intellasys, and who's doing the damage?
However, I don't believe that my customers read c.l.f, anyway.
Back to the SEAForth chip itself: About 5 years ago, arrays of ALUs were
hyped as "the new thing beyond VLIW and SIMD". Like configurable gates on
an FPGA, people put configurable ALUs on a chip, and let the data flow
through. The critical part here was data propagation (data needs to pass
from one node to the next), reconfiguration (takes time), and flexibility.
I think the SEAForth approach offers solutions to a number of these
problems by executing small programs per node, and not just one operation
per node, and by passing Forthlets between the nodes.
In so far, Jeff is right that my b16 doesn't address all the steps necessary
to put more than one core on a single chip. It's not intented as such, it's
a processor core. I'm still more the ad-hoc type of developper. In my
current digital audio project, I have several DSPs on one chip doing the
filtering stuff necessary for digital audio (e.g. graphic equalizer). These
DSPs are special-purpose DSPs, designed around the FIR filters you use for
this purpose.
Could I use SEAForth for the same purpose? In theory, yes, in practice, 18
bit data width is not enough for a "high end" digital audio system. Yes,
it's perfectly well suited for what humans can hear, but "high end" digital
audio buyer don't work that way. For start, they buy a system that provides
at least 100 times the power that's necessary for their living room. So you
have to anticipate that they will put the speaker to 1% of the designed
power. So you need an incredible amount of headroom just because these
people have too much money and too little common sense. The challange of
high end audio is the damping factor range, and that's where our solution
is extremely good. And we love to get a bit from the excessive money these
people want to spend on audio ;-).
The other reason why not use the SEAForth is price: We want to sell that
chip for a price comparable to SEAForth, and want to make the profit
ourselves.
jmdra...@yahoo.com
Bernd Paysan wrote:
> jmdra...@yahoo.com wrote:
>
> > If you
> > want to flame folks who say "My b16 inspired the SEAForth" that's
> > one thing.
>
> What I wanted to say (without tongue in check) is that SEAForth's *+
> resembles more my b16's *+ than Chuck's 5 year old c18's *+. Now that can
> be independently evolved or not, which I can't proof, nor can Jeff proof
> the contrary. I just published my version first, so there is a possibility
> of influence in this direction. There are several ways to do a *+ with A+T
> register as target and build-in shift, so it's still possible that
> SEAForth's *+ is quite different from mine (and I won't say mine is the
> best one - it just fit well with the available other parts). Unless it's
> published, we can't know. I think it's obvious, because I just wrote the
> whole thing down in a few hours + some more hours testing. But that sort of
> obviousness doesn't count anything at the patent office - having published
> my solution first at least makes me immune from patent-trolling on that
> stuff.
I don't have a dog in that fight and I understood you the first time.
I guess
my point to Roger was that if there was anything in these thread
potentially
problematic for IntellaSys its the potential patent posturing. Again,
I don't
have a dog in those fights, but I can see how they can start. But I
see that
as fundamentally different from someone simply asking "How does the !p+
instruction work" or someone saying "This is my limited understanding
based on the current documentation."
> What I didn't like was the unfriendly response of Jeff. He acted exacly like
> what he hates from other people. He claimed that my b16 was a bloated slow
> thing, that I made a "cheap copy", that it was all unreal stuff, that I
> don't understand everything but a tiny part of it, and so on. No humor at
> all. If this would be a damage to my b16 business model (which it doesn't),
> imagine, how much work I would have to spent to undo that damage? On the
> other hand: How much damage does a flame-bait like that cause to
> Intellasys, and who's doing the damage?
Well I think it's obvious that an FPGA is going to be slower than
custom
silicon. ;-) As for whether or not its a "cheap copy", I haven't
looked close
enough at the b16 to know. I'm not doing that kind of work.
> However, I don't believe that my customers read c.l.f, anyway.
If they did, I hope the have better sense than to take c.l.f.
seriously. I think
that's something you and Jeff can agree on. ;-)
> Back to the SEAForth chip itself: About 5 years ago, arrays of ALUs were
> hyped as "the new thing beyond VLIW and SIMD". Like configurable gates on
> an FPGA, people put configurable ALUs on a chip, and let the data flow
> through. The critical part here was data propagation (data needs to pass
> from one node to the next), reconfiguration (takes time), and flexibility.
> I think the SEAForth approach offers solutions to a number of these
> problems by executing small programs per node, and not just one operation
> per node, and by passing Forthlets between the nodes.
Yeah. I remember reading about ALU arrays a while back.
> In so far, Jeff is right that my b16 doesn't address all the steps necessary
> to put more than one core on a single chip. It's not intented as such, it's
> a processor core. I'm still more the ad-hoc type of developper. In my
> current digital audio project, I have several DSPs on one chip doing the
> filtering stuff necessary for digital audio (e.g. graphic equalizer). These
> DSPs are special-purpose DSPs, designed around the FIR filters you use for
> this purpose.
>
> Could I use SEAForth for the same purpose? In theory, yes, in practice, 18
> bit data width is not enough for a "high end" digital audio system. Yes,
> it's perfectly well suited for what humans can hear, but "high end" digital
> audio buyer don't work that way. For start, they buy a system that provides
> at least 100 times the power that's necessary for their living room. So you
> have to anticipate that they will put the speaker to 1% of the designed
> power. So you need an incredible amount of headroom just because these
> people have too much money and too little common sense. The challange of
> high end audio is the damping factor range, and that's where our solution
> is extremely good. And we love to get a bit from the excessive money these
> people want to spend on audio ;-).
It's funny, but I was listening to NPR the other day and they were
talking
about some fomer "hi fi" fanatics moving in the opposite direction.
The
direction is "i-pod" like setups. Even though the quality is arguably
less,
they like the fact that the equipment is MUCH smaller and there are
less wires. Could this type of person be turned on by a "wireless"
system
even though it "only" had 18 bit quality? Perhaps. Lots of different
stuff
drives markets.
> The other reason why not use the SEAForth is price: We want to sell that
> chip for a price comparable to SEAForth, and want to make the profit
> ourselves.
>
> --
> Bernd Paysan
Well at this point nobody knows the price of the SEAForth chips in
high quantity. (At least I don't).
Regards,
John M. Drake
Jerry Avins
...
> Could I use SEAForth for the same purpose? In theory, yes, in practice, 18
> bit data width is not enough for a "high end" digital audio system. Yes,
> it's perfectly well suited for what humans can hear, but "high end" digital
> audio buyer don't work that way.
...
Not quite accurate. 16 -- even 15 -- bits are plenty for the output, but
processing incurs losses along the way. Word size grows in the innards
of FFTs, and multiplication to change gain involves roundoff. Similar
roundoff losses happen with frequency-response-shaping filters.
Dithering can overcome some of the ill effects, but carrying 25 cits
during computation is a simple way to sidestep many of these issues.
Of course, audio enthusiasts (the kind who use speaker cables as thick
as my thumb) shut their eyes to the limitations of the codecs used in
these products. Take their money and run.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Albert van der Horst
<jmdra...@yahoo.com> wrote:
>
<SNIP>
>
>Now as to why Jeff gets irate HERE he can best answer
>that. But I suspect it has something to do with the
>strange turn threads seem to take at c.l.f. For instance
>Bernd's (tounge in cheek I hope) assertion that he's
>b16 inspired part of the design for the updated c18.
>Stuff like that gets under Jeff's skin. So maybe early
>on in such threads he sees a familair pattern about
>to emerge. I don't know. Like I said, he could best
>answer that.
My working hypothesis is that we will never see a real chip from
Intellasys. It is just a Intellectual Property scam like Patriot. One
million shares per employee and counting.
The idea that you can build a similar chip yourself and
can get actual working examples from the Internet is not
favorable for the hype needed to get speculative investors
in. That's why Jeff gets berserk from Bernds note.
If Bernd would post speculative information about seaforth
in a separate page (marked as such), it would show up
very high in google. "Unfortunately" google is very good in
separating real information from marketing hype.
The secrecy about the instruction set is just a set up to
be able to tell the investors that it's buzzing all over
the Internet. By directing it into a flame war Jeff managed to
get everybody involved, not only the technically savvy.
Yet more messages. No investor is actually checking out what
we are telling here. It is high-profile no-news like
Paris Hilton lost her doggy again.
(Tong in cheek, but not all the way.)
>
>Regards,
>
>John M. Drake