Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

# Starting out on Forth

100 views

### Rob Spykerman

Jan 10, 2005, 9:25:12 AM1/10/05
to
Good day all. I have just begun learning forth just as a pastime and I
have just realised there is actually very little material out there
for the uninitiated. I have to say what little I have found has been
pretty good - and am currently thumbing thru' Leo Brodie's Starting
Forth.

I am not sure however if I am doing it mm... right?

ie if the idioms I am using are efficient. It looks to me with all the
stack manipulations, one could write really inefficient code and not
have the compiler to help compensate for it.

For example... To define a word for factorials...

: _factorial 1 swap 0 do i 1+ * loop ;

obviously if a 0 was passed to it, it would hang, so I am left with:

: _factorial 1 swap 0 do i 1+ * loop ;
: factorial ?dup if _factorial else 1 then ;

Now I've littered the namespace with 2 words to accomplish one task.
Of which none look like they can be re-used for anything else.

This is one thing that I find a little frustrating with forth. Can
anyone explain a way round littering the dictionary with all these
tiny factored words? Or is this in fact a good thing?

In the meantime I've come up with a slightly better solution:
: ?n:1 ?dup if else 1 then ;
: factorial ?n:1 1 swap 1+ 1 do i * loop ;

Now at least in this ?n:1 can be used anywhere else I need to replace
all 0's passed as 1's.

Thing is the word factorial can also be defined pretty similarly by
: factorial 1 swap ?n:1 1+ 1 do i * loop ;

This generates less efficient code on the compiler I am using for
reasons I suspect are implementation dependent.

So I don't really know if I am approaching things the right way or if
my idioms are efficient - for such a trivial problem. If some one
could enlighten me I would be very grateful - for I guess it's better
to build the foundation right from day 0 rather than pick up bad
habits that are hard to break later.

Incidentally MPE ltd were very kind to let me test-drive their
evaluation version of VFX Forth Windows. I have to say I am totally
gobsmacked. I did not know forth compilers could optimize like that.

### Federico de Ceballos

Jan 10, 2005, 10:33:51 AM1/10/05
to
Rob Spykerman wrote :

> I have just begun learning forth [...]

Welcome on board!

> For example... To define a word for factorials...
>
> : _factorial 1 swap 0 do i 1+ * loop ;
>
> obviously if a 0 was passed to it, it would hang, so I am left with:
>
> : _factorial 1 swap 0 do i 1+ * loop ;
> : factorial ?dup if _factorial else 1 then ;
>
> Now I've littered the namespace with 2 words to accomplish one task.
> Of which none look like they can be re-used for anything else.

: factorial ( u1 - u2 ) 1 swap 0 ?do i 1+ * loop ;

If you are troubled by negative numbers you can try:

: factorial ( n - u ) 0 max 1 swap 0 ?do i 1+ * loop ;

or better still:

: factorial ( n - u ) dup 0< throw 1 swap 0 ?do i 1+ * loop ;

These words can be factored. For example:

: (fact) ( u1 - u2 ) 1 swap 0 ?do i 1+ * loop ;
: factorial ( n - u ) dup 0< throw (fact) ;

(fact) can be reused when you have to calculate the factorial of a lot
of numbers and you are sure that none is negative.

I hope this helps.

Regards,
Federico de Ceballos

### dhof...@talkamerica.net

Jan 10, 2005, 5:15:38 PM1/10/05
to

Rob Spykerman wrote:

> Now I've littered the namespace with 2 words to accomplish one task.
> Of which none look like they can be re-used for anything else.
>
> This is one thing that I find a little frustrating with forth. Can
> anyone explain a way round littering the dictionary with all these
> tiny factored words? Or is this in fact a good thing?

Don't get hung up on the idea that everything you write must be
re-useable in some other program. Write your word(s) to solve the
problem at hand. If you solve the problem with readable code, then

If you happen to write some words that can be used later in some other
task, that's icing on the cake. I think with practice you will begin
to recognize when a word is written, or can be written, that you will
use again. Practice!

> So I don't really know if I am approaching things the right way or if
> my idioms are efficient - for such a trivial problem. If some one
> could enlighten me I would be very grateful - for I guess it's better
> to build the foundation right from day 0 rather than pick up bad
> habits that are hard to break later.

You are asking the right questions. With that attitude you will likely
find that you will enjoy programming in Forth more and more, as you
become more familiar with it.

Regards,

-Doug

### Rob Spykerman

Jan 10, 2005, 9:29:17 PM1/10/05
to
"Federico de Ceballos" <federico...@unican.es> wrote in message news:<34flhtF...@individual.net>...

> These words can be factored. For example:
>
> : (fact) ( u1 - u2 ) 1 swap 0 ?do i 1+ * loop ;
> : factorial ( n - u ) dup 0< throw (fact) ;
>
> (fact) can be reused when you have to calculate the factorial of a lot
> of numbers and you are sure that none is negative.
>
> I hope this helps.

Thank you! I did not know about ?do *sheepish grin*
Well, that's a couple more words I've learnt today, ?do and throw

One thing absolutely FANTASTIC about forth i am discovering is the
ease of transistion in and out of assembly. For example the above
translates to:

see (fact)

(FACT)
( 0049D6B0 68EAD64900 ) PUSH 0049D6EA
( 0049D6B5 8BC3 ) MOV EAX, EBX
( 0049D6B7 3500000080 ) XOR EAX, 80000000
( 0049D6BC F7D8 ) NEG EAX
( 0049D6BE 50 ) PUSH EAX
( 0049D6BF 6A00 ) PUSH 00
( 0049D6C1 BB01000000 ) MOV EBX, 00000001
( 0049D6C6 817C240400000080 ) CMP [ESP+04], 80000000
( 0049D6CE 7505 ) JNZ/NE 0049D6D5
( 0049D6D0 8D642408 ) LEA ESP, [ESP+08]
( 0049D6D4 C3 ) NEXT,
( 0049D6D5 8B1424 ) MOV EDX, [ESP]
( 0049D6D8 42 ) INC EDX
( 0049D6D9 0FAFD3 ) IMUL EDX, EBX
( 0049D6DC 8BDA ) MOV EBX, EDX
( 0049D6DE FF0424 ) INC [ESP]
( 0049D6E1 FF442404 ) INC [ESP+04]
( 0049D6E5 71EE ) JNO 0049D6D5
( 0049D6E7 83C40C ) ADD ESP, 0C
( 0049D6EA C3 ) NEXT,
( 59 bytes, 20 instructions )
ok

I guess I could cheat, if I were only doing a signed int factorial
function, sorry WORD - still trying to kill old habits :) I've taken
out the increment in the loop to tighten it and just made it count
down and multiply.

code factorial
xor ecx, ecx
or ecx, ebx
dec ecx
jnle l\$1
mov ebx, # 1
ret / this stuff gets rid of negatives, 0 and 1
l\$1: imul ebx, ecx / this is the main loop ebx returns TOS
dec ecx
jne l\$1
ret
end-code

just had a thought... cmov would be nice to have but the evaluation
edition of VFX Forth I have does not do P6 opcodes AFAIK (Steve?) ,
and I've yet to figure the assembler syntax fully so I can insert my
own hex code as a temporary stop-gap for the unimplemented opcodes
(till I figure out how to extend the assembler)

Couple of questions...

1. You put (fact) in () - is this some sort of convention?

2. I can see the virtue of factoring things to small bits but what
about the (at least to my perception) negative effect of littering the
global namespace or dictionary with all these little code fragments?
What can one do?

3. There is OBVIOUSLY a heckuva lot I don't know yet about forth. Can
someone point me to a good reference - particularly idioms, what to do

Starting Forth does not go into this too much, just seems to describe
the basics of forth very well and the indirectly threaded forth model.

Cheers

Rob

### robert.sp...@gmail.com

Jan 10, 2005, 9:50:19 PM1/10/05
to
Rob Spykerman wrote:

> code factorial
> xor ecx, ecx
> or ecx, ebx
> dec ecx
> jnle l\$1
> mov ebx, # 1
> ret / this stuff gets rid of negatives, 0 and
1
> l\$1: imul ebx, ecx / this is the main loop ebx returns TOS
> dec ecx
> jne l\$1
> ret
> end-code

sorry, duh! This is better

code factorial
mov ecx, ebx

dec ecx
jnle l\$1
mov ebx, # 1
ret

l\$1: imul ebx, ecx

### Elizabeth D. Rather

Jan 10, 2005, 9:54:40 PM1/10/05
to
"Rob Spykerman" <robert.sp...@gmail.com> wrote in message
...

> Couple of questions...
>
> 1. You put (fact) in () - is this some sort of convention?

Yes, it's long been common to name a word that exists primarily to contain
the active part of some other word that maybe needs a shell (for security or
whatever) around it with the "visible" word's name in parens.

> 2. I can see the virtue of factoring things to small bits but what
> about the (at least to my perception) negative effect of littering the
> global namespace or dictionary with all these little code fragments?
> What can one do?

What negative effect did you have in mind? Most modern systems have
extremely fast searches (typically dividing the namespace invisibly somehow
to help) and lots of memory, and Forth is designed to make the time required
for a call to be absolutely minimal. And there are ways of subdividing the
things in different contexts), but that's probably a little advanced for you
right now.

> 3. There is OBVIOUSLY a heckuva lot I don't know yet about forth. Can
> someone point me to a good reference - particularly idioms, what to do
>
> Starting Forth does not go into this too much, just seems to describe
> the basics of forth very well and the indirectly threaded forth model.

Well, the indirectly threaded model is not all that common an implementation
strategy nowadays, so don't assume that's in any way intrinsic to Forth.
There are several books on our web site, www.forth.com. One of them, "Forth
Application Techniques", is designed for beginners, and has a lot of
exercises. It is a lot more up-to-date with respect to contemporary Forth
practice than Starting Forth. It even includes a section on naming
conventions that includes the use of parens.

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."
==================================================

### Thomas Pornin

Jan 11, 2005, 3:39:03 AM1/11/05
to
According to Rob Spykerman <robert.sp...@gmail.com>:

> 2. I can see the virtue of factoring things to small bits but what
> about the (at least to my perception) negative effect of littering the
> global namespace or dictionary with all these little code fragments?
> What can one do?

The usual answer is that such littering is not a problem: if two words
are named the same, then they should do the same and as such be one. If
they do not do the same thing, then one of them is badly named. Besides,
most of the time, Forth refers to data implicitely, by its position
on the stack, whereas other languages have to give names (to local
variables, function parameters and so on). This gives Forth much more
"breathing room" for the word names. Moreover, Forth word names are not
limited to the letters, digits and underscore character; you can be very
creative in the way you name words, which gives you even more room. Last
but not least, Forth names can be redefined without changing the meaning
of words which were defined with the old definition; and you can easily
update your Forth so that redefinitions trigger warnings.

Such is the theory. As usual, practice may disagree. Forth also includes
some features to work with sub-dictionaries. ANS Forth defines the
"wordlist" concept which can be used to provide local namespaces. This
is also known as "vocabulary". Whether this is a good idea or not is
subject to (much heated) debate. The point of Forth is that it does
not choose for you: it gives you ways to do with or without local
namespaces, as you wish.

--Thomas Pornin

### robert.sp...@gmail.com

Jan 11, 2005, 5:17:00 AM1/11/05
to

Elizabeth D. Rather wrote:

> "Rob Spykerman" <robert.sp...@gmail.com> wrote in message

[snip]

> > 2. I can see the virtue of factoring things to small bits but what
> > about the (at least to my perception) negative effect of littering
the
> > global namespace or dictionary with all these little code
fragments?
>

> What negative effect did you have in mind? Most modern systems have
> extremely fast searches (typically dividing the namespace invisibly
somehow
> to help) and lots of memory, and Forth is designed to make the time
required
> for a call to be absolutely minimal. And there are ways of
subdividing the
different
> things in different contexts), but that's probably a little advanced
for you
> right now.

The thing I feel may be a problem is trying to think of names for
words, once the 'good ones' have been used up...

At present I am trying to learn to minimize the use of traditional
'variables' by doing everything as much as possible on the stack so I
don't have to name 'variables' - haven't had to use 'locals' yet - in
fact I don't know how to do this yet which may well be a good thing.

How do I learn about the more advance stuff? Like keeping errr... name
space pollution to a minimum (okay, I guess I am a bit hung up about
this now, but that's probably cos I know no better?)

There's probably no better way to learn a language than starting to try
and write something useful.

I was thinking when I've learnt enough I might write an mp3 encoder or
adapt a DeCSS to forth. Thing is I've seen the output of optimizing c
compilers and I reckon it will be a bit of a challenge to see if one
can do better...

> Well, the indirectly threaded model is not all that common an
implementation
> strategy nowadays, so don't assume that's in any way intrinsic to
Forth.
> There are several books on our web site, www.forth.com. One of them,
"Forth
> Application Techniques", is designed for beginners, and has a lot of
> exercises. It is a lot more up-to-date with respect to contemporary
Forth
> practice than Starting Forth. It even includes a section on naming
> conventions that includes the use of parens.

Heh, is that a coincidence or what, your book's in the mail to me from
Amazon :) I'm sort of hoping it'll answer all those queries and set me
down the right path. Can I post questions here ;-)

Cheers

Rob

### Stephen Pelc

Jan 11, 2005, 8:11:50 AM1/11/05
to comp.lang.forth
On 11 Jan 2005 02:17:00 -0800, robert.sp...@gmail.com wrote:

>How do I learn about the more advance stuff? Like keeping errr... name
>space pollution to a minimum (okay, I guess I am a bit hung up about
>this now, but that's probably cos I know no better?)

The traditional thing to do is to hide implementation factors
inside vocabularies to provide namespace control.

vocabulary factors

also factors definitions \ new words are in FACTORS

: foo ... ;

: bar ... ;

also forth definitions \ new words are in FORTH
\ FACTORS are visible

: inForth ... foo ... bar ... ;

previous previous definitions
\ FACTORS are invisible

VFX Forth has its own MODULE mechanism as well, but the
ALSO DEFINITIONS PREVIOUS wordset is in widespread use. You
can also use the ANS wordset mechanism.

Stephen

--
Stephen Pelc, steph...@INVALID.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

### Anton Ertl

Jan 11, 2005, 12:24:36 PM1/11/05
to
robert.sp...@gmail.com (Rob Spykerman) writes:
>2. I can see the virtue of factoring things to small bits but what
>about the (at least to my perception) negative effect of littering the
>global namespace or dictionary with all these little code fragments?

What about it. It's a much smaller problem in Forth than in most
other languages, because Forth allows redefining names, but uses
static binding of names.

So even if you defined a name before, and used it in some other words,
when you define another word with the same name, the Forth system will
not give you an error (but usually a warning), and the already-defined
words will not be affected by your redefinition.

However, it is still a good idea to make word names unique, in order

As others have mentioned, you can also use wordlists to get the effect
of namespaces or modules, but that approach often gets in the way of
debugging convenience, so I use it much less often than I would in
some other programming languages.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html

### Elizabeth D. Rather

Jan 11, 2005, 3:06:33 PM1/11/05
to
<robert.sp...@gmail.com> wrote in message
>
> ...

> The thing I feel may be a problem is trying to think of names for
> words, once the 'good ones' have been used up...

Forth enlarges its potential namespace considerably by allowing characters
other than letters, digits, and underscore. Well-chosen names are important
in writing readable code, though. I prefer simple English words (avoiding
long, concatenated "phrases"). There are some hints for naming in my book.

As others have mentioned, the concept of wordlists or vocabularies (two
terms for the same thing) can help in complex applications, but don't worry

> At present I am trying to learn to minimize the use of traditional
> 'variables' by doing everything as much as possible on the stack so I
> don't have to name 'variables' - haven't had to use 'locals' yet - in
> fact I don't know how to do this yet which may well be a good thing.

In the courses I teach, I don't introduce variables at all until the second
day, to ensure students get lots of practice with the stack. And even then
I get after people who define variables unnecessarily. A good guideline is
to define a variable where you would use a "global" in other languages, e.g.
for persistent data that will be accessed at various parts of your program
or for data that is needed by multiple tasks. Anything for which you'd
define a "local variable" you should use the stack for. I don't actually
teach locals in my class at all, and they are not in my introductory book.
In my experience cases in which they are actually helpful are very rare, and
for beginners they encourage bad habits and poor stack management.

> How do I learn about the more advance stuff? Like keeping errr... name
> space pollution to a minimum (okay, I guess I am a bit hung up about
> this now, but that's probably cos I know no better?)

Wordlists/vocabularies are covered briefly in my "Application Techniques"
book. But (as I and others keep saying) it really isn't as much a problem
as you seem to think. Really, don't worry about it for now.

### Julian V. Noble

Jan 11, 2005, 4:36:23 PM1/11/05
to
Rob Spykerman wrote:
>
> Good day all. I have just begun learning forth just as a pastime and I
> have just realised there is actually very little material out there
> for the uninitiated. I have to say what little I have found has been
> pretty good - and am currently thumbing thru' Leo Brodie's Starting
> Forth.
>
> I am not sure however if I am doing it mm... right?

See, e.g. (there are other tutorials)

--
Julian V. Noble
Professor Emeritus of Physics
j...@lessspamformother.virginia.edu
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/

"As democracy is perfected, the office of president represents, more and
more closely, the inner soul of the people. On some great and glorious
day the plain folks of the land will reach their heart's desire at last
and the White House will be adorned by a downright moron."

--- H. L. Mencken (1880 - 1956)

### Albert van der Horst

Jan 11, 2005, 10:07:47 PM1/11/05
to
<robert.sp...@gmail.com> wrote:
>
<SNIP>

>
>There's probably no better way to learn a language than starting to try
>and write something useful.
>
>I was thinking when I've learnt enough I might write an mp3 encoder or
>adapt a DeCSS to forth. Thing is I've seen the output of optimizing c
>compilers and I reckon it will be a bit of a challenge to see if one
>can do better...

If you are serious... Bernd Paysan has mentioned this before.
There is no good open source OCR program. There is a gocr, but it is
crap. Now there is a killer. I know pretty well how it should be
structured, I have put some thoughts into it. Bernd Paysan has made
some remarks too. With the recent success of a community effort to get
Thinking Forth availability, we just might ...

OCR is extremely important and valueable for the free world (as in freedom
not as in capitalism). It plays an important role in distributing news
about the crap patents that are pushed in Europe. Now they are public
in the sense that you are allowed to go there and fotocopy lousy two column
type writer pages. Conspiration theories abound here.
This hampers the free software foundation in getting competent people
look into these. There are reportedly already 60.000 of them.
You just can't search them efficiently without computers.

Then there is millions (yes millions) of books and documents to be scanned.
The strong points of Forth would suggest to have a book paging automaton
with built in ocr.

For example. After the war Unilever and the Dutch "Christen Democrats"
conspired to get hold of the margarine machines payed for by the company
my mother worked for. It is not unlikely that I own the last copy of
"Wat ons bedrijf wedervoer." This is a historic document with literal
texts of letters back and forth. I must get that out on the Internet.

<SNIP>

>
>Heh, is that a coincidence or what, your book's in the mail to me from
>Amazon :) I'm sort of hoping it'll answer all those queries and set me
>down the right path. Can I post questions here ;-)
>
>Cheers
>
>Rob
>

--
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

### robert.sp...@gmail.com

Jan 12, 2005, 12:21:59 PM1/12/05
to

Albert van der Horst wrote:

> If you are serious... Bernd Paysan has mentioned this before.
> There is no good open source OCR program. There is a gocr, but it is
> crap. Now there is a killer. I know pretty well how it should be
> structured, I have put some thoughts into it. Bernd Paysan has made
> some remarks too. With the recent success of a community effort to
get
> Thinking Forth availability, we just might ...

You are right, that is an interesting project. However way beyond my
means at present ;) I've yet to prove to myself I can write practical
code in forth - hey I have YET to learn it properly.

I guess the best way perhaps for me to learn is to adapt simpler
algorithms that perhaps are well known and try and translate them to
forth, ideally not direct translations but optimised to the features of
the language.

Start simple with sorts, trees and stuff all the way to perhaps file
compression that sort of thing. I can be overly abmbitious but I guess
it's best to take it slow. Rome not built in a day and all that.

I was just thinking (and this is probably blasphemy on this newsgroup)
but there are tons more C programmers around - what are the odds that
the first usable free OCR will be in C? (I have not seen FOCR so I
don't know how good it is... it is in C nope?)

What's really scary is what optimizing c compilers can do with code
these days... they're pretty impressive already on IA32's - I can't
speak with any experience on this but they must be VERY SCARY on risc
machines with tons of registers and where perhaps compiler scheduling
of instructions is more important than pentiums.

How do the native forth compilers fare on riscs?

Cheers

Rob

b0ll0x...

### robert.sp...@gmail.com

Jan 12, 2005, 1:29:09 PM1/12/05
to
Stephen Pelc wrote:
> On 11 Jan 2005 02:17:00 -0800, robert.sp...@gmail.com wrote:
> >How do I learn about the more advance stuff? Like keeping errr...
name
> >space pollution to a minimum (okay, I guess I am a bit hung up about
> >this now, but that's probably cos I know no better?)
>
> The traditional thing to do is to hide implementation factors
> inside vocabularies to provide namespace control.
[snip]

Thanks - will look into that!

At this stage I want to thank all of you here for all your help! I
stumbled onto forth quite by accident I have to admit - I have Neal
Bridges to thank in this regard - I was looking for a PalmOS dev kit
and his forth was free to try.

I also have Stephen here to thank for his free to try VFX - thanks for
a stonkin' gret compiler.

Eliz Rather: Your book arrived in the mail today. It's great,
complements Starting Forth quite well especially with regardst to the
newer aspects of forth as it is today.

And all you guys here at c.l.f. - another serendipitous find like forth
itself, I was pleasantly surprised to see pretty much who's who in
forth pretty much here.

*** Where is Chuck Moore by the way - I would have thought he would be
present here to if not intermittently given the presence of everyone
else here....

While we're at it - speaking of Chuck Moore - ColorForth - reminding me
of tail call recursion/optimisation:

ie
: foo ... ... ... ... a-word ;

compiled to : ...
jsr a-word
rts

optimized to: ...
jmp a-word

(using a-word's rts or further jmp to a rts to return)

Stephen I know you leave it pretty much as an option for your users to
implement on VFX if they want. Forth inc's Swift does it pretty much
consistently.

What's the verdict, is this good or bad?

Been wracking my brains trying to think of disadvantages to this, I can
only think if a programmer tries to get the return address of the EXACT
calling word off the stack he won't get it - but is this useful?

Well back to the day job for now - no doubts I shall be back ;)
Cheers Rob

### Richard Owlett

Jan 12, 2005, 1:30:53 PM1/12/05
to
Cross posted comp.lang.forth and comp.dsp

robert.sp...@gmail.com wrote:

>[SNIP]

>
> b0ll0x...
>

I just challenged Google to prove they pay attention to negative comments.

Doubt I'll get response :(

### Richard Owlett

Jan 12, 2005, 1:40:17 PM1/12/05
to
robert.sp...@gmail.com wrote:
> [snip]

>
> *** Where is Chuck Moore by the way - I would have thought he would be
> present here to if not intermittently given the presence of everyone
> else here....
>

He does occasionally show up here.

I suspect that if he appeared as often as many wished, he would never
get anything done :)

I do suspect he finds a need to earn a living ;)

PS to whomever may filter mail for him,
Tell him *thank you*

### Ian Osgood

Jan 12, 2005, 1:56:34 PM1/12/05
to

robert.spykerma...@gmail.com wrote:
>
> At this stage I want to thank all of you here for all your help! I
> stumbled onto forth quite by accident I have to admit - I have Neal
> Bridges to thank in this regard - I was looking for a PalmOS dev kit
> and his forth was free to try.

I also use Quartus Forth for hacking on the bus. Check out the
Sleepless Night Wiki for lots of Quartus and Palm programming tips:
http://kristopherjohnson.net/wiki/

> *** Where is Chuck Moore by the way - I would have thought he would
be
> present here to if not intermittently given the presence of everyone
> else here....

Chuck chimes in occasionally on the colorForth mailing list.
The archives are at http://www.strangegizmo.com/forth/

Jeff Fox will sometimes update c.l.f about Chuck's current work.

> Well back to the day job for now - no doubts I shall be back ;)
> Cheers Rob

Ian

### Richard Owlett

Jan 12, 2005, 3:46:15 PM1/12/05
to

Odds on intelligent reply anyone ?

### Paul E. Bennett

Jan 12, 2005, 4:36:04 PM1/12/05
to
robert.sp...@gmail.com wrote:

> Stephen Pelc wrote:
>> On 11 Jan 2005 02:17:00 -0800, robert.sp...@gmail.com wrote:
>> >How do I learn about the more advance stuff? Like keeping errr...
> name
>> >space pollution to a minimum (okay, I guess I am a bit hung up about
>> >this now, but that's probably cos I know no better?)
>>
>> The traditional thing to do is to hide implementation factors
>> inside vocabularies to provide namespace control.
> [snip]
>
> Thanks - will look into that!
>
> At this stage I want to thank all of you here for all your help! I
> stumbled onto forth quite by accident I have to admit - I have Neal
> Bridges to thank in this regard - I was looking for a PalmOS dev kit
> and his forth was free to try.
>
> I also have Stephen here to thank for his free to try VFX - thanks for
> a stonkin' gret compiler.
>
> Eliz Rather: Your book arrived in the mail today. It's great,
> complements Starting Forth quite well especially with regardst to the
> newer aspects of forth as it is today.

Complete the set and get a copy of Thinking Forth as well.
going through final proofing at present to ensure it is as close as
possible to the original prinbted version - well done guys). I think that
the other one that is worthwhile is John Matthews "Engineering Applications
in Forth"

As you seem to be sticking with Forth, for a while at least, then can I
suggest that you download a copy of my "Forth Coding Standard". This will
your own style if you wish to.

> And all you guys here at c.l.f. - another serendipitous find like forth
> itself, I was pleasantly surprised to see pretty much who's who in
> forth pretty much here.

...and we are good friends most of the time too ;>

> *** Where is Chuck Moore by the way - I would have thought he would be
> present here to if not intermittently given the presence of everyone
> else here....

He's busy continuing to push the boundaries of Forth even further and
completing commercial work. Whatever he is working on will filter down,
usually through Jeff Fox, in time when he is able to talk about it.

> Well back to the day job for now - no doubts I shall be back ;)
> Cheers Rob

Welcome anytime.

--
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

### Elizabeth D. Rather

Jan 12, 2005, 5:56:53 PM1/12/05
to
"Paul E. Bennett" <p...@amleth.demon.co.uk> wrote in message
news:cs458f\$iar\$1\$8300...@news.demon.co.uk...
...

> > Eliz Rather: Your book arrived in the mail today. It's great,
> > complements Starting Forth quite well especially with regardst to the
> > newer aspects of forth as it is today.
>
> Complete the set and get a copy of Thinking Forth as well.
> going through final proofing at present to ensure it is as close as
> possible to the original prinbted version - well done guys). I think that
> the other one that is worthwhile is John Matthews "Engineering
Applications
> in Forth"

To *really* complete the set, get the Forth Programmer's Handbook, a
reference manual available as paper from our web site, or as a pdf with our
free SwiftForth evaluation version (also on the web site), and with all our
products.

> As you seem to be sticking with Forth, for a while at least, then can I
> suggest that you download a copy of my "Forth Coding Standard". This will
> give you a useful style guide to start with but feel free to adapt it for
> your own style if you wish to.

There is also a style guide in the back of Forth Application Techniques. It
includes two somewhat different approaches to source style, FORTH, Inc.'s
and the one adopted by the Open Firmware group. There are no absolutes
about style, the important thing is to adopt a style that you feel gives
with it consistently.

I'll also observe that for beginners it may be useful to adopt a somewhat
more vertical style than shown in my books, with a word or phrase per line
followed by a comment showing the stack effect of that word or phrase. As
you get more experienced, that becomes less necessary, and can give way to a
more horizontal style and comments devoted to explaining what's going on
logically.

### Richard Owlett

Jan 13, 2005, 4:26:59 AM1/13/05
to

I stand corrected. I've received the following:

mail that is received. Regardless of tone, user feedback is very
important to us and we keep all their ideas in mind as we work to
on your comp.lang.forth and comp.dsp search suggestions to the
appropriate team."

### Stephen Pelc

Jan 13, 2005, 4:30:13 AM1/13/05
to comp.lang.forth
On 12 Jan 2005 09:21:59 -0800, robert.sp...@gmail.com wrote:

>What's really scary is what optimizing c compilers can do with code
>these days... they're pretty impressive already on IA32's - I can't
>speak with any experience on this but they must be VERY SCARY on risc
>machines with tons of registers and where perhaps compiler scheduling
>of instructions is more important than pentiums.
>
>How do the native forth compilers fare on riscs?

It depends on the benchmarks. Comparing VFX Forth for ARM against
gcc 2.2xx (95?) a few years ago gave about the same speeds. Comparing
gcc 3.4.x against last week's VFX for ARM on a Philips LPC2106 at
60 MHz gave gcc a 20% advantage on the Dhrystone benchmark (the
only one for which I have a comparison). The Forth code was
originally from Marcel Hendrix, uses a lot of locals, and
VFX could be more aggressive in its locals handling.

More Forthification of the Dhrystone code will help, and we
should recover the difference soon. The basic Dhrystone code
we use is derived from the benchmark code in BENCHMRK.FTH
available on our website. We will post the embedded version,
XBENCH32.FTH, when we've had a chance to perform a few more
ports.

### Marcel Hendrix

Jan 13, 2005, 9:01:58 AM1/13/05
to
steph...@INVALID.mpeltd.demon.co.uk (Stephen Pelc) writes Re: focr was Re: Starting out on Forth

> Comparing
> gcc 3.4.x against last week's VFX for ARM on a Philips LPC2106 at
> 60 MHz gave gcc a 20% advantage on the Dhrystone benchmark (the
> only one for which I have a comparison). The Forth code was
> originally from Marcel Hendrix, uses a lot of locals, and
> VFX could be more aggressive in its locals handling.

> More Forthification of the Dhrystone code will help, and we
> should recover the difference soon. The basic Dhrystone code
> we use is derived from the benchmark code in BENCHMRK.FTH
> available on our website. We will post the embedded version,
> XBENCH32.FTH, when we've had a chance to perform a few more
> ports.

There is a famous "bug" (related to COMPARE) in the Dhrystone that is copied
in benchmrk.frt. I just recently found it / noticed it. At least it did
affect iForth to an astonishing degree.

-marcel

### m-coughlin

Jan 13, 2005, 1:27:46 PM1/13/05
to
Rob Spykerman wrote:

> Good day all. I have just begun learning forth just as a
> pastime and I have just realised there is actually very
> little material out there for the uninitiated. I have to say
> what little I have found has been pretty good - and am
> currently thumbing thru' Leo Brodie's Starting Forth.
>
> I am not sure however if I am doing it mm... right?

You shouldn't have to ask if you are doing it right, even
when you are just starting out. But as you say, there is
actually very little material out there for the uninitiated. You
are lucky to be able to read Leo Brodie's book since it has been
out of print for around a decade. I find it very strange that
Forth was used for the best book ever written about programming
but Forth programmers or vendors are not able to do the same
today. There is plenty of material for learning about Forth for
on comp.lang.forth you will find the answers you need.

[snip]

> Incidentally MPE ltd were very kind to let me test-drive their
> evaluation version of VFX Forth Windows. I have to say I am
> totally gobsmacked. I did not know forth compilers could
> optimize like that.

Forth is a general purpose computer language and can be used
for any application. Then there is also the idea that with
properly written Forth there is no need for an optimizing compiler.

--
Michael Coughlin m-cou...@comcast.net Cambridge, MA USA

### Coos Haak

Jan 13, 2005, 2:12:10 PM1/13/05
to
Op Thu, 13 Jan 2005 13:27:46 -0500 schreef m-coughlin:

<>
> Forth is a general purpose computer language and can be used
> for any application.

Yes, I agree

> Then there is also the idea that with
> properly written Forth there is no need for an optimizing compiler.

We don't need P XII's in the 21st century.
We don't need aeroplanes in the 20th century
We don't need steam engines in the 19th century.
We don't need coinage in the 12th century
We don't need houses in the 4th millenium BC.

--
Coos

### Anton Ertl

Jan 13, 2005, 5:03:15 PM1/13/05
to
robert.sp...@gmail.com writes:
>How do the native forth compilers fare on riscs?

PPC: Take a look at PowerMops or D; should be somewhat like VFX, but
with more registers available.

ARM: VFX is available there.

MIPS: RAFTS was a little better, but never released.

>b0ll0x...

comp.lang.forth to the FAQ:
http://www.complang.tuwien.ac.at/forth/faq/faq-general-6.html

For the general critique, here it is:

6.1. How can I read and post to comp.lang.forth?

The usual way is to use a newsreader and an NNTP server. If your
internet provider does not offer you access to a good NNTP server, you
might consider switching providers. There is also a free
(registration required) NNTP server: news.individual.net.

Once you have access to an NNTP server, you can use a wide variety of
newsreaders. You should consider using one that has passed the GNKSA
<http://www.gnksa.org/gnksa-evaluations.html> test, as such
(even if you don't want to post right now, you probably don't want to
have to change the newsreader if you ever decide to post).

Even with a good newsreader, you should make test postings to a test
group (e.g., misc.test) before posting to discussion groups like
comp.lang.forth. Also, check your test postings; not with your
newsreader, as it tends to hide its own errors; try the "Show
telnet <http://www.complang.tuwien.ac.at/anton/mail-news-
errors.html#line-breaks>.

well. Most people will do ok if they read the newsgroup they want to
post to for a while before posting (note that different newsgroups can
smart questions <http://www.catb.org/~esr/faqs/smart-questions.html>,
<http://www.complang.tuwien.ac.at/anton/mail-news-errors.html>.

As a poor alternative to an NNTP server, you can also use Google
Groups.

### Bruce McFarling

Jan 14, 2005, 5:34:30 AM1/14/05
to

Coos Haak wrote:
> We don't need aeroplanes in the 20th century

Certainly not, airplanes will serve quite nicely.

However, sometime in the 21st century we will discover
the need a bit more material efficiency in the way we
do things. Dispensing with a need is quite often the
most materially efficient way of satisfying it.

### robert spyke

Jan 16, 2005, 3:42:08 PM1/16/05
to
On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin
<m-cou...@comcast.net> wrote:

[snippety-snip]

>Rob Spykerman wrote:
>
>> I am not sure however if I am doing it mm... right?
>
> You shouldn't have to ask if you are doing it right, even
>when you are just starting out.

As 7 of 9 would probably reply, 'Explain?'

> I find it very strange that
>Forth was used for the best book ever written about programming
>but Forth programmers or vendors are not able to do the same
>today.

I find it strange that apparently there is so much embedded forth
around yet there's so little material around perhaps because of the
_'fashion'_ of the moment.

To be honest, there's not a lot available for low-level programming
either. In the past where one could get a book for say, oh, say a Z80
or a 6502 in a bookstore, these days, it's hard enough finding a
book for x86 assembly, what with all the Java and C++ stuff around. In
fact in most borders where I am, C++ books already outnumber C books
which seems to be the sign of the times.

Which is a bit of a pain because what I REALLY am looking for is a
good book on learning how to use x87 instructions or SSE3 (for that
matter the whole gamut of SIMD instructions these new processors
have).

> Forth is a general purpose computer language and can be used
>for any application. Then there is also the idea that with
>properly written Forth there is no need for an optimizing compiler.

Again, as 7 of 9 would say, 'Explain!'

I think this would depend.

This is relative. Speed that is. How much you need. With computers at
gigahertz speed one could argue code need not be optimized purely for
speed but convenience hence oop and scripting languages like python,
perl which could yield acceptable performance.

However, if it is speed and speed alone, here are my ideas... ( and
look, you wouldn't like your perl interpreter compiled by a crappy
compiler would you? )

Firstly I would say that even with the best written forth code (ie
pure forth no assembly except primitives), all that stack maneuvering
costs CPU cycles.

A compiler which can spit code that juggles more of these maneuvers in
registers will be obviously generating better code than one that keeps
pushing and popping off a stack in memory exclusively.

For example at present, in my recent explorations, my understanding of
looping with do loops in forth is that it's VERY expensive because of
the counter having to exist on the return stack. I guess it could be a
language necessity. But if a compiler was smart enough to perhaps use
a register as a counter, that's again a step up in efficiency. Of
course, you could avoid 'do' loops altogether too - I have yet to look
at the begin until looping code on the compilers I use to see if this
is any better.

Then it's choosing the right instructions depending on the context.
ie, I reckon in most chips to compare with x, if x = 0 it's probably
faster to:

or r1, r1

rather than a

cmp r1, # 0

(because the #0 which is presumably word length has to be fetched from
memory - of course if it's a risc, you'll probably have to do register
compares so it may not matter then).

Then to zero a register,

xor r1, r1 is probably again better than
mv 0, r1

(depending again on the context, if flags can be ignored etc)

I am sure there are tons of other examples a real compiler writer can
give you.

And then there is the matter of choosing the right order of
instructions.

This is of some importance on pentiums even with the out of ordering,
but what about other risc machines where instruction scheduling is so
critical for optimal performance - all those rules you need to
remember, that even hand assembly is difficult - arguably these days
optimizing c compilers generate better code on average than average
assembly language programmers.

No, I argue if you are going to compile something, you should be able
to compile it optimally....

Even Chuck Moore optimized colorforth.... (ie tail call optimisation
for one)

Cheers

Rob

### Howard Lee Harkness

Jan 17, 2005, 9:43:46 AM1/17/05
to
robert spyke <robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote:

> m-coughlin <m-cou...@comcast.net> wrote:
>> Forth is a general purpose computer language and can be used
>>for any application. Then there is also the idea that with
>>properly written Forth there is no need for an optimizing compiler.

>Again, as 7 of 9 would say, 'Explain!'

Forth is the "assembly language" of the Forth machine. In assembly language,
the only optimizations possible have to do with choosing the right algorythms
and implementing them correctly.

Having actually programmed on a Forth machine (RTX2000), I think I can
confidently claim that the only possible optimization has to come from proper
algorithm choice. I was greatly humbled by a programmer from Rockwell that took
my program, made a few choice changes of algorythm, and made my program run
about 10 time faster. I don't believe that current compiler technology is
capable of choosing the right algorythms for you.

### m-coughlin

Jan 17, 2005, 12:32:09 PM1/17/05
to
robert spyke wrote:
>
> On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin
> <m-cou...@comcast.net> wrote:
>
> [snippety-snip]
>
> >Rob Spykerman wrote:
> >
> >> I am not sure however if I am doing it mm... right?
> >
> > You shouldn't have to ask if you are doing it right, even
> >when you are just starting out.
>
> As 7 of 9 would probably reply, 'Explain?'
>
> > I find it very strange that
> >Forth was used for the best book ever written about
> >programming but Forth programmers or vendors are not able
> >to do the same today.

The explanation follows my statement immediately. If Forth
had continued to be used to write good books on programming (as
it was in 1981 to 1987), then you could just read about the
right way of doing things when you were starting out.

> I find it strange that apparently there is so much embedded
> forth around yet there's so little material around perhaps
> because of the _'fashion'_ of the moment.

There is very little of embedded Forth around. One of the
main uses of Forth is programming embedded systems but Forth's
market share of programming embedded systems is very low. It is
clear to me that this is due to the difficulty new programmers
have in finding out about Forth and learning to use it. Perhaps
the criticism I will receive for such an opinion will result in
an improvement of the situation.

> To be honest, there's not a lot available for low-level
> programming either. In the past where one could get a book for
> say, oh, say a Z80 or a 6502 in a bookstore, these days, it's
> hard enough finding a book for x86 assembly, what with all the
> Java and C++ stuff around. In fact in most borders where I am,
> C++ books already outnumber C books which seems to be the sign
> of the times.
>
> Which is a bit of a pain because what I REALLY am looking for
> is a good book on learning how to use x87 instructions or SSE3
> (for that matter the whole gamut of SIMD instructions these new
> processors have).

In the past the limited power of home computers made it
necessary to learn and use assembly language in order to get
of computers has made it necessary to find much better ways of
programming. Low level programming textbooks are still
available, but not usually in bookstores. The CPU manufacturers
provide these books free for the asking and there are many
tutorials available on the web for more elementary instruction.

### m-coughlin

Jan 17, 2005, 1:22:35 PM1/17/05
to
robert spyke wrote:
>
> On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin
> <m-cou...@comcast.net> wrote:
>
> [snippety-snip]
>
> > Forth is a general purpose computer language and can be
> > used for any application. Then there is also the idea that
> > with properly written Forth there is no need for an
> > optimizing compiler.
>
> Again, as 7 of 9 would say, 'Explain!'

Forth is neither a compiler nor an interpreter. It is its
own thing. An optimizing compiler is needed for languages like
Fortran and C. Forth does things differently. Is there such a
thing as an optimizing assembler? I haven't heard of that yet.
Maybe Forth should be in the same category.

> I think this would depend.
>
> This is relative. Speed that is. How much you need. With
> computers at gigahertz speed one could argue code need not be
> optimized purely for speed but convenience hence oop and
> scripting languages like python, perl which could yield
> acceptable performance.
>
> However, if it is speed and speed alone, here are my ideas...
> ( and look, you wouldn't like your perl interpreter compiled
> by a crappy compiler would you? )
>
> Firstly I would say that even with the best written forth code
> (ie pure forth no assembly except primitives), all that stack
> maneuvering costs CPU cycles.

The best written Forth code needs to include assembly
language primitives. There has been an attempt lately to change
Forth source code style to make it portable. Forth is inherently
a way to write non-portable code. A change like this makes Forth
into something that is not Forth. It is like the attempts to
write a universal portable assembly language. I think the
efforts to make Forth a portable compiled language are
interesting and it would be a great improvement if it was called
something other than "Forth". A nice distinctive name would show

> A compiler which can spit code that juggles more of these
> maneuvers in registers will be obviously generating better
> code than one that keeps pushing and popping off a stack in
> memory exclusively.
>
> For example at present, in my recent explorations, my
> understanding of looping with do loops in forth is that
> it's VERY expensive because of the counter having to exist
> on the return stack. I guess it could be a language necessity.
> But if a compiler was smart enough to perhaps use a register
> as a counter, that's again a step up in efficiency. Of course,
> you could avoid 'do' loops altogether too - I have yet to look
> at the begin until looping code on the compilers I use to see
> if this is any better.

Such considerations have been extensively explored and many
different low level coding variations have been used in
different versions of Forth. These have not been documented for
beginners who are just starting out learning about Forth. In
fact, they have not even been well documented for experienced
Forth programmers who usually reverse engineer any code they
need to understand better. Now that you have brought up the
topic, I expect you will receive some information on the
varieties of low level Forth implementations. Once again, this
is not a topic for beginners, but perhaps it should be.

### Albert van der Horst

Jan 17, 2005, 5:19:42 AM1/17/05
to
In article <5bjlu0pm9mf9abv8m...@4ax.com>,

robert spyke <robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote:
>
>Which is a bit of a pain because what I REALLY am looking for is a
>good book on learning how to use x87 instructions or SSE3 (for that
>matter the whole gamut of SIMD instructions these new processors
>have).

A free and autoritive source for Intel processors is Intel.
surprising amount of tutorial material.

<SNIP>

>This is of some importance on pentiums even with the out of ordering,
>but what about other risc machines where instruction scheduling is so
>critical for optimal performance - all those rules you need to
>remember, that even hand assembly is difficult - arguably these days
>optimizing c compilers generate better code on average than average
>assembly language programmers.
>
>No, I argue if you are going to compile something, you should be able
>to compile it optimally....

Well. Eh. Lets say that only a few knowledgeable people here at
c.l.f. dare to touch the subject.

>
>Even Chuck Moore optimized colorforth.... (ie tail call optimisation
>for one)

Hardly. He keeps things simple, then Intel processors are fast.
He doesn't much in the direction of instruction scheduling in
his Forth. (I have been reading those assembler sources rather
thoroughly.).
He does a O(n) search to look up a word. This is theoretically
inferior compared to hashing and whatnot. But n is small (ca.
1000) and the lookup is simple (finding a 32 bit value in an
array.)

>
>Cheers
>
>Rob

Groetjes Albert.

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS

One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

### Paul E. Bennett

Jan 17, 2005, 5:27:06 PM1/17/05
to
m-coughlin wrote:

> There is very little of embedded Forth around.

Just because it is not very publicly apparent which embedded systems are
programmed in Forth does not mean that there are very few. There may be
more surprises than you think out there. I suppose we will all have to
remain uncertain about the proportions. ;>

### Elizabeth D. Rather

Jan 17, 2005, 8:35:29 PM1/17/05
to
"robert spyke" <robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote in
message news:5bjlu0pm9mf9abv8m...@4ax.com...
> ...

> I find it strange that apparently there is so much embedded forth
> around yet there's so little material around perhaps because of the
> _'fashion'_ of the moment.
>
> To be honest, there's not a lot available for low-level programming
> either. In the past where one could get a book for say, oh, say a Z80
> or a 6502 in a bookstore, these days, it's hard enough finding a
> book for x86 assembly, what with all the Java and C++ stuff around. In
> fact in most borders where I am, C++ books already outnumber C books
> which seems to be the sign of the times.
>
> Which is a bit of a pain because what I REALLY am looking for is a
> good book on learning how to use x87 instructions or SSE3 (for that
> matter the whole gamut of SIMD instructions these new processors
> have).

Well, our primary business for >30 years has been providing Forth
development systems and programming services for embedded systems. This is
a field that doesn't get much publicity or books written about it, and I
agree that it's too bad, since some studies I've seen indicate that there
are lots more microprocessors in use than desktop computers (any reasonably
new car has over 50, for example).

Our customers are writing firmware for everything from "smart cards" to
satellites, with many kinds of control systems in between. The thing is,
folks in the private sector don't usually have the time or incentive to
write books and magazine articles, so the whole field doesn't get publicized
in a way that makes it clear what's happening. Mike Coughlin is in
academia, and for him if it isn't in the MIT bookstore it doesn't exist. As
a result, he's pretty out of touch with real-world computing (particularly
the state of the art in the Forth community -- he's working on some
impressions from 20 years ago).

> > Forth is a general purpose computer language and can be used
> >for any application. Then there is also the idea that with
> >properly written Forth there is no need for an optimizing compiler.
>
> Again, as 7 of 9 would say, 'Explain!'

I actually disagree with that. We find an optimizing compiler to be very
helpful, and have them in all our Forth products.

> This is relative. Speed that is. How much you need. With computers at
> gigahertz speed one could argue code need not be optimized purely for
> speed but convenience hence oop and scripting languages like python,
> perl which could yield acceptable performance.

All true, but in the embedded world, where you may be dealing with 8051s and
AVRs and MSP430s, you need all the performance you can get.

> However, if it is speed and speed alone, here are my ideas... ( and
> look, you wouldn't like your perl interpreter compiled by a crappy
> compiler would you? )
>
> Firstly I would say that even with the best written forth code (ie
> pure forth no assembly except primitives), all that stack maneuvering
> costs CPU cycles.

It's not that clear. If you're trying to write modular code (which saves
memory and can greatly improve reliability) the cost of subroutine calls in
other languages can be quite steep. Unless all your local variables are in
registers (which is often not possible, particularly again on low-end
microcontrollers) you spend about as many cycles fetching and storing as you
would on stack manipulation. Finally, there's the possibility of putting
your stacks in on-board RAM on some chips, which helps a lot.

> A compiler which can spit code that juggles more of these maneuvers in
> registers will be obviously generating better code than one that keeps
> pushing and popping off a stack in memory exclusively.

Well, where possible we always keep the top stack item in a register as well
as the stack pointer, and also preserve several registers that can be used
as scratch without saving & restoring. Usually you aren't dealing with more
than the top few things, so it really isn't that costly.

> For example at present, in my recent explorations, my understanding of
> looping with do loops in forth is that it's VERY expensive because of
> the counter having to exist on the return stack. I guess it could be a
> language necessity. But if a compiler was smart enough to perhaps use
> a register as a counter, that's again a step up in efficiency. Of
> course, you could avoid 'do' loops altogether too - I have yet to look
> at the begin until looping code on the compilers I use to see if this
> is any better.

Do loops are somewhat more expensive than begin-type ("indefinite") loops,
but you also get the loop counter -- depending on what you're doing, if you
have to simulate a loop counter manually in an indefinite loop, it's slower
than the do loop. The return stack pointer is almost always in a register,
and that code is pretty tight. They're not nearly as bad as you seem to
think. If you need to do something a known number of times or need access
to a loop counter, you're better off using a do...loop.

But in embedded systems code speed isn't usually the most important issue.
Your performance is mainly going to depend on I/O, and memory may be
limited. And I completely agree with Harkness' comment that ultimately it's
the algorithm (or system design) that really matters. Let me tell you a
true story (which old timers here have heard, but you haven't):

Some years ago American Airlines asked us to re-write the program managing
their baggage handling system at LAX. It was written in assembly language,
and was too hard to maintain. Our program had to run on the same hardware
and present an identical user interface to the operators. It was a very
complex system, and it took us several months to do it. Part of the
acceptance test was the original requirement of handling 1000 bags/hour on
each line, a requirement which the assembler program had never achieved (it
could only do 800 bags/line). Our program, which was completely redesigned
on the inside, only the user interface was the same, passed 1200 bags on its
first time trial. Now, this was in the days *before* we were doing
optimizing compilers, and there's no way our code was itself running faster
than assembler -- but we had a far more efficient overall system design, and

### John Doty

Jan 17, 2005, 10:38:22 PM1/17/05
to
Elizabeth D. Rather wrote:

> Our customers are writing firmware for everything from "smart cards" to
> satellites,

There's very little Forth in satellites these days. Worse, Forth has
lost the respect of the community that builds them: I've heard very
little positive, and much negative, about Forth in this community over
the last 10 years.

> with many kinds of control systems in between. The thing is,
> folks in the private sector don't usually have the time or incentive to
> write books and magazine articles, so the whole field doesn't get publicized
> in a way that makes it clear what's happening.

Not true. People in academia write lots in areas like robotics. Forth
appears to be in steep decline there, too.

> Mike Coughlin is in
> academia, and for him if it isn't in the MIT bookstore it doesn't exist.

Nah, Mike's a Hahvahd guy: he wouldn't be caught dead at the Coop in
Kendall Square :-)

> As
> a result, he's pretty out of touch with real-world computing (particularly
> the state of the art in the Forth community -- he's working on some
> impressions from 20 years ago).

It is very strange for *you* to make this claim. Mike has a far broader
perspective than you. Forth is a tiny corner of a broad world about
which you know very little.

The Forth Mike knows about is the Forth that invited astronomers to use
it, before the mainstream Forths became so complex and obfuscated that
only specialists find them usable.

-jpd

### Elizabeth D. Rather

Jan 17, 2005, 10:56:34 PM1/17/05
to
"John Doty" <j...@whispertel.LoseTheH.net> wrote in message
news:41EC84AE...@whispertel.LoseTheH.net...

> Elizabeth D. Rather wrote:
>
> > Our customers are writing firmware for everything from "smart cards" to
> > satellites,
>
> There's very little Forth in satellites these days. Worse, Forth has
> lost the respect of the community that builds them: I've heard very
> little positive, and much negative, about Forth in this community over
> the last 10 years.

Well, we have several customers who are either working on satellite systems
now or have completed projects within the last few years, at Aerospace,
Lockheed Martin, and some lesser-known contractors. And I assume the folks
at Johns Hopkins APL are still using it.
...

> > Mike Coughlin is in
> > academia, and for him if it isn't in the MIT bookstore it doesn't exist.
>
> Nah, Mike's a Hahvahd guy: he wouldn't be caught dead at the Coop in
> Kendall Square :-)

That's the library he's mentioned in the past, I think.

> > As
> > a result, he's pretty out of touch with real-world computing
(particularly
> > the state of the art in the Forth community -- he's working on some
> > impressions from 20 years ago).
>
> It is very strange for *you* to make this claim. Mike has a far broader
> perspective than you. Forth is a tiny corner of a broad world about
> which you know very little.

I do know quite a lot about the Forth world, and Mike makes a lot of
extremely ill-informed statements about it. My statement was that he's out
of touch with the state of art in the Forth community -- I stand by that.
He hasn't read the books that are available today, nor used contemporary
Forth systems, nor even followed closely what their capabilities are.

> The Forth Mike knows about is the Forth that invited astronomers to use
> it, before the mainstream Forths became so complex and obfuscated that
> only specialists find them usable.

Hmm, he seems unaware of the group at the Smithsonian Astrophysical
Observatory that is currently using Forth (and has been for years), or Bob
Ghertz at the University of Minnesota and his colleagues.

Actually, the feedback we get from our customers is that our current
products are far simpler and easier for the user than the products of 20
years ago. I remember Chuck's axiom about the conservation of complexity;
we have put a lot of effort into making our systems be easy to learn and
use.

### robert spykerman

Jan 18, 2005, 2:53:45 AM1/18/05
to
On Mon, 17 Jan 2005 17:35:29 -0800, "Elizabeth D. Rather"
<era...@forth.com> wrote:

>"robert spyke" <robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote in

[snip]

>Well, our primary business for >30 years has been providing Forth
>development systems and programming services for embedded systems. This is
>a field that doesn't get much publicity or books written about it, and I
>agree that it's too bad, since some studies I've seen indicate that there
>are lots more microprocessors in use than desktop computers (any reasonably
>new car has over 50, for example).

Yeah, and there are some weird lunatics (hand raised) that actually
want to learn forth - mainly because it looks intensely mad and fun
and is so interactive. It's close enough to the machine, in fact, much
nicer than C to interface with asm, and since I'm looking to bone up
on x86 asm as well, it's perfect.

I have to admit I have never had so much fun in ages. The last time I
remember having that much fun was with an apple II, you know,

]CALL -151

*300: A9 C0 8D etc....

*300G

>I actually disagree with that. We find an optimizing compiler to be very
>helpful, and have them in all our Forth products.

I would agree.... Algorithms being similar, I find it extremely
difficult to write better asm than an optimizing c compiler (but I'm
not a great asm programmer). On some compilers, it's easy to see
what's being stuck on the stack and should be in the registers and
it's also easy to see what jumps can be eliminated for pipeline
efficiency that sort of thing - I have to say that now apart from the
PIV and PIII.

I've also seen code on PowerPC's (briefly - Macs) generated by forth
compilers which, given the number of registers, looked like a little
hand optimisation (ie more stuff in registers) would have gone a long
way. Which one specifically I cannot recall.

I know I don't have any real PPC asm experience but when you've got 32
registers and perhaps if half of them are reserved, you've still got
16! However I am also aware that there are diminishing returns - it
can get very complicated trying to juggle more than 1 or 2 stack items
in registers - you may end up eating more cycles moving stuff round
than leaving them in memory - I don't know. That's where I believe
optimizing compilers can come in - where a processor was not designed
for a stack intensive language like forth, an optimizing compiler can
certainly help.

>Well, where possible we always keep the top stack item in a register as well
>as the stack pointer, and also preserve several registers that can be used
>as scratch without saving & restoring. Usually you aren't dealing with more
>than the top few things, so it really isn't that costly.

I'm glad there are compilers like Swift and VFX - that's my point
exactly - we need compilers like these for machines that are not
exclusively designed for forth in mind.

>Do loops are somewhat more expensive than begin-type ("indefinite") loops,
>but you also get the loop counter -- depending on what you're doing, if you
>have to simulate a loop counter manually in an indefinite loop, it's slower
>than the do loop. The return stack pointer is almost always in a register,
>and that code is pretty tight. They're not nearly as bad as you seem to
>think. If you need to do something a known number of times or need access
>to a loop counter, you're better off using a do...loop.

Or a low level rewrite :) I've noticed a 30% - 100% gain in speed
doing so depending on the complexity - but then agian I may not be
writing optimal code at a higher level.

What I am really beginning to like about forth is it's ability to let
you go as low as you like and interactively debug the stuff and code
the stuff you don't want to code in a higher level language - which
you can write yourself even, all within the same environment with none
of that compile/asm/link cycle c has go undergo.

>>But in embedded systems code speed isn't usually the most important issue.
>Your performance is mainly going to depend on I/O, and memory may be
>limited. And I completely agree with Harkness' comment that ultimately it's
>the algorithm (or system design) that really matters. Let me tell you a
>true story (which old timers here have heard, but you haven't):

[snip]

Let me tell you another story about where I work we have software
running exclusively on x86 windoze pc's and for reasons best known to
IT (I don't work in IT - I don't do computers for a living!) put in
this JAVA application to access a database of very high resolution
images - which we have to look at very frequently.

God knows why. Didn't NEED to be in Java I reckon, but sure I'm not an
IT guy. Suffice to say it crawls... It may be badly written as well
for it needs restarting frequently.

I can't see why it could not have been done with Delphi... or to keep
with the KISS rule...

I can't see any reason why it couldn't have been a CGI app residing on
another server which one could access with a browser (it would then
theoretically be more portable even, you wouldn't even need java).

But such is fashion.. I guess..

But again, I'll say, Forth reminds me of the bygone days of an Apple
][ + and messing with 6502 code in the monitor. Which in my books is a
definite winner.

Maybe that's where you should target your customer base. There's lots
of people like me around you know? I have to admit, most will
initially go, 'You what? Forth?' but once they give it a try...

Cheers

Rob

### robert spykerman

Jan 18, 2005, 4:15:12 AM1/18/05
to
On Mon, 17 Jan 2005 13:22:35 -0500, m-coughlin
<m-cou...@comcast.net> wrote:

>robert spyke wrote:
>>
> Forth is neither a compiler nor an interpreter. It is its
>own thing. An optimizing compiler is needed for languages like
>Fortran and C. Forth does things differently. Is there such a
>thing as an optimizing assembler? I haven't heard of that yet.
>Maybe Forth should be in the same category.

I have to say, I was just thinking to myself what a wonderful
assembler forth is... I am almost tempted to say it's easier to write
assembly in forth than in a classical assembler because of the turn
around time, and also because realistically, it's rather impractical
to write large blocks of assembly in forth - so you've got to break
down and factor, which makes you plan a little more and not get too
caught up in rats nests.

I might get spanked for saying that but I say this with the following
caveat

1. I only mess with computers for fun. (ie not for a living)
2. I actually WANT to learn forth
3. I want to learn x86 assembly too

2 and 3 aren't particularly mutually exclusive in Forth I guess...

But I can see what you're saying about forth being it's own thing.

I would still argue an optimizing compiler is needed for Forth - if
it's embedded forth, to optimize for size perhaps, if constraints are
limited

Iff otherwise, it's likely to be for a desktop and AFAIK, none of the
major deskstops CPU's are stack CPU's, and hence optimisation is
desirable, if not, necessary, to compete with other languages like C -
algoritms being equal ... or should I say equivalent.... for example.

C compilers are VERY scary sometimes - the mainstream ones... Sure,
calls are expensive and all that but I think it's extremely hard to
beat them at assembly code generation if your c code is optimal. Only
when it does something silly that a human can see a better obvious
solution... Most know many tricks... I've learnt quite a bit from c
compiler output.....

Anyways back to the day job. Mmm.. that reminds me... have been
meaning to write up some words for statistics... Has anyone done this
yet? Might do that later.

Cheers

Rob

### Stan Barr

Jan 18, 2005, 4:21:06 AM1/18/05
to
On Mon, 17 Jan 2005 17:35:29 -0800, Elizabeth D. Rather <era...@forth.com>
wrote:
>
>Well, our primary business for >30 years has been providing Forth
>development systems and programming services for embedded systems. This is
>a field that doesn't get much publicity or books written about it, and I
>agree that it's too bad, since some studies I've seen indicate that there
>are lots more microprocessors in use than desktop computers (any reasonably
>new car has over 50, for example).

A recent magazine article stated that the second largest selling processor
in 2004 was the ARC with nearly 100 million sold in 2004, that must beat
the number of desktop units sold. I wonder, how many were programmmed in
Forth? It looks quite an interesting processor.

--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)

The future was never like this!

### Marc Olschok

Jan 18, 2005, 9:38:26 AM1/18/05
to
robert spykerman <robspyke_nospam@nos_spam_iprimus.com.au_nospam> wrote:
>[...]
> But again, I'll say, Forth reminds me of the bygone days of an Apple
> ][ + and messing with 6502 code in the monitor. Which in my books is a
> definite winner.

In fact there was a Forth (written by William Graves) for the Apple II
which made the Apple even more palatable in the old days.

Marc

### Paul E. Bennett

Jan 18, 2005, 1:13:33 PM1/18/05
to
Elizabeth D. Rather wrote:

[%X]

> .... I remember Chuck's axiom about the conservation of complexity;

That sounds like an interesting one. I don't recall seeing it written
anywhere. Is there a reference for it?