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.

From:	Federico de Ceballos
Subject:	Re: Starting out on Forth
Date:	Mon, 10 Jan 2005 16:33:51 +0100

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.

Perhaps you were thinking about:

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

which also works for 0. (Don't forget your stack comments.)

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

From:	Rob Spykerman
Subject:	Re: Starting out on Forth
Date:	10 Jan 2005 18:29:17 -0800

"Federico de Ceballos" wrote in message news:<34flhtF49u8enU1@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
about namespaces/dictionaries, conventions etc...

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

From:	Elizabeth D. Rather
Subject:	Re: Starting out on Forth
Date:	Mon, 10 Jan 2005 18:54:40 -0800

"Rob Spykerman" wrote in message
news:89589046.0501101829.6454ff7a@posting.google.com...
....
> 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
namespace to help you (e.g. if you need a word like READ to do different
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
> about namespaces/dictionaries, conventions etc...
>
> 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."
==================================================

From:	Anton Ertl
Subject:	Re: Starting out on Forth
Date:	Tue, 11 Jan 2005 17:24:36 GMT

robert.spykerman.1@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
to allow direct access to all the words during debugging.

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

From:	dhoffman at talkamerica.net
Subject:	Re: Starting out on Forth
Date:	10 Jan 2005 14:15:38 -0800

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
feel good about that.

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

From:	robert.spykerman.1 at gmail.com
Subject:	Re: Starting out on Forth
Date:	11 Jan 2005 02:17:00 -0800

Elizabeth D. Rather wrote:

> "Rob Spykerman" 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
> namespace to help you (e.g. if you need a word like READ to do
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

From:	Stephen Pelc
Subject:	Re: Starting out on Forth
Date:	Tue, 11 Jan 2005 13:11:50 GMT

On 11 Jan 2005 02:17:00 -0800, robert.spykerman.1@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, stephenXXX@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
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

From:	Elizabeth D. Rather
Subject:	Re: Starting out on Forth
Date:	Tue, 11 Jan 2005 12:06:33 -0800

wrote in message
news:1105438620.265077.30840@f14g2000cwb.googlegroups.com...
>
> ...
> 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
about this for now.

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

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

From:	Albert van der Horst
Subject:	focr was Re: Starting out on Forth
Date:	12 Jan 2005 04:07:47 +0100

In article <1105438620.265077.30840@f14g2000cwb.googlegroups.com>,
wrote:
>

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

>
>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.
albert@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst

From:	robert.spykerman.1 at gmail.com
Subject:	Re: Starting out on Forth
Date:	10 Jan 2005 18:50:19 -0800

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
dec ecx
jne l$1
ret
end-code

From:	Julian V. Noble
Subject:	Re: Starting out on Forth
Date:	Tue, 11 Jan 2005 16:36:23 -0500

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)

http://Galileo.phys.Virginia.EDU/classes/551.jvn.fall01/primer.htm

--
Julian V. Noble
Professor Emeritus of Physics
jvn@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)

From:	m-coughlin
Subject:	Re: Starting out on Forth
Date:	Thu, 13 Jan 2005 13:27:46 -0500

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
the initiated and by asking about anything you don't understand
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-coughlin@comcast.net Cambridge, MA USA

From:	Coos Haak
Subject:	Re: Starting out on Forth
Date:	Thu, 13 Jan 2005 20:12:10 +0100

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

From:	robert spyke
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 07:42:08 +1100

On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin

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

From:	Howard Lee Harkness
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 08:43:46 -0600

robert spyke wrote:

> m-coughlin 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.

From:	Albert van der Horst
Subject:	Re: Starting out on Forth
Date:	17 Jan 2005 10:19:42 GMT

In article <5bjlu0pm9mf9abv8mr206pk7i44u5c4ige@4ax.com>,
robert spyke 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.
Download the Pentium architecture manuals. They contain a
surprising amount of tutorial material.

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

From:	m-coughlin
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 12:32:09 -0500

robert spyke wrote:
>
> On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin
> 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
then to do anything worth buying. Nowadays, the increased power
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.

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

From:	Paul E. Bennett
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 22:27:06 +0000

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

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
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..
********************************************************************

From:	m-coughlin
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 13:22:35 -0500

robert spyke wrote:
>
> On Thu, 13 Jan 2005 13:27:46 -0500, m-coughlin
> 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
up well in Google searches.

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

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

From:	robert spykerman
Subject:	Re: Starting out on Forth
Date:	Tue, 18 Jan 2005 20:15:12 +1100

On Mon, 17 Jan 2005 13:22:35 -0500, m-coughlin

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

From:	Stephen Pelc
Subject:	Re: Starting out on Forth
Date:	Wed, 19 Jan 2005 09:54:11 GMT

On Mon, 17 Jan 2005 07:42:08 +1100, robert spyke
wrote:

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

Before you do that, you have to be able to compile it
correctly *in all cases*.

Especially with current implementations of the i32
instruction set and P4 memory system, it is quite
possible to improve code performance for one algorithm
and ruin it on another. This leads to testing on a
range of benchmarks, which in turn leads to arguments
about which benchmarks are relevant.

Stephen

--
Stephen Pelc, stephenXXX@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
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

From:	Elizabeth D. Rather
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 17:35:29 -0800

"robert spyke" wrote in
message news:5bjlu0pm9mf9abv8mr206pk7i44u5c4ige@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
that made all the difference.

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

From:	Stan Barr
Subject:	Re: Starting out on Forth
Date:	18 Jan 2005 09:21:06 GMT

On Mon, 17 Jan 2005 17:35:29 -0800, Elizabeth D. Rather
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!

From:	John Doty
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 20:38:22 -0700

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

From:	m-coughlin
Subject:	Re: Starting out on Forth
Date:	Thu, 20 Jan 2005 13:24:44 -0500

John Doty wrote:
>
> 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 :-)

My ambition is to be a renaissance man whose interests
cannot be neatly pigeonholed. Lets say for the sake of argument
that I am a Forth hobbyist, not a professional. As part of my
computer hobby, I look for people who could profitably use Forth
but do not, and pay particular attention to their reasons for
not using it or not even knowing it exists. Did anybody besides
me notice this thread was started by someone new to Forth who
mentioned he did not have an easy time finding what he wanted to learn?

Incidentally I am neither a Hahvahd guy nor an MIT guy. As
far as those institutions are concerned, I am just someone who
walks in off the street to use the facilities they provide to
the public to learn about science and technology. And they
provide many resources for this purpose. In ancient times I saw
Forth textbooks for sale in both the MIT and the Harvard U. bookstores.

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

I'm going to try to avoid getting too involved in new Forth,
old Forth, and mainstream obfuscation. Let's leave that to
another day. There is a larger picture that should be seen from
the lack
of new Forth texts at the MIT bookstore and, much more
important, from the MIT, Harvard and other college libraries. It
is a sign that no professor is assigning Forth to his students
and few academic researchers think they need to know about Forth
for current work. This has nothing to do with weather I think
ANS Forth is better or worse than the Forth of twenty years ago
(altho the Forth texts of twenty years ago are in the college
libraries). I think it is a sign that Forth is only of interest
to the generation of programmers who are about to retire. Now
there is nothing to prevent someone in touch with the real-world
to change this situation and maybe that will happen real-soon-now.

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

From:	Richard Owlett
Subject:	Re: Starting out on Forth
Date:	Thu, 20 Jan 2005 14:42:14 -0600

m-coughlin wrote:

> My ambition is to be a renaissance man whose interests
> cannot be neatly pigeonholed. Lets say for the sake of argument
> that ...

Full of sound and ....
Macbeth in "Macbeth" Act 5, Scene 5

From:	Elizabeth D. Rather
Subject:	Re: Starting out on Forth
Date:	Mon, 17 Jan 2005 19:56:34 -0800

"John Doty" wrote in message
news:41EC84AE.3020608@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.

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

From:	John Doty
Subject:	Re: Starting out on Forth
Date:	Tue, 18 Jan 2005 11:54:10 -0700

Elizabeth D. Rather wrote:
> "John Doty" wrote in message
> news:41EC84AE.3020608@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.

Sure. The space program is a museum of obsolete technologies. When I
redesigned the HETE measurement chains for Chandra, the R&QA folks made
me change the NPN transistors to 2N930's. I'm not sure when that spec
was registered, but it's listed in my 1962 GE Transistor Manual. Why
taking a silicon chip cooked in a relatively modern process, sticking it
in a brittle, obsolete package, and procuring it to a vague, sloppy spec
makes these guys believe it'll make your system more reliable I cannot say.

So, yes, there are still a few small things happening in Forth in space,
and there will continue to be for some time. That doesn't change the
fact that its reputation is in steep decline.

> I do know quite a lot about the Forth world,

*ANS* Forth world.

> and Mike makes a lot of
> extremely ill-informed statements about it.

Mike's statements are about Forth, not ANS Forth.

> My statement was that he's out
> of touch with the state of art in the Forth community -- I stand by that.

*ANS* Forth community.

> He hasn't read the books that are available today, nor used contemporary
> Forth systems, nor even followed closely what their capabilities are.

Could it be that *ANS* Forth isn't what he is interested in?

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

Comparing your products to your products says nothing about the state of
Forth in general. Your customers are also not representative of the
applications community in general. Mike is an excellent case of someone
who has used and appreciated Forth, but has been ill served by ANS
Forth. Behind him there are many, many more who have simply given up on
Forth. You know nothing of these people.

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

You haven't done your homework here. All you know is ANS Forth: you know
almost nothing of alternate techniques. You have no right to complain of
Mike's ignorance when your own ignorance is so much more comprehensive
and willful. You've hidden from the broader computing world for 30
years. "Easy to learn and use" for an ANS Forth specialist is nothing
like "easy to learn and use" for the rest of us.

It would be really nice to see Forth rise from the ashes and become a
viable option for my projects again. But every time you post, I get
discouraged: you are working as hard as you possibly can to marginalize
Forth further.

-jpd

From:	Paul E. Bennett
Subject:	Re: Starting out on Forth
Date:	Tue, 18 Jan 2005 18:13:33 +0000

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?

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
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..
********************************************************************

From:	Elizabeth D. Rather
Subject:	Re: Starting out on Forth
Date:	Tue, 18 Jan 2005 16:46:16 -0800

"Paul E. Bennett" wrote in message
news:csjjkc$gtl$1$830fa79d@news.demon.co.uk...
> 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?

It goes something like this:

Any given problem has a certain intrinsic level of complexity. In the
solution of the problem, this complexity will be conserved: if you dive in
with too little advance thought, your solution may become very complex by
the time it's done. On the other hand, if you invest more in thought,
design, and preparation, you may be able to achieve a very simple solution
(the complexity hasn't gone away, it's become embodied in the sophistication
of the design).

In connection with our recent discussion, that investment certainly can take
the form of prototyping. When I was working with Chuck, he'd typically go
through the following process:

1. Read the spec. Assert confidently that it really isn't as complicated as
that, and write a very clever program that solves the essence of the
problem.

2. Enter a phase in which the customer repeatedly points out aspects of the
spec that have been ignored or omitted; in fixing these, the code gets more
and more complicated.

3. At some point, a full understanding of the problem emerges. All the
previous code is thrown out and a new program emerges which represents a
simple, elegant solution to the *whole* problem.

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

From:	Paul E. Bennett
Subject:	Re: Starting out on Forth
Date:	Wed, 19 Jan 2005 20:25:58 +0000

Elizabeth D. Rather wrote:

> "Paul E. Bennett" wrote in message
> news:csjjkc$gtl$1$830fa79d@news.demon.co.uk...
>> 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?
>
> It goes something like this:
>
> Any given problem has a certain intrinsic level of complexity. In the
> solution of the problem, this complexity will be conserved: if you dive
> in with too little advance thought, your solution may become very complex
> by
> the time it's done. On the other hand, if you invest more in thought,
> design, and preparation, you may be able to achieve a very simple solution
> (the complexity hasn't gone away, it's become embodied in the
> sophistication of the design).
>
> In connection with our recent discussion, that investment certainly can
> take
> the form of prototyping. When I was working with Chuck, he'd typically go
> through the following process:
>
> 1. Read the spec. Assert confidently that it really isn't as complicated
> as that, and write a very clever program that solves the essence of the
> problem.
>
> 2. Enter a phase in which the customer repeatedly points out aspects of
> the spec that have been ignored or omitted; in fixing these, the code gets
> more and more complicated.
>
> 3. At some point, a full understanding of the problem emerges. All the
> previous code is thrown out and a new program emerges which represents a
> simple, elegant solution to the *whole* problem.
>
> Cheers,
> Elizabeth

Thanks Liz. That certainly falls into the lines that I was thinking it
might.

On the subject of prototypes, these need not always be code prototypes.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
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..
********************************************************************

From:	nocnick
Subject:	Re: Starting out on Forth
Date:	Wed, 19 Jan 2005 19:19:43 -0500

I start to like the idea, that certain stuff needs to be conserved thru
dark ages.

Closed up in monasteries with eager monks transcribing page for page and
trying to keep the flame alive.

Forth for sure is one of the things you have to close your eyes to see its
brightness, gee, I'm afraid I'm carried away by all the wisdom I read
here...

;)
Gerhard

From:	robert spykerman
Subject:	Re: Starting out on Forth
Date:	Tue, 18 Jan 2005 18:53:45 +1100

On Mon, 17 Jan 2005 17:35:29 -0800, "Elizabeth D. Rather"
wrote:

>"robert spyke" 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

That sort of madness...

>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

From:	Marc Olschok
Subject:	Re: Starting out on Forth
Date:	Tue, 18 Jan 2005 14:38:26 +0000 (UTC)

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

From:	robert.spykerman.1 at gmail.com
Subject:	Re: focr was Re: Starting out on Forth
Date:	12 Jan 2005 09:21:59 -0800

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

PS Off topic, but this google groups online newsreader is a load of
b0ll0x...

From:	Richard Owlett
Subject:	Re: focr was Re: Starting out on Forth
Date:	Wed, 12 Jan 2005 12:30:53 -0600

Cross posted comp.lang.forth and comp.dsp

robert.spykerman.1@gmail.com wrote:

>[SNIP]
>
> PS Off topic, but this google groups online newsreader is a load of
> b0ll0x...
>

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

Doubt I'll get response :(

From:	Richard Owlett
Subject:	Re: focr was Re: Starting out on Forth
Date:	Wed, 12 Jan 2005 14:46:15 -0600

Richard Owlett wrote:
> Cross posted comp.lang.forth and comp.dsp
>
> robert.spykerman.1@gmail.com wrote:
>
>> [SNIP]
>>
>> PS Off topic, but this google groups online newsreader is a load of
>> b0ll0x...
>>
>
> I just challenged Google to prove they pay attention to negative comments.
>
> Doubt I'll get response :(
>

Well I got expected AD (artificially dumb) reply

Odds on intelligent reply anyone ?

From:	Richard Owlett
Subject:	Re: focr was Re: Starting out on Forth
Date:	Thu, 13 Jan 2005 03:26:59 -0600

Richard Owlett wrote:
> Richard Owlett wrote:
>
>> Cross posted comp.lang.forth and comp.dsp
>>
>> robert.spykerman.1@gmail.com wrote:
>>
>>> [SNIP]
>>>
>>> PS Off topic, but this google groups online newsreader is a load of
>>> b0ll0x...
>>>
>>
>> I just challenged Google to prove they pay attention to negative
>> comments.
>>
>> Doubt I'll get response :(
>>
>
>
> Well I got expected AD (artificially dumb) reply
>
> Odds on intelligent reply anyone ?

I stand corrected. I've received the following:

"Thank you for your note. Please be assured that we read all the
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
improve Google Groups. We appreciate your comments and have passed
on your comp.lang.forth and comp.dsp search suggestions to the
appropriate team."

[ I had mentioned the gripes I'd seen about Google news groups in some
threads. ]

From:	Anton Ertl
Subject:	Re: focr was Re: Starting out on Forth
Date:	Thu, 13 Jan 2005 22:03:15 GMT

robert.spykerman.1@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.

>PS Off topic, but this google groups online newsreader is a load of
>b0ll0x...

I have recently added a section about reading and posting to
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
test, as such
newsreaders can help you to avoid a number of errors when posting
(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
original" button of Google groups or use
telnet errors.html#line-breaks>.

Not only your newsreader should be well-behaved, you should be as
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
have different cultures). If you want to learn more, read the
Netiquette , news.newusers.answers, about
smart questions ,
or about avoiding common mistakes
.

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

- 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

From:	Stephen Pelc
Subject:	Re: focr was Re: Starting out on Forth
Date:	Thu, 13 Jan 2005 09:30:13 GMT

On 12 Jan 2005 09:21:59 -0800, robert.spykerman.1@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.

Stephen

--
Stephen Pelc, stephenXXX@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
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

From:	Marcel Hendrix
Subject:	Re: focr was Re: Starting out on Forth
Date:	Thu, 13 Jan 2005 14:01:58 GMT

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

From:	Bruce McFarling
Subject:	Re: Starting out on Forth
Date:	14 Jan 2005 02:34:30 -0800

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.

From:	robert.spykerman.1 at gmail.com
Subject:	Re: Starting out on Forth
Date:	12 Jan 2005 10:29:09 -0800

Stephen Pelc wrote:
> On 11 Jan 2005 02:17:00 -0800, robert.spykerman.1@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

From:	Paul E. Bennett
Subject:	Re: Starting out on Forth
Date:	Wed, 12 Jan 2005 21:36:04 +0000