Standing up for DIY.
M Joonas Pihlaja
*Whhoom* Random delurk.
Hello,
I've been wondering about two related issues that pop up in c.l.f
once in a while: Why newbies would write their own Forth
implementation, and why are those that do sighed at? Not
harassed or anything (and I can't point out specific examples
this), but joining the league of DIY Forth hobbyist does seem to
elicit a chorus of 'Not Yet Another Forth System'. Well that's
just the feeling I'm getting.
Yes, I've implemented my own Forth, and no I've not written any
meaningful applications with it. The reasons for doing it are
similar to most quoted on c.l.f., but take them as a data point:
- Learning about threaded languages.
- Learning the word set. I can read the ANS spec or a copy
of Forth Programmer's Handbook until my eyes hurt, but I'm just
not getting the big picture until I prove to myself a need for
all those words. Maybe I need Forth Application Techniques.
- It's easy, at least compared to implementing almost any other
language. This is really important, because writing say a C
compiler from scratch in assembly is just too scary to even
contemplate.
- Compilation / Interpretation state/semantics. I thought I
understood all there is to know about state, but it wasn't
until writing the Forth compiler did the ramifications spell
themselves out. For example, the difference between [COMPILE]
and POSTPONE , and I'm still not sure how FIND should operate
in all circumstances.
Given that Forth is a marginal subculture in the not-overwhelmingly
large subculture of programming, and that *Forth fundamentals are
simple*, I'm not surprised the DIYers are more pronounced.
Hardly anyone is claiming their homemade Forth to be the best
thing ever, and it's not like there's a huge base of excellent
and professional DIY Forth systems being produced every year, so
what exactly is the problem with us DIYers?
Regards,
Joonas Pihlaja
Marcel Hendrix
> - It's easy, at least compared to implementing almost any other language.
> This is really important, because writing say a C compiler from scratch in
> assembly is just too scary to even contemplate.
If writing a Forth compiler in assembly language is not scary enough to you,
you're not doing it right :-)
-marcel
Elizabeth D. Rather
> I've been wondering about two related issues that pop up in c.l.f
> once in a while: Why newbies would write their own Forth
> implementation, and why are those that do sighed at? Not
> harassed or anything (and I can't point out specific examples
> this), but joining the league of DIY Forth hobbyist does seem to
> elicit a chorus of 'Not Yet Another Forth System'. Well that's
> just the feeling I'm getting.
>
> Yes, I've implemented my own Forth, and no I've not written any
> meaningful applications with it. The reasons for doing it are
> similar to most quoted on c.l.f., but take them as a data point:
>
> - Learning about threaded languages.
Ok, have fun, but remember that Forth isn't necessarily a
"threaded language." That was a common implementation
strategy in the 80's, but serious implementaions today
generate optimzed machine code.
> - Learning the word set. I can read the ANS spec or a copy
> of Forth Programmer's Handbook until my eyes hurt, but I'm just
> not getting the big picture until I prove to myself a need for
> all those words. Maybe I need Forth Application Techniques.
It might help ;-)
But the best way to master the command set is to use it to
solve a real-world problem.
> - It's easy, at least compared to implementing almost any other
> language. This is really important, because writing say a C
> compiler from scratch in assembly is just too scary to even
> contemplate.
Many Forths are written in Forth, not assembler. In fact,
I've personally never seen a Forth _not_ written in Forth,
and I've been working with it since 1971. We use existing
Forths to generate a Forth for a new platform. Some Forths
are written in C. These are more portable, but typically slower
than native Forths.
> - Compilation / Interpretation state/semantics. I thought I
> understood all there is to know about state, but it wasn't
> until writing the Forth compiler did the ramifications spell
> themselves out. For example, the difference between [COMPILE]
> and POSTPONE , and I'm still not sure how FIND should operate
> in all circumstances.
It's possible to write excellent Forth applications without using
these concepts. They aren't in the "survival skills" kit, IMO.
> Given that Forth is a marginal subculture in the not-overwhelmingly
> large subculture of programming, and that *Forth fundamentals are
> simple*, I'm not surprised the DIYers are more pronounced.
> Hardly anyone is claiming their homemade Forth to be the best
> thing ever, and it's not like there's a huge base of excellent
> and professional DIY Forth systems being produced every year, so
> what exactly is the problem with us DIYers?
From my perspective as one who is concerned to see the use of
Forth spread among professional programmers, the issue is that
a DIY Forth is fun and educational to the implementor, but the energy
expended is wasted as far as advancing the language is concerned.
Most enthusiasts for languages use their favorite language to
implement some neat algorithm, tool, application, feature, etc.
and then publish it. Such efforts help the enthusiast by providing
a worthwhile and interesting objective, and also advance the
language by enriching the set of things available to the community
of folks working in the language, and therefore make the language
that much more attractive.
Forth was designed to be _used_.
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."
================================================
Jeff Fox
> Why newbies would write their own Forth
> implementation, and why are those that do sighed at?
It is usenet. We have seen examples of newbies writing
their own Forths, asked questions in c.l.f, and then
argued with everyone who tried to help them. Some
people sigh sooner than others. Some get insulting
sooner than others, it is usenet.
Newbies may also not know what buttons each of the
regular c.l.f posters have and often set people off
who have strong opinions. But I also know that some
people doing experiments with Forth are not comfortable
talking about it here because they got the same feeling
that you did that you did.
> - Compilation / Interpretation state/semantics. I thought I
> understood all there is to know about state, but it wasn't
> until writing the Forth compiler did the ramifications spell
> themselves out. For example, the difference between [COMPILE]
> and POSTPONE , and I'm still not sure how FIND should operate
> in all circumstances.
Using something and building it provide different views.
> Hardly anyone is claiming their homemade Forth to be the best
> thing ever, and it's not like there's a huge base of excellent
> and professional DIY Forth systems being produced every year, so
> what exactly is the problem with us DIYers?
Well we have had experience with newbies claiming that everyone
else has it wrong in c.l.f. And since Forth lets one do it
your own way people get attached to their own ways and helpful
people will often insist that you do it their way. Sometimes they
may have a good point too.
Michael L.Gassanenko
>
> - Compilation / Interpretation state/semantics. I thought I
> understood all there is to know about state, but it wasn't
> until writing the Forth compiler did the ramifications spell
> themselves out. For example, the difference between [COMPILE]
> and POSTPONE , and I'm still not sure how FIND should operate
> in all circumstances.
[COMPILE] <name>
compile <name> to the current definition regardless of its immediacy.
It is there for historical reasons.
Once there was COMPILE and [COMPILE] .
: COMPILE R@ @ , R> CELL+ ( compiled token size ) >R ;
: [COMPILE] ' , ; IMMEDIATE
\ assuming : COMPILE, , ;
COMPILE is used as COMPILE <name> within colon definitions.
<name> is compiled as a function, but it really is an argument
for COMPILE. COMPILE fetches it from the threaded code
( R@ @ ) and compiles ( , ) it. Then, it advances ( R> CELL+ >R )
the return address to have the threaded code interpreter
bypass this argument.
Later, people started using subroutine threaded code with inlining.
For example,
: MOD /MOD DROP ;
could be compiled to
CALL ' /MOD \ for /MOD
POP EBX \ for DROP
RET \ for EXIT
The definition for DROP could be
: DROP asm{ POP EBX }asm ; IMMEDIATE
but what would ' DROP EXECUTE do ?
The folks did not stop at that, they continued their way
in this direction. They placed compiling versions of words into
one wordlist and the "normal" version into the another wordlist.
: (colon) changed the search order.... Making implementation
of the the SEARCH EXT wordset not worth the cost.
To make these navorots work, they needed more navorots.
(Navorot -- unnecessary complication, unnecessary functionality).
Finally, the ANS Forth TC had to develop a formulation loyal to
as many implementation techniques as possible.
There were no modern optimizing compilers.
The modern optimizing compilers (SwiftForth and VFX)
cope with such things as return address manipulations with
no problems.
SwiftForth 2.2.2 09Mar2001
ok
: ENTER >R ; ok
: 1-10 1 BEGIN R@ ENTER 1+ DUP 11 = UNTIL DROP R> DROP ; ok
: t 1-10 DUP . ; ok
t 1 2 3 4 5 6 7 8 9 10 ok
MPE VFX Forth for Windows i386+
© MicroProcessor Engineering Ltd, 1998-2001
Version: 3.40.0402
Build date: 14 May 2001
Free dictionary = 7763802 bytes [7581 k]
: ENTER >R ; ok
: 1-10 1 BEGIN R@ ENTER 1+ DUP 11 = UNTIL DROP R> DROP ; ok
: t 1-10 DUP . ; ok
t 1 2 3 4 5 6 7 8 9 10 ok
.S
DATA STACK
empty stack
ok
But at that time it looked (for some persons) like restricting
Forth to a subset is necessary for optimizing compilers.
It was a mistake.
Modern compilers are compatible with threaded code compilers,
and not because everybody agrees that such techniques as
return address manipulations are vital, but because there is
existing code written for threaded code systems.
For example, the assemblers use the technique
2VARIABLE pfa&code
: doasm R> pfa&code 2@ 2SWAP pfa&code 2! >R ;
: addop CREATE , ...
DOES> doasm .... ;
Other programs also could compile data to threaded code.
Now we have:
On VFX:
: mylit R@ @ R> CELL+ >R ; ok
: foo mylit [ 5 , ] . ; ok
foo 5 ok
On SwiftForth:
: mylit R@ @ R> CELL+ >R ; ok
: fo mylit [ 5 , ] . ; ok
fo 5 ok
That is, both compilers can cope with that technique.
------
Well, back to POSTPONE
it is like [COMPILE] for immediate words and like COMPILE
for non-immediate words.
In most cases this is what you need.
[COMPILE] may be used in the following cases:
1) FIG-Forth required : to be immediate, while other standards
require it too be non-immediate. [COMPILE] : should work on both.
2) by using [COMPILE] you can underline that you know that the
word is immediate.
There used to be one more reason that I do not remember.
BTW, it is not even marked obsolete in the standard.
See also http://forth.sourceforge.net/Standard+/POSTPONE/index.html
---
> and I'm still not sure how FIND should operate
> in all circumstances.
IIRC, this has been a subject of an RFI.
For a DIY Forth, just be compatible with Forth-83
http://forth.sourceforge.net/standard/fst83/index.html
and as to FIND,
http://forth.sourceforge.net/standard/fst83/fst83-12.htm#find
(a bit glitchy <a> tag may lead you to the middle of the spec.)
a...@redhat.invalid
> M Joonas Pihlaja wrote:
>> Hardly anyone is claiming their homemade Forth to be the best
>> thing ever, and it's not like there's a huge base of excellent
>> and professional DIY Forth systems being produced every year, so
>> what exactly is the problem with us DIYers?
> Well we have had experience with newbies claiming that everyone
> else has it wrong in c.l.f.
Exactly.
The trouble is that changes to Forth (or, for that matter, to any
programming language) are too weak to use until they have been
hardened in the fire of real applications. Inevitably, most language
changes turn out not to be a good idea; only very occasionally are
they truly useful. So, when a newbie -- particularly one who has
never written a single application in Forth -- extols a language
feature that has never been used and has obvious drawbacks, people get
irritated.
Now, one could argue that experienced programmers should not get
irritated by this...
Andrew.
Jerry Avins
>
...
> From my perspective as one who is concerned to see the use of
> Forth spread among professional programmers, the issue is that
> a DIY Forth is fun and educational to the implementor, but the energy
> expended is wasted as far as advancing the language is concerned.
>
> Most enthusiasts for languages use their favorite language to
> implement some neat algorithm, tool, application, feature, etc.
> and then publish it. Such efforts help the enthusiast by providing
> a worthwhile and interesting objective, and also advance the
> language by enriching the set of things available to the community
> of folks working in the language, and therefore make the language
> that much more attractive.
>
> Forth was designed to be _used_.
>
> 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."
> ================================================
A beginner building a personal Forth is like a dog playing checkers. The
remarkable thing is not that it's done well, but that it can be done at
all. Forth has the remarkable qualities that make this possible.
It's clearly possible to bicycle from San Francisco to Coney Island; I
knew someone who did that in 30 days. That is can be done is no reason
to believe that every amateur cyclist ought to.
I build tools for two reasons: because the tool isn't available in the
form I want, or because it isn't available at a price I'm willing to
pay. The latter reason is largely confined to amateur pursuits. This
applies equally to tools of software or wrought steel.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jerry Avins
>
...
>
> 1) FIG-Forth required : to be immediate, while other standards
> require it too be non-immediate. [COMPILE] : should work on both.
>
I'm confused now. I hope you mean POSTPONE : should work on both.
Gary Chanson
"Jerry Avins" <j...@ieee.org> wrote in message
news:3C03B9E6...@ieee.org...
[COMPILE] : is correct. This is a case were POSTPONE : does not work
correctly. If the object is to create a new defining word which has the
behavior of :, : must execute when the new defining word is executed. It is
irrelevant in this case whether : is immediate or not (and [COMPILE] doesn't
care). It will always be executed when the new defining word is executed.
If you use postpone on an immediate :, it will compile : into the child and
defer execution until the execution of the child word.
This is a perfect example of why I've always considered POSTPONE to be
broken. It's a special case function for building macros and does not
replace [COMPILE] and COMPILE. It also does not remove confusion. Instead,
it generates more.
--
-GJC
-gcha...@shore.net
-War is the last resort of the incompetent.
Neal Bridges
news:yeTM7.9847$0N4.5...@news.shore.net...
[snip]
> > I'm confused now. I hope you mean POSTPONE : should work on both.
> [COMPILE] : is correct. This is a case were POSTPONE : does not work
> correctly. If the object is to create a new defining word which has the
> behavior of :, : must execute when the new defining word is executed. It
is
> irrelevant in this case whether : is immediate or not (and [COMPILE]
doesn't
> care). It will always be executed when the new defining word is executed.
> If you use postpone on an immediate :, it will compile : into the child
and
> defer execution until the execution of the child word.
>
> This is a perfect example of why I've always considered POSTPONE to be
> broken. It's a special case function for building macros and does not
> replace [COMPILE] and COMPILE. It also does not remove confusion.
Instead,
> it generates more.
For the purpose you state, POSTPONE is entirely consistent in an ANS
Forth -- and also unnecessary, as the Standard ':' is not immediate.
: my: : ;
--
Neal Bridges
<http://www.quartus.net> Quartus Handheld Software!
Line Noise
> Yes, I've implemented my own Forth, and no I've not written any
> meaningful applications with it.
> Regards,
>
> Joonas Pihlaja
I think you have ansered your question.
Folks are sadened to see effort being spent on what thay consider a
distraction from the work of extending 4th into "killer apps".
Some folks alsow feel that every variant of 4th makes the thair version
of 4th (or aney version of 4th) less likely to catch-on.
Look for a moment at the Ultamate DIY, Chuck Moor, recently he has made
a chip that runs 25 networked 4th engins at once. He put it into a
mouse, replacing the keybord and the computer, then bilt a GUI and an
app from stratch. Sadly the app was not a killer app.
For $75 I can buy a second-hand PDA that is slightly larger than a
mouse. It would already have a GUI and simmilar app. But it would also
have more, it would have maney industry standerd application and an
upgrede path to more apps as they became avalible.
True thes apps will not have voice and face recognition, thay will not
have high powered nural net simulations that learn to antisipate my
habits, wishes and wims, thay will not have savont level secrotaries and
expert-systims to organise and advise me, nor will thay distinguish
signel from noise or filter _all_ spam. But then niether will the PDA
that has Chuck's chip in it.
Since the only person who is fluent enough to progran chucks chip is
chuck and since he will be too bussy disighning his next chip to spend
time programing said 'killer apps' and to bussy to teach verry bright
kids to program his chip the result is not just "Yet-anouther-4th" but
rather "Yet-anouther-4th/chip that will never be used".
It is the "never be used" part that depresices some folks.
Line Noise
Jeff Fox
> Look for a moment at the Ultamate DIY, Chuck Moor,
> recently he has made a chip that runs 25 networked
> 4th engins at once.
Chuck Moore has created the 25x design in his new CAD
program in his relatively new versio of a language
that he created thirty some years ago, that is DIY.
BUT... 25x has not been fabricated so as long as you
don't refer to actual "chips" yet.
> He put it into a mouse, replacing the keybord and
> the computer, then bilt a GUI and an
> app from stratch. Sadly the app was not a killer app.
I think you got your chips, people, and facts
more than a bit mixed up. Well what else would
we expect from a source named Line Noise.
Just for the record I dropped one of the chips that
Chuck has designed, F21, into a mouse as a demo
of how a total of 600 words of code is enough to
fool most people into thinking it a PC running
windows, but without the PC or windows. That was
a few years ago. Since then I have done a more
serious OS and GUI for the chip, but is about
the same size as that two day demo.
Just for the record that F21 was fabed in .8u
but the fab now offers .18u and one beauty
of Chuck's design methods is that the tiles
scale. So F21e could run at speeds similar
to those predicted for the c18 core in .18u.
Just for the record the chip design was optimized to run
AI, voice and face recognition, provide sub-nanosecond I/O
interface, route gigabit data streams, and to operate as
a node in a scalable multiprocessor. I really should say it
was first optimized to be inexpensive and low-
(electrical)power and then optimized for performance
on the above classes of problems.
Just for the record I did work, as a consultant,
on a PDA using one of Chuck's other chips that
had a color touchscreen, voice recognition, and
video out, but that was seven years ago.
I use my actual name to show that the statements
I make are from personal experience and do not
come from an anonymous source of garbled misinformation.
Gigabytes of actual details are available at my website.
> True thes apps will not have voice and face recognition,
> thay will not have high powered nural net simulations that
> learn to antisipate my habits, wishes and wims,
(and it's a good thing in this case. ;-)
> thay will not have savont level secrotaries and
> expert-systims to organise and advise me, nor will thay
> distinguish signel from noise
Funny considering the source. ;-) People might think
that I am really Line Noise operating as an obvious
schill.
> or filter _all_ spam. But then niether will the PDA
> that has Chuck's chip in it.
Which PDA is it that you are talking about? Chuck must
be involved in a project doing a PDA that I haven't heard
about yet. Maybe it is a secret project that you have
going with Chuck? ;-)
> Since the only person who is fluent enough to progran
> chucks chip is chuck and since he will be too busy
There are of course people who are very familiar with
all of the chips that Chuck has designed, including
the people who own them. Talk about Line Noise!
(it is a better name than big-hairy-spider however,
it provides readers with more warning.)
> disighning his next chip to spend time programing
> said 'killer apps' and to bussy to teach verry bright
> kids to program his chip the result is not just
> "Yet-anouther-4th" but rather "Yet-anouther-4th/chip
> that will never be used".
Chuck has commented that in explaining his approach
to chip design and programming to a wide range of
audiences that the Forth programmers are the most
difficult to reach. They have the most preset
ideas about what Forth is.
I think this is why he said in this years
persentation to FIG that he thinks that the next
generation of Forth should be made more attractive
to a younger audience. (it is easier to learn
it right in the first place than to learn it wrong,
and have to start over.)
> It is the "never be used" part that depresices some folks.
>
> Line Noise
I guess... I lost any coherent meaning in all
the damn line noise or something, oh well, it's
just usenet. ;-)
Jeff Fox
http://www.UltraTechnology.com
Jeff Fox
> This is a perfect example of why I've always considered
> POSTPONE to be broken. It's a special case function for
> building macros and does not replace [COMPILE] and COMPILE.
> It also does not remove confusion. Instead,
> it generates more.
I agree with you completely. (which will probably make
you reconsider your point. ;-)
I was taught never to postpone.
Ed Beroset
>A beginner building a personal Forth is like a dog playing checkers. The
>remarkable thing is not that it's done well, but that it can be done at
>all. Forth has the remarkable qualities that make this possible.
Just to weigh in here, and as one who has solicited (and gratefully
used) advice from c.l.f., I would say that it's a bit different from a
dog playing checkers. It's more like using exclusively hand tools to
create furniture versus using power tools like belt sanders and
planers versus using esoteric and special purpose power tools like
"biscuit cutters" or dovetail routers. (If you don't have any idea
what these are, it's even better because you can appreciate how
foreign a phrase like "The xt table for dealing with control
characters in ACCEPT wasbuilt using the '] ... [' technique," might
seem.)
>I build tools for two reasons: because the tool isn't available in the
>form I want, or because it isn't available at a price I'm willing to
>pay. The latter reason is largely confined to amateur pursuits. This
>applies equally to tools of software or wrought steel.
Au contraire, mon frere! Cost is an issue for commercial pursuits as
well. If I tell my corporate sponsors that I want $50,000 to buy a
commercial Forth implementation and sufficiently train a couple of
people to experiment with a technique that *might* not pay off at all,
I need to have some reason for believing (and therefore a compelling
argument to make) for this expense. It's not a lot of money, granted,
but I'd feel bad about wasting $50K if there were a demonstrably
better use.
One way to gain this justification is to experiment on my own (as an
amateur, if you like) to the point that I feel that the probable
payoff makes a sufficiently compelling story to present. I can do
this with C, C++, XML, Java, and even assembly language, but when I'm
told that I need to buy a commercial compiler to even experiment
reasonably with Forth, I have to weigh that against the various
excellent free offerings in other languages. I have done some
projects that I find valuable using hForth, eforth, and Quartus Forth
(all of which are either free or under $100) and have experimented
with the demo version of SwiftX Forth. I have read the library's copy
of _Starting Forth_, and have purchased (and found valuable) both
_Forth Applications Techniques_ and the _Forth Programmer's Handbook_.
Still, I can't in good conscience recommend Forth for use in my
embedded environment because:
1. I have no data to suggest that Forth is cost effective over C or
assembly
2. I have no data to suggest that Forth is time effective in
generating real world code for embedded systems versus C or assembly.
Note that I'm not saying that those things aren't true, but that I
don't have reproduceable, objective data to back up those claims.
Further, I am somewhat inhibited from checking those assertions
independently unless I pay money for a commercial implementation and,
more importantly, sink significant time into learning how to use it.
I don't have an easy solution for this, but I thought it might be
informative to let y'all know how an "outsider" might view the
prospect of potentially using Forth in a commercial application, and
to offer some speculation on why DIY implementers aren't necessarily
college students with way too much time on their hands.
Ed
Jerry Avins
I hope you're missing my point. If not, you're ignoring it while
pretending to address it, and that seems unlikely. Comments are
interspersed below.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Ed Beroset wrote:
>
> Jerry Avins <j...@ieee.org> wrote:
>
> >A beginner building a personal Forth is like a dog playing checkers. The
> >remarkable thing is not that it's done well, but that it can be done at
> >all. Forth has the remarkable qualities that make this possible.
>
> Just to weigh in here, and as one who has solicited (and gratefully
> used) advice from c.l.f., I would say that it's a bit different from a
> dog playing checkers. It's more like using exclusively hand tools to
> create furniture versus using power tools like belt sanders and
> planers versus using esoteric and special purpose power tools like
> "biscuit cutters" or dovetail routers. (If you don't have any idea
> what these are, it's even better because you can appreciate how
> foreign a phrase like "The xt table for dealing with control
> characters in ACCEPT was built using the '] ... [' technique," might
> seem.)
You probably know that '[' turns of the compiler and ']' turns it on. So
we can at least guess what the technique involves. I suspect it's
something that one needs to know in order to write a good compiler, and
for very little else.
>
> >I build tools for two reasons: because the tool isn't available in the
> >form I want, or because it isn't available at a price I'm willing to
> >pay. The latter reason is largely confined to amateur pursuits. This
> >applies equally to tools of software or wrought steel.
>
> Au contraire, mon frere! Cost is an issue for commercial pursuits as
> well. If I tell my corporate sponsors that I want $50,000 to buy a
> commercial Forth implementation and sufficiently train a couple of
> people to experiment with a technique that *might* not pay off at all,
> I need to have some reason for believing (and therefore a compelling
> argument to make) for this expense. It's not a lot of money, granted,
> but I'd feel bad about wasting $50K if there were a demonstrably
> better use.
You can buy a compiler and training for a lot less than that. To write a
decent compiler at a decent salary will cost far more than the cost of
any commercial one. If you can live with the license issues, there are
free Forths already written. For developing even a single a product, the
support alone is worth the cost of a commercial Forth.
>
> One way to gain this justification is to experiment on my own (as an
> amateur, if you like) to the point that I feel that the probable
> payoff makes a sufficiently compelling story to present. I can do
> this with C, C++, XML, Java, and even assembly language, but when I'm
> told that I need to buy a commercial compiler to even experiment
> reasonably with Forth, I have to weigh that against the various
> excellent free offerings in other languages.
What about the excellent free Forth offerings? We were discussing
writing one's own compiler, not the need to buy. Would you set out to
learn "C, C++, XML, Java" by assuming that it would be beneficial if
your first project were a compiler so that you "know the system"? Only
Forth makes that possible; you seem to equate "possible" with
"desirable".
> I have done some
> projects that I find valuable using hForth, eforth, and Quartus Forth
> (all of which are either free or under $100) and have experimented
> with the demo version of SwiftX Forth. I have read the library's copy
> of _Starting Forth_, and have purchased (and found valuable) both
> _Forth Applications Techniques_ and the _Forth Programmer's Handbook_.
> Still, I can't in good conscience recommend Forth for use in my
> embedded environment because:
> 1. I have no data to suggest that Forth is cost effective over C or
> assembly
> 2. I have no data to suggest that Forth is time effective in
> generating real world code for embedded systems versus C or assembly.
>
> Note that I'm not saying that those things aren't true, but that I
> don't have reproduceable, objective data to back up those claims.
> Further, I am somewhat inhibited from checking those assertions
> independently unless I pay money for a commercial implementation and,
> more importantly, sink significant time into learning how to use it.
>
> I don't have an easy solution for this, but I thought it might be
> informative to let y'all know how an "outsider" might view the
> prospect of potentially using Forth in a commercial application, and
> to offer some speculation on why DIY implementers aren't necessarily
> college students with way too much time on their hands.
You can get a free commercial implementation of Swiftforth and VFX that
don't restrict how you can use them for learning, but these are Windows
GUI oriented, not suitable for embedded work. I don't know where you can
get a demo version of a cross compiler, or even how such a thing would
be possible. You can buy small boards programmable in Forth and
eminently suited to, and in use for, embedded work. Is $80 too much to
spend for working hardware with Forth in ROM?
>
> Ed
Gary Chanson
"Neal Bridges" <nbri...@interlog.com> wrote in message
news:DdWM7.30588$2i.12...@news3.rdc1.on.home.com...
>
> For the purpose you state, POSTPONE is entirely consistent in an ANS
> Forth -- and also unnecessary, as the Standard ':' is not immediate.
>
> : my: : ;
Ok. That just transfers the blame to ANS for such a requirement. If I
can't implement an immediate :, I consider it broken.
Gary Chanson
"Darin Johnson" <da...@usa.net> wrote in message
news:cu1vgfv...@thatch.nwr...
>
> As for confusing, if you look at the ANS descriptions, POSTPONE has an
> extremely simple definition, whereas [COMPILE] is the confusing one.
> Ie, POSTPONE always appends the compilation semantics of the next word
> in the input stream; [COMPILE] either appends the execution semantics
> or it appends the non-default compilation semantics of the next word
> in the input.
There's nothing confusing about the definition of [COMPILE]. It simply
forces execution of the following word. On the other hand, it's
implications are complex and subtle, and understanding them gives valuable
insight into how Forth works.
> At the moment I can't think of any uses for COMPILE that POSTPONE
> can't do (although I'm sure there are some esoteric ones).
Sure. If COMPILE is implemented they way I implement it, it is very
useful in creating state smart words. The key is that my COMPILE only
executes in compile mode (it becomes a no-op in execution mode).
Sébastien Furic
James Hague a écrit :
> Elizabeth D. Rather wrote:
> >
> > From my perspective as one who is concerned to see the use of
> > Forth spread among professional programmers, the issue is that
> > a DIY Forth is fun and educational to the implementor, but the energy
> > expended is wasted as far as advancing the language is concerned.
>
> I think there are two type of DIY Forths:
>
> 1. Those written by people who want to implement their own languages for
> the fun or romance of it. Forth is a good choice because it is relatively
> easy to implement, though the result will likely not be used for much of
> value.
>
> 2. Those written by people who have a specific problem domain and can best
> attack it with a custom Forth. For example, to use as a form of scripting
> language inside of a larger application. I don't think these people hang
> around c.l.f. It could also be argued that the best way to write a
> custom Forth is to use an existing, more fully-featured Forth.
>
3. People who want to program in Forth on a given hardware, but there is no
Forth compiler designed to run on this hardware...
Sebastien.
Michael L.Gassanenko
>
> "Gary Chanson" <gcha...@no.spam.shore.net> writes:
>
> > This is a perfect example of why I've always considered POSTPONE to be
> > broken. It's a special case function for building macros and does not
> > replace [COMPILE] and COMPILE. It also does not remove confusion. Instead,
> > it generates more.
>
> does replace COMPILE. Ie, the new pair is POSTPONE/[COMPILE].
>
> As for confusing, if you look at the ANS descriptions, POSTPONE has an
> extremely simple definition, whereas [COMPILE] is the confusing one.
Ok.
: foo STATE @ IF ." welcome " ELSE ." goodbye " THEN ; IMMEDIATE
: bar POSTPONE foo ;
bar
What should be printed: 'welcome' or 'goodbye'?
foo's compilation action is to print 'welcome',
but on most systems it will print 'goodbye'.
(My answer may be derived from
http://forth.sourceforge.net/Standard+/POSTPONE/index.html )
> Ie, POSTPONE always appends the compilation semantics of the next word
> in the input stream; [COMPILE] either appends the execution semantics
> or it appends the non-default compilation semantics of the next word
> in the input.
>
> At the moment I can't think of any uses for COMPILE that POSTPONE
> can't do (although I'm sure there are some esoteric ones).
1)
: bar COMPILE [COMPILE] foo ;
Recommended ANS replacement:
\ for immediate foo
: __foo POSTPONE foo ;
: bar POSTPONE __foo ;
\ for non-immediate foo
: bar POSTPONE foo ;
2)
In a cross-compiler, COMPILE may be preferrable because it requires
an argument that is a target procedure. How POSTPONE FOO will behave
on various FOOs is a question (FOO may be a library definition, subject
to on-demand loading, as well as a host word), while with COMPILE
life is significantly easier.
Michael L.Gassanenko
>
> "Michael L.Gassanenko" <m_l...@yahoo.com> writes:
>
> > : ENTER >R ; ok
> > : 1-10 1 BEGIN R@ ENTER 1+ DUP 11 = UNTIL DROP R> DROP ; ok
> > : t 1-10 DUP . ; ok
> > t 1 2 3 4 5 6 7 8 9 10 ok
> > Modern compilers are compatible with threaded code compilers,
> > and not because everybody agrees that such techniques as
> > return address manipulations are vital,
>
It's a long soap.
1) ANS Forth is a subset of Forth.
The TC could not standardize everything in Forth,
in each particular case for its own set of reasons.
If you studied a natural language and learned by heart the grammar,
but then found out that native speakers speak differently,
how would you resolve that?
2)
http://www.forth.org.ru/~mlg/#bacforth
> The above code has undefined results in
> the ANS standard. Ie, there is no requirement that I've noticed that
> says the top of the return stack has to have any particular relation
> to the execution of a colon word. Some older Forths may have put the
> address of the next work at the top of return stack, but others put
> the return address of the calling word there instead, and others don't
> use the return stack at all for executing colon words.
Good new Forths behave as good old Forths.
a...@redhat.invalid
> [COMPILE] : is correct. This is a case were POSTPONE : does not
> work correctly. If the object is to create a new defining word
> which has the behavior of :, : must execute when the new defining
> word is executed. It is irrelevant in this case whether : is
> immediate or not (and [COMPILE] doesn't care).
But if : wasn't immediate, [COMPILE] wouldn't be necessary.
Making : immediate adds nothing of any use and causes problems.
> It will always be executed when the new defining word is executed.
> If you use postpone on an immediate :, it will compile : into the
> child and defer execution until the execution of the child word.
> This is a perfect example of why I've always considered POSTPONE
> to be broken. It's a special case function for building macros and
> does not replace [COMPILE] and COMPILE. It also does not remove
> confusion. Instead, it generates more.
You're using [COMPILE] to work around a bug, rather than fixing the
bug itself. It's easier to fix the bug.
Andrew.
a...@redhat.invalid
>> : ENTER >R ; ok
>> : 1-10 1 BEGIN R@ ENTER 1+ DUP 11 = UNTIL DROP R> DROP ; ok
>> : t 1-10 DUP . ; ok
>> t 1 2 3 4 5 6 7 8 9 10 ok
> ...
>> Modern compilers are compatible with threaded code compilers,
>> and not because everybody agrees that such techniques as
>> return address manipulations are vital,
> Er, am I missing something? The above code has undefined results in
> the ANS standard. Ie, there is no requirement that I've noticed that
> says the top of the return stack has to have any particular relation
> to the execution of a colon word. Some older Forths may have put the
> address of the next work at the top of return stack, but others put
> the return address of the calling word there instead, and others don't
> use the return stack at all for executing colon words.
He's making the point, I believe, that an optimizing native code
compiler can be made entirely compatible with words that manipulate
the return stack in interesting ways, and that there are some
advantages in doing so. I agree.
Andrew.
Petrus Prawirodidjojo
Regards,
Petrus.
"Jerry Avins" <j...@ieee.org> wrote in message
news:3C03B602...@ieee.org...
Gary Chanson
<a...@redhat.invalid> wrote in message
news:9u2fou$e3e$1...@hammerfield.cambridge.redhat.com...
>
> But if : wasn't immediate, [COMPILE] wouldn't be necessary.
> Making : immediate adds nothing of any use and causes problems.
I strongly disagree. Making : immediate does not cause me any problems
and it makes the compiler more programmer friendly at the cost of setting
one bit.
I also do not agree that this is the only reason for [COMPILE].
> You're using [COMPILE] to work around a bug, rather than fixing the
> bug itself. It's easier to fix the bug.
No bugs involved. This is a design philosophy issue and our design
philosophies are obviously different.
Bernd Paysan
> From my perspective as one who is concerned to see the use of
> Forth spread among professional programmers, the issue is that
> a DIY Forth is fun and educational to the implementor, but the energy
> expended is wasted as far as advancing the language is concerned.
Totally agreed. The main problem with a DIY Forth is that people really
just got the basics from books like SF, and don't know about all the
other tricky stuff that's needed for a Forth system. E.g. some time ago,
I had a coworker who claimed to have written his own Forth on the C64.
Back then, we developed a small CPU, and I proposed to write the
assembler in Forth. When I told him that I use the Forth interpreter to
execute these very simple commands, it was completely new for him. He
didn't even think that Forth was a good choice to write an assembler in!
> Forth was designed to be _used_.
Most of the DIY people think that Forth was designed to be implemented,
and not to be used. They don't know how to use it, and they treat it as
nice little toy language, easy to build, but useless.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bernd Paysan
> Just for the record that F21 was fabed in .8u
> but the fab now offers .18u and one beauty
> of Chuck's design methods is that the tiles
> scale. So F21e could run at speeds similar
> to those predicted for the c18 core in .18u.
But the scaling of the tiles comes at a cost. I've seen the layout of
c18 on EuroForth. The tiled transistors take more space than the typical
layout of standard cell gates on a .18u process. They look more like .8u
transistors scaled down, without taking other process advantages (like
better contact alignment or more metal layers) into account. What looks
fine in .8u looks bloated in .18u. Especially when in .18u about half of
the delay is interconnect delay, and smaller cells means less
interconnect delay.
Bernd Paysan
> The other options, such as BigForth
> and Gforth, have their own sets of issues that may make them less
> appealing.
Has anybody of the DIY Forthers thought that the whole idea of open
sourcing Gforth and bigFORTH was that you can *fix* these issues to make
them more appealing? No? It looks so. The Windows parts of both versions
are almost orphaned, because noone volunteers to do at least some bug
hunting. They seem still to be popular, at least according to the
download numbers. But there's no feedback. I don't need the Windows
versions, so if you want them to be continued, you have to give
feedback.
Same with the documentation. I'd like to offload much of the
documentation process to other people. It doesn't work. On the
EuroForth, some of the "volunteers" told me that he would be able to
e.g. translate my assembler reference into English, but he won't do,
because he doesn't understand the German version. That's because what he
really wants is a tutorial how to write Intel assembler code. Basically,
instead of taking some work away from me, he'd rather like to put a load
of work on my shoulders (teaching people to write x86 assembler is a
tremenduous amount of work, but teaching people who already can do that
to translate their sources into bigFORTH's inline assembler is much
less).
I can only refuse such attempts. After all, the bigFORTH documentation
works fine for me, because it's all in my head. If other people need it,
they should at least try to do something for it. It would make requests
for added stuff much simpler if the requester could show that he's
cooperative.
If people don't get my footer line, I can't help them. If you find some
problem with a free software product, it's *you* who can start helping
to fix it, it's *not* somebody else's problem.
Ed Beroset
>ber...@mindspring.com (Ed Beroset) writes:
>
>> It's more like using exclusively hand tools to
>> create furniture versus using power tools like belt sanders and
>> planers versus using esoteric and special purpose power tools like
>> "biscuit cutters" or dovetail routers.
>
>Although listening to some past comments, I think the difference is
>closer to "why are you building furniture using hand tools instead of
>just heading down to the furniture store?" :-)
You're right!
>> One way to gain this justification is to experiment on my own (as an
>> amateur, if you like) to the point that I feel that the probable
>> payoff makes a sufficiently compelling story to present.
>
>True. Many budgets do not include a tiny $500 or $5000 for buying a
>tool to see if doing things differently will pay off, and the inertia
>that's in place often prevents getting such tools. A tool often has
>to be proven to be effective before it can be purchased (and a one
>week trial won't cut it).
The cost of the tool ($500 or $5000) isn't necessarily the issue here
-- it's the time required.
>Oddly, I've been in situations where it was simpler to have staff
>waste $50,000 dollars of effort rather than buy a $10,000 tool with
>$10,000 of time to learn it. (I think it's because the programmers
>are already there, whereas buying a tool is a new asset and has to go
>through different channels)
In my case, it's "under the radar" and work I do in the evenings for
fun. I am the only person in my department interested in Forth, and
to actually use the thing for our bread & butter embedded work would
require a knowledgeable advocate. I am attempting to become
sufficiently knowledgeable to decide whether I'm an advocate.
>In most of the places I've worked, there have been a variety of Perl
>scripts lying around to automate various tasks (builds, regression
>testing, revision management, etc). But I doubt any of those places
>would ever have paid for a tool to do that sort of thing if Perl
>didn't exist. (but I cynically suspect about half of them would have
>bought Visual Basic without blinking for use of middle and upper
>management to automate their tasks)
Sure, we have Python, Perl, Ruby, Java, and a couple of other
languages floating around the place and in use. None of those
language implementations were written in house and all are available
for free download -- often with source. However, none was written to
be used *inside* the embedded system, and that's where I'd like to try
Forth.
Ed
a...@redhat.invalid
> <a...@redhat.invalid> wrote in message
> news:9u2fou$e3e$1...@hammerfield.cambridge.redhat.com...
>>
>> But if : wasn't immediate, [COMPILE] wouldn't be necessary.
>> Making : immediate adds nothing of any use and causes problems.
> I strongly disagree. Making : immediate does not cause me any
> problems
Sure it does: you can't use ":" in a word. This means you have to use
[COMPILE] where it wouldn't otherwise be needed. This is not a big
problem, I agree, but to say it is no problem at all seems wrong.
> and it makes the compiler more programmer friendly at the cost of
> setting one bit.
I _can_ understand why some people insist that all branches are
resolved before the end of a word, and they check for that. I
wouldn't do so myself, but I can see why it might be useful.
However, I don't understand how making : immediate adds an iota of
programmer friendliness. That's what I means when I said this was a
bug: it's a feature that adds some inconvenience for zero gain.
> I also do not agree that this is the only reason for [COMPILE].
>> You're using [COMPILE] to work around a bug, rather than fixing the
>> bug itself. It's easier to fix the bug.
> No bugs involved. This is a design philosophy issue and our
> design philosophies are obviously different.
Of course that's true. However, it can still be a bug: bugs can
appear in any phase of the development process, from design philosophy
onwards.
The trouble with all this "compiler security" stuff is that it
initially appears to help, but l when extending the compiler it adds
complexity because programmers have to jump through hoops to get
around the security.
Andrew.
Ed Beroset
>I hope you're missing my point. If not, you're ignoring it while
>pretending to address it, and that seems unlikely. Comments are
>interspersed below.
I read your comment as an explanation for why it's generally a bad
idea to write your own Forth. I was trying to explain reasons one
might. I don't know if that addresses your point or not.
>> >I build tools for two reasons: because the tool isn't available in the
>> >form I want, or because it isn't available at a price I'm willing to
>> >pay. The latter reason is largely confined to amateur pursuits. This
>> >applies equally to tools of software or wrought steel.
>>
>> Au contraire, mon frere! Cost is an issue for commercial pursuits as
>> well. If I tell my corporate sponsors that I want $50,000 to buy a
>> commercial Forth implementation and sufficiently train a couple of
>> people to experiment with a technique that *might* not pay off at all,
>> I need to have some reason for believing (and therefore a compelling
>> argument to make) for this expense. It's not a lot of money, granted,
>> but I'd feel bad about wasting $50K if there were a demonstrably
>> better use.
>
>You can buy a compiler and training for a lot less than that. To write a
>decent compiler at a decent salary will cost far more than the cost of
>any commercial one. If you can live with the license issues, there are
>free Forths already written. For developing even a single a product, the
>support alone is worth the cost of a commercial Forth.
Let's say we spend $1500 on the tool, send two engineers to a $2000
(each) training. Air fare, hotel, rental car, and meals for that we
can lump together and approximate at another $3000 for a few days.
That makes $8500 so far. Now if we approximate engineering time at
$2000/wk per engineer, and we assume that it's about a week for
training, we've spent $12500 just to get sufficiently trained to
start. Now if we spend two months doing a trial with Forth in an
embedded project, that's another $32000 for a total of $44500 -- not
that far off my hypothetical $50k. Now it's pretty clear that you're
absolutely right that it will be MORE expensive and longer time to get
these two engineers trained and able to implement their own Forth.
However, if I fiddle around learning Forth on my own time, even if it
takes years, then this is an expense that I pay and not one that the
company pays, except arguably indirectly. That's what I was trying to
convey there, and one explanation for why one might do YAFI (yet
another Forth implementation).
>> One way to gain this justification is to experiment on my own (as an
>> amateur, if you like) to the point that I feel that the probable
>> payoff makes a sufficiently compelling story to present. I can do
>> this with C, C++, XML, Java, and even assembly language, but when I'm
>> told that I need to buy a commercial compiler to even experiment
>> reasonably with Forth, I have to weigh that against the various
>> excellent free offerings in other languages.
>
>What about the excellent free Forth offerings? We were discussing
>writing one's own compiler, not the need to buy. Would you set out to
>learn "C, C++, XML, Java" by assuming that it would be beneficial if
>your first project were a compiler so that you "know the system"? Only
>Forth makes that possible; you seem to equate "possible" with
>"desirable".
I don't think building a Forth implementation should ever be anyone's
first project. I don't think that building a compiler for any
language should be a first project for someone new to that target
language. However, if I intend to use a Forth implementation for an
*embedded system,* I have to either pick a common architecture (x86,
Z80, etc.) for which a free Forth already exists or write one (port
one, more likely) myself to the target processor I already use.
>You can get a free commercial implementation of Swiftforth and VFX that
>don't restrict how you can use them for learning, but these are Windows
>GUI oriented, not suitable for embedded work. I don't know where you can
>get a demo version of a cross compiler, or even how such a thing would
>be possible. You can buy small boards programmable in Forth and
>eminently suited to, and in use for, embedded work. Is $80 too much to
>spend for working hardware with Forth in ROM?
No, but it doesn't address *my* hardware. I already have hardware and
would like to see if Forth would work effectively there -- not on a
PC, and not on a test board with a different micro. I already have a
C compiler for that target micro and an assembler for it. If I want
to use anything else -- Ada, Forth, APL, whatever -- I have a couple
of alternatives:
1. buy a commercial implementation that matches my hardware
2. find a free version that matches my hardware
3. DIY
All I'm saying is that options 1 and 2 aren't the only reasonable
choices. Sometimes they aren't possible choices at all.
Ed
lysse.ha...@blueyonder.co.uk
: James Hague schrieb:
:> The other options, such as BigForth
:> and Gforth, have their own sets of issues that may make them less
:> appealing.
: Has anybody of the DIY Forthers thought that the whole idea of open
: sourcing Gforth and bigFORTH was that you can *fix* these issues to make
: them more appealing? No? It looks so.
But the problem Forth comes up against, possibly uniquely (although maybe
Lisp suffered from it too) is that because it's so easy to implement a
Forth, it becomes easier to implement your own than to fix someone else's.
I've looked, briefly, at the source code for the optimising compiler of
bigForth - but briefly isn't sufficient, whereas for something as simple
as colorForth it is. OK, bigForth will perform better in microbenchmarks,
but we are talking about a language which (according to the HOPL II paper)
outperformed anything else when written in threaded code on prehistoric
architectures, so maybe C-standard optimisation is seen as less important
than having a tool made to fit your own hand.
: I can only refuse such attempts. After all, the bigFORTH documentation
: works fine for me, because it's all in my head.
Exactly - and when faced with a choice of working out what was in your
head and transcribing what's in hir own, what's a poor implementor to
do? ;-)
--
lysse at lysse dot co dot uk
"Why are your problems always so much bigger than everyone else's?"
"Because they're mine." -- Ally McBeal
J E Thomas
> Cost is an issue for commercial pursuits as
> well. If I tell my corporate sponsors that I want $50,000 to buy a
> commercial Forth implementation and sufficiently train a couple of
> people to experiment with a technique that *might* not pay off at
> all, I need to have some reason for believing (and therefore a
> compelling argument to make) for this expense. It's not a lot of
> money, granted, but I'd feel bad about wasting $50K if there were a
> demonstrably better use.
You could buy a system from Forth, Inc. and get a one-week training
class for two people (at Forth, Inc's schedule) much cheaper than
$50,000. Could they learn enough in a week? If you pick really smart
people they will. But then there are the opporunity costs of having
your smart people learn Forth instead of whatever else you need them
for. And there are the costs of waiting for them to experiment. So it
might add up to $50,000, of which Forth, Inc. would get only a small
sliver. So it wouldn't help for them to reduce prices.
> One way to gain this justification is to experiment on my own (as
> an amateur, if you like) to the point that I feel that the probable
> payoff makes a sufficiently compelling story to present. I can do
> this with C, C++, XML, Java, and even assembly language, but when
> I'm told that I need to buy a commercial compiler to even
> experiment reasonably with Forth, I have to weigh that against the
> various excellent free offerings in other languages.
You can of course get very good free Forth systems that run on PCs. If
you want to develop code for uses that aren't too PC-hardware-specific,
you can move the code to a commercial system later and probably have
very few problems with the migration.
You could develop the high-level things for an embedded system the same
way. Do it on a PC and then when you're ready to move to an embedded
system, write the minimum of system-specific code and see whether you
can get it working, and later improve it either until it's good enough
to suit you or you run out of time. A side benefit of this approach is
that when you want to move to a different embedded system you might be
able to go back to the high-level code and repeat the process quickly.
There are some free Forths for embedded things, and they have the sort
of limitations you'd expect from people who release their own tools and
add documentation until they run out of time. One of them might be good
for you, but you can't expect to easily migrate your code to a
commercial embedded Forth.
> I have done some projects that I find valuable using hForth,
> eforth, and Quartus Forth (all of which are either free or under
> $100) and have experimented with the demo version of SwiftX Forth.
> I have read the library's copy of _Starting Forth_, and have
> purchased (and found valuable) both _Forth Applications Techniques_
> and the _Forth Programmer's Handbook_. Still, I can't in good
> conscience recommend Forth for use in my embedded environment
> because:
> 1. I have no data to suggest that Forth is cost effective over C
> or assembly
Yes. The data is disputed about Java etc, but at least people are ready
to spend lots of money to create their claims. The Forth community
doesn't have that kind of money.
> 2. I have no data to suggest that Forth is time effective in
> generating real world code for embedded systems versus C or assembly.
If at some point you find yourself managing a project where delivery
time is much more important than cost, you might suggest adding a Forth
team for an additional 10% of the budget. You will be able to link
Forth modules into a C application, and you will be able to pay for ways
to link the Forth into Java etc. So if neither team fully succeeds you
might possibly be able to combine them, provided they fail at different
spots. You could advertise the Forth team as a sort of Rapid
Prototyping thing. It would give you data. You could publish your
results. I say it's a success if the Forth team gives more than 10% of
the results, or if it succeeds at some problems the regular team does
badly with.
> Note that I'm not saying that those things aren't true, but that I
> don't have reproduceable, objective data to back up those claims.
> Further, I am somewhat inhibited from checking those assertions
> independently unless I pay money for a commercial implementation
> and, more importantly, sink significant time into learning how to
> use it.
Yes. Get somebody else to pay for it. Somebody who needs rapid
delivery enough to take a chance.
> I don't have an easy solution for this, but I thought it might be
> informative to let y'all know how an "outsider" might view the
> prospect of potentially using Forth in a commercial application,
> and to offer some speculation on why DIY implementers aren't
> necessarily college students with way too much time on their hands.
Good, inexpensive, ready quick. Pick two. Too often it turn into 'Pick
one'. If you write a DIY Forth, it probably won't be the best free
Forth available. It will take some of your time, a good investment of
that time if you can afford it. If you want other people to be able to
use it you must either make it look very much like another Forth system
so they can use existing documentation, or you must write extensive
documentation that is hard to organise well.
Either way takes extra time on your part, and again your system probably
won't be the free Forth that does it best.
So I say, what we do need are free or shareware or cheap Forths for new
systems. Quartus Forth for the PDAs is a good example. It's probably
good to get some kind of Forth available quickly for a new system.
Since one of the things people do easily with Forth is to improve an
existing system, if you get a Forth out that isn't very efficient but
has full source, others might improve it faster than they could build or
buy a new one. Of course commercial Forth vendors might improve your
Forth and sell it, but that ought to be OK too, if the result is we get
a good commercial Forth for that system sooner than we would otherwise,
you can buy it if you need it. But one more free Forth for a platform
that already has one, probably won't help anyone but you. And the big
benefit you get in that case is what you learn doing it, unless the
other free Forth has licensing restrictions you can't accept.
jmdrake
> Just for the record I dropped one of the chips that
> Chuck has designed, F21, into a mouse as a demo
> of how a total of 600 words of code is enough to
> fool most people into thinking it a PC running
> windows, but without the PC or windows. That was
> a few years ago. Since then I have done a more
> serious OS and GUI for the chip, but is about
> the same size as that two day demo.
Aha fits in 600 words? Good work.
> Just for the record that F21 was fabed in .8u
> but the fab now offers .18u and one beauty
> of Chuck's design methods is that the tiles
> scale. So F21e could run at speeds similar
> to those predicted for the c18 core in .18u.
>
> Just for the record the chip design was optimized to run
> AI, voice and face recognition, provide sub-nanosecond I/O
> interface, route gigabit data streams, and to operate as
> a node in a scalable multiprocessor. I really should say it
> was first optimized to be inexpensive and low-
> (electrical)power and then optimized for performance
> on the above classes of problems.
If the F21 could handle gigabit data streams, what's the
estimate on the type of data streams a 25X could handle?
> Just for the record I did work, as a consultant,
> on a PDA using one of Chuck's other chips that
> had a color touchscreen, voice recognition, and
> video out, but that was seven years ago.
Was that at iTV? I didn't know they had worked on a PDA.
(or if I did know I had forgotten.) I've always felt that
voice recognition would beat the crap out of a pen interface
(well except when you're using your PDA at the library. :-) )
Neal Bridges
>
> "Neal Bridges" <nbri...@interlog.com> wrote in message
> news:DdWM7.30588$2i.12...@news3.rdc1.on.home.com...
> >
> > For the purpose you state, POSTPONE is entirely consistent in an ANS
> > Forth -- and also unnecessary, as the Standard ':' is not immediate.
> >
> > : my: : ;
>
> Ok. That just transfers the blame to ANS for such a requirement. If
I
> can't implement an immediate :, I consider it broken.
I can't claim to fully understand what you mean, however:
: my: : ; immediate
Michael L.Gassanenko
> M Joonas Pihlaja wrote:
>
> > Why newbies would write their own Forth
> > implementation, and why are those that do sighed at?
...
> > what exactly is the problem with us DIYers?
>
> From my perspective as one who is concerned to see the use of
> Forth spread among professional programmers, the issue is that
> a DIY Forth is fun and educational to the implementor, but the energy
> expended is wasted as far as advancing the language is concerned.
>
> implement some neat algorithm, tool, application, feature, etc.
> and then publish it. Such efforts help the enthusiast by providing
> a worthwhile and interesting objective, and also advance the
> language by enriching the set of things available to the community
> of folks working in the language, and therefore make the language
> that much more attractive.
>
> Forth was designed to be _used_.
I myself have nothing against DIYers, but
I have remembered about one more nuance.
You are not trying to learn Forth by implementing it, are you?
In general, you do not learn a language by implementing it.
First you use some implementation which you think of as
"canonical", then, if there is some motivation,
you can implement your own Forth and learn more.
If you do not know what to write in your Forth, write
1) a decompiler
2) the WHEREUSED <name> utility
--
do not do that -- universal advice
(applicable to itself)
Elizabeth D. Rather
> >> Au contraire, mon frere! Cost is an issue for commercial pursuits as
> >> well. If I tell my corporate sponsors that I want $50,000 to buy a
> >> commercial Forth implementation and sufficiently train a couple of
> >> people to experiment with a technique that *might* not pay off at all,
> >> I need to have some reason for believing (and therefore a compelling
> >> argument to make) for this expense. It's not a lot of money, granted,
> >> but I'd feel bad about wasting $50K if there were a demonstrably
> >> better use.
> >
> >You can buy a compiler and training for a lot less than that. To write a
> >decent compiler at a decent salary will cost far more than the cost of
> >any commercial one. If you can live with the license issues, there are
> >free Forths already written. For developing even a single a product, the
> >support alone is worth the cost of a commercial Forth.
>
> Let's say we spend $1500 on the tool
SwiftX starts at $450, including a board. The board enables you
to start off with a working environment for learning; it's easy to
adapt the system to your hardware (assuming same CPU) once
you're familiar with it.
> , send two engineers to a $2000
> (each) training.
Our classes are $1200 ea., and (though helpful) aren't really necessary.
> Air fare, hotel, rental car, and meals for that we
> can lump together and approximate at another $3000 for a few days.
Wow, I'd like to travel for your company. Depending on where
you're flying from and assuming the 2 engineers share a car, you should
be well under $2K for travel.
> That makes $8500 so far.
Well, $4850.
> Now if we approximate engineering time at
> $2000/wk per engineer, and we assume that it's about a week for
> training, we've spent $12500 just to get sufficiently trained to
> start. Now if we spend two months doing a trial with Forth in an
> embedded project, that's another $32000 for a total of $44500 -- not
> that far off my hypothetical $50k. Now it's pretty clear that you're
> absolutely right that it will be MORE expensive and longer time to get
> these two engineers trained and able to implement their own Forth.
> However, if I fiddle around learning Forth on my own time, even if it
> takes years, then this is an expense that I pay and not one that the
> company pays, except arguably indirectly. That's what I was trying to
> convey there, and one explanation for why one might do YAFI (yet
> another Forth implementation).
You're comparing apples and oranges. What you have following
your investment (whose size is clearly exaggerated) is a supported
commercial product and two trained
engineers with several months' experience using that product,
hopefully on a project that is meaningful (not wasted time).
If you "fiddle around" for a couple of years you've invested 2 yrs
lead time (what's the cost of that?) and what you have is unsupported
software of dubious quality and you haven't learned anything about
the capabilities of professional-quality implementations.
> >What about the excellent free Forth offerings? We were discussing
> >writing one's own compiler, not the need to buy. Would you set out to
> >learn "C, C++, XML, Java" by assuming that it would be beneficial if
> >your first project were a compiler so that you "know the system"? Only
> >Forth makes that possible; you seem to equate "possible" with
> >"desirable".
>
> I don't think building a Forth implementation should ever be anyone's
> first project. I don't think that building a compiler for any
> language should be a first project for someone new to that target
> language. However, if I intend to use a Forth implementation for an
> *embedded system,* I have to either pick a common architecture (x86,
> Z80, etc.) for which a free Forth already exists or write one (port
> one, more likely) myself to the target processor I already use.
Or get the regular SwiftX ($450) for your target processor assuming
it's one we support, work with it on your own doing some experiments
where you can get a good feel for design and performance issues, using
the documentation that comes with the system plus the books you've
already bought, and form some conclusions based on that.
> >You can get a free commercial implementation of Swiftforth and VFX that
> >don't restrict how you can use them for learning, but these are Windows
> >GUI oriented, not suitable for embedded work. I don't know where you can
> >get a demo version of a cross compiler, or even how such a thing would
> >be possible.
There are demo SwiftX's available (all CPUs we support) on a single
CD for $15. You need compatible hardware to run things, but that can
be <$100. It's enough to get the documentation (on the CD) and explore
the user interface, compile code and examine the results, and decide
whether to invest the $435 more (the $15 counts toward purchase) to
go the next step.
> You can buy small boards programmable in Forth and
> >eminently suited to, and in use for, embedded work. Is $80 too much to
> >spend for working hardware with Forth in ROM?
>
> No, but it doesn't address *my* hardware. I already have hardware and
> would like to see if Forth would work effectively there -- not on a
> PC, and not on a test board with a different micro.
What micro are you using?
> I already have a
> C compiler for that target micro and an assembler for it. If I want
> to use anything else -- Ada, Forth, APL, whatever -- I have a couple
> of alternatives:
>
> 1. buy a commercial implementation that matches my hardware
> 2. find a free version that matches my hardware
> 3. DIY
>
> All I'm saying is that options 1 and 2 aren't the only reasonable
> choices. Sometimes they aren't possible choices at all.
Depending on what your hardware is, it may be more feasible
than you think.
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."
================================================
Elizabeth D. Rather
> Darin Johnson wrote:
> >
> > "Michael L.Gassanenko" <m_l...@yahoo.com> writes:
> >
> > > : ENTER >R ; ok
> > > : 1-10 1 BEGIN R@ ENTER 1+ DUP 11 = UNTIL DROP R> DROP ; ok
> > > : t 1-10 DUP . ; ok
> > > t 1 2 3 4 5 6 7 8 9 10 ok
> > ...
> > > Modern compilers are compatible with threaded code compilers,
> > > and not because everybody agrees that such techniques as
> > > return address manipulations are vital,
> >
> > Er, am I missing something?
>
> It's a long soap.
>
> 1) ANS Forth is a subset of Forth.
> The TC could not standardize everything in Forth,
> in each particular case for its own set of reasons.
What it _does_ do is identify things you can and can not depend
on in multiple compliant implementations. One of the things you
are explicitly warned that you _can't_ depend on is the nature of
anything on the return stack that you didn't yourself put there
using >R and following the related rules, which do include
the fact that a >R and subsequent R@ or R> must be in the same
definition as the >R.
> If you studied a natural language and learned by heart the grammar,
> but then found out that native speakers speak differently,
> how would you resolve that?
As in Forth or any language, you're welcome to take advantage
of implementation-specific features providing you're willing
to accept that they limit the portability of your code.
Gary Chanson
<a...@redhat.invalid> wrote in message
news:9u2ns6$flo$1...@hammerfield.cambridge.redhat.com...
>
> However, I don't understand how making : immediate adds an iota of
> programmer friendliness. That's what I means when I said this was a
> bug: it's a feature that adds some inconvenience for zero gain.
It's not zero gain. It allows the compiler to detect missing ;.
> The trouble with all this "compiler security" stuff is that it
> initially appears to help, but l when extending the compiler it adds
> complexity because programmers have to jump through hoops to get
> around the security.
The programmer should virtually never need to "get around" compiler
security, and in the few cases were it might be desirable, you are already
"jumping through hoops". Compiler security may make the situation more
complex, but it also helps to manage that complexity by detecting dumb
errors.
Michael L.Gassanenko
>
> "Michael L.Gassanenko" wrote:
>
> > Darin Johnson wrote:
> > >
> > > "Michael L.Gassanenko" <m_l...@yahoo.com> writes:
> > >
> > > > : ENTER >R ; ok
> > > > : 1-10 1 BEGIN R@ ENTER 1+ DUP 11 = UNTIL DROP R> DROP ; ok
> > > > : t 1-10 DUP . ; ok
> > > > t 1 2 3 4 5 6 7 8 9 10 ok
> > > ...
> > > > Modern compilers are compatible with threaded code compilers,
> > > > and not because everybody agrees that such techniques as
> > > > return address manipulations are vital,
> > >
> > > Er, am I missing something?
> >
> > It's a long soap.
> >
> > 1) ANS Forth is a subset of Forth.
> > The TC could not standardize everything in Forth,
> > in each particular case for its own set of reasons.
>
> What it _does_ do is identify things you can and can not depend
> on in multiple compliant implementations. One of the things you
> are explicitly warned that you _can't_ depend on is the nature of
> anything on the return stack that you didn't yourself put there
> using >R and following the related rules, which do include
> the fact that a >R and subsequent R@ or R> must be in the same
> definition as the >R.
I deliberately did not want to speak about this particular case.
I wanted to explain what ANS Forth is, and what ANS Forth is not.
ANS Forth is not a defiintion of Forth.
Imagine a teleportation transporter from Star Trek.
It can transport people standing on the platform,
or reasonably sized things.
They also do transport things that do not fit onto
the platform, multiple times every day, but such
transportation requires a different device and
different procedures.
ANS Forth also is a porting means.
Its potentialities are limited,
people do port things that do not fit into ANS Forth,
sometimes their job is to work with things that
in no way can fit into ANS Forth,
but in many cases ANS Forth is enough.
--
And as to species that do not survive such transportation...
Some folks wrote the TCP/IP stack using CELL but meaning
4 bytes. Obviously, such code cannot be ported to 16-bit
processors and probably even to processors with a different
byte order.
--
the right question is half the answer
Michael L.Gassanenko
>
> However, I don't understand how making : immediate adds an iota of
> programmer friendliness. That's what I means when I said this was a
> bug: it's a feature that adds some inconvenience for zero gain.
As to programmer-friendlyness...
Imagine that some guy calls you and says that the definition
: 3DUP 2 PICK 2 PICK 2 PICK ;
aborts with the message "3DUP -?".
What might it be?
---
Earlier a...@redhat.invalid wrote:
>
> Gary Chanson <gcha...@no.spam.shore.net> wrote:
>
> > [COMPILE] : is correct. This is a case were POSTPONE : does not
> > work correctly. If the object is to create a new defining word
> > which has the behavior of :, : must execute when the new defining
> > word is executed. It is irrelevant in this case whether : is
> > immediate or not (and [COMPILE] doesn't care).
>
> But if : wasn't immediate, [COMPILE] wouldn't be necessary.
> Making : immediate adds nothing of any use and causes problems.
Making : immediate was a design decision made in FIG Forth (IIRC).
The redefinition
: ?EXEC STATE @ 0= ABORT" interpretation only" ;
: : ?EXEC : ; IMMEDIATE
would introduce that functionality into an ANS Forth system.
The gain from immediate : is that when you forget to finish
a : definition, you get an error message at the next : .
If you mispress the shift key end get a : instead of a ; ,
sort of : foo blah blah blah : ,
you also get an error message.
>
> > It will always be executed when the new defining word is executed.
> > If you use postpone on an immediate :, it will compile : into the
> > child and defer execution until the execution of the child word.
>
> > This is a perfect example of why I've always considered POSTPONE
> > to be broken. It's a special case function for building macros and
> > does not replace [COMPILE] and COMPILE. It also does not remove
> > confusion. Instead, it generates more.
>
> You're using [COMPILE] to work around a bug, rather than fixing the
> bug itself. It's easier to fix the bug.
>
> Andrew.
Jeff Fox
>
> Jeff Fox schrieb:
> > Just for the record that F21 was fabed in .8u
> > but the fab now offers .18u and one beauty
> > of Chuck's design methods is that the tiles
> > scale. So F21e could run at speeds similar
> > to those predicted for the c18 core in .18u.
>
> But the scaling of the tiles comes at a cost. I've seen
> the layout of c18 on EuroForth. The tiled transistors
> take more space than the typical layout of standard cell
> gates on a .18u process.
That is quite true. There are other penalties too.
By using a graphical represntation where each transistor
has custom size and connections they do take up more
space than if they are generated from a schematic.
That is true. The reason is that brain damaged place
and route software minimizes path lengths in a very
very stupid way rather than make the ones that have
to be short short. It makes the average short, but
important lines too long, many many lines that are
just not needed, and requires a complete relayout
for a different geometry.
But Chuck feels that the benefits are much more
valuable. One is an order of magnitude higher
performance in the same geomentry. A second is
that it is the holy grail that VLSI cad has
been seeking for years, a way to deal with the
change in line delay vs transistor delay with
scaling. A third benefit is that you just can't
do that with the obsolete approach of _having_ to
go through the schematic, it removes a large
proportion of the hardware components that are
_needed_ with the schematic approach but not
really _needed_ by the design.
The design becomes much simpler with the tiled
approach so you don't need as many transistors.
So they "look" less dense but are actually
more dense overall because of efficiency at
runtime. Those are runtime benefits in addition
to the design benefits of this apporach. It
is analogous to a Forth approach to software.
Since the goal is low cost and high performance
the lower than normal gate density might look
like a problem unless you realize that it is
actually one of the ways to reduce the overall
use of chip real estate by orders of magnitude.
So although density "looks" less from a distance
the overal desnity is actualaly much higher
resulting in lower cost, higher performance,
and greater simpliciy. Just like software.
> They look more like .8u transistors scaled down, without
> taking other process advantages (like better contact alignment
Better contact alignment was one of the changes from OKAD
to OKAD II as Chuck has explained in his presentations
though I expet only those actually working with CAD would
understand the details of such things.
> or more metal layers) into account.
Right. I saw a design the other day in .07u with nine,
nine metal layers... You know, the kind of $3000 CPU
that some people love. Wow, talk about development
budgets!
Chuck's design was carefully constructed to need a
minimal of metal layers since that is also an associated
cost factor. It was designed to get the most from the
least needed, not be wasteful and require more silicon and
metal to do the same job to raise profit margins.
The ideas from these opposite ends of the hardware
and software spectrum don't mix so people on the
big end have a hard time figuring out all the
"backwards" ideas that work on the other end of
the universe, like Forth and Forth hardware the
way Chuck does them. For instance...
Chuck's chips don't need nine metal layers, they
don't need $3000 worth of silicon for a chip with
several CPU, they don't need schematics, they
don't need hundreds of megabytes and hundreds
of thousands of dollars of VLSI CAD code, they
don't need absurd amounts of computing power
and time to simulate their operation, and it
really upsets the people who either do need
all that or all selling all of that and want
everyone to think that they also need it.
The same with software.
> What looks
> fine in .8u looks bloated in .18u. Especially when in
> .18u about half of the delay is interconnect delay, and
> smaller cells means less interconnect delay.
Right. But many of the "smaller cells" are for compontents
that are simply not needed at all and are generated by
stupid place and route software. You cannot make these
components any smaller than Chuck makes them, he uses
zero chip real estate for them. As he often says the
minium is zero.
Chuck eliminated most of the waste and carefully
designed the layout so the tile size would scale
with transistor and gate delay continuing to work.
This means that one can move from .8u to .6 to .5
to .35 to .25 to .18 to .13 to .07 without spending
millions or billions redesigning the
whole chip like other companies have to do.
Without the tile approach the whole chip must be
layed out again, or studid place and route software
must add an absurd overhead of unneeded components to
get the thing to work. Just like software.
It is entirely consistent with Chuck's approach to
Forth as a language. Most programmers do exaclty
the same thing. They show tiny code snippets to
show the efficienty of their code, but 90% to
99% of the code is simply unneeded fat and
although their code "looks" dense it is just
heavy with fat. Hardware or software both
work that way. And fat hardware promotes fat
software, fat software promotes fat hardware
and that keeps the system moving and profit
margins high. Marketing fat is what makes
the system work. What makes computers work
(efficency) is pretty much opposite what makes the
industry work (planned inefficiency).
Jeff Fox
Jeff Fox
Our economic system gives us three groupings:
#1. Selling products. In most cases today the motto
is "Never give a suck an even break or smarten up
a chump." The bottom line for most companies is
profit margin. If we can make them think they
want it, and get them to buy it, our job is
done. People respect someone who can sell pet
rocks.
It didn't use to be that way, at least in olden
times business was often more human and customer
satisfaction was key. But with the shift to
production line thinking, and the new corporate
robber barrons replacing governments (corporations
are not larger players than most contries in the
world) consumerism has changed many things.
#2. Buying products. In most cases the motto is
"I want it now." It is fun to buy things. Consumerism.
Many times the consumer gets taken. (you will not
actually be able to fly if you upgrade to XP for
instance.. Well those kind of commercials always
worked on children before so they should work
on today's adults.)
(in fact I was supprised that Mr. Gates announced that
XP is nothing more than removing some of the fat that
they put in Windows and said that, "Companies can get
two or three weeks more productive work each year out
of employees with this upgrade. It is admitting that
more trillions of dollars in our economy will be
intentionally wasted by the last version of MS
software if we don't pay tribute to MS. Tens of
millions of workers are now wasting a lot of their
time because of milage governors in their software.
Would consumers object to learn that they have to pay for
their car maker again to turn off the milage
governor in their car that has been making them
pay more for gas and generate more polution for
the last few years?)
When taken, the consumer will usually just put the
product in the closet or throw it away and
hope they learned something from the experience.
It is kind of sad. Billions of people who would
kill to get a computer and millions of PC sold
as calandars, recepie holders, and email boxes
are sitting in closets because foolish consumers
were tricked into bying machines that took their
money like a one armed bandit on steroids.
They don't like to admit when they get taken
and they don't like anyone else talking about
it. They have a sense of shame and go into
denail about repeatedly getting taken.
#3. Other things that are not based on monitary
exchange. Cooperation, charity, education, learning,
love, spirituality, free exchange of ideas, and air
are some of the good things that are sometimes
outside of the monitary exchange system.
Often #3 comes into conflict with #1 and #2.
Some people don't like cooperation, charity,
education, love, spirituality, free exchange
of ideas and other things that cut into
their efforts to make money. Sometimes
people who have to pay for their cooperation,
love, education, and ideas or who sell
these things object to the idea that other
people give them away for free. So many
people will object to people giving away
free information or ideas that cut into
their profit plans and so their job
(it's just business) is to try to sell
the deception game that the only real
way to measure value is monitary. Those
who buy it also often don't want to admit
it when what they bought should go to the
garbage and be replaced with something
free. DIY.
Some people and companies still sell
customer satisfaction and their lives
are made more difficult by types #1
and #2. Those people will generally
not object to group #3 or DIY and will not
identify with groups #1 or #2. Those
in groups #1 and #2 may object strongly
to the idea that groups #1 or #2 exist
at all, and to DIY in general.
All my life I have known people who
felt that the only reality on this
planet was monitary exchange. Charity,
kindness, love, science, art, spiritualy,
etc. are all "worthless" according to
these people unless money is changing
hands. It leads to much of the problem
that many people have with DIY. They
see it as not just a worthless waste of time,
but more importantly a missed chance to
make money. Sacrelig!
So when Chuck gives Forth away to the
world, some people selling software will
have a different take on the value of it.
When Chuck gives away the secrets behind
significant developments in hardware design
the people selling obsolete ideas will take
a differnt view on the value of giving
away free ideas.
People tend put all the facts in a mixer
and choose to view only those that fit with
their world view. So once one has decided
that one wants to use the most complicated
chips and become and expert and sell them or
sell software for them the idea that simple
is better becomes bad. Complex has higher
profit margins and thus is better. More fat
is better. The same is true for software.
It is about making a living.
The same is true for ideas. If you are teaching
people how to do math with Roman numerals then
you will object to the very "stupid" idea of someone
teaching teaching Arabic math with the concept
of zero for free. They will say, "Zero is nothing,
it is a meaningless and worthless concept. It is
only worth as much as people are paying for it!"
That all said, it is also worth remembering that
a lot of DIY _is_ crap. Blind leading the blind.
But a lot of commercial products are crap too.
I have seen plenty of examples on both sides.
Jeff Fox
If you want something done right, Do It Yourself.
(But only if you are me since you probably can't
do it _my_ way, the right way, anyway. ;-)
Jeff Fox
>
> James Hague schrieb:
> > The other options, such as BigForth
> > and Gforth, have their own sets of issues that may make them less
> > appealing.
For me the set of issues includes use restrictions. Some
free Forths have more use restrictions than commerical
Forths, or at least use restrictions that are more
critical for some things.
> Has anybody of the DIY Forthers thought that the
> whole idea of open sourcing Gforth and bigFORTH
> was that you can *fix* these issues to make
> them more appealing?
Of course you know that it is true. That is what
most DIY people think. But many times other people's
DIY stuff takes _so_ much work to *fix* than
Doing It Yourself that people just should not
expect other people to finish their software
for them.
They give it away so that anyone can take it, fix it as
they see fit, and use it. But just because they give
it away does not mean that people will be interested
in trying to fix other people's code. Don't take
it personally. In this case it might just be that
most people don't like mucking with Windows any more
than you.
> No?
No.
> It looks so. The Windows parts of both versions
> are almost orphaned, because noone volunteers to do at
> least some bug hunting.
There could be other explanations why people don't
want to try to fix windows bugs, remember Sisyphus.
> Same with the documentation. I'd like to offload much of the
> documentation process to other people. It doesn't work.
Sure. If you will give them the Forth maybe you will
also give them the documentation. If you will give them
that, maybe you will give them tutorials and trainging
too. If you will do that maybe they can get you to
write their applications for them. It goes with the
territory.
> On the
> EuroForth, some of the "volunteers" told me that he would be able to
> e.g. translate my assembler reference into English, but he won't do,
> because he doesn't understand the German version. That's because
> what he
> really wants is a tutorial how to write Intel
> assembler code. Basically, instead of taking some work
> away from me, he'd rather like to put a load
> of work on my shoulders (teaching people to write
> x86 assembler is a tremenduous amount of work, but
> teaching people who already can do that
> to translate their sources into bigFORTH's
> inline assembler is much less).
Frustrating isn't it? A lot of background is
needed to understand your work, and many people
want you to give them the background that you
had to fight hard to get.
> If people don't get my footer line, I can't help them.
> If you find some problem with a free software product,
> it's *you* who can start helping to fix it, it's *not*
> somebody else's problem.
No kidding. But many people cannot do it themselves
and will try to "help" by doing what they can
do, trying to be your manager and get you to do the
work by telling you what _you_ should do. ;-)
Jeff Fox
Jeff Fox
> Aha fits in 600 words? Good work.
Aha is something else altogether, a compiler and tool
suite. It should be about that size too. After all,
"most programs fit in 1K". ;-) I haven't assigned a
name to the OS yet. I haven't decided how far in
several different directions to take it either.
Someone was impressed enough to arrange funding and
make plans to expand the project to something pretty
exciting. But you know how funding tends to come and
go...
> If the F21 could handle gigabit data streams, what's the
> estimate on the type of data streams a 25X could handle?
Good question. I addressed that question at the last
FIG meeting. Chuck talked mostly about colorForth
and all the questions that I asked were about 25x
architecture... I will post the answers that I got
in another post.
> > Just for the record I did work, as a consultant,
> > on a PDA using one of Chuck's other chips that
> > had a color touchscreen, voice recognition, and
> > video out, but that was seven years ago.
>
> Was that at iTV?
No it was before iTV existed. A P32 client.
> I didn't know they had worked on a PDA.
iTV did have a handheld LCD screen internet browser
and email appliance. Managment changed direction
from a settop box to a handheld after the prototype
and programming was done and after Microsoft
spent $500,000 to dump product below cost to
control another emerging market. That scared
investors. What could they do?
Then they changed direction again by making an
appliance module that could drop into a TV to
make a TV internet appliance that was actually
cheaper than the settop box without a TV inside.
The only internet ready TV at the time was $3000
and iTV was talking about a $25 internet TV.
Gee, something about Forth seems different...
In India, China, Japan, Indonesia, and other places
where people cannot afford PCs or $3000 internet
appliances companies were talking about orders
for hundreds of millions of units to "evaluate"
the product before bying in volume. That might
have changed the internet and computing landscape.
> (or if I did know I had forgotten.) I've always felt that
> voice recognition would beat the crap out of a pen interface
> (well except when you're using your PDA at the library. :-) )
For years Chuck had doubts about voice. He said that he
did not want to picture and office with lots of people
all talking to their computers at once, too much noise. But
you know, that is how telephones work and they caught on
despite the doubters. Chuck seems to have come around and become
interested in such things as well as parallelism.
I began voice recognition research in 65 at the University of
Iowa. I wrote my first voice recognition and resonse programs
about a decade later. I thought the story was actually
pretty funny. A decade later I began to consider custom
hardware as well, back when ANS Forth was conceived.
If is really funny sometimes when people don't know that
they are having a conversation with a non-organic
computer. (an informal Turing test.) ;-)
Anton Ertl
M Joonas Pihlaja <jpih...@cc.helsinki.fi> writes:
>- Compilation / Interpretation state/semantics. I thought I
> understood all there is to know about state, but it wasn't
> until writing the Forth compiler did the ramifications spell
> themselves out. For example, the difference between [COMPILE]
> and POSTPONE , and I'm still not sure how FIND should operate
> in all circumstances.
Neither do I. It's not well defined for many circumstances. My
conclusion is that you should either only apply it only to
user-defined words, or in a plain text interpreter context.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
Anton Ertl
jha...@dadgum.com (James Hague) writes:
>In terms of Forths for Windows, I think there's still interest in
>do-it-yourself systems because the commercial Forths don't cover the
>hobbyist market well. If you want a good machine code generating Forth
>for Windows, then you're looking at $400 products, and there are some
>holes even in those (quality of floating-point code, for example, or not
>being able to re-compile the kernel). The other options, such as BigForth
>and Gforth, have their own sets of issues that may make them less
>appealing.
Well, one of the reasons why Gforth may work less well on Windows than
on other OSs is that many Windows users don't provide good bug
reports; instead, some prefer to mutter darkly about "sets of issues
that may make them less appealing". A developer who was really
interested in the Windows port would also help.
Strangely, you forgot to mention Win32Forth, which is probably the
most popular free Windows Forth.
Anton Ertl
"Michael L.Gassanenko" <m_l...@yahoo.com> writes:
>Well, back to POSTPONE
>it is like [COMPILE] for immediate words and like COMPILE
>for non-immediate words.
>In most cases this is what you need.
>
>[COMPILE] may be used in the following cases:
>
>1) FIG-Forth required : to be immediate, while other standards
>require it too be non-immediate. [COMPILE] : should work on both.
>
>2) by using [COMPILE] you can underline that you know that the
>word is immediate.
Does not fit with 1). In that example you use [COMPILE] because you
don't know if the word is immediate, but you want to compile the
interpretation/execution semantics (which is the same whether the word
is immediate or not).
You don't use POSTPONE :, because you don't want to compile the
compilation semantics of : (and these differ between the Forth
versions you are looking at).
>> and I'm still not sure how FIND should operate
>> in all circumstances.
>
>IIRC, this has been a subject of an RFI.
RFI 8.
Anton Ertl
ber...@mindspring.com (Ed Beroset) writes:
>1. I have no data to suggest that Forth is cost effective over C or
>assembly
>generating real world code for embedded systems versus C or assembly.
You might be interested in:
@InProceedings{ertl99ef,
author = {M. Anton Ertl},
title = {Is {Forth} Code Compact? {A} Case Study},
booktitle = {EuroForth'99 Conference Proceedings},
year = {1999},
address = {St. Petersburg, Russia},
url = {http://www.complang.tuwien.ac.at/papers/ertl99ef.ps.gz},
abstract = {Forth advocates often claim that Forth code is
smaller, faster, and requires less development time
than equivalent programs in other languages. This
paper investigates this claim by comparing a number
of parser generators written in various languages
with respect to source code size. The smallest
parser generator (14 lines) in this comparison is
written in Forth, and the other Forth program is
smaller than the others in its class by a factor of
8 or more; however, the Forth programs do not have
all the features of their counterparts. I took a
closer look at Gray (in Forth) and Coco/R (in
Modula-2) and found that several Forth features
missing from Modula-2 give Gray more than a factor
of three advantage over Coco/R (even if the other
size differences were solely due to differences in
functionality): run-time code generation; access to
the parser and a simple, flexible syntax; and
Forth's dictionary.}
Anton Ertl
"Michael L.Gassanenko" <m_l...@yahoo.com> writes:
>: foo STATE @ IF ." welcome " ELSE ." goodbye " THEN ; IMMEDIATE
>: bar POSTPONE foo ;
>bar
>
>What should be printed: 'welcome' or 'goodbye'?
>foo's compilation action is to print 'welcome',
>but on most systems it will print 'goodbye'.
ANS Forth systems must print "goodbye". The reason is: the
compilation semantics of foo is to execute STATE @ IF ... THEN. The
POSTPONE FOO compiles this into BAR, so executing BAR executes that;
STATE is false when BAR is executed in the example above.
POSTPONE deals with compilation semantics. Introducing undefined new
terms like "compilation action" only causes confusion. In the present
example you confused yourself.
Anton Ertl
Bernd Paysan <bernd....@gmx.de> writes:
>Same with the documentation. I'd like to offload much of the
>documentation process to other people. It doesn't work.
It does. Neal Crook did a lot of documentation work between 0.4.0 and
0.5.0, and as a result the Gforth manual is quite presentable
nowadays.
Jeff Fox
or even if it had been selected yet. I had warned
that people would try to sell him their products
before bothering to find out any details of his
project.
"Elizabeth D. Rather" wrote:
> > Let's say we spend $1500 on the tool
>
> SwiftX starts at $450, including a board.
Great! I would like to order one for F21 and one
for P21 and one for c18 and one for 25x. That
should be $1800, what a deal! When can you
deliver the boards, chips and software if I
send the money over the net today? If you
can actually deliver as you say I know lots
of other people who will order soon too.
Ed asked about learning how well Forth will work on
his project with his CPU. He said it was to evaluate
the value of Forth on his project, he did say that
he wanted to do it just to learn in general about
Forth. Saying his hardware and software will
only cost $450 without knowing anyting more about
his project sounds like a classic bait-and-switch.
> > these two engineers trained and able to implement their own
> > Forth. However, if I fiddle around learning Forth on my own
> > time, even if it takes years, then this is an expense that I
> > pay and not one that the company pays, except arguably
> > indirectly. That's what I was trying to
> > convey there, and one explanation for why one might do
> > YAFI (yet another Forth implementation).
I thought you were very clear about that in your first post.
But I expect that it would be taken as an invitation to
advertize specific products and downplay DIY. But people
don't seem to want to listen to the points that you made
or that other people made about all the perfectly valid
reasons for DIY or YAFI.
> You're comparing apples and oranges.
Oh no, not that! Comparing two types of fruit that
are about the same size, same cost, same nutritional
value and have 99.999% of the same properties
in common. Ed should be arrested immediately by
the apples-organes police! ;-)
Elizabeth, you are talking about everything except what
Ed was talking about and trying to use that to invalidate
the perfectly reasonable things that Ed has said. Can
you address the points that were raised?
> What you have following
> your investment (whose size is clearly exaggerated)
Not as much as you are bending the facts the other way.
OK, if what you say is true, and I am wrong then I
am really very very happy. I can't wait to get my
new compilers from Forth Inc.
I think his numbers were underestimated in general.
Maybe his company can't even afford a real quote.
> is a supported
> commercial product and two trained
> engineers with several months' experience using that product,
> hopefully on a project that is meaningful (not wasted time).
I seem to recall someone telling about how their company
believed that $2000 a copy was a reasonable price considering
the professional support claims only to learn that it simply did
not exist. When bugs were reported the customer was not
taken seriously and they couldn't believe the product has
those bugs. Then they said another company was responsible
for fixing the bugs. Then they said that the product was
no longer supported. Then they said that a $2000 upgrade
was needed to get the new version with those bugs fixed.
Then new version had the similar but different bugs and
no support either. There seem to be a lot of companies
that do business that way these days.
If I had heard the story from someone else I might not
believe it. Of course I saw this many times from many
companies over 35 years. Having seen it coming from
Forth Inc. and MPE made me take many marketing claims
with a grain of salt and a stiff belt. Some people
use Forth like they use everything else.
> If you "fiddle around" for a couple of years you've invested 2 yrs
Ed was talking about being a more valuable worker, bettering
himself by learning something that would allow him to do a
better job, earn more, etc. But because he mentioned DIY
and YAFI he is being characterized as a fool instead of
simply having a professional attitude and learn more
about his profession.
It is just nuts to suggest that instead of gaining an
understanding of the issues first that he should just
put his career on the line and suggest using Forth
in a project that we have heard _nothing_ about.
Ed does not appear to be the fool that you want to
make him out to be. But I am sure that there are
a lot of them out there.
> lead time (what's the cost of that?) and what you have is unsupported
> software of dubious quality and you haven't learned anything about
> the capabilities of professional-quality implementations.
That has little to do with what he is talking about. If he
said that he programs in assembler but is planning to take
a course in C++ to be a more qualified employee it seems it
would be easy to understand that his present project's
assembler code schedule has nothing to do with his wanting
to learn more himself. Can't you be a little more
insulting to Ed? Is the problem that you don't like the
idea of educated consumers? Are they bad comsumers?
Is it bad if people don't "buy" their education from
you? Does he have to pay you to get an answer to
his questions?
> > I don't think building a Forth implementation should
> > ever be anyone's first project.
But you mentioned DIY and YAFI so you have been characterized
as a newbie and fool wanting to learn Forth by writing a system
and screwing up everything at your company by being
unprofessional. But keep repeating the above and some of
these folks might eventually figure out the point that you
have repeatedly made.
> > language. However, if I intend to use a Forth implementation for an
> > *embedded system,* I have to either pick a common architecture (x86,
> > Z80, etc.) for which a free Forth already exists or write one (port
> > one, more likely) myself to the target processor I already use.
That is the first time you mentioned any target constraints yet
people have been trying to sell you products, or sell them
to others by trying to make you look the fool, without any
knowledge of any details of your project plans.
> Or get the regular SwiftX ($450) for your target processor assuming
> it's one we support,
Maybe that is where you should have started. Without knowing
if his embedded system is supported quoting him the $450
price is, kind of straddling the bait-and-switch line.
> work with it on your own doing some experiments
> where you can get a good feel for design and performance issues, using
> the documentation that comes with the system plus the books you've
> already bought, and form some conclusions based on that.
I would love to actually hear your responses to all the
cases that people have given where commercial products
just won't do for various quite valid reasons instead
of just posting advertizing and insulting the person
who asked why people are so hostile.
I haven't seen anyone respond for instance to my comments
about how one of the things that makes Forth unique
is the way the compiler can be used at runtime but that
most commercial compilers cannot be distributed as part
of an application unless restricted. Those restrictions
often make the use of a commerical compiler impossible
if you want to take advantage of the more powerful
features of the langauge.
How many years has it been since you switched from
being a Forth programmer to management and teaching
anyway? Do you teach people some of the most powerful
things in Forth that your products won't allow them
to do? I doubt it. You seem to avoid the subject
when it came up and just keep repeating the
advertizements and insulting Ed.
> What micro are you using?
He already said that it wasn't selected yet. You should
have asked that question before all the advertizing IMHO.
> > All I'm saying is that options 1 and 2 aren't the only reasonable
> > choices. Sometimes they aren't possible choices at all.
Yes, I think the thread has become very funny because a
lot of people's reflexes about DIY and YAFI are showing. ;-)
> Depending on what your hardware is, it may be more feasible
> than you think.
Sure. He might be a fool, but I haven't seen evidence of
it other than drawing a target on himself by asking
a question about "Standing up for DIY" in c.l.f. ;-)
I would still love to see an actual response to the
points that Ed has made instead of the dodging and
avoidance that is so common in c.l.f.
Cheers,
Jeff Fox
Coos Haak
Sébastien Furic <sebasti...@tni.fr> schreef in berichtnieuws
3C04AA25...@tni.fr...
> 3. People who want to program in Forth on a given hardware, but there is
no
> Forth compiler designed to run on this hardware...
>
> Sebastien.
>
Name one processor (old, modern, future, virtual) that has
no Forth written for it ;-)
Coos
Ed Beroset
>Ed Beroset wrote:
>
>> Air fare, hotel, rental car, and meals for that we
>> can lump together and approximate at another $3000 for a few days.
>
>Wow, I'd like to travel for your company. Depending on where
>you're flying from and assuming the 2 engineers share a car, you should
>be well under $2K for travel.
You sound like my accounting department!
>> That makes $8500 so far.
>
>Well, $4850.
OK, we'll take your numbers.
>> Now if we approximate engineering time at
>> $2000/wk per engineer, and we assume that it's about a week for
>> training, we've spent $12500 just to get sufficiently trained to
>> start. Now if we spend two months doing a trial with Forth in an
>> embedded project, that's another $32000 for a total of $44500 -- not
>> that far off my hypothetical $50k.
It's $36850 with your numbers. Let's call it $30000 and we'll make
those hapless engineers sleep in the rental car and eat only ketchup
packets from fast food joints. ;-) In any case, whether it's $30000
or $50000 or somewhere in between, it's a large enough number to be
noticed and I don't want to squander that kind of money unless I'm
pretty certain it's worth the gamble.
>> Now it's pretty clear that you're
>> absolutely right that it will be MORE expensive and longer time to get
>> these two engineers trained and able to implement their own Forth.
>> However, if I fiddle around learning Forth on my own time, even if it
>> takes years, then this is an expense that I pay and not one that the
>> company pays, except arguably indirectly. That's what I was trying to
>> convey there, and one explanation for why one might do YAFI (yet
>> another Forth implementation).
>
>You're comparing apples and oranges. What you have following
>your investment (whose size is clearly exaggerated) is a supported
>commercial product and two trained
>engineers with several months' experience using that product,
>hopefully on a project that is meaningful (not wasted time).
Yes, they're certainly two different approaches with different
results. In that regard, they're certainly "apples and oranges" but I
find that rarely am I called on to compare two possible approaches
with identical results. If I were, I think my job would be much
easier!
>If you "fiddle around" for a couple of years you've invested 2 yrs
>lead time (what's the cost of that?) and what you have is unsupported
>software of dubious quality and you haven't learned anything about
>the capabilities of professional-quality implementations.
I understand what you're saying, and there's merit to it. There are
some things you seem to be assuming here, however that aren't
necessarily so. First, the primary result of two years of study isn't
the implementation but the knowledge. Second, while I suppose some
professionals instantly unlearn what they know about developing
quality software when they leave the office, I'm not among them.
Third, "professional-quality" could mean Windows 98 (which just
crashed here moments ago, trashing the first draft of this reply)
while "amateur" Linux rarely crashes, at least in my experience.
While I'm sure that Forth, Inc. products are of high quality, "you get
what you pay for" doesn't necessarily apply to software. Some of my
favorite tools are freeware. Finally, it's worth recognizing that the
conclusion of all that study could well be "let's buy a commercial
offering" -- not the easiest way to arrive at that conclusion but it's
not insane, either.
>> I don't think building a Forth implementation should ever be anyone's
>> first project. I don't think that building a compiler for any
>> language should be a first project for someone new to that target
>> language. However, if I intend to use a Forth implementation for an
>> *embedded system,* I have to either pick a common architecture (x86,
>> Z80, etc.) for which a free Forth already exists or write one (port
>> one, more likely) myself to the target processor I already use.
>
>Or get the regular SwiftX ($450) for your target processor assuming
>it's one we support,
It doesn't happen to be. However, MPE sells a Mitsubishi 740 series
implementation, so I could still buy a commercial product if I chose
to.
>work with it on your own doing some experiments
>where you can get a good feel for design and performance issues, using
>the documentation that comes with the system plus the books you've
>already bought, and form some conclusions based on that.
Yes, and I'll probably do exactly that at some point. I just haven't
chosen to yet, and I was hoping to illuminate why that's not
necessarily irrational. Maybe not successfully, but that was the
intent!
>There are demo SwiftX's available (all CPUs we support) on a single
>CD for $15.
Yes, thanks, I know. I already have one.
>What micro are you using?
A Mitsubishi 740 series micro (basically a 6502 with a few additional
embedded-oriented instructions) on this particular thing.
>> C compiler for that target micro and an assembler for it. If I want
>> to use anything else -- Ada, Forth, APL, whatever -- I have a couple
>> of alternatives:
>>
>> 1. buy a commercial implementation that matches my hardware
>> 2. find a free version that matches my hardware
>> 3. DIY
>>
>> All I'm saying is that options 1 and 2 aren't the only reasonable
>> choices. Sometimes they aren't possible choices at all.
>
>Depending on what your hardware is, it may be more feasible
>than you think.
I'm sure that at least one commercial offering exists for this
particular micro. For some of the other embedded products I work on,
I'm quite sure there are none because we use proprietary hardware.
Yes, it's possible to pay to have one created, but that's just a
variation on one of the choices above.
Anyway, I'm not out to convince you that you're wrong to offer a
commercial implementation -- just to convince you that there might be
a possibility that DIY implementations aren't the sole province of
lunatics and children. It's not always a ridiculous waste of time to
roll your own.
Ed
Jeff Fox
> Name one processor (old, modern, future, virtual) that has
> no Forth written for it ;-)
I assume that is tongue-in-cheek because of the smiley.
Without going to modern, future, or virtual and writing
a long post I will just ask where to I get a Forth for
my Intel iapx432? How much does it cost? Is it PD? ;-)
Ed Beroset
Ed Beroset
>It is just nuts to suggest that instead of gaining an
>understanding of the issues first that he should just
>put his career on the line and suggest using Forth
>in a project that we have heard _nothing_ about.
I like to think they're not quite that close to booting me out the
door!
>Ed does not appear to be the fool that you want to
>make him out to be.
I don't think Ms. Rather is making a fool out me. In the proud
tradition of DIY, I can do that myself! ;-) Seriously, while it
seems that you have understood what I've written, I think you're
misinterpreting both the substance and intent of her reply to me. I
wasn't insulted by what she wrote (and I don't think she meant it to
be insulting) and I certainly hope she doesn't feel insulted by what
I've written (and I didn't mean to be insulting).
Usenet is a generally contentious places -- let's try hard not to let
c.l.f. slip into that practice. By my reading, it's a pretty
civilized and congenial place and I think it's an atmosphere and a
resource worth preserving. Don't you?
Ed
Jeff Fox
> Usenet is a generally contentious places -- let's try hard not to let
> c.l.f. slip into that practice. By my reading, it's a pretty
> civilized and congenial place and I think it's an atmosphere and a
> resource worth preserving. Don't you?
Yes I agree for the most part that c.l.f is well above
average and fairly civilized with the exception of
certain topics which always seem to result in
things heating up a bit.
Certain subjects like newbies, DIY, YAFI,
Chuck's changes to his Forth in the last
twenty years or his chips or what he says
about Forth are all subjects that are likely
to get very polarized responses in c.l.f.
at best. Things remain civilized for the most part
until any of those subjects come up. Someday
I may feel pushed far enough to say what
I really think about those things like I do in
some emails. ;-)
I let most stuff slide most of the time.
Gary Chanson
"Coos Haak" <j.j....@hccnet.nl> wrote in message
news:9u3tcd$nkg$1...@news.hccnet.nl...
The Philips TriMedia.
Marcel Hendrix
Ed:
> How 'bout the NEC uPD172xx series?
Pijnenburg had one in their Evolution crosscompiler environment.
How about a Shark, Intel '860, Itanium, Burroughs B7700, ST7?
-marcel
Sébastien Furic
Coos Haak a écrit :
Sharp SC62015 aka "ESR-L"
Sebastien.
Anton Ertl
m...@iaehv.iae.nl (Marcel Hendrix) writes:
[Name one processor that has no Forth written for it]
>How about a Shark, Intel '860, Itanium, Burroughs B7700, ST7?
Itanium: Gforth (and probably also PFE and some others)
Sharc: maybe Gforth (there's a Sharc directory in Gforth, don't know
if the port works).
Anton Ertl
Jerry Avins <j...@ieee.org> writes:
>Ed Beroset wrote:
>> foreign a phrase like "The xt table for dealing with control
>> characters in ACCEPT was built using the '] ... [' technique," might
>> seem.)
>
>You probably know that '[' turns of the compiler and ']' turns it on. So
>we can at least guess what the technique involves. I suspect it's
>something that one needs to know in order to write a good compiler, and
>for very little else.
No, it's not needed for a good compiler, and actually it does not work
with sophisticated compilers, it only works with plain threaded code
systems.
It's the technique of building a table of xts like this:
create table ] word1 word2 word3 [
instead of the standard-compliant
create table ' word1 , ' word2 , ' word3 ,
This technique works in traditional threaded code systems because they
lay down one xt for every word they compile. It does not work in a
primitive-centric system that compiles a colon definition into the xt
of CALL and a body address.
a...@redhat.invalid
> a...@redhat.invalid writes:
>> He's making the point, I believe, that an optimizing native code
>> compiler can be made entirely compatible with words that manipulate
>> the return stack in interesting ways, and that there are some
>> advantages in doing so. I agree.
> But you can never standardize on that behavior.
You can go a lot of the way. For instance:
: foo bar ;
: bar baz abort ;
: baz r> drop ;
foo will not abort. There's nothing in principle to stop this
behaviour being standardized, except that it would be incompatible
with some implementation techniques.
> Of course, if a system wishes to implement system behavior that way
> instead of using code words, that's great. But an application
> should never have to rely upon behind-the-scenes behavior.
Of course that's true, but we've lost some useful opportunities as
well as gaining standardization.
Andrew.
Stephen Pelc
wrote:
>Why is "Standing up for DIY" so unpopular?
All successful software projects that I have come across,
including an 850,000+ lines of source Forth project, use
a layered approach to the project.
Each layer promotes a higher level of abstraction for the
layer above.
There's a layer below which the company decides it doesn't
want to go, usually when the layer (e.g. Forth compiler) has
nothing to do with the company's core business (e.g. civil
engineering).
It is just cheaper in most cases to buy in what you need
for a commercial operation.
The other problem (and probably the more severe one) is
that people end up concentrating on Forth kernels rather
than on the higher levels (e.g. TCP/IP stacks and GUIs)
that make the language useful. The commercial Forth vendors
have actually written very few kernels, but have written
a vast amount of library code and tools to make programmers'
lives much easier.
Jeff, you and I are just never going to agree on this issue.
When it comes to the productivity of one approach or the other,
I am always reminded that Digital took the standard tool route
and delivered the first StrongARM CPU in 18 months. Direct
descendants of this CPU are now available in XScale form
running at 800MHz. It may not be the the very best approach
in terms of performance, but it works.
Stephen
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Petrus Prawirodidjojo
1. Forth attracts particular/specific user. Forth is not an ordinary
language
a. rpn, which is closer to Japanese, subject object predicate
b. knowledge of number system is required, at least 16 bit integer, sign
and unsign
c. close to machine language
Probably this kind of people tend to do it oneself, Bernd's motto. And have
other characteristics that all of you have known.
2. Forth is unusual, and the documentation is not good enough. The
documentations
a. explain simple things like stack
b. how to use it
But fail to explain why. The above a and b maybe sufficient for a database
programmer, but not for Forthers. But a database programmer will not like
Forth.
3. Some will become fanatics, and forget the purpose of a programming
language. Just like some Harley Davidson fans, they clean the motor
everyday, add new accesories but do not ride. So I think this is natural,
because there are plenty of examples.
Others have no time to continue, that is making apps. They are occupied by
improving the system, benchmark and benchmark. Adding words, and words.
I look at students, and the one who study mechanical engineering are open,
they may shout and noisy, but the one who study electrical engineering are
"shy", they talk slowly. And I conclude that it is by nature each department
attract specific student. And I can not expect someone who learn Forth will
only use it. Forthers are likely to disassemble and then reassemble a system
:-).
Petrus.
"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:3C04D2B0...@gmx.de...
> "Elizabeth D. Rather" schrieb:
> > From my perspective as one who is concerned to see the use of
> > Forth spread among professional programmers, the issue is that
> > a DIY Forth is fun and educational to the implementor, but the energy
> > expended is wasted as far as advancing the language is concerned.
>
> Totally agreed. The main problem with a DIY Forth is that people really
> just got the basics from books like SF, and don't know about all the
> other tricky stuff that's needed for a Forth system. E.g. some time ago,
> I had a coworker who claimed to have written his own Forth on the C64.
> Back then, we developed a small CPU, and I proposed to write the
> assembler in Forth. When I told him that I use the Forth interpreter to
> execute these very simple commands, it was completely new for him. He
> didn't even think that Forth was a good choice to write an assembler in!
>
> > Forth was designed to be _used_.
>
> Most of the DIY people think that Forth was designed to be implemented,
> and not to be used. They don't know how to use it, and they treat it as
> nice little toy language, easy to build, but useless.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> http://www.jwdt.com/~paysan/
Jeff Fox
>
> There are several reasons for DIY.
> Forthers are likely to disassemble and then
> reassemble a system :-).
A small percentage of children will disassemble
their toys and other things that they find
in their household. A subset of that group
is able to reassemble them. I'll bet we get
a lot of those folks in Forth.
We are a very currious group of weirdos,
missfits, rebels, and human oddities but
we do have fun when we get together. I'll
bet that that is also another problem for
the folks trying to fight Forth's reputation
and maintain a professional image. I have
heard a few people's first reactions to
seeing our group at SVFIG meetings.
My brother once attended and one look was
all that was needed to confirm to him
everything that he had heard about Forth
which wasn't much and wasn't from me.
Apparently all he had heard was reputation
stories... He asked me how many Forth
programmers does it take to prepare dinner?
Bernd Paysan
> If you studied a natural language and learned by heart the grammar,
> but then found out that native speakers speak differently,
> how would you resolve that?
Native speakers typically speak a more modern dialect as written
language. If you learn German and go to Bavaria, you'd be quite
surprised ;-). However, the answer is: People react by correcting the
native speakers.
Bernd Paysan
> Sharc: maybe Gforth (there's a Sharc directory in Gforth, don't know
> if the port works).
The port works, but the library supplied by the Sharc doesn't work, and
I didn't have the time to rewrite this damn'd stuff (mainly because the
Sharc needs it's complicated protocol for the downloader, but I want to
have a simple terminal afterwards).
Bernd Paysan
> Since the goal is low cost and high performance
> the lower than normal gate density might look
> like a problem unless you realize that it is
> actually one of the ways to reduce the overall
> use of chip real estate by orders of magnitude.
??? It's the simplicity of the underlying architecture that reduces the
chip real estate by orders of magnitude. I've seen it. c18 is half SRAM
(the 192 words + 96 words ROM), another third stacks (arrays of
latches), and one sixth ALU. This relation doesn't change if you improve
the density of the SRAM cells, the latches, and the ALU gates; the
result would be that the overall chip is simply smaller. Chuck has a
metal utilization of about 10%, so there's no problem with routing if he
gets smaller cells. Not that you care if you can fit 25, 50, or 100 c18
on a minimum die, where the main question still is: what do you do with
MIPS for free? In any case, you have difficulties to utilize all the
c18s.
Chuck's tiled approach is like threaded code: it is simple, but it
wastes some space (TC wastes time). It however makes porting much easier
(porting with chips typically means shrinking). I'm sure Chuck knows
about the tradeoff of both concepts, and he knows why he has chose one
route (and might choose the other route next time). A "standard cell"
approach would still somehow work with OKAD II's approach, but the short
definitions for cells would become longer (because now, the cells are
defined in terms of tiles, rather than being tiles themselves).
Bernd Paysan
>
> In article <3C04D5FE...@gmx.de>,
> Bernd Paysan <bernd....@gmx.de> writes:
> >Same with the documentation. I'd like to offload much of the
> >documentation process to other people. It doesn't work.
>
> It does. Neal Crook did a lot of documentation work between 0.4.0 and
> 0.5.0, and as a result the Gforth manual is quite presentable
> nowadays.
Indeed it did work for Gforth. But for bigFORTH, where I have already a
load of German documentation, and all I was looking for was some people
who translate that stuff, it didn't work.
Bernd Paysan
> And as to species that do not survive such transportation...
> Some folks wrote the TCP/IP stack using CELL but meaning
> 4 bytes.
Indeed, because there's nothing in ANS Forth that allows you to specify
4 bytes, when you mean 4 bytes. You might be able to write a portable
PPP implementation (with TCP/IP over PPP), because PPP is defined in
terms of ASCII characters, and there are ASCII characters in ANS Forth.
a...@redhat.invalid
> a...@redhat.invalid wrote:
>>
>> However, I don't understand how making : immediate adds an iota of
>> programmer friendliness. That's what I means when I said this was a
>> bug: it's a feature that adds some inconvenience for zero gain.
> As to programmer-friendlyness...
> Imagine that some guy calls you and says that the definition
> : 3DUP 2 PICK 2 PICK 2 PICK ;
> aborts with the message "3DUP -?".
> What might it be?
Err, missing semicolon? What else might it be?
Andrew.
Trey Boudreau
>
>Apparently all he had heard was reputation
>stories... He asked me how many Forth
>programmers does it take to prepare dinner?
>
-- Trey
J E Thomas
> Apparently all he had heard was reputation
> stories... He asked me how many Forth
> programmers does it take to prepare dinner?
OK, I'll bite.
How many Forth programmers does it take to prepare dinner?
Here's my first guess:
One. And it's ready quicker than you'd expect.
But the carrots are sliced in an unusual direction and the meat has an
unfamiliar sauce -- good, but not what you'd expect. And the forks all
have a little curlique on one of the tines that perhaps makes it work
better than a regular fork but leaves it not looking like a fork.
And some people would argue that leaving aside whether you like the
result, it would be cheaper and easier to go to McDonald's. They have
served a standard product over fifty billion times now, and they have
economy of scale.
Jeff Fox
> Chuck's tiled approach is like threaded code: it is simple,
> but it wastes some space (TC wastes time). It however makes
> porting much easier (porting with chips typically means shrinking).
Yes. That is exactly right. But since the chips have all
been constrained mostly by the pad ring specifications, which
are far less flexible than what you do inside of the chip
at certain fabs, Chuck's earlier chips were 50% to 70%
white space, completely wasted. On 25x this has dropped
to a much smaller number.
You have the tradeoffs exactly right. On 25x the design
has wasted space. That space costs money and the waste
adds to the cost of the chip just like it does on every
other chip. But since we are not talking about expensive
chips and are talking about $.15 worth of silicon total
we are talking about an extra cost of a penny or two at
most. That is not exactly something that I would complain
about very much.
Especially considering that the benefit of that $.01
cost is that it might save you $100,000 or more since
scaling is then almost free. I don't wince over a $.01
expense, well not much, but I do over $100,000. ;-)
I mean really big companies have spent billions on
a port. This penny or two gives you ports almmost
for free.
> I'm sure Chuck knows about the tradeoff of both concepts,
Gee, do you really think so?
> and he knows why he has chose one route (and might choose
> the other route next time).
You got that right. He is very hard to predict.
> A "standard cell" approach would still somehow work
> with OKAD II's approach, but the short definitions
> for cells would become longer (because now, the cells are
> defined in terms of tiles, rather than being tiles themselves).
You lost me there. OKAD was about editing the tiles
themselves, it also was limited by GDSII format restrictions.
That was way back in "the map is not the territory" days.
That goes back to the sources programming phase and all
that a decade ago.
Chuck did what he always does, he took the problems with
the first version and exploited them as advantanges in
the second version where GDSII constraints have very
small problems and big advantages to the new approach.
Chuck understood the problem better after working on
it exclusively for the first ten years.
OKAD II is all about defining a library of components
in Forth. OKAD II is written in Forth. In OKAD colorForth
was a scripting language added in the last few years. In
OKAD II colorForth is used a systems language and is the
OS. Chuck's component library is written in Forth.
This library is very much like a standard cell library except
that they are all Chuck's proprietary library components.
He started this whole process by studying the NSA's
VLSI library to see how they did it and them make
his own set of library components that were about
20 times more efficient that the "standard" ones
which are intentionally inefficient to make up
for the fact that the standard CAD programs are
so inefficient that they won't work reliably
unless you keep them 1000% away from the
cutting edge where Chuck wants to be.
You might appreciate that one important
difference in the library is that there are
lots of things that are not there. That is
they aren't needed by Chuck because his version
of library components are like his Forth code.
His library components have far fewer gates
than standard components and that is part of
why they are so much faster. Just like Chuck's
approach to software.
But I don't really understand your point. How what Chuck
is doing is really different than using standard cells?
Yes, it was different way back in OKAD where it was
about editing the layout, not editing a description.
It sounds to me like you are talking about a
previous millenium and not the 21st century version.
If I missunderstood what you meant please try again.
Best wishes,
Jeff Fox
Jeff Fox
> >stories... He asked me how many Forth
> >programmers does it take to prepare dinner?
> >
> I'll bite. How many?
Two. One to watch for cars while the other
scrapes the opossum off the road.
Hey I
Trey Boudreau
>
>I've run across C programmers that do similar things; ala
> foo ()
> {
> int a[0];
> a[-1] = a[-2];
> }
>
>It *could* be standardized, but that would result in several drawbacks:
>
1) Note that the ANSI C standard explicitly allows accessing arrays with
negative indices.
2) Depending on the above code to access something resembling a return address
falls squarely into the realm of "implementation defined" behaviour.
3) If I ever caught someone working for me writing code like that, and they
didn't document the bejeebers out of why-when-and-how, they would find
themselves on the receiving end of a your-future-with-this-company kind of
speech.
I don't know if you intended to say 1), but I think you intended to say 2).
-- Trey
Albert van der Horst
>While a full blown optimizing compiler may be quite an extensive
>amount of work, a simpler compiler is manageable. A compiler is an
>application, so writing a compiler should be counted as worthwhile
>learning experience. Since a simple compiler is still quite large and
>with complex and interrelated components, you're bound to use a majority
>of the features and become well acquainted with how to best use
>the language to deal with large projects.
This depends strongly on the language. A classic Pascal compiler is
a two weeks assignment for a student and could be two evenings work
for a professional well versed in lex and yacc. That is because
PASCAL fits those tools, by the way. But in fact you don't design.
Compared to that a Forth compiler is much more work, because the
standard concerns itself with a lot of real world intricacies.
If I port an existing design, two weeks is not impossible. But
that doesn't count probably as writing a compiler.
(I chalked my Intel to Alpha port of ciforth up under "porting
experience" not under "compiler experience").
Everybody seriously considering doing a C++ implementation plus
standard library as a learning experience is either out of his mind,
or doesn't know what he is talking about. Even a genius wouldn't cope
with that. A master mason can't build a cathedral in a week, there are
just too many bricks. Each one cost at least a few seconds to handle.
Regularly conflicts between two sections of the standard are detected
with C++ because nobody in the world has gone into these specific two
sections deeply.
So I suspect that talking about writing compilers in general
borders to nonsense.
Back to your valid question:
Is writing a Forth compiler valuable for learning Forth?
I think yes. After you have done a lot of Forth programming
to guide you in selecting features, etc. etc.
Not as a starter, no. But from day one, you are entitled to
change feature from your compiler that you don't like.
That is part of Forth.
>Darin Johnson
> Gravity is a harsh mistress -- The Tick
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
James Hague <jamesh@volition-inc_fake.com> wrote:
>X-no-archive: yes
> Answering Anton Ertl :
>
>I didn't mean it that way. Gforth works quite well under Windows. Mostly I
>meant that Gforth is (currently) a threaded system, so it's not what I would
>consider a modern Forth implementation.
You must be kidding.
Albert.
--
M Joonas Pihlaja
On Wed, 28 Nov 2001, Michael L.Gassanenko wrote:
[snip]
> You are not trying to learn Forth by implementing it, are you?
No, not exactly. More like penetrating into Forth better. BTW,
thank's very much for the interesting subthread about [COMPILE]
and POSTPONE .
> In general, you do not learn a language by implementing it.
> First you use some implementation which you think of as
> "canonical", then, if there is some motivation, you can
> implement your own Forth and learn more.
I'm mostly using gforth for my Forthing needs -- the DIY Forth
was for a target that didn't have one, and I thought it might be
nice to familiarise myself with the target and (traditional)
Forth internals. The main reference I used was Brad Rodriguez's
Moving Forth articles & source code (esp. Z80 version) in The
Computer Journal.
Now, I *could* have gotten experience from say peeking at Gforth
internals and working with that implementation strategy. The
problem with that approach is that modern Forth's are too
complicated to penetrate exactly because they are so optimised
and advanced.
Anyway, the thing that was most gratifying was seeing how the
system developed in complexity -- from writing primitives and
testing various threading strategies, using the primitives to
create basic supporting words, using them to make slightly more
complex ones, ... and ending up writing a resident assembler.
Re: Writing Forth in Forth vs. assembler: most code is indeed in
Forth, as data statements in assembler. At least until I got
file access working. Tried creating a metacompiler a la
Rodriguez's CHROMIUM2, but it was beyond me. (No wonder.)
> If you do not know what to write in your Forth, write
> 1) a decompiler
Done that, although I have to admit it is absolutely crap
compared to all other decompilers I've seen. The dis/assembler
is better, but I consider all that to be a part of the system,
not an application itself.
> 2) the WHEREUSED <name> utility
No locate fields in the headers I'm afraid... Not much point in
having them when the target I/O system doesn't guarantee *any*
input source other than the keyboard. I do support files if the
capability exists, so adding a locate field would be a good idea.
Regards,
Joonas
Line Noise
> Line Noise wrote:
>
> > It is the "never be used" part that depresices some folks.
> >
> > Line Noise
>
> I guess... I lost any coherent meaning in all
> the damn line noise or something, oh well, it's
> just usenet. ;-)
>
> Jeff Fox
> http://www.UltraTechnology.com
Dear Jeff: I am sorry if the meaning got lost in my message. I realise
that I was unclear as to the core argument of why some folks are saddend
to see posts about DIY 4th.
So to state it simply programers produce applications. Some of these
applications are tools for producing other applications. We can clasify
every app into 2 catagories; those apps that are the final gole whith
which we will improve our lives; those apps that are used to create apps
in the other catagorie.
Only programers put programing languages in the first catagorie.
Every programing language has a host of programers, who spend thair time
split between extending and/or improving the language so that it can be
used more efficatnly, and time spent using that language to produce
programs for end users.
Maney peaple feel that 4th programers spend alomst all thair time
improving or re-inventing 4th and thus have no time left to use 4th to
produce aney other type of app. It is almost like 4th's eligence, power
and simplicity where a kind of phyological virus. That aney one who was
bouth interested and inteligent enough to value 4th becames compeled to
spend all there "4th-time" improving 4th. For maney 4th programers 4th
has gone from being a tool used to achieve a gole; to being the gole in
and of it-self.
I used Chuck Moor as the ultamate example of a DIY 4th programer who has
does stuningly beautifull work on inproving 4th (and chips made to run
4th) but relitivly little work on using said 4th to produce user apps
that don't allready exist elswhere.
As you have pointed out my details where in error, it was not Chuck Moor
but rather you - using some of Mr. Moor's technology, who I should have
been using as an example. Thankyou for refreshing my memory. But I
believe that you can see how the substance of this example is, in this
rare case, unafected by the spasifics of the example.
Wheather it was yourself or Mr. Moor who deminstrated brilance in the
field of tool creation combined whith dullness in the field of tool use
is a moot point. The fact remains that 4th is a programing tool that is
under utilised.
You gave examples of this under utlisation your-self. To make my
prievous point I used the example of a PDA that I have that does not do
aneything spatacular, and which probably won't do aneything spatacular
in the future. I then said that these same spatacular thing would alosw
not be doen by a PDA whith chuck's chip in it. In a humorous aside you
joked that i was aware of some PDA project that Mr. Moor had in the
works, which is of course a silly idea. I stated that Mr. Moor's PDA
would not have spatacular applications becous all his time would be
consumed improving forth, leaving none to program the afore mentioned
spatacular applications, or to teach kids to program in 4th.
You then proved my supitions. In your followup post you said:
> Just for the record the chip design was optimized to run
> AI, voice and face recognition, provide sub-nanosecond I/O
> interface, route gigabit data streams, and to operate as
> a node in a scalable multiprocessor. I really should say it
> was first optimized to be inexpensive and low-
> (electrical)power and then optimized for performance
> on the above classes of problems.
So it is not a lack of hardwhare that is the couse of the non-exestance
of these spatacular applications. When i assumed that there might by a
shortage of programers knolegible about chuck's 4th you replied:
> There are of course people who are very familiar with
> all of the chips that Chuck has designed, including
> the people who own them.
So it is not a lack of wetwhare iether. In the case of voice recognition
you need only look at my spelling to see that it is not a lack of
costomers hungrey for product. So what is it that is lacking? The will
of 4th programers to program aneything other than yet an other version
or improvment of yet anouther 4th is lacking!
When i sugest that Mr. Moor is too bussey improving/re-inventing 4th to
teach kids, you conferm my fears by saying:
> I think this is why he said in this years
> persentation to FIG that he thinks that the next
> generation of Forth should be made more attractive
> to a younger audience.
What about the present audience! _sigh_ So he has no plan to instruct
the presant generation of kids untill he has writen a sutible next
generation of 4th, and what is true for Moor is true for maney more
DIY's - no time to teach. So the vast majority of kids who learn 4th
learn it on thair own by studing the code of versions of 4th writen in
4th, or by getting a book on 4th which expliands how to implament 4th in
4th. When they learn 4th the first thing those kids code in 4th is thair
own version of 4th, and so the cycle continues.
Now I am not saying that aney of this is nassarly a bad thing. I think
DIY 4th's are great. I think 4th is eligent, powerfull and beautifull.
I thing one of the best things you can do in 4th is roll your own 4th.
But i realise that the best 4th programers are typicaly going to lavish
most of thair skill on inproving the tool and less on coding some
hear-to-for imposible application. If DIY want to spend time on
improving the tools - so be it. After all AI will still get writen, it
will just get writen by LISPers since AI is what they are hung up about.
Jeff I hope this post does not greatly offend you, as my last post seem
to do, and that i have cleared up aney confusion as to why some folks
seem to dispair when they here of yet-another-4th by some budding DIYer.
Michael L.Gassanenko
>
> On Wed, 28 Nov 2001, Michael L.Gassanenko wrote:
>
> [snip]
> > You are not trying to learn Forth by implementing it, are you?
>
> No, not exactly. More like penetrating into Forth better. BTW,
> thank's very much for the interesting subthread about [COMPILE]
> and POSTPONE .
>
> > In general, you do not learn a language by implementing it.
> > First you use some implementation which you think of as
> > "canonical", then, if there is some motivation, you can
> > implement your own Forth and learn more.
>
> I'm mostly using gforth for my Forthing needs -- the DIY Forth
> was for a target that didn't have one, and I thought it might be
> nice to familiarise myself with the target and (traditional)
> Forth internals. The main reference I used was Brad Rodriguez's
> Moving Forth articles & source code (esp. Z80 version) in The
> Computer Journal.
>
> Now, I *could* have gotten experience from say peeking at Gforth
> internals and working with that implementation strategy.
Oh, NO!
Not gForth!
Have a look at Win32Forth, it's a normal threaded code Forth.
GForth looks as if its authors were trying to construct a
refutation by a counter-example to the ANS Forth document,
[BTW, they indeed managed to discover problems at POSTPONE,
FIND and semantics]
but then forgot that it was a sarcastic joke.
> The
> problem with that approach is that modern Forth's are too
> complicated to penetrate exactly because they are so optimised
> and advanced.
Look at Win32Forth. It's fat, but simple.
>
> Anyway, the thing that was most gratifying was seeing how the
> system developed in complexity -- from writing primitives and
> testing various threading strategies, using the primitives to
> create basic supporting words, using them to make slightly more
> complex ones, ... and ending up writing a resident assembler.
>
> Re: Writing Forth in Forth vs. assembler: most code is indeed in
> Forth, as data statements in assembler. At least until I got
> file access working. Tried creating a metacompiler a la
> Rodriguez's CHROMIUM2, but it was beyond me. (No wonder.)
>
> > If you do not know what to write in your Forth, write
> > 1) a decompiler
>
> Done that, although I have to admit it is absolutely crap
> compared to all other decompilers I've seen. The dis/assembler
> is better, but I consider all that to be a part of the system,
> not an application itself.
Assembler and disassembler are Forth applications.
In principle, you can write the output to the file
or load it into the target memory via a RS-232 line
(if you have a target board).
But these applications have hooks that allow them to be
used as a part of the system. As to the assembler, these
hook words are mostly CODE, END-CODE, and the words that
access the memory, e.g. T, T! T@ TC, TC! TC@ (in principle,
the asembler may use , @ ! C, C@ C! ).
>
> > 2) the WHEREUSED <name> utility
>
> No locate fields in the headers I'm afraid... Not much point in
> having them when the target I/O system doesn't guarantee *any*
> input source other than the keyboard. I do support files if the
> capability exists, so adding a locate field would be a good idea.
>
YOU DO NOT NEED LOCATE FIELDS.
You decompile all words in the system and report which words
contain the word of interest.
For example:
whereused TUCK
in (D.) ---- [4181000] TUCK DABS <#
in -COUNT ---- SWAP 1- ( CHAR- ) TUCK C! EXIT
in CH> ---- >IN @ TUCK > >R
in H>NEXT>H ---- DUP @ TUCK <> AND
in _hlp_?more ---- [7571206f"o qu"] [7469"it"] TUCK TYPE KEYPAUSE
in SS$PREF? ---- 0 ( FALSE ) EXIT TUCK COMPARE 0=
in $help ---- (S") [2a2a2a03"***"] TUCK COMPARE 0= ok[Dec]
Boundaries of words you know from the word list headers.
Of course, in the following example
: x ;
ALIGN 100 CELLS ALLOT CONSTANT y
the 100 allotted cells may be misattributed to x.
How it works:
see :
: : donest CF, LASTCF ( IT ) ALIAS HIDE ] !CSP RESET-LOCALS EXIT ok[Dec]
' :
ok( $4004934 )[Dec]
15 +
ok( $4004943{[4]"XD"} )[Dec]
WORD-BEFORE
ok( $4004934 )[Dec]
>.NAMES
: ok[Dec]
Michael L.Gassanenko
??? [COMPILE] must compile the state-sensitive semantics ???
{END-BRIEFLY}
Darin Johnson wrote:
>
> "Michael L.Gassanenko" <m_l...@yahoo.com> writes:
>
> > > As for confusing, if you look at the ANS descriptions, POSTPONE has an
> > > extremely simple definition, whereas [COMPILE] is the confusing one.
> >
> > Ok.
> > : foo STATE @ IF ." welcome " ELSE ." goodbye " THEN ; IMMEDIATE
> > : bar POSTPONE foo ;
> > bar
>
> Well, given that foo's action is ambiguous and depends upon what the
No, foo's action is not ambiguous.
Compilation: print "welcome"
Interpretation: print "goodbye"
What do you mean under 'ambiguous'?
> current STATE is, then bar is also ambiguous and depends upon what
> STATE is. I don't really see a big problem.
>
> This code is no less ambiguous than the POSTPONE version
> : bar [COMPILE] foo ;
> Since foo has non-default compilation semantics, [COMPILE] and
> POSTPONE will do the same thing with it. What's ambiguous about
> POSTPONE that is not ambiguous with [COMPILE]?
There are problems in the formulation of what POSTPONE and [COMPILE]
do. The original RFI was formulated somehow like:
: myS" POSTPONE S" ;
: my( POSTPONE ( ;
The compilation semantics of S" is to compile a string literal.
Depending on the implementation, myS" may be or not be
equivalent to S" in the interpretation state.
But if execution of POSTPONEd things in interpretation state
is ambiguous, my( does not work.
---
But you are right, [COMPILE] must compile the state-sensitive semantics.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> My point about confusion is that POSTPONE has a simple defintion
> (append the compilation semantics), whereas [COMPILE] has the more
> complex definition (if the following word has non-default compilation
> semantics, append those, otherwise append its execution semantics).
>
The definition of [COMPILE] is complex only in ANS Forth.
: [COMPILE] ' COMPILE, ; IMMEDIATE
You may try to invent a better formulation of what [COMPILE] does
in the ANS Forth English.
Why?
1) Because the TC tried to express implementation options
with language ambiguity.
2) Because Mr Moore has developed multiple incompatible approaches.
(An exapmle of a technique that has been rejected by the TC:
the word ] was responsible for text compilation and [ was responsible
for text interpretation. Advantage: no STATE @ IF was needed.
Disadvantage: incompatibility with all Forth standards.)
M Joonas Pihlaja
First off, thanks for everyone who contributed to the subject of
this thread (or the interesting subthreads). Perhaps I shouldn't
have asked about such a sensitive topic, but at least the
question was answered quite extensively from many different
points of view. What could be more satisfying than that? :-)
I should probably just point out that in my original message I
didn't mean to imply that people must learn Forth by DIY, or that
that's how I started.
On Fri, 30 Nov 2001, Michael L.Gassanenko wrote:
[snip]
> Look at Win32Forth. It's fat, but simple.
Thanks for the pointer. Unfortunately I've not got a Windows
machine.
> > > 2) the WHEREUSED <name> utility
[snip I said that I had no locate fields]
> YOU DO NOT NEED LOCATE FIELDS.
>
> You decompile all words in the system and report which words
> contain the word of interest.
Ah, I see. In my rush to reply I somehow managed to understand
it as the equivalent of LOCATE <word> . (Obviously my
subconscious is nagging me about the lack of a LOCATE word.
Freudian slip.) Sorry for the confusion. :-/
Regards,
Joonas
Michael L.Gassanenko
>
> a...@redhat.invalid writes:
>
> > : foo bar ;
> > : bar baz abort ;
> > : baz r> drop ;
> >
> > foo will not abort. There's nothing in principle to stop this
> > behaviour being standardized, except that it would be incompatible
> > with some implementation techniques.
>
> that other languages are only used by duffers, and think ANS Forth was
> a step backwards for mankind, cover their ears now.)
>
> Doing such things fall squarely in the category of stupid-programmer-tricks.
>
> Yes, it may work. But only as a side effect of the implementation
> technique used in many Forths. Relying upon side effects is never a
> good idea.
It's not a side effect. It's a part of the virtul machine
specification.
BTW, the use of thereaded code is not necessary
for return address manipulations to work.
You can extend the [threaded] code interpretation
scheme with the means that suit your problem better.
There is even a formal description of how return address
manipulations affect the control flow.
> The reason it worked in the past is that older Forth's
> were defined in terms of implementation rather than in language
> semantics.
It's not important. Many discoveries were made only
because someone did not wash the Petri dishes well.
[...]
>
> And there's very little need to do such things. If there is a useful
> function that could be done by using such techniques, then either
> create a high level word to accomplish such things, or rethink if
> there's another way to accomplish it.
http://www.forth.org.ru/~mlg/ef99/gassanenko99b.pdf
2.2 Data execution with customized data interpreter
: ENTER >R ;
: el R@ ENTER DROP ;
: .{} CR ." { " DEPTH 0 ?DO I PICK COUNT TYPE SPACE LOOP ." } " ;
: subsets C" first" el C" second" el C" third" el .{} ;
subsets
{ third second first }
{ second first }
{ third first }
{ first }
{ third second }
{ second }
{ third }
{ } ok
This program is a toy, but it shows the method.
Of course, programmers that do not know techniques
cannot support code that uses these techniques.
This is true for any techniques.
---
[in some other message]
> That's exactly my point. Pulling something off the return stack that
> you didn't put there is no different from relying upon implementation
> defined behavior in other languages.
What means "you"?
When I call a colon definition, I require placing
the corresponding return address onto the return stack.
I understand that I need Open Interpreter.
What we can agree upon is that you consider the return stack
as an internal mechanism while I consider it as a part
of the virtual machine.
Anyway, you cannot persuade me not to extend the virtual
machine spec to what I find useful at least sometimes.
BTW, now you probably see why I call ANS Forth a subset of Forth.
To me, Forth includes open interpreter, access to headers, etc.
The standard has drawn a dividing line between so-called portable
and so-called unportable code, between so-called compliant and
so-called non-compliant systems.
But this dividing line is a result of committee's decision.
The properties "standard" [of programs] and "compliant" [of systems]
do not reflect something that could be measured if there was no
ANS Forth standard.
The committee could draw the dividing line differently, and
we would call some other set of techniques "portable".
(You see that here I speak as a researcher.)
As to real life problems programming, it's always your
responsibility to decide which VM functionality you need.
For example, if you need threaded code, there is a cost in
execution speed, but the cost may be acceptable, while the
gain may be significant, I mean, in your particular case.
If you need something unstandard, the same reasoning applies:
you have to compare the cost and the benefit.
BTW, this reasoning applies even when you want to use something
standard, for example, ANS Forth locals, or EVALUATE at run-time.
--
regards, mlg
http://www.forth.org.ru/~mlg/
Bernd Paysan
> But I don't really understand your point. How what Chuck
> is doing is really different than using standard cells?
The difference is small, after all, OKAD has a library of cells, and
these cells are "standard cells" within OKAD. But they are composed out
of smaller parts, the tiles. These tiles already have position and shape
restrictions (that's the whole idea of a tile). These restrictions are
similar to those of a place & route tool, there's a grid, there are
standardized components. The real restrictions (design rules) are less
strict than the restrictions of a tile. Therefore, by drawing the cells
with a less strict approach (no tiles, just process-specific design
rules) would make them smaller. They will still be Chuck's cells,
because I don't think he'll use standard TSMC cells (or at least he'd
want to replace some of the TSMC cells).
The design layer in OKAD is
Design -> Tiles -> Mask data
The layer of my proporsal would be
Design -> Cells + routing tiles -> Mask data
I.e. the cells would be specified in terms of mask data (with minimal
restrictions) instead of tiles (more restrictions). It's more work to
draw the cells, then. And the extractor for the simulator would stop at
the cell level, and use precomputed models of them.
Anton Ertl
"Michael L.Gassanenko" <m_l...@yahoo.com> writes:
>M Joonas Pihlaja wrote:
...
>GForth looks as if its authors were trying to construct a
>refutation by a counter-example to the ANS Forth document,
ANS Forth makes no universal claim that could be refuted by a
counterexample. As for the goals of Gforth, they are stated at the
start of the manual. I include them at the end of this message.
>[BTW, they indeed managed to discover problems at POSTPONE,
>FIND and semantics]
Not a problem with POSTPONE or semantics, just a problem with one
implementation technique (state-smartness). The TC eventually chose
to deal with this bye restricting what the programmer can do with
compilation semantics.
[Gforth]
>> The
>> problem with that approach is that modern Forth's are too
>> complicated to penetrate exactly because they are so optimised
>> and advanced.
Ah, one of those funny occurences when two people make two opposing
statements about the same thing: in <3c056fc7$1...@corp.newsgroups.com>
James Hague wrote that Gforth is not what he "would consider a modern
Forth implementation." It probably just means that Gforth is not an
extreme system (then there would be only comments in one direction:-).
Gforth is not extremely optimized, but it does not totally ignore
efficiency, either. It has some pretty sophisticated stuff in some
places (locals, SEE, semantics); some of that is explained in the
documentation and in various papers. If you have any question, feel
free to ask.
- anton
And here are the goals, as promised:
File: gforth.info, Node: Goals, Next: Gforth Environment, Prev: License, Up: Top
Goals of Gforth
***************
The goal of the Gforth Project is to develop a standard model for
ANS Forth. This can be split into several subgoals:
* Gforth should conform to the ANS Forth Standard.
* It should be a model, i.e. it should define all the
implementation-dependent things.
* It should become standard, i.e. widely accepted and used. This goal
is the most difficult one.
To achieve these goals Gforth should be
* Similar to previous models (fig-Forth, F83)
* Powerful. It should provide for all the things that are considered
necessary today and even some that are not yet considered
necessary.
* Efficient. It should not get the reputation of being exceptionally
slow.
* Free.
* Available on many machines/easy to port.
Have we achieved these goals? Gforth conforms to the ANS Forth
standard. It may be considered a model, but we have not yet documented
which parts of the model are stable and which parts we are likely to
change. It certainly has not yet become a de facto standard, but it
appears to be quite popular. It has some similarities to and some
differences from previous models. It has some powerful features, but not
yet everything that we envisioned. We certainly have achieved our
execution speed goals (*note Performance::)(1). It is free and
available on many machines.
---------- Footnotes ----------
(1) However, in 1998 the bar was raised when the major commercial
Forth vendors switched to native code compilers.
James Hague
>
> >I didn't mean it that way. Gforth works quite well under Windows.
Mostly I
> >meant that Gforth is (currently) a threaded system, so it's not what I
would
> >consider a modern Forth implementation.
>
> You must be kidding.
Kididng that Gforth works quite well under Windows? It does. I enjoy using
it. Kudos to the authors.
Kidding that a threaded system isn't modern? Well, it depends on your
definition of modern. You can go a long way with direct threaded Forth,
especially when you consider that PCs are hundreds of times faster than they
were in the fig-forth days. But the performance difference between
threading and native code can easily be a factor of 10 or more, so if you
want to use a Forth that's competitive with modern compilers, then native
code is the way to go.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Gary Chanson
"Darin Johnson" <da...@usa.net> wrote in message
news:cu1snaw...@thatch.nwr...
>
> I had seen some systems when looking for a suitable Forth that looked
> like they were mostly composed of Forth that was hand converted to
> assembler. Which prompted me to think "I could automate that, it's
> probably not too hard". Which prompted me to discover that people do
> something similar all the time using cross compilers written in Forth.
> And eventually I'm side-tracked into writing a cross compiler :-)
I've never seen a meta compiler which generates assember output. The
ones I'm familar with output object code.
--
-GJC
-gcha...@shore.net
-War is the last resort of the incompetent.
James Hague
>
> >> The
> >> problem with that approach is that modern Forth's are too
> >> complicated to penetrate exactly because they are so optimised
> >> and advanced.
>
> Ah, one of those funny occurences when two people make two opposing
I agree with the above sentiment about Gforth, though maybe not for the same
reason. Gforth certainly isn't the flashiest or fastest Forth out there, by
a large margin, in this day of native code generating Forths (Swift, VFX,
iForth, Power MacForth). But at the same time Gforth is certainly not a
simple system to understand when compared with other direct threaded Forths.
Whether or not that matters is personal preference.
That said, I still like Gforth and find it comfortable to use.
Coos Haak
Michael L.Gassanenko <m_l...@yahoo.com> schreef in berichtnieuws
3C074AA9...@yahoo.com...
..
> > > 2) the WHEREUSED <name> utility
> >
> > No locate fields in the headers I'm afraid... Not much point in
> > having them when the target I/O system doesn't guarantee *any*
> > input source other than the keyboard. I do support files if the
> > capability exists, so adding a locate field would be a good idea.
> >
>
> YOU DO NOT NEED LOCATE FIELDS.
> You decompile all words in the system and report which words
> contain the word of interest.
>
> For example:
>
> whereused TUCK
>
> in (D.) ---- [4181000] TUCK DABS <#
> in -COUNT ---- SWAP 1- ( CHAR- ) TUCK C! EXIT
> in CH> ---- >IN @ TUCK > >R
> in H>NEXT>H ---- DUP @ TUCK <> AND
> in _hlp_?more ---- [7571206f"o qu"] [7469"it"] TUCK TYPE KEYPAUSE
> in SS$PREF? ---- 0 ( FALSE ) EXIT TUCK COMPARE 0=
> in $help ---- (S") [2a2a2a03"***"] TUCK COMPARE 0= ok[Dec]
Now I understand, why not use the name REF (reference, see F-PC)
for this? It's shorter and easier to type, because it's used as a tool.
Coos
Coos Haak
Line Noise <l...@telus.net> schreef in berichtnieuws
1f3nds3.1rjpy2d16iyy3mN%l...@telus.net...
..
> I used Chuck Moor as the ultamate example of a DIY 4th programer who has
Please write in English that us non-native speakers can understand.
The language is Forth and not 4th
The inventor is Chuck Moore and not C. Moor.
Ok?
Coos Haak
Axel Harvey
> Line Noise <l...@telus.net> schreef [ ... ]
>
> > I used Chuck Moor as the ultamate example of a DIY 4th programer who has
>
> Please write in English that us non-native speakers can understand.
> The language is Forth and not 4th
> The inventor is Chuck Moore and not C. Moor.
>
> Ok?
Mr Line Noise may have a problem with spelling. Maybe he is not
deliberately trying to write in a way that disturbs non-native (or
native, for that matter) speakers.
Gary Chanson
"Axel Harvey" <a...@cam.org> wrote in message
news:Pine.LNX.4.10.10112...@localhost.localdomain...
Then he should invest in a good spelling checker. I think he's just
being lazy (while he makes us work harder).
Bart Lateur
>> Mr Line Noise may have a problem with spelling. Maybe he is not
>> deliberately trying to write in a way that disturbs non-native (or
>> native, for that matter) speakers.
>
> Then he should invest in a good spelling checker. I think he's just
>being lazy (while he makes us work harder).
Please don't do that.
Mr. Line Noise, as you can see, people get itchy when they see a post
under a nickname like yours. If, in addition, your writings contain a
lot of spelling errors, this works double, some people get really
snappy.
For what it's worth, it looks to me as if mr. Line Noise is not used to
writing English, or likely even reading. Judging from his domain, he's
Finnish. If you read his stuff aloud, you hear that is clear and
intelligent prose. I just think that Mr. Line Noise learned English by
hearing it, likely through pop music or television. I don't think he's
malicious.
A spell checker can do a lot. Many even cheap text editors or news/mail
programs include one. That would take the worst edge out of it.
But I don't think any spell checker would know to correct Mr. Moor to
Mr. Moore. I guess it would rather come up with "Mr. More". :-)
--
Bart.
Jeff Fox
Line Noise wrote:
> That aney one who was
> bouth interested and inteligent enough to value
> 4th becames compeled to
> spend all there "4th-time" improving 4th. For maney
> 4th programers 4th has gone from being a tool used to
> achieve a gole; to being the gole in
> and of it-self.
Absolutely. Almost evey one of us complains about
this from time to time. Chuck was one of the
first and one who complains about his most often,
but not in c.l.f of course but to FIG.
People like to also chacterize Chuck as one of
these people however and I think that that is
about as far away from the truth as one can
get. How many times has he completely
redesigned Forth in the last fifteen years?
Twice? Three if you count the first colorForth
as significantly different than the second
which I don't.
How long did it take him to do the first,
MachineForth? Over a seven year period he
spent a couple of hours to do that!
The result of those two hour were huge
over a series of years. His second
complete redesign of Forth was not much
more work for him. The third change,
where colorForth became the OS did
take longer to implement than a few
hours but whatever time it took
was more than made up in increased
productivity very quickly.
So when people try to claim that Chuck is
one of these people wasting his time redesigning
Forth instead of using it I have to step in
and say NO. It isn't true and it is insulting
to him. It also will hurt other people who
might read it and get the wrong impression
of what Chuck's software is all about,
productity.
This is very hard to get since most software
today is about profit margins and productivity
reduction is often the result. Yet people like
that or the $ and ignore the ugly parts of
getting it that way.
> I used Chuck Moor as the ultamate example of a DIY
I agree with you on that. That may another reason
that DIY is so unpopular. Chuck is a rebel and it
makes people angry who want everyone to be yoked
together and march in step. Some people really
hate the idea that not eveyone is yoked.
> but relitivly little work on using said 4th to
> produce user apps that don't allready exist elswhere.
Just the opposte. Chuck has said OKAD is a program
that he has used far far more than any other program
that he ever wrote in his life. He used this daily
full time for fifteen years. It does stuff that
didn't already exist. I has been available for
anyone who wanted to use it as a commercial
product. I have been a user. Other people have
been users.
Chuck has only redesigned Forth to match his ideas
about hardware and software and to implement new
software that never existed and does stuff that
no other software has ever done and to be USED!
This is why HE is the biggest complainer about
DIY types not just playing with Forth but
ONLY playing with Forth instead of doing what
HE does, write software for users to USE!
> I stated that Mr. Moor's PDA
> would not have spatacular applications becous all his
> time would be consumed improving forth,
That is a crock. His time is completely consumed
USING Forth to do CAD. His CAD work now is just
Forth programming.
I wrote a post to one of our maillists today where
I explained that Chuck expects the clients for his
chips to program them. He does CAD. He does
design.
He also does consulting, and anyone is free to hire
him to write your code for you. You can get your
own chip and program it yourself, you can get
him to program it. He will also program your
Pentium, or VAX or whatever for you if you
use his software consulting service at
Computer Cowboys. Check out his consulting
page at his website.
> leaving none to program the afore mentioned
> spatacular applications, or to teach kids to program in 4th.
No. The way we shared the work, he focused on CAD, I focused
on the target software. He focus on inside details. I
focused on outside details and everything else we shared
and did together.
I did consulting work with him where he recommended to
other people that they hire me to do the software. I
was the first person they hired at iTV to do the software.
Chuck focuses on hardware. That is what he wants to do.
I am glad. I can't do what he does in hardware at all,
and no one else can at this time either although I
think John Rible could make the transition fastest.
I think that there are other people who Chuck has
trained to do software more like him. And I think
those people have trained other people.
We can't expect Chuck to write everyone's software.
He thinks writing software is easy, but he can't
write everyone else's software. He thinks that
it is so easy, and so easy to learn, unless you
just have too many bad habits that you refuse to
break that it should be easy for other people too.
I said about my chip, designed for what I wanted,
not what Chuck wanted ...
> > Just for the record the chip design was optimized to run
> > AI, voice and face recognition, provide sub-nanosecond I/O
> > interface, route gigabit data streams, and to operate as
> > a node in a scalable multiprocessor. I really should say it
> > was first optimized to be inexpensive and low-
> > (electrical)power and then optimized for performance
> > on the above classes of problems.
>
> So it is not a lack of hardwhare that is the couse of the
> non-exestance of these spatacular applications.
Much of the software exists, but due to various funding
problems with my company I have had to do software
consulting and write other people's applications for
them rather than my own for the most part.
Much of that software was written, but I didn't end
up owning the version that I wrote. So it is
just time and money issues that I haven't got my own
"better" versions yet.
It certainly has absolutely nothing to do with
Chuck redesigning Forth. ;-)
> When i assumed that there might by a
> shortage of programers knolegible about chuck's 4th you replied:
>
> > There are of course people who are very familiar with
> > all of the chips that Chuck has designed, including
> > the people who own them.
>
> So it is not a lack of wetwhare iether. In the case
> of voice recognition you need only look at my spelling
> to see that it is not a lack of
> costomers hungrey for product. So what is it that is lacking?
I did my first voice recognition and response system in
76 for a client. It was quite a lot of fun. Using it
was even more fun. I wondered what I could do if I
tried something like it on a computer millions of
times more powerful. ...
> The will
> of 4th programers to program aneything other than
> yet an other version
> or improvment of yet anouther 4th is lacking!
That isn't the problem here, or with Chuck, but it
is a rampent problem. It is also a reason that
DIY is unpopular with some people. Carried to
an extreme one could play with Forth implementations
forever and do nothing else.
But Mr. Moore is the antithesis of that. He has USED
code written in Forth more than anyone in the world.
> When i sugest that Mr. Moor is too bussey
> improving/re-inventing 4th to
> teach kids, you conferm my fears by saying:
>
> > I think this is why he said in this years
> > persentation to FIG that he thinks that the next
> > generation of Forth should be made more attractive
> > to a younger audience.
He is too busy doing work, gambling that someone
someday might be interested, and trying to survive
that he isn't going to start teaching children
or doing a thousand other things. That is true.
But it is not true that he is spending more than
a fraction of a percent of his time improving/
re-inventing Forth. I hate to see people write
things like that. Those sorts of false statements
contribute to Forth's image problems.
> What about the present audience! _sigh_ So he has
> no plan to instruct the presant generation of kids
> untill he has writen a sutible next
> generation of 4th, and what is true for Moor is true
> for maney more DIY's - no time to teach.
I have been spending a lot of my time teaching a
growing group of interested people. Chuck and I
agreed that I would take this role. But I can only
do so much of it without being paid to do it. But
no one is paying me to do anything else at the
moment so I donate some time to teaching others,
mostly in our maillists, and doing damage
control in c.l.f.
I don't know what you call kids. I guess many of
the people I teach are kids compared to Chuck or I.
Are "kids" <40 <30, <20, <15, <12 ?
I know people who consider people my age kids. ;-)
> So the vast majority of kids who learn 4th
> learn it on thair own by studing the code of versions
> of 4th writen in
> 4th, or by getting a book on 4th
> which expliands how to implament 4th in
> 4th. When they learn 4th the first thing
> those kids code in 4th is thair
> own version of 4th, and so the cycle continues.
Exactly. The problem is that a Forth compiler
is not a very "typical" application if there is
any such thing. To "learn" the most important
things you need to use it to write apps and
learn how it works. Once you know how it
works on the outside, then and only then, can one
muck around with the insides with any positive
results appearing on the outside.
Doing what you say people will learn something
about the insides, but it is the hard way to
do it and I agree completely with Elizabeth
and a lot of other people that using it provides
the most important knowledge. Then insides
become important for some people but not all.
> Now I am not saying that aney of this is
> nassarly a bad thing.
I think some of it is bad, some is good, and some
just is.
> I think DIY 4th's are great.
I think that sometimes they are and are the
only choice. But sometimes they are crap too.
> Jeff I hope this post does not greatly offend you,
It doesn't offend me at all. I don't agree at all
with your observations about the reasons for various
things being that Chuck spends so much time
redesigning Forth. No. That's not true and I
hope that I convinced you, and others, that
Chuck USES Forth for applications 95+% of the
time.
Forth is great as a game and toy for learning.
Forth is greater when used to write real programs.
I think we agree. I think most readers agree with
us too about that.
Jeff Fox
> Jeff, you and I are just never going to agree on this issue.
> When it comes to the productivity of one approach or the other,
> I am always reminded that Digital took the standard tool route
> and delivered the first StrongARM CPU in 18 months. Direct
> descendants of this CPU are now available in XScale form
> running at 800MHz. It may not be the the very best approach
> in terms of performance, but it works.
Sure. But I think we are also talking about somewhat
different things. I have been talking about DIY Forth
and where it is justified. I have been talking about
how you and Elizabeth look you are "virtually incapable"
of addressing that issue. I have been saying that you
guys have talked about everything but it. Now you
talking about Digital?
Back to the DIY topic for one last time. Sometimes
small companies or individuals developing new products
need to take a different approach than Digital to
things.
Things are different for DIY. Do I think Digital
will begin a project by taking a non-programmer
and saying, we are doing this new project in Forth
so write us a Forth from scratch so you will become
a Forth programmer then finish this project? No.
If Mom-and-Pop software house comes to me and
says this is our problem ... and I say that
the solution requires embedding a fully functional
Forth compiler with no distribution restriction and
xyz properties in their app I will tell them this. "I
will see if such a thing exists. If it doesn't then DIY
is an option." I would explain the tradeoffs
and do the research and perhaps DIY will be
the most conservative thing that they can do.
It may make the most business sense in that
enviroment.
I have detailed cases where commercial Forths
and PD Forths don't do. I have detailed examples
of where only DIY will do.
I really thought that it would improve the
"image problem" if the major vendors would not
act like the clueless newbies I mentioned in
another thread by simply refusing to admit
that your products will always be the best
choice, period. I just sounds so much like
those clueless newbies that learn a little
and go around trying to convince everyone
that Forth can solve all problems better than
anything else.
All these people have said is that in some
cases your products won't cut it and that DIY
makes sense! No one said that your products
won't work 99% of the time (not in this newsgroup
anyway, Forth haters might) or even 10% of the
time or given any estimates.
I have tried very hard to make it sound like
all I am trying to say is that in some small
percentage of the total cases your products
won't meet the requirements. I think the
fact that the major Forth vendors appear
to simply be "virtually incapable" to use
their own words, of admitting this is as
damaging to Forth's reputation, if not much
worse than clueless newbies. You should
really know better. I know that you both
know it is true.
The fact that you guys just can't bring your
selves to say it, or even address the issue
publically when asked repeatedly in no undertain
terms to admit such a simple things I think is
terrible.
I think it gives the appearance that either
you are just like the clueless newbies who
think Forth is best for everything but worse
because you should know better, or it makes
you look like the other things you say
about your products is no more true than
that they are always best for everything,
or that you simply don't read what other
people say and just respond with the same
advertizments for your products regardless
of whether people ask about PD software
or chips that you don't support or whatever.
But, OK. I agree you and I and Elizabeth will
never agree on this. I will drop it. I will
just leave it alone after saying that I think
there is a justification for standing up for
DIY and that I do not think that your
commercial products are *always* the *only*
responsible choice, and that I think you guys
look very silly for not being able to admit such
a simple thing.
Best wishes,
Jeff Fox
Jeff Fox
> The problem with that approach is that modern Forth's
> are too complicated to penetrate exactly because they
> are so optimised and advanced.
I think the because clause should be traced down to
the next level. The(se) "modern Forths" are complicated
because the chips that they are designed for are
so fabulously complicated that they require fabuluously
complicated optimizations and so the compilers are
fabulously complicated. People do call that "advanced"
and it _is_ just "too complicated to penetrate" as you
say.
So in search of performance for the sake of productivity
that is the way the hardware has evolved so that is
the way advanced optimized software works on them. Some
of those who were attracted to Forth because it was simple
feel that it has become intelectually impenetrable for all
but a few of the people on this planet. They are right about
that niche. I think there are a few of you who do understand
that code, like Anton. But when you guys start to
go into the optimization rules on those processors
I know that many people's heads are spinning around.
I realize that learning how to use such a system to
program is far from difficult to learn. But learning
everything about it, inside and out is virtually
impossible for all but a few people. So it keeps
programming in the hands of the present specialists
where it "should" be.
Of course I live where Forth made the hardware
simpler (because Forth IS simple) the way it used
to make the software simpler on simple processors.
With even simpler hardware, more closely matching Forth,
Forth becomes even simpler again. A 300 byte optimizing
compiler is NOT intellectually impenetrable. So those
who lament the passing of simple Forth really
need not. It remains an option.
The way I see it 99.9% of end users don't give
a damn about internals. I point at that, I click,
and ... happens. I do what I want to get done....
But programmers want to know more, and engineers
want to know more and that is proper.
So if you can satisfy 99.9% of the people by
just doing the job, and do it really simply
then the system also has the property that
it can be used for education and tutorials
to teach people everything that they need
to know to satisfy the 99.9% but 1000 times
more easily than the hard way.
But programmers and engineers pride themselves
and judge others by the level of difficulty
that they can handle. The 99.9% want it simple.
But the programmers and engineers jobs and livelyhoods
depend on the problems being so complicated that
those who can solve the hard problems get paid
more and are essential.
They actually *are* threatened by the idea that
there are ways a to satisfy 99.9% of the people
with something simple that isn't where their
expertise is persently located. But they
really shouldn't be. If they could learn all
the details of Pentium they will pick everything
here up in a couple of minutes and be experts.
But perhaps because learning things like Pentium
is so hard the idea of any big change like to
something entirely different is perceived as
more threatening than it really is. They seem
to think that an easy and cheap way to satisfy
the users and that it was easy to teach to
people that it would be the worst thing that
ever happened to them. It wouldn't.
Michael L.Gassanenko
1) the word 'reference' has many meanings. At least, to me.
The meanings include "a pointer", "a mention", and "about" ( ~ manual).
What's worse is that multiple meanings are relevant to programming.
For the same reason, I did not use the word "locate".
2) in my system, REF@ REF! REF, operate on references
that follow BRANCH instructions.
(I believe that code generation must be open)
Anton Ertl
"Michael L.Gassanenko" <m_l...@yahoo.com> writes:
>Darin Johnson wrote:
>> "Michael L.Gassanenko" <m_l...@yahoo.com> writes:
>{BRIEFLY}
> ??? [COMPILE] must compile the state-sensitive semantics ???
>{END-BRIEFLY}
If the [compile]d word is a state-smart user-defined word, the word it
is compiled into will be state-smart, too.
>> > : foo STATE @ IF ." welcome " ELSE ." goodbye " THEN ; IMMEDIATE
>> > : bar POSTPONE foo ;
>> > bar
...
>There are problems in the formulation of what POSTPONE and [COMPILE]
>do. The original RFI was formulated somehow like:
>
>: myS" POSTPONE S" ;
>: my( POSTPONE ( ;
>
>The compilation semantics of S" is to compile a string literal.
>Depending on the implementation, myS" may be or not be
>equivalent to S" in the interpretation state.
>But if execution of POSTPONEd things in interpretation state
>is ambiguous, my( does not work.
Right, according to the answer to RFI 99-27, my( is ambigious in
interpret state. So, according to this answer, BAR is ambiguous in
interpret state, too (and would also be if you replace POSTPONE with
[COMPILE]).
>The definition of [COMPILE] is complex only in ANS Forth.
>
>: [COMPILE] ' COMPILE, ; IMMEDIATE
: endif [compile] then ; immediate
does not work with that (there is no guarantee that "' THEN" works).
>You may try to invent a better formulation of what [COMPILE] does
>in the ANS Forth English.
That's unnecessary. Just drop [COMPILE]. It is a creature of the
single-xt-plus-immediate-flag concept and fits badly into the
two-semantics concept used in the standard; this results in a
complicated formulation in the standard.
BTW, I believe your (and other people's) confusion about POSTPONE and
related topics results from trying to avoid thinking about these
issues with the semantics concepts in the standard, and trying to fit
them in the single-xt-plus-immediate-flag concept (which does not
work). It all becomes simple and straightforward when you think about
it using the standard concepts.
If you (like many) prefer to think about this in terms of an
implementation, just think about an implementation where each named
word has two xts, one for the interpretation semantics, and one for
the compilation semantics. Or alternatively, that there are two
words, one findable when looking for the interpretation semantics, the
other when looking for the compilation semantics. I'll try to outline
the latter variant in the following:
\ assume the word is invisible until made visible for the appropriate
\ searches by INTERPRETATION or COMPILATION
\ how words are defined
\ ordinary words
code + ... end-code interpretation
: + ['] + compile, ; compilation
\ immediate words
: ( ... ; interpretation
: ( ['] ( execute ; compilation
\ compile-only words
: IF ... ; compilation
\ combined words
: s" ... ; interpretation
: s" ['] s" execute postpone sliteral ; compilation
\ how the word-parts are used:
: interpret-word ( ... addr u -- ... )
\ forget about literals for now
state @ if
find-compilation ( xt )
else
find-interpretation ( xt )
then
execute ; interpretation
...
: ' ( "name" -- xt )
parse-word find-interpretation ; interpretation
...
: postpone ( C: "name" -- )
parse-word find-compilation compile, ; compilation
Not that complex, eh?
- anton