FORTH Trouble--Please Show Me

[Charles Richmond]

I am using FPC in the command window under Vista Home Premium.

Okay, I'm *not* a wonderful FORTH programmer. I know that. But I think the
following code should *not* break the interpreter... but it *does*!!! I load
the code and it compiles without complaint. I do a "CLEAR-G%" and *no*
complaint. Then I type in a "CLEAR-Q%"... and the FPC interpreter crashes
on me. Some complaint about a bad instruction.

I'm sure there are better and more efficient ways to do all the things I'm
trying to do. I just want to know *why* this code is broken.

(When I learn better... I will do better.)

Here is the code in question:


( this is a sample program )

: cell-matrix
create ( width height "name" ) over , * 2* allot
does> ( x y -- addr ) dup 2+ >r @ * + 2* r> + ;

: VECTOR CREATE 2* ALLOT DOES> SWAP 2* + ;

9 9 cell-matrix G%

9 9 cell-matrix Q%

7 VECTOR D%


: CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ;
: CLEAR-G% 10 0 DO 10 0 DO 0 I J G% ! LOOP LOOP ;


: set-quad
316 4 5 G% !
316 5 4 G% !

1 3 2 Q% !
2 6 4 Q% !
2 3 8 Q% !
2 5 1 Q% !
3 7 2 Q% !
3 2 7 Q% !
3 6 2 Q% !
3 2 6 Q% !
3 1 7 Q% !
3 7 1 Q% ! ;

( -------------------------------------------------- )


--
acer at aquaporin4 dot com

[Wolfgang Allinger]

On 17 Oct 12 at group /comp/lang/forth in article k5n9i1$b3a$1...@dont-email.me

<nume...@aquaporin4.com> (Charles Richmond) wrote:

>I am using FPC in the command window under Vista Home Premium.
>
>Okay, I'm *not* a wonderful FORTH programmer. I know that. But I
>think the following code should *not* break the interpreter... but it
>*does*!!! I load the code and it compiles without complaint. I do a
>"CLEAR-G%" and *no* complaint. Then I type in a "CLEAR-Q%"... and the
>FPC interpreter crashes on me. Some complaint about a bad instruction.
>
>I'm sure there are better and more efficient ways to do all the things
>I'm trying to do. I just want to know *why* this code is broken.
>
>(When I learn better... I will do better.)
>
>Here is the code in question:
>
>
>( this is a sample program )
>
>: cell-matrix
> create ( width height "name" ) over , * 2* allot
> does> ( x y -- addr ) dup 2+ >r @ * + 2* r> + ;
>
>: VECTOR CREATE 2* ALLOT DOES> SWAP 2* + ;
>
>9 9 cell-matrix G%
>
>9 9 cell-matrix Q%

[...]

>: CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ;
>: CLEAR-G% 10 0 DO 10 0 DO 0 I J G% ! LOOP LOOP ;

You declare 9x9=81 cells matrix, but scrubs 10x10 entries.

CLEAR-O% clears some space of Q% too. I forgot, where FPC stores the
array, but I think they were in the code area, so you overwrite some
code of Q% ...

make 9 0 do... or 10 10 cell-matrix....



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)

[Marcel Hendrix]

"Charles Richmond" <nume...@aquaporin4.com> writes Re: FORTH Trouble--Please Show Me

[..]

> Okay, I'm *not* a wonderful FORTH programmer. I know that. But I think the
> following code should *not* break the interpreter... but it *does*!!!

[..]
> 9 9 cell-matrix G%
[..]

This is a 9 x 9 array.

> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ;

[..]

And here you store 100 numbers in it.
The interpreter has every right to break.

I know what will happen next.

-marcel

[Sp...@controlq.com]

On Thu, 18 Oct 2012, Marcel Hendrix wrote:

> This is a 9 x 9 array.
>
>> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ;
> [..]
>
> And here you store 100 numbers in it.
> The interpreter has every right to break.
>
> I know what will happen next.
>
> -marcel
>
>

Marcel,

Perhaps you should recalibrate "The interpreter has every right to break."

Don't you really mean that interpreters should support bad application
code, and give meaningful error messages??

Cheers,
Rob Sciuk

[Hugh Aguilar]

On Oct 17, 2:56 pm, "Charles Richmond" <numer...@aquaporin4.com>
wrote:

> I'm sure there are better and more efficient ways to do all the things I'm
> trying to do.  I just want to know *why* this code is broken.
>
> (When I learn better... I will do better.)

I recommend against implementing data structures as a way to learn
Forth. I recommend that you write application programs in Forth first,
and tinker with the language later on only *after* gaining some
practical experience.

You can use my novice package:
http://www.forth.org/novice.html
You get arrays and lists and associative arrays, and a lot of other
stuff that is useful for writing programs.

[Mark Wills]

On Oct 17, 11:11 pm, all2...@spambog.com (Wolfgang Allinger) wrote:
>  On 17 Oct 12 at group /comp/lang/forth in article k5n9i1$b3...@dont-email.me
>  <numer...@aquaporin4.com>  (Charles Richmond)  wrote:

> (lt. alter usenet Weisheit)- Hide quoted text -
>
> - Show quoted text -

Indeed. It looks like the array is spilling over compiled code. That
will break the linked dictionary and therefore the interpreter will
fail to find words in the dictionary.

[Anonymous]

I'm not Marcel, but I'll take this one:

No, the interpreter can't do that (well it *could* on some systems but not
all) any more than C can prevent you from running off the end of a string or
array. If you write bad code and overlay storage, most applications are
going to crash.

[Charles Richmond]

"Mark Wills" <forth...@gmail.com> wrote in message
news:7c26c1a0-c61d-42c0...@b12g2000vbg.googlegroups.com...

>Indeed. It looks like the array is spilling over compiled code. That
>will break the linked dictionary and therefore the interpreter will
>fail to find words in the dictionary.

Thanks for the help!!! Yes, last night when I was about to sleep... it came
to me that I had overrun the arrays when I tried to clear them. Duh!!!
I'll go away now... and slink back into my dungeon. :-)

--

numerist at aquaporin4 dot com

[Marcel Hendrix]

Sp...@ControlQ.com writes Re: FORTH Trouble--Please Show Me

> On Thu, 18 Oct 2012, Marcel Hendrix wrote:

>> This is a 9 x 9 array.
>>
>>> : CLEAR-Q% 10 0 DO 10 0 DO 0 I J Q% ! LOOP LOOP ;
>> [..]
>>
>> And here you store 100 numbers in it.
>> The interpreter has every right to break.
>>

[..]

> Perhaps you should recalibrate "The interpreter has every right to break."

I should have said "Under no conditions the interpreter should try to cover
up obvious mistakes -- I want to know about them as soon as possible."

> Don't you really mean that interpreters should support bad application
> code, and give meaningful error messages??

You can make high-level Forth do anything you want. However, the code
as written is extremely low-level:

: cell-matrix
create ( width height "name" ) over , * cells allot
does> ( x y -- addr ) dup cell+ >r @ * + cells r> + ;

This is not the code of a beginner. It can not be designed by a programmer
who has no notion of how memory is layed out, and also shows mastering
of the stack. In such a case and for such a user the Forth interpreter
should do EXACTLY what it is told. Any problems with this code should be
caught 1 second after it is written, during the first interactive tests
with DUMP etc.

Alternatively I could say that this is not application code. The word will
be hidden deep into something else and the top-level code will take care of
catching any (range or datatype) errors. As it is not application code, it
is not bad, and needs no safety-net.

Meaningful (that's not the same for everybody) error messages would be nice.

FORTH> 99 0 !
Caught exception 0xc0000005
ACCESS VIOLATION
instruction pointer = $0000000001131203
RAX = $01142E30 RBX = $00000000
RCX = $00000000 RDX = $00000041
RSI = $01045C00 RDI = $0140079A
RBP = $01025F88 RSP = $094AF820
R8 = $00000000 R9 = $010124B8
R10 = $00FD5BD0 R11 = $0501FC00
R12 = $00FD84E0 R13 = $01047000
R14 = $01036000 R15 = $01010000
Hardware exception in ``!''+$0000000B
**** RETURN STACK DUMP ****

But the hardware does not / cannot protect when we store to an address
in user memory -- there are no "good" or "bad" addresses there, we are
entitled and even encouraged (by the language) to access them all and
do anything we want with them.

I guess that what you mean is that the code is allowed to crash,
but there must be a host of diagnostics when that happens. I agree.

It would be nice to have a monitor that can protect an arbitrary block
of memory and shows the source code of any word that tries to store or
fetch there. (I can do this by starting the Forth interpreter within
Visual studio, get the adresses I need by poking around, exit to the
debugger, set breakpoints and monitors, re-enter Forth and run my code
at full speed, waiting until the debugger finds something. Piece of
cake but used maybe once every 10 years.

-marcel

[Mark Wills]

On Oct 18, 8:08 pm, m...@iae.nl (Marcel Hendrix) wrote:
> S...@ControlQ.com writes Re: FORTH Trouble--Please Show Me

In Forth one can simply re-define @ and ! have them trap/abort if they
access a memory area that is unexpected.

Nice!

[Sp...@controlq.com]

On Thu, 18 Oct 2012, Anonymous wrote:

> Date: Thu, 18 Oct 2012 08:49:46 +0000 (UTC)
> From: Anonymous <nob...@remailer.paranoici.org>
> Newsgroups: comp.lang.forth
> Subject: Re: FORTH Trouble--Please Show Me

Admittedly, run time bounds checking has a price, but if this were under
the control of a global setting, one might use a "safe" mode to debug new
code, and a "fast" mode to run production code.

I'm not proposing global bounds checking, but low hanging fruit like stack
overflow/underflow should and could be handled this way, and perhaps
dictionary and heap management should be simple to check. Indeed, forth
encourages system exploration in an interactive environment, so this
cannot be too restrictive ...

IMHO.

Rob.

[Albert van der Horst]

In article <alpine.BSF.2.00.1...@yoko.controlq.com>,
<Sp...@ControlQ.com> wrote:
<SNIP>

>Admittedly, run time bounds checking has a price, but if this were under
>the control of a global setting, one might use a "safe" mode to debug new
>code, and a "fast" mode to run production code.
>
>I'm not proposing global bounds checking, but low hanging fruit like stack
>overflow/underflow should and could be handled this way, and perhaps
>dictionary and heap management should be simple to check. Indeed, forth
>encourages system exploration in an interactive environment, so this
>cannot be too restrictive ...

You missed an important point here. If you can get your arrays right
with bound checking, you certainly can get them right without.
If you make a mistake in the bounds checking, you're back to square one.
So it makes sense for novices to use a novice package to be saved
from this. The logic behind the Novice Package of Aguilar is flawless.

>
>IMHO.
>
>Rob.
>

Groetjes Albert

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message
news:2017da18-ac49-4b0e...@pz10g2000pbb.googlegroups.com...
...

> I recommend against implementing data structures as
> a way to learn Forth.

Lol! Classic.

That should be your in your signature.


RP

[Hugh Aguilar]

On Oct 18, 12:58 pm, S...@ControlQ.com wrote:
> On Thu, 18 Oct 2012, Anonymous wrote:
> > Date: Thu, 18 Oct 2012 08:49:46 +0000 (UTC)
> > From: Anonymous <nob...@remailer.paranoici.org>
> > Newsgroups: comp.lang.forth
> > Subject: Re: FORTH Trouble--Please Show Me
>

My arrays do have a compiler directive that can be set to turn on
bounds checking or turn it off for better speed. This is "low-hanging
fruit" --- it is easy to implement, and it helps catch bugs. Mark's
suggestion of rewriting @ and ! is also good. Sometimes some data is
getting corrupted and you have no idea what is corrupting it --- you
can generally be pretty sure that it is a ! or C! or CMOVE however, so
you can rewrite these to find your bug for you. C programmers would do
this with ICE, but that is way more complicated than I care for --- I
never really use symbolic debuggers, although I did write one for my
65c02 cross-compiler a long time ago when I was still a novice. I
remember in MS-DOS days that soft-ICE was The technology for the
80286, but that was then --- nobody does that anymore.

It is not just novices who make dumb mistakes such as forgetting that
an array is 9x9 and accessing it as if it were 10x10, everybody does
that. I did the exact same thing when I wrote my alien-alphabet
program earlier. I solved the problem quickly enough though. This kind
of mishap is typical of programming. This is why I'm unimpressed by
people who talk a lot about programming theory but who never write any
programs --- most of them have bumped into these problems and didn't
solve them, or they took forever solving them and became frustrated
--- so they stop writing programs and just focus on talking up their
own expertise on forums like this. Well, I have sobering news for
these self-proclaimed experts --- programming is mostly about
debugging, and if you can't do this then you aren't a programmer.

[Hugh Aguilar]

On Oct 19, 4:42 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message

I don't know why you laugh at this.

Writing programs is the best way to learn. It is fun, you get a sense
of accomplishment, and you learn the language. Implementing low-level
data structures such as arrays is not fun but is quite boring, and you
don't get any sense of accomplishment because you still haven't
written a program that does something.

I recommend writing a program that does something that you find
interesting outside of the context of programming. Most people like
games, so writing a game that you would enjoy playing is a good way to
start. I did that with Forth when I was 18, and I'm doing it now with
Scheme. What else would I do? To write a program more complicated than
Hello-World however, you need to have basic data-structures such as
records, arrays and lists already available.

[Mark Wills]

On Oct 20, 2:39 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
80286, but that was then --- nobody does that anymore.
>

> This is why I'm unimpressed by
> people who talk a lot about programming theory but who never write any
> programs --- most of them have bumped into these problems and didn't
> solve them, or they took forever solving them and became frustrated
> --- so they stop writing programs and just focus on talking up their
> own expertise on forums like this. Well, I have sobering news for
> these self-proclaimed experts --- programming is mostly about
> debugging, and if you can't do this then you aren't a programmer.

Exactly. Or those bloody annoying articles that one reads all over the
web talking about how finding bugs is really hard, and constantly
developing new 'stuff' (languages) to "solve" the "problem".

"Yeah we found that language X was too difficult to debug, so we made
language Y"
<a year later>
"Yeah we found that language Y was too difficult to debug, so we made
language Z"

Of course, Z is no better than Y or X. But it doesn't suffer from the
"not invented here" syndrome, so it is "better".

You know what? STFU. Man up. Study your code, and fix it.

Oh, and comment your code properly. Give yourself and others a chance!

[Elizabeth D. Rather]

This whole thing is a great lesson in good programming strategy. It is
poor strategy to use as many literal values as Charles has. If you
define a SIZE constant for your array and use it, it's easy to avoid
overruns. If you use the CELL-words instead of 2* etc. for conversions,
your code will be easier to port to a 32-bit environment. The basic
commandment (not specific to Forth) is "avoid 'magic' numbers" meaning
literals that should really be a named and reused value.

And I see no reason why the interpreter should have figured this out.
The program crashed. That's a great diagnostic. Crashed programs are (in
human interface terms) far more useful in getting you to pay attention
to coding strategy than error messages, which are much too easy to ignore.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[A. K.]

On 20.10.2012 09:00, Elizabeth D. Rather wrote:
> And I see no reason why the interpreter should have figured this out.
> The program crashed. That's a great diagnostic. Crashed programs are (in
> human interface terms) far more useful in getting you to pay attention
> to coding strategy than error messages, which are much too easy to ignore.
>

Okay for the development process, but not okay for productive systems.

You can't leave a system in an undefined state following a crash.
An exception handling process and outputting diagnostic information is
nearly always a must.

[Elizabeth D. Rather]

The primary causes of exceptions in a production system, assuming that
system was thoroughly tested before deployment, are inappropriate or
invalid input caused by user error or faulty equipment. Checking input
is always an imperative, and appropriate response to erroneous input
should be an element in the system's design. Input should be checked at
the point at which it enters the system, so that redundant internal
checks can be safely avoided.

Charles' problem was a program bug. Program bugs that cause the system
to crash, as this one, are easily detected and repaired, and can be
avoided by good programming practice such as I was recommending. Program
bugs that don't cause crashes need to be eradicated through
pre-deployment testing.

Cheers,
elizabeth

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:7fa71346-ad58-4baf...@p5g2000pbs.googlegroups.com...

> On Oct 19, 4:42 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> wrote:
> > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
> >
news:2017da18-ac49-4b0e...@pz10g2000pbb.googlegroups.com...
...

> > > I recommend against implementing data structures as
> > > a way to learn Forth.
> >
> > Lol! Classic.
> >
> > That should be your in your signature.
>

> I don't know why you laugh at this.

Over the past six years, I can't even tell you how many Forth people posting
here, and on other newsgroups I read also, constantly tout how good Forth
is. But, all I see, without intending to incite flames, is a very weak
language, as compared to many others, most notably C. Yet, none of these
promoters of Forth ever see it's weakness, or perhaps are just unwilling to
openly admit them. There are many areas of weakness in C, and I've
discussed them with many people, in many different groups. You, without
realizing it - perhaps, summarized, in one concise sentence, one of the many
glaring defects of Forth: correctly implementing Forth data structures. I
found it funny that you would attempt to learn a language without also
learning how to implement data structures at the same time. The two go hand
in hand. Without data structures, a language is just a bunch of do-nothing
loops and if's. You basically said you should learn Forth without learning
a critical component of it! Now, having read many of your posts, I took
your own apparent revulsion to implementing data structures in Forth to be a
direct response of you developing them for your novice and slide rule Forth
packages. Am I mistaken?


Rod Pemberton

[Elizabeth D. Rather]

On 10/20/12 3:03 PM, Rod Pemberton wrote:
...
>>>> I recommend against implementing data structures as
>>>> a way to learn Forth.
>>>
>>> Lol! Classic.
>>>
>>> That should be your in your signature.
>>
>> I don't know why you laugh at this.
>
>
> Over the past six years, I can't even tell you how many Forth people posting
> here, and on other newsgroups I read also, constantly tout how good Forth
> is. But, all I see, without intending to incite flames, is a very weak
> language, as compared to many others, most notably C. Yet, none of these
> promoters of Forth ever see it's weakness, or perhaps are just unwilling to
> openly admit them. There are many areas of weakness in C, and I've
> discussed them with many people, in many different groups. You, without
> realizing it - perhaps, summarized, in one concise sentence, one of the many
> glaring defects of Forth: correctly implementing Forth data structures.

You're making the mistake of listening to Hugh, rather than the
horselaugh that follows his absurd assertion.

And you're making the mistake of judging Forth based on a feature list,
without actually making the effort to learn how it's used in applications.

How can the ability to define any kind of data structure you want, with
exactly the compile-time and run-time behavior you need, be a weakness?
It's one of the most powerful features I've seen in any language.

Cheers,
Elizabeth

[Paul Rubin]

"Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
> Without data structures, a language is just a bunch of do-nothing
> loops and if's. You basically said you should learn Forth without learning
> a critical component of it!

Especially in the embedded regime, a heck of a lot of real-world
programs don't have any complex algorithms or data structures. There's
just some variables and maybe a few arrays, plus the stacks for
intermediate values and control, plus a bunch of special case tests and
i/o for the application at hand. Even numerical computation (numerical
linear algebra or signal processing, say), which does use fancy
algorithms, tends to still not use advanced data structures beyond the
aforesaid variables and arrays.

Language processing and compilers do use fancy data structures, and
Forth newbies who get interested in implementing Forth themselves, often
get advised not to do it. That is probably not a coincidence.
Implementing Forth in Forth typically uses data structures that are
within Forth's capabilities, but not completely within its comfort zone.
And those data structure (linear ALLOT area and linked wordlists) are
themselves unusually simple compared to what more usual compiler writers
are used to.

[Elizabeth D. Rather]

On 10/20/12 3:52 PM, Paul Rubin wrote:
> "Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
>> Without data structures, a language is just a bunch of do-nothing
>> loops and if's. You basically said you should learn Forth without learning
>> a critical component of it!
>
> Especially in the embedded regime, a heck of a lot of real-world
> programs don't have any complex algorithms or data structures. There's
> just some variables and maybe a few arrays, plus the stacks for
> intermediate values and control, plus a bunch of special case tests and
> i/o for the application at hand. Even numerical computation (numerical
> linear algebra or signal processing, say), which does use fancy
> algorithms, tends to still not use advanced data structures beyond the
> aforesaid variables and arrays.
>

This is true, but Forth's ability to define application-specific data
types is still valuable in embedded systems. Examples I've seen include
named "objects" that are actually data ports (or even selected bits on a
data port) with implicit reads or writes when accessed; circular buffers
for high-speed data acquisition, and a circular list of polynomial
coefficients that returns the next one when referenced.

The ability to define custom data types easily is one of Forth's most
powerful (and unique) features. But it's also something that's easy for
beginners to learn, and I think it would be a massive disservice to
advise someone to forgo learning it!

[Hugh Aguilar]

On Oct 20, 6:00 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>

I wouldn't say that I have a "revulsion" for implementing data
structures from my experience implementing them in the novice package
(the slide-rule program was a demonstration of the novice package, and
I didn't implement any data structures in there) --- implementing data
structures isn't particularly difficult.

I'm saying that novices shouldn't be required to implement data
structures before they can write their first program. They should have
basic stuff such as records, arrays and linked-lists available
already. This is necessary for even the simplest program.

Novices need to get their feet wet writing programs. They need the
sense of accomplishment that comes from writing a program that works
and does something. What it does can be fairly simple such as
converting data from one format to another. It can even do something
silly like play Pong on a text screen (use the asterisk as the ball
and the square brackets as the paddle). It has to do something though.
Implementing arrays or whatever is just boring, because when you are
done you can't claim to have yet written a program.

I remember in MS-DOS days that we had QBasic that lacked records. The
typical solution was to define multiple arrays, each of which
contained one field of the record. After you calculate your index it
would be used in the appropriate array to get whatever field you need.
PolyForth also lacked records. It is actually easy to implement
records, but "Starting Forth" was so novice-level that it didn't even
provide this "advanced" information. The result is that people tended
to consider Forth in the same category as QBasic, which is to say that
they were toy languages unsuitable for writing real programs. Also,
people would sometimes carry over their QBasic techniques, such as the
several arrays representing a record, to their Forth programming. This
looked ridiculous! They didn't know any better though. I've read
Elizabeth Rather's books, the handbook and the application guide
(which cost me about $75), and they were extremely light on useful
information. There is nothing in there explaining the implementation
of even rudimentary data structures. People just figure this stuff out
on their own eventually, but they mostly screw it up. My novice
package provides these data structures in a way that is robust and
efficient --- most people just implement this stuff off the cuff when
they need it and produce something that can't really be reused in
another program, so every program has a different ad hoc
implementation of arrays or linked lists or whatever, and this lack of
consistency is largely what gives Forth a reputation for being
unreadable.

I agree that Forth has weaknesses. I don't think that C is any better
though; C is worse. Forth is pretty lame compared to Scheme or Lisp
however. In my novice package I implemented linked lists. I provided
EACH that would take the xt of a function (what I call a "toucher" in
the documentation) and execute it for every node in the list. This is
much better than manually writing out a loop every time that you need
to traverse a list. In my slide-rule program there are over 30 uses of
EACH --- you don't want to write essentially the same code that many
times. In Scheme this kind of thing is common. In Forth, people just
write all of their code manually over and over again. In Forth
something like EACH is difficult to implement because ANS-Forth lacks
closures. Both Forth and C are seriously hamstrung by their lack of
support for closures. Straight Forth will have closures though ---
this will be its strong point. You can't use Scheme on a micro-
controller, as a lot of Scheme features such as dynamic OOP and GC are
inappropriate. With Straight Forth however, you will get closures and
so you can program in a Scheme-like way --- but still use a language
appropriate for micro-controllers.

I recommend that Forth be used for micro-controller programming,
Scheme or Lisp be used for desktop-computer application programming,
and C be phased out.

"When C++ is your hammer, every problem looks like your thumb." (this
is some guy's tag-line on the Racket mailing list)

[Marcel Hendrix]

Sp...@ControlQ.com writes Re: FORTH Trouble--Please Show Me

> On Thu, 18 Oct 2012, Anonymous wrote:

[..]

>>> Perhaps you should recalibrate "The interpreter has every right to break."
>>>
>>> Don't you really mean that interpreters should support bad application
>>> code, and give meaningful error messages??

[..]

> Admittedly, run time bounds checking has a price, but if this were under
> the control of a global setting, one might use a "safe" mode to debug new
> code, and a "fast" mode to run production code.

The Forth language specification does not define arrays. How do you let
the interpreter do automatic bounds checking then? In my experience bounds
checks for ordinary variables is not needed when one uses (F)(D)X)(Z)VALUEs
instead (i.e the type can be a problem more than the index).

Programmers that have trouble with out-of-bounds accesses are advised to
write their array code including checks. "Safe" array definers are
one of the most published (and least used) code snippets in Forth.

> I'm not proposing global bounds checking, but low hanging fruit like stack
> overflow/underflow should and could be handled this way, and perhaps
> dictionary and heap management should be simple to check. Indeed, forth
> encourages system exploration in an interactive environment, so this
> cannot be too restrictive ...

> IMHO.

If you check out a few modern Forths, you will notice that they already
do all of what you propose above (and more)?

A long time ago I proposed that Forthers post all the silly mistakes they
make when writing something new (or debugging/using something old).
Unfortunately there were no reactions.

Most bugs that I make myself are related to specifications (unclear, or
incomplete, or too difficult/timeconsuming to get right for the first
version). There is also a large number of problems related to interfacing
with other programs or the OS (e.g. a file that is written by A that
must be opened by B but the OS/A takes its time to really write it).

A very large number of bugs (and very murky code) is related to
trying to make a program run on both Windows and Linux, or to support
interfaces to more than one external program (e.g. both LTSpice and
NGSpice, or both sockets and pipes, or FORTRAN and C-style interfacing).
It seems to be generally better to write the program in a very modular
way for one situation and then port it to the other ones. However, at
some point you do the port, and maintainance/upgrading doesn't work that way.

-marcel

[Andrew Haley]

Rod Pemberton <do_no...@notemailnotz.cnm> wrote:

> Over the past six years, I can't even tell you how many Forth people
> posting here, and on other newsgroups I read also, constantly tout
> how good Forth is. But, all I see, without intending to incite
> flames, is a very weak language, as compared to many others, most
> notably C. Yet, none of these promoters of Forth ever see it's
> weakness, or perhaps are just unwilling to openly admit them.

Or maybe they just disagree with you. I think that's not really fair.
Many of us use C for various things, and we're well aware of its
strengths and weaknesses. Forth is not a "weak language". Forth is
great. It's not perfect. But it takes a completely different
approach to software development than C does.

That you can easily create structures is a substantial advantage
because it allows you create the exact ones you need. There is
absolutely no reason for a beginner to use a "training wheels"
approach with a bunch of canned data structures because structures
aren't hard to write. It's a good confidence-booster during an
introductory course and it's a fundamental skill you need to have to
be a Forth programmer. Having said that, we've added simple
structures to Forth 200x. These aren't the same as C structures, but
they do the job.

Given that you think that Forth is a weak language, why are you here?

Andrew.

[Doug Hoffman]

On 10/21/12 6:22 AM, Marcel Hendrix wrote:

> Programmers that have trouble with out-of-bounds accesses are advised to
> write their array code including checks.

The original poster had no idea that was his problem. Chicken and egg?

> "Safe" array definers are
> one of the most published (and least used) code snippets in Forth.

Interesting statement given the original post. But you're right, he
didn't use it (and likely wishes he had).

-Doug

[Rod Pemberton]

"Andrew Haley" <andr...@littlepinkcloud.invalid> wrote in message
news:MoydnTfoOPwQUx7N...@supernews.com...
> Rod Pemberton <do_no...@notemailnotz.cnm> wrote:
...

> Given that you think that Forth is a weak language, why are you here?
>

I'm working on getting my ITC Forth interpreter in C to pass the remaining
1/3rd or so of Hayes core. Except for a handful of primitives (in C), a
bunch of variables, and a few parsing words (compiled Forth in C), much of
it is now coded in Forth (as ASCII text).


Rod Pemberton

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:717bab9e-8733-4399...@i2g2000pbi.googlegroups.com...

> On Oct 20, 6:00 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> wrote:

...

> [Novices] should have basic stuff such as records,

> arrays and linked-lists available already.

C has structs and arrays. That's what's needed.

> This is necessary for even the simplest program.

As C proves - it's missing them too - there is minimal need for
linked-lists. Are they needed from time to time? Yes. So are complex
numbers, but C didn't support those for a long time either.

> I remember in MS-DOS days that we had QBasic that lacked records.
> The typical solution was to define multiple arrays, each of which
> contained one field of the record. After you calculate your index it
> would be used in the appropriate array to get whatever field you need.

Isn't that the way Forth _still_ does it?

See CFA, LFA, PFA, or >BODY, >NAME, >LINK, etc. They all define
offsets from the start of a "struct". I think I may have mentioned this in
a prior conversation. The only C compiler I'm aware of that requires the
user to use offsets to implement struct's is an old and very primitive
compiler known as SmallC.

> I agree that Forth has weaknesses. I don't think that C is any better
> though; C is worse.

Yet, nearly every language in existence uses or has used C as it's backend.
Doesn't that prove C's effectiveness?

> In Forth something like EACH is difficult to implement because
> ANS-Forth lacks closures. Both Forth and C are seriously hamstrung
> by their lack of support for closures.

"Closures" seems to be the one "magic" feature that everyone seems to think
is missing from their favorite language. What's so special about closures?

What does C need closures for? What does Forth ... ?

I may have asked you that previously. I know I've asked others on
comp.lang.misc and elsewhere. I doubt I've gotten a satisfactory answer so
far. I may need to see sample code to grasp the issue ...

C has been used to implement nearly all, if not all, of the languages on
Wikipedia's "closure" page that have closures or closure like structures. I
know I've been over _this_ previously on c.l.f. ...

> [...] and C be phased out.

Lol! (I just don't foresee that happening any time soon.)

C still very effectively captures the "essence" of a modern microprocessor.


Rod Pemberton

[Bernd Paysan]

Andrew Haley wrote:
> Given that you think that Forth is a weak language, why are you here?

Trolling to annoy people, of course. I think that's easy to guess,
given how he behaved in the past. Don't feed the trolls.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Charles Richmond]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:0df4f181-de4d-4943...@v11g2000pbs.googlegroups.com...

It's the infamous off-by-one error. With loops, that off-by-one gets
*multiplied*! :-)

"To err is human; it takes a computer to really foul things up."

[Paul Rubin]

"Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
> C has structs and arrays. That's what's needed.

Well, C doesn't really have arrays ;-).

> "Closures" seems to be the one "magic" feature that everyone seems to think
> is missing from their favorite language. What's so special about closures?

They're not magic. You can do similar things with OOP or structs
containing function pointers and data, but closures avoid a lot of
syntactic clutter and bureaucracy compared to that. Example in Python:

def square(x):
return x*x

def derivative(f, h): # approximate numerical derivative
def df(x):
return (f(x+h) - f(x)) / h
return df

print square(3) # prints 9
print derivative(square,0.0001)(3) # prints approximately 6

You could write something like "derivative" in C with function pointers,
but it would be much messier.

> C has been used to implement nearly all, if not all, of the languages on
> Wikipedia's "closure" page that have closures or closure like structures. I
> know I've been over _this_ previously on c.l.f. ...

It's just the usual situation of using a simpler tool to implement a
more advanced one. Jet engines are made using screwdrivers, not the
other way around. C is the screwdriver in that picture.

[Marcel Hendrix]

Paul Rubin <no.e...@nospam.invalid> writes Re: FORTH Trouble--Please Show Me
[..]

> Example in Python:
>
> def square(x):
> return x*x
>
> def derivative(f, h): # approximate numerical derivative
> def df(x):
> return (f(x+h) - f(x)) / h
> return df
>
> print square(3) # prints 9
> print derivative(square,0.0001)(3) # prints approximately 6

> You could write something like "derivative" in C with function pointers,
> but it would be much messier.

[..]

I doubt the much in "much messier."

-marcel

-- -------------------
ANEW -derivative

: eval ( ? xt -- ? ) ( F: ? -- ? ) EXECUTE ;

: derivative ( xt -- ) ( F: x h -- d )
LOCAL f FLOCALS| h x |
x h F+ f eval x f eval F- h F/ ;

CR 3e FSQR F. \ prints 9
CR ' FSQR 3e 1e-4 derivative F. \ prints approximately 6

\ FORTH> in idata/derivative
\ 9.000000
\ 6.000100 ok

[Hugh Aguilar]

On Oct 21, 6:36 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message

>
> news:717bab9e-8733-4399...@i2g2000pbi.googlegroups.com...> On Oct 20, 6:00 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> > wrote:
>
> ...
>
> > [Novices] should have basic stuff such as records,
> > arrays and linked-lists available already.
>
> C has structs and arrays.  That's what's needed.
>
> > This is necessary for even the simplest program.
>
> As C proves - it's missing them too - there is minimal need for
> linked-lists.  Are they needed from time to time?  Yes.  So are complex
> numbers, but C didn't support those for a long time either.

I was impressed by how Factor uses "sequences" as its primary data
structure (these are arrays, but with Factor's dynamic memory they can
be resized easily). There are other data structures available, and you
can write whatever you want, but all the libraries primarily expect
data in sequences. Similarly, Scheme and Lisp use lists, which behave
very similarly to sequences although they are implemented differently
internally. Lua has tables. Awk has associations, which are similar.

I think that every language needs to have a standard data structure
that all the libraries primarily work with. This is what Forth sorely
lacks however. I implemented linked-lists in the novice package for
this purpose. Almost all programs can use them. In some cases a
different data structure, such as a hash table or a binary tree, might
be a better choice (I provided association arrays based on LLRB trees
in the novice package for anybody who needs this). You can go pretty
far with lists however --- I use them all the time.

Complex numbers are completely different. This isn't a general-purpose
data-structure; this is for a specific and rare use. Fortran had
complex numbers and matricies, but it was not a general-purpose
language --- it was for numerical work (something that most
programmers avoid like the plague).

The word "computer" implies that the things compute numerically. This
may have been true in the 1950s when the machines were replacing rooms
full of guys with slide-rules, but it isn't true anymore. Beginning in
the 1960s, almost all software involves converting data from one
format to another. The machines should be called "formatters" rather
than "computers."

> > I remember in MS-DOS days that we had QBasic that lacked records.
> > The typical solution was to define multiple arrays, each of which
> > contained one field of the record. After you calculate your index it
> > would be used in the appropriate array to get whatever field you need.
>
> Isn't that the way Forth _still_ does it?
>
> See CFA, LFA, PFA, or >BODY, >NAME, >LINK, etc.  They all define
> offsets from the start of a "struct".  I think I may have mentioned this in
> a prior conversation.  The only C compiler I'm aware of that requires the
> user to use offsets to implement struct's is an old and very primitive
> compiler known as SmallC.

I don't understand what you are saying. All records (structs) are
implemented with offsets. You have the record with all of the fields
adjacent to each other, and you access the fields by their offset from
the base of the record.

In QBasic, the fields weren't adjacent to each other. There was a
separate array for each field. This was a crude workaround for
QBasic's lack of support for records.

> > I agree that Forth has weaknesses. I don't think that C is any better
> > though; C is worse.
>
> Yet, nearly every language in existence uses or has used C as it's backend.
> Doesn't that prove C's effectiveness?

That doesn't "prove" anything.

Look at how horribly slow Gforth is. That is because it was written in
C rather than assembly-language. Your C-based Forth will also be
horribly slow for the same reason.

I have never seen any language written in C that provided decent
speed. C is used primarily for convenience. We have scripting
languages such as Lua or AutoLisp that don't have to be fast, but are
just provided to allow the user of the software to customize it. We
also have languages such as Gambit or Chicken Scheme that allow the
programmer to take advantage of the many C libraries available. In all
cases however, C implementations are grossly inefficient compared to
assembly-language implementations.

> > In Forth something like EACH is difficult to implement because
> > ANS-Forth lacks closures. Both Forth and C are seriously hamstrung
> > by their lack of support for closures.
>
> "Closures" seems to be the one "magic" feature that everyone seems to think
> is missing from their favorite language.  What's so special about closures?
>
> What does C need closures for?  What does Forth ... ?
>
> I may have asked you that previously.  I know I've asked others on
> comp.lang.misc and elsewhere.  I doubt I've gotten a satisfactory answer so
> far.  I may need to see sample code to grasp the issue ...

Look at my slide-rule program. See how I use EACH. ANS-Forth doesn't
really support closures, but this is pretty close.

Closures are hugely important! I think that OOP is overrated; I'm only
going to support a very rudimentary form of OOP in Straight Forth. By
comparison however, closures can't be overrated --- they really
simplify programs a lot.

> C has been used to implement nearly all, if not all, of the languages on
> Wikipedia's "closure" page that have closures or closure like structures.  I
> know I've been over _this_ previously on c.l.f. ...
>
> > [...] and C be phased out.
>
> Lol!  (I just don't foresee that happening any time soon.)
>
> C still very effectively captures the "essence" of a modern microprocessor.

That is definitely bad news, that the essence of modern
microprocessors could be something so ugly and limiting as C. I think
that is more the essence of C programmers, rather than the essence of
the hardware --- the hardware can support any language.

It is true that many microprocessors were designed to support C. The
x86, for example, has support for the C stack-frame, and it even has
ENTER and LEAVE instructions (as does the 68000). The processors were
designed this way because C was popular, and this doesn't at all imply
that C became popular because it C is a natural language for micro-
processors --- you are getting cause and effect mixed up. Processors
can be designed to support any language --- Forth and Lisp have both
been targeted successfully.

As a practical matter, I agree that C won't get phased out any time
soon. I am learning Gambit Scheme primarily because it compiles into C
and hence can use C libraries. There are a lot of C libraries! By
comparison, Racket Scheme and the several Common Lisp systems can
interface to C libraries but this isn't really what they are for ---
they each have their own ecosystem of libraries. By using Gambit
Scheme I can use C without having to actually program in C --- keep
the ugliness hidden under the hood.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>> Given that you think that Forth is a weak language, why are you here?
>
> Trolling to annoy people, of course. I think that's easy to guess,
> given how he behaved in the past. Don't feed the trolls.

Ah, okay, that makes sense. I was wondering.

Andrew.

[Paul Rubin]

m...@iae.nl (Marcel Hendrix) writes:
> ANEW -derivative
>
> : eval ( ? xt -- ? ) ( F: ? -- ? ) EXECUTE ;
>
> : derivative ( xt -- ) ( F: x h -- d )
> LOCAL f FLOCALS| h x |
> x h F+ f eval x f eval F- h F/ ;
>
> CR 3e FSQR F. \ prints 9
> CR ' FSQR 3e 1e-4 derivative F. \ prints approximately 6

If I understand this, it doesn't actually create a closure. Rather, it
passes a function as an arg to derivative that gets called during the
call to derivative, so if you want to compute two derivatives you have
to call "derivative" twice. Maybe I'm wrong. Can you do this slightly
modified example? Change

print square(3) # prints 9
print derivative(square,0.0001)(3) # prints approximately 6

to:

print square(3) # prints 9

d = derivative(square, 0.00001)
print d(3) # prints approximately 6
print d(4) # prints approximately 8

I may not have made it clear enough earlier: the thing coming back from
"derivative" is a value that you can (for example) save in the variable
"d" (like above). That value is the closure.

[van...@vsta.org]

Paul Rubin <no.e...@nospam.invalid> wrote:
> "Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
>> C has structs and arrays. That's what's needed.
> Well, C doesn't really have arrays ;-).

Well, no, C really does have arrays. You're confused because C also has
a connection between pointer arithmetic and arrays. But C does also have
plain old arrays. If I do array accesses like:

int
myfunc(void)
{
int a[4][4];
int x, y;

for (x = 0; x < 4; ++x) {
for (y = 0; y < 4; ++y) {
a[x][y] = x*y;
}
}
}

a[] is *not* an array of pointers. a[1][2] is calculated in the
classic Fortran style by scaling the indices of each subscript of
the multi-dimensional array.

--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[Bernd Paysan]

Hugh Aguilar wrote:
> Look at how horribly slow Gforth is. That is because it was written in
> C rather than assembly-language. Your C-based Forth will also be
> horribly slow for the same reason.

I don't know what you mean with "horribly slow". E.g. take a very
classical Forth benchmark, the Byte sieve one. On my machine, gforth-
fast does this benchmark in 0.325s (1000 times primes, x64
architecture). VFXForth, which has a way more sophisticated compiler,
does it in 0.215s. bigForth, which is a less sophisticated native code
compiler for x86, does it in 0.277s - both use the x86 architecture,
i.e. the register starved 32 bit model.

We did put quite some effort into Gforth to make it fast while still
using the C compiler - the latter to make it easy enough to port. The
effort to write a compiler like the one in VFX is tremendous, and not
worth to repeat for more than a very few popular platforms. I.e. the
result wouldn't be a very portable Forth.

I'm not actually looking forward to your "straight Forth", because I
don't think it ever will see light. But if it does, I hope it is at
least a factor 10 faster than Gforth, because "horribly slow" is usually
something you can't only measure, but you can really perceive as big
difference. A factor 10 is perceivable. If you achieve this, I will
call you Superman.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Hugh Aguilar wrote:
>> Look at how horribly slow Gforth is. That is because it was written in
>> C rather than assembly-language. Your C-based Forth will also be
>> horribly slow for the same reason.
>
> I don't know what you mean with "horribly slow".

Hold on! I'm sure you just told me "Don't feed the trolls."

Andrew.

[Bernd Paysan]

Ok, yes, I shouldn't feed Hugh either ;-). But doing these benchmarks
was fun, and from time to time I want to know how horribly slow Gforth
really is.

[m...@iae.nl]

On Monday, October 22, 2012 2:11:17 AM UTC+2, Paul Rubin wrote:
> Can you do this slightly modified example?

[..]
-- first version
: derive ( xt -- ) ( F: x h -- d )

LOCAL f FLOCALS| h x |

x h F+ f EXECUTE x f EXECUTE F- h F/ ;

CR 3e FSQR F. .( \ prints 9 )
CR ' FSQR 3e 1e-4 derive F. .( \ prints approximately 6 )

-- second version
: derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name"
CREATE F, , DOES> F@+ @ derive ;

' FSQR 1e-4 derivative d
CR 3e FSQR F. .( \ prints 9 )
CR 3e d F. .( \ prints approximately 6 )
CR 4e d F. .( \ prints approximately 8 )

-marcel

[Paul Rubin]

m...@iae.nl writes:
> -- second version
> : derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name"
> CREATE F, , DOES> F@+ @ derive ;
>
> ' FSQR 1e-4 derivative d
> CR 3e FSQR F. .( \ prints 9 )
> CR 3e d F. .( \ prints approximately 6 )
> CR 4e d F. .( \ prints approximately 8 )

This is better, though it allocates permanent space in the dictionary
rather than returning a temporary value (the Python program used a
variable but the Forth equivalent would be to return a value on the
stack). Of course Python uses something like ALLOCATE under the hood,
and automatically reclaims the space once the value has no live
references left, and you could do something similar with Anton's garbage
collector for Gforth. Anyway I'll accept that your second version is
reasonably close, and only somewhat messy.

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:4915176.b...@sunwukong.fritz.box...

> Hugh Aguilar wrote:
> > Look at how horribly slow Gforth is. That is because it was written in
> > C rather than assembly-language. Your C-based Forth will also be
> > horribly slow for the same reason.
>
> I don't know what you mean with "horribly slow".

My Forth is interpreted as in ITC. So, yes, it'll be slow as compared to a
compiled Forth. But, I think Hugh was referring to the usually switch()
based Forth in C, which aren't very fast either. GForth moved "beyond" that
design years ago.

> E.g. take a very
> classical Forth benchmark, the Byte sieve one. On my machine, gforth-
> fast does this benchmark in 0.325s (1000 times primes, x64
> architecture). VFXForth, which has a way more sophisticated compiler,
> does it in 0.215s. bigForth, which is a less sophisticated native code
> compiler for x86, does it in 0.277s - both use the x86 architecture,
> i.e. the register starved 32 bit model.
>
> We did put quite some effort into Gforth to make it fast while still
> using the C compiler - the latter to make it easy enough to port. The
> effort to write a compiler like the one in VFX is tremendous, and not
> worth to repeat for more than a very few popular platforms. I.e. the
> result wouldn't be a very portable Forth.

Correction:
"... did put quite some effort into" _Gforth-fast_ "to make ..."

My ITC interpreter easily outperforms GForth ITC, except for loops - where
it is currently very, very slow. The loop constructs are now coded in
Forth. It does nothing special. It's very simple. It has almost no
optimizations. In fact, I've been making it progessively *slower* in
order to eliminate C code. It'll be reworked later, after the
transformation is complete. The loop constructs might be converted to
low-level words or primitives at that time.


Rod Pemberton

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:1d7dd236-5952-41eb...@i7g2000pbf.googlegroups.com...

> On Oct 21, 6:36 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> wrote:
> > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
news:717bab9e-8733-4399...@i2g2000pbi.googlegroups.com...

> > > I remember in MS-DOS days that we had QBasic that lacked records.
> > > The typical solution was to define multiple arrays, each of which
> > > contained one field of the record. After you calculate your index it
> > > would be used in the appropriate array to get whatever field you need.
>
> > Isn't that the way Forth _still_ does it?
>
> > See CFA, LFA, PFA, or >BODY, >NAME, >LINK, etc. They all define
> > offsets from the start of a "struct". I think I may have mentioned this
> > in a prior conversation. The only C compiler I'm aware of that requires
> > the user to use offsets to implement struct's is an old and very
> > primitive compiler known as SmallC.
>
> I don't understand what you are saying. All records (structs) are
> implemented with offsets. You have the record with all of the fields
> adjacent to each other, and you access the fields by their offset from
> the base of the record.

Yes, but the C compiler takes care of it for you when you define a struct.
Forth doesn't. It requires you to define the offsets yourself.

> Look at how horribly slow Gforth is. That is because it was written in
> C rather than assembly-language. Your C-based Forth will also be
> horribly slow for the same reason.

Yes, all interpreters are "slow".

I already told you both here a while ago and on c.l.a.x. recently that my
interpreter is faster than GForth-ITC. It does nothing special. It's just
a simple implementation in C. This is except for LOOP related words, which
I've re-implemented in Forth while working through a process of minimizing
the C related code. So, they're very, very slow now. They were slow before
though too, as pre-compiled Forth in C. I never implemented them as
primitives or low-level words.

> > C still very effectively captures the "essence" of a modern
> > microprocessor.
>
> That is definitely bad news, that the essence of modern
> microprocessors could be something so ugly and limiting as C. I think
> that is more the essence of C programmers, rather than the essence of
> the hardware --- the hardware can support any language.

It's the reason C and Forth are still around. Look at all the other "dead"
languages. None of them fit the standard machine model: two's complement
arithmetic, contiguous memory, 8-bit bytes for ASCII or EBCDIC, pointers the
same size as an integer type, Von Neumann architecture, etc.

> It is true that many microprocessors were designed to support C. The
> x86, for example, has support for the C stack-frame, and it even has
> ENTER and LEAVE instructions (as does the 68000). The processors were
> designed this way because C was popular, and this doesn't at all imply
> that C became popular because it C is a natural language for micro-
> processors --- you are getting cause and effect mixed up. Processors
> can be designed to support any language --- Forth and Lisp have both
> been targeted successfully.

I'm not familiar with Lisp processors.

As for Forth, I'd agree except for one word: "successfully". It depends on
what you mean by "successfully". Yes, Forth processors were and are
successfully manufactured, but which of them has successfully captured a
microprocessor market? None of them that I'm aware of have.


Rod Pemberton

[Hugh Aguilar]

On Oct 21, 5:51 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Hugh Aguilar wrote:
> > Look at how horribly slow Gforth is. That is because it was written in
> > C rather than assembly-language. Your C-based Forth will also be
> > horribly slow for the same reason.
>
> I don't know what you mean with "horribly slow".

I didn't benchmark it, I just ran my own programs and timed them. A
lot of my programs do recursive-descent searches and they can take
several minutes to run. The slide-rule program doesn't search, but it
still takes several minutes to run, just because it is doing a lot.
Roughly speaking, I found SwiftForth to be 2 times faster than Gforth.
With some assembly-language help for SwiftForth (mostly in LIST.4TH
for programs like SLIDE-RULE.4TH that use lists a lot) it was 3 times
faster.

This was with SwiftForth 2.0, as I don't have 3.0 (and I'm not going
to spend another $300 to get it). SwiftForth does almost no
optimization at all. It will inline short machine-code functions to
save the CALL/RET, but it isn't really optimizing. It is just pasting
the code snippets together. It is still pushing values onto the stack
and immediately taking them off again. It is pretty lame.

I have always suspected that the reason why Gforth was written in C,
was to ensure that it wouldn't run faster than SwiftForth. I think
Elizabeth Rather insisted that Gforth be slower than SwiftForth in
exchange for allowing you guys to participate in creating ANS-Forth
and Forth-200x. That whole standards committee is a charade --- Forth
Inc. has veto power over everybody --- none of you guys can buck them.

> E.g. take a very
> classical Forth benchmark, the Byte sieve one.  On my machine, gforth-
> fast does this benchmark in 0.325s (1000 times primes, x64
> architecture).  VFXForth, which has a way more sophisticated compiler,
> does it in 0.215s.  bigForth, which is a less sophisticated native code
> compiler for x86, does it in 0.277s - both use the x86 architecture,
> i.e. the register starved 32 bit model.
>
> We did put quite some effort into Gforth to make it fast while still
> using the C compiler - the latter to make it easy enough to port.  The
> effort to write a compiler like the one in VFX is tremendous, and not
> worth to repeat for more than a very few popular platforms.  I.e. the
> result wouldn't be a very portable Forth.
>
> I'm not actually looking forward to your "straight Forth", because I
> don't think it ever will see light.  But if it does, I hope it is at
> least a factor 10 faster than Gforth, because "horribly slow" is usually
> something you can't only measure, but you can really perceive as big
> difference.  A factor 10 is perceivable.  If you achieve this, I will
> call you Superman.

Are you aware that Straight Forth is a cross-compiler for micro-
controllers? I will first be targeting the PIC24. From there maybe
onto the MSP430. Eventually some 32-bit targets such as the PIC32, the
ARM or the AVR32 (but not the x86). I'm mostly interested in 16-bit
micro-controllers though. Does Gforth even run on 16-bit micro-
controllers?

Straight Forth is actually two Forth systems. We have HostForth which
runs on the x86. The only program that will ever be written in
HostForth is TargForth, which is the cross-compiler. TargForth
generates the micro-controller program.

If HostForth is slow, the only effect will be that TargForth will
compile programs slowly. Even if HostForth is very slow however,
TargForth should still compile large programs in under a second. There
is no real point in my spending a lot of time on HostForth's speed ---
it can be a crude threaded system and still be plenty fast for what it
is being used for. HostForth will be written in assembly language (HLA
right now, although I may change later in order to get 64-bit x86),
and I expect it to be about 2 times faster than SwiftForth, but if it
isn't I won't care.

Also, btw, Straight Forth will not be ANS-Forth compliant. This makes
it difficult to compare speeds with Gforth. Its main feature will be
closures. People are going to use iterators a lot --- they aren't
going to manually write loops with BEGIN all that much. I won't
support DO loops at all. Lists will be used a lot. The programs will
look different --- there is a lot of influence from Scheme here.

What kind of benchmarks are used to test micro-controller systems?
Most micro-controller programs spend somewhere around 1/2 of their
time in ISRs (Straight Forth will support ISRs but will take away some
features such as floating-point). What kind of benchmark would be
meaningful in the context of micro-controllers? Straight Forth is
intended to be used for hobbyist robotics. Maybe we should just build
robots and have them fight! :-)

[Rod Pemberton]

"Paul Rubin" <no.e...@nospam.invalid> wrote in message
news:7x3917h...@ruckus.brouhaha.com...

> "Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
> > C has structs and arrays. That's what's needed.
>
> Well, C doesn't really have arrays ;-).
>

That's true. But, I can't seem to convince other C programmers, be it
novices or "experts" of that. So, I've stopped placing arrays in quotes
and preferencing it with: C as in C "arrays".

And, I always seem to get one guy from comp.lang.c that insists C does have
arrays...

Of course, they've never read the early B and C papers by Dennis Ritchie,
Brian Kernighan, Ken Thompson, and Steve Johnson where this is revealed, or
even realize a famous quote they've likely quoted applies to arrays in C.

Most C programmers don't seem to understand how C fits onto assembly or is
converted to it. They all believe that a house (C specification) without a
foundation (assembly and a machine model) is perfectly valid.

Of course, as those original authors and others like Samuel Harbison and Guy
Steele, Jr. have noted, that's not true either. C fits onto certain
processor architectures very well and doesn't fit others.

> > "Closures" seems to be the one "magic" feature that everyone seems to
> > think is missing from their favorite language. What's so special about
> > closures?
>
> They're not magic. You can do similar things with OOP or structs
> containing function pointers and data, but closures avoid a lot of
> syntactic clutter and bureaucracy compared to that. Example in Python:
>
> def square(x):
> return x*x
>
> def derivative(f, h): # approximate numerical derivative
> def df(x):
> return (f(x+h) - f(x)) / h
> return df
>
> print square(3) # prints 9
> print derivative(square,0.0001)(3) # prints approximately 6
>
> You could write something like "derivative" in C with function pointers,
> but it would be much messier.

I only understand this in two ways:

1) passing function pointers
2) as macro processing

I don't understand this in the object-oriented sense of code plus data that
is always mentioned in regards to closures.


Rod Pemberton

[Elizabeth D. Rather]

On 10/21/12 9:56 PM, Rod Pemberton wrote:
> "Hugh Aguilar" <hughag...@yahoo.com> wrote in message
> news:1d7dd236-5952-41eb...@i7g2000pbf.googlegroups.com...
>> On Oct 21, 6:36 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
>> wrote:
>>> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
> news:717bab9e-8733-4399...@i2g2000pbi.googlegroups.com...
>
>>>> I remember in MS-DOS days that we had QBasic that lacked records.
>>>> The typical solution was to define multiple arrays, each of which
>>>> contained one field of the record. After you calculate your index it
>>>> would be used in the appropriate array to get whatever field you need.
>>
>>> Isn't that the way Forth _still_ does it?

"Forth" doesn't do it. Forth *programmers* can do it any way that works
for the application at hand (satisfying whatever requirements there are
for performance, flexibility, readability, etc.).

>>> See CFA, LFA, PFA, or >BODY, >NAME, >LINK, etc. They all define
>>> offsets from the start of a "struct". I think I may have mentioned this
>>> in a prior conversation. The only C compiler I'm aware of that requires
>>> the user to use offsets to implement struct's is an old and very
>>> primitive compiler known as SmallC.
>>
>> I don't understand what you are saying. All records (structs) are
>> implemented with offsets. You have the record with all of the fields
>> adjacent to each other, and you access the fields by their offset from
>> the base of the record.
>
> Yes, but the C compiler takes care of it for you when you define a struct.
> Forth doesn't. It requires you to define the offsets yourself.

It can, if you write your struct that way. The FORTH, Inc. database
system didn't follow the struct model for records, but used a much more
convenient model that didn't require explicit offsets, for example.

You're still following the thought model of adapting your familiar
programming style, tools, etc., to Forth. In order to fully appreciate
Forth you have to learn to think differently. You don't build with steel
and aluminum the same way you do with bricks.

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message

news:36511775....@sunwukong.fritz.box...

> Andrew Haley wrote:
> > Given that you think that Forth is a weak language, why are you here?
>
> Trolling to annoy people, of course. I think that's easy to guess,
> given how he behaved in the past. Don't feed the trolls.
>

You may be a long time contributor here, but you haven't posted anything of
any value since '04. I know. I've read many of your old posts. They come
up in searches on Forth issues. I've read the past posts of many others
here too and even those who aren't here anymore. Given your Forth skill,
you don't need to consult any Forth experts here. You don't ask any Forth
related questions. You're not helping any novices learn Forth. You're not
contributing to the future of Forth. So, it's you who might as well leave.
This group serves no purpose for you, _anymore_ . The only thing here is
your online friends. It's time to move on or meet them in real life.

As I recall (AIR), you picked a fight with me first. I was posting here for
some years asking just basic Forth questions for my interpreter. There was
never a response of any type by you to my posts. No kind replies. No angry
replies. No informative replies. There was absolutely nothing from you.
You completely ignored me. Then, out of nowhere you verbally attacked me!
About a month later, Passaniti did for the first time of many times to
follow. I think it was about my fourth year. So, given your past abusive
behavior, you don't get to call me a troll. You initiated this and still
instigate.


Rod Pemberton

[Paul Rubin]

"Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
> I only understand this in two ways:
>
> 1) passing function pointers
> 2) as macro processing
>
> I don't understand this in the object-oriented sense of code plus data that
> is always mentioned in regards to closures.

There is no macro processing going on. The thing returned from
derivative is a structure containing a pointer to some code (the
function that computes (f(x+h)-f(x))/h given f and h, plus some data (a
pointer to the function f, and the number h). It's messy to do in C
partly because of having to deal with those pointers and structures
explicitly, and partly with having to allocate and free the storage for
them.

[Hugh Aguilar]

On Oct 22, 1:08 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:

> Of course, they've never read the early B and C papers by Dennis Ritchie,
> Brian Kernighan, Ken Thompson, and Steve Johnson where this is revealed, or
> even realize a famous quote they've likely quoted applies to arrays in C.
>
> Most C programmers don't seem to understand how C fits onto assembly or is
> converted to it.  They all believe that a house (C specification) without a
> foundation (assembly and a machine model) is perfectly valid.
>
> Of course, as those original authors and others like Samuel Harbison and Guy
> Steele, Jr. have noted, that's not true either.  C fits onto certain
> processor architectures very well and doesn't fit others.

Does your extensive reading on C include the ugly-fish book?

http://www.e-reading.org.ua/bookreader.php/138815/Expert_C_Programming%3A_Deep_C_Secrets.pdf

[Hugh Aguilar]

On Oct 22, 1:40 am, Paul Rubin <no.em...@nospam.invalid> wrote:

It is messy to do in Forth because the function passed in doesn't have
access to the parent function's local variables. This is what Straight
Forth will provide.

In the novice package I wrote the iterators such as EACH in such a way
that they held all of their internal data on the return stack when
calling the function that was passed in. This means that the passed-in
function has access to the parameter stack --- everything that the
parent function had on the stack is right there available for the
passed-in function to modify. This is how the passed-in function
communicates with the parent function. It is a half-step towards
closures. Everything in the novice package is just a work-around for
all of the problems in ANS-Forth --- it is depressing --- it inspires
me to write my own Forth and forget about ANS-Forth altogether.

I wouldn't mess with anything like this in C. For one thing,
typedefing a pointer to a function is just painful. Also, the function
is not going to have access to the parent function's local variables,
which is the whole point of the exercise. C is actually much worse
than Forth --- and Forth is pretty bad.

[Hugh Aguilar]

On Oct 22, 12:52 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>

wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message

> > It is true that many microprocessors were designed to support C. The
> > x86, for example, has support for the C stack-frame, and it even has
> > ENTER and LEAVE instructions (as does the 68000). The processors were
> > designed this way because C was popular, and this doesn't at all imply
> > that C became popular because it C is a natural language for micro-
> > processors --- you are getting cause and effect mixed up. Processors
> > can be designed to support any language --- Forth and Lisp have both
> > been targeted successfully.
>
> I'm not familiar with Lisp processors.
>
> As for Forth, I'd agree except for one word: "successfully".  It depends on
> what you mean by "successfully".  Yes, Forth processors were and are
> successfully manufactured, but which of them has successfully captured a
> microprocessor market?  None of them that I'm aware of have.

The MiniForth was designed to support a motion-control program. This
program did get ported over to the MiniForth (it ran on the Dallas
80c320 previously). All of those motion-control boards from Testra now
contain a MiniForth processor.

I wrote MFX. Only one program has ever been written in MFX, but that
is infinitely more than most compiler-writers have. :-)

[Stephen Pelc]

On Mon, 22 Oct 2012 02:51:02 +0200, Bernd Paysan <bernd....@gmx.de>
wrote:

>I don't know what you mean with "horribly slow". E.g. take a very
>classical Forth benchmark, the Byte sieve one. On my machine, gforth-
>fast does this benchmark in 0.325s (1000 times primes, x64
>architecture). VFXForth, which has a way more sophisticated compiler,
>does it in 0.215s. bigForth, which is a less sophisticated native code
>compiler for x86, does it in 0.277s - both use the x86 architecture,
>i.e. the register starved 32 bit model.

As you yourself have commented several times, be careful with
benchmarks. Over the application benchmarks on the MPE website,
the gforth-fast time is 3.90 times the VFX time on an i7.

>We did put quite some effort into Gforth to make it fast while still
>using the C compiler - the latter to make it easy enough to port. The
>effort to write a compiler like the one in VFX is tremendous, and not
>worth to repeat for more than a very few popular platforms.

x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430

The effort put in to designing and implementing the first two VFX
compilers was huge. Implementing a code generator for a new CPU is
a matter of a few weeks, including writing the assembler and
disassembler. However, I will concede that, over the years, we
have put more effort into the x86 code generator than we should
have done. After initially writing a reasonable quality code
generator, further improvements are usually a matter of incremental
development.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Stephen Pelc]

On Mon, 22 Oct 2012 01:03:43 -0700 (PDT), Hugh Aguilar
<hughag...@yahoo.com> wrote:

>That whole standards committee is a charade --- Forth
>Inc. has veto power over everybody --- none of you guys can buck them.

Total rubbish. Both MPE and Forth Inc have been outvoted in the past.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> m...@iae.nl writes:
>> -- second version
>> : derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name"
>> CREATE F, , DOES> F@+ @ derive ;
>>
>> ' FSQR 1e-4 derivative d
>> CR 3e FSQR F. .( \ prints 9 )
>> CR 3e d F. .( \ prints approximately 6 )
>> CR 4e d F. .( \ prints approximately 8 )
>
> This is better, though it allocates permanent space in the dictionary
> rather than returning a temporary value (the Python program used a
> variable but the Forth equivalent would be to return a value on the
> stack).

Yeah, but that's just Forth: Forth generally prefers static allocation
to dynamic allocation. A dynamic version would surely have been
possible, but in the absence of GC its use would have been a bit
painful.

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> Yeah, but that's just Forth: Forth generally prefers static allocation
> to dynamic allocation. A dynamic version would surely have been
> possible, but in the absence of GC its use would have been a bit
> painful.

Right, the same could be said for C. The conclusion is that using this
style in either of those languages probably more trouble than it's
worth.

[Bernd Paysan]

Stephen Pelc wrote:
> As you yourself have commented several times, be careful with
> benchmarks. Over the application benchmarks on the MPE website,
> the gforth-fast time is 3.90 times the VFX time on an i7.

Everybody uses the benchmarks where their compiler shines most. The
sieve you use takes 458ms here on Gforth, ours takes 321ms. It's doing
the same thing, we just use +LOOP for the inner loop, and not this
horribly bad coding style from the Byte article. Maybe this gives an
advantage for Gforth and a disadvantage for VFX? It's not deliberately.
Using +LOOP instead of the WHILE loop is a code cleanup for style
purposes that already had been done in VolksForth, from which I
inherited that benchmark.

However, as several benchmarks are almost identical (you also do fib):
Why on earth is your Core i7 only marginally faster than my netbook AMD
E-350, at less than half the frequency and a much smaller die? I would
expect a Core i7 at 3.4GHz to run the current Gforth sieve benchmark in
~100ms.

There's something fishy going on. I don't know, maybe the Windows
version of Gforth 0.7.0 still suffers from GCC problems or whatever.

Another fishy thing (which don't go into the factor 3.9, but where
Gforth on your machine is really horribly slow): You test 40k times
KEY?, and Gforth comes out at 765ms on a really fancy Core i7 at 3.4GHz.
On my machine (Linux, E-350, 1.6GHz), this takes 48ms. Cygwin problem?
Maybe. Some simple innocent and fast code on Linux might turn out as
nightmarish slow on Cygwin.

>>We did put quite some effort into Gforth to make it fast while still
>>using the C compiler - the latter to make it easy enough to port. The
>>effort to write a compiler like the one in VFX is tremendous, and not
>>worth to repeat for more than a very few popular platforms.
>
> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>
> The effort put in to designing and implementing the first two VFX
> compilers was huge. Implementing a code generator for a new CPU is
> a matter of a few weeks, including writing the assembler and
> disassembler. However, I will concede that, over the years, we
> have put more effort into the x86 code generator than we should
> have done. After initially writing a reasonable quality code
> generator, further improvements are usually a matter of incremental
> development.

There's another reason for not using the C compiler: You don't have to
work around the bugs each new version brings you.

And yes: Be careful with benchmarks. Different people will get
different results. All of them are invalid, because only liars do
benchmarks.

[humptydumpty]

On Sunday, October 21, 2012 7:52:00 PM UTC, Paul Rubin wrote:
> "Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
>
> > C has structs and arrays. That's what's needed.
>
>
>
> Well, C doesn't really have arrays ;-).
>
>
>

> > "Closures" seems to be the one "magic" feature that everyone seems to think
>
> > is missing from their favorite language. What's so special about closures?
>
>
>
> They're not magic. You can do similar things with OOP or structs
>
> containing function pointers and data, but closures avoid a lot of
>
> syntactic clutter and bureaucracy compared to that. Example in Python:
>
>
>
> def square(x):
>
> return x*x
>
>
>
> def derivative(f, h): # approximate numerical derivative
>
> def df(x):
>
> return (f(x+h) - f(x)) / h
>
> return df
>
>
>
> print square(3) # prints 9
>
> print derivative(square,0.0001)(3) # prints approximately 6
>
>
>
> You could write something like "derivative" in C with function pointers,
>
> but it would be much messier.
>
>
>

> > C has been used to implement nearly all, if not all, of the languages on
>
> > Wikipedia's "closure" page that have closures or closure like structures. I
>
> > know I've been over _this_ previously on c.l.f. ...
>
>
>

> It's just the usual situation of using a simpler tool to implement a
>
> more advanced one. Jet engines are made using screwdrivers, not the
>
> other way around. C is the screwdriver in that picture.

Hi Paul!

Tested in gforth:

: fsqr ( F: x -- y )
fdup f* ;

: derivative ( -- xt[F:x--y] ) ( F: h -- )
:noname
postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
postpone fswap compile, postpone f- postpone fliteral
postpone f/ postpone ;
; immediate

3e0 1e-4 derivative fsqr execute

Have a nice day,
humptydumpty

[Marcel Hendrix]

Paul Rubin <no.e...@nospam.invalid> writes Re: FORTH Trouble--Please Show Me

In a Forth context (this is CLF) it is absolutely no limitation that
dictionary space is allotted. This is because "derivative" is executed
only once [here *]. The data space allotted by F, and , is insignificant
with respect to d's header space.

As Forth is an interpreter (as is Python!), the space taken by words
like d can never be reclaimed: at any time the user may type "d". Only
the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted
space.

If use of 'd-type' words is such that they can't be reached by the interpreter
anymore, this can only mean that MARKER has been executed. In that case all
space is (automatically) reclaimed. Forth words can execute MARKER words.

I admit that I am resisting going along with your silent demand to show a
extremely messy and complicated bastard closure in Forth :-)
A basic idea in Forth is to not building in hooks that may never be used [*].

Believe me, the better your specification for a useful piece of code that
absolutely needs closures, the happier both of us will be.

And yes, I really think that the Forth interpreter should be kept in all
Forth programs, and that all Forth programs should be built from source.

-marcel

[Paul Rubin]

humptydumpty <oua...@gmail.com> writes:
> : derivative ( -- xt[F:x--y] ) ( F: h -- )
> :noname
> postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
> postpone fswap compile, postpone f- postpone fliteral
> postpone f/ postpone ;
> ; immediate
>
> 3e0 1e-4 derivative fsqr execute

Thanks. I don't really understand that but I thought I'd test it. I wrote:

: dsin ( F: x -- y ) 1e-4 derivative fsin execute ;

which should approximately compute cos x, by taking the derivative of
sin at x. It gave me a floating stack undeflow error as soon as I tried
to compile the word. Any advice? The next thing I wanted to try was
finding -sin(x) by differentiating again:

: d2sin ( F: x -- y) 1e-4 derivative dsin execute ;

Overall I think the solution uses too much metaprogramming.

[Marcel Hendrix]

Bernd Paysan <bernd....@gmx.de> writes Re: FORTH Trouble--Please Show Me

> Stephen Pelc wrote:
>> As you yourself have commented several times, be careful with
>> benchmarks. Over the application benchmarks on the MPE website,
>> the gforth-fast time is 3.90 times the VFX time on an i7.

> Everybody uses the benchmarks where their compiler shines most. The
> sieve you use takes 458ms here on Gforth, ours takes 321ms. It's doing
> the same thing, we just use +LOOP for the inner loop, and not this
> horribly bad coding style from the Byte article. Maybe this gives an
> advantage for Gforth and a disadvantage for VFX? It's not deliberately.
> Using +LOOP instead of the WHILE loop is a code cleanup for style
> purposes that already had been done in VolksForth, from which I
> inherited that benchmark.

What hardware are you using? A steam-powered CPU?

> However, as several benchmarks are almost identical (you also do fib):
> Why on earth is your Core i7 only marginally faster than my netbook AMD
> E-350, at less than half the frequency and a much smaller die? I would
> expect a Core i7 at 3.4GHz to run the current Gforth sieve benchmark in
> ~100ms.

On my hardware ( i7 2.66 GHz ) gForth 0.7 runs it in 171 ms, while
iForth64 takes 79 ms and VFX 32bit 93 ms.

> There's something fishy going on. I don't know, maybe the Windows
> version of Gforth 0.7.0 still suffers from GCC problems or whatever.

[..]

Then fix it :-)

-marcel

-- ---------------------------------------------------------------------

\ i7 system, 2.66 GHz, Windows 7.

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
include siev.fs ok

main main main
171000 us elapsed
172000 us elapsed
171000 us elapsed ok


-- ----------------------------
marker -sieve

CREATE FLAGS 8190 ALLOT
variable eflag

: PRIMES ( -- n )
FLAGS 8190 1 FILL
0 3 EFLAG @ FLAGS
DO
I C@
IF DUP I + DUP EFLAG @ <
IF EFLAG @ SWAP
DO 0 I C! DUP +LOOP
ELSE DROP
THEN
SWAP 1+ SWAP
THEN 2+
LOOP DROP ;

: BENCHMARK 0 1000 0 DO PRIMES NIP LOOP ;

: main
TIMER-RESET
flags 8190 + eflag !
benchmark ( . ) drop
CR .ELAPSED ;

-- -------------------------

\ i7 system, 2.66 GHz, Windows 7, iForth 64bit.

FORTH> main main main
0.087 seconds elapsed.
0.081 seconds elapsed.
0.079 seconds elapsed. ok

-- --------------------------------------------

VFX Forth for Windows IA32
� MicroProcessor Engineering Ltd, 1998-2012

Version: 4.50 [build 3327]
Build date: 17 April 2012

Free dictionary = 7561806 bytes [7384kb]


( exact same code source as for iForth )

\ i7 system, 2.66 GHz, Windows 7

main
93 ms elapsed ok
main
94 ms elapsed ok
main
94 ms elapsed ok

[Paul Rubin]

m...@iae.nl (Marcel Hendrix) writes:
> As Forth is an interpreter (as is Python!), the space taken by words
> like d can never be reclaimed: at any time the user may type "d". Only
> the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted
> space.

Well, in the Python version, d (assuming it was inside some function
definition) was the equivalent of a local, so I'd expect it to get
cleaned up when the function returned.

> Believe me, the better your specification for a useful piece of code that
> absolutely needs closures, the happier both of us will be.

I think I said up front, there is no code that absolutely needs
closures. They just make things easier some of the time, so you can
complete your task faster. It comes down to this:

http://people.cs.umass.edu/~yannis/law.html

a version of Moore's law, that claims programmer productivity doubles
every 6 years. Improvements in languages and software understanding
surely have a lot to do with that.

Those of us who have been programming for a while should be asking
ourselves, "has my productivity doubled in the last 6 years? And what
am I going to do to double it again in the next 6 years?" Staying on
top of current tools and techniques is an important component.

[Elizabeth D. Rather]

On 10/22/12 10:14 AM, Paul Rubin wrote:
> m...@iae.nl (Marcel Hendrix) writes:
>> As Forth is an interpreter (as is Python!), the space taken by words
>> like d can never be reclaimed: at any time the user may type "d". Only
>> the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted
>> space.
>
> Well, in the Python version, d (assuming it was inside some function
> definition) was the equivalent of a local, so I'd expect it to get
> cleaned up when the function returned.

A better implementation would be to put those values in a reusable space
such as PAD.

[Marcel Hendrix]

"Elizabeth D. Rather" <era...@forth.com> writes Re: FORTH Trouble--Please Show Me

> On 10/22/12 10:14 AM, Paul Rubin wrote:
>> m...@iae.nl (Marcel Hendrix) writes:
>>> As Forth is an interpreter (as is Python!), the space taken by words
>>> like d can never be reclaimed: at any time the user may type "d". Only
>>> the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted
>>> space.
>>
>> Well, in the Python version, d (assuming it was inside some function
>> definition) was the equivalent of a local, so I'd expect it to get
>> cleaned up when the function returned.

> A better implementation would be to put those values in a reusable space
> such as PAD.

: derive ( xt -- ) ( F: x h -- d )
LOCAL f FLOCALS| h x |
x h F+ f EXECUTE x f EXECUTE F- h F/ ;

: derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name"
CREATE F, , DOES> F@+ @ derive ;

: C[ S" marker -once" EVALUATE ;
: ]C S" -once" EVALUATE ;

C[

CR 3e FSQR F. .( \ prints 9 )

CR ' FSQR 3e 1e-4 derive F. .( \ prints approximately 6 )

' FSQR 1e-4 derivative d
CR 3e FSQR F. .( \ prints 9 )
CR 3e d F. .( \ prints approximately 6 )
CR 4e d F. .( \ prints approximately 8 )

' FSIN 1e-4 derivative e
' e 1e-4 derivative f
CR PI/2 e F. .( \ prints dsin[pi/2] = cos[pi/2] )
CR PI/2 f F. .( \ prints ddsin[pi/2] = -sin[pi/2] )
: .tt 0e #4 0 do FDUP e F. PI/2 F+ LOOP FDROP ;
CR .tt .( cosine in a loop )
]C

-- output

FORTH> in
9.000000 \ prints 9
6.000100 \ prints approximately 6
9.000000 \ prints 9
6.000100 \ prints approximately 6
8.000100 \ prints approximately 8
-0.000050 \ prints dsin[pi/2] = cos[pi/2]
-1.000000 \ prints ddsin[pi/2] = -sin[pi/2]
1.000000 -0.000050 -1.000000 0.000050 ok

FORTH> words
]C C[ derivative derive -derivative

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:
> A better implementation would be to put those values in a reusable
> space such as PAD.

Then they could get overwritten by something else while still in use.
Really, we're talking about a language feature that just doesn't fit
into the Forth way of doing things. The most sensible approximation is
probably with OOP and whatever methods Forthers normally use to reclaim
storage from dead objects.

[Elizabeth D. Rather]

Probably not. PAD is entirely under the control of the application
programmer, systems are forbidden to use it.

It is not common practice in Forth to "reclaim" storage. Instead, we
prefer to use temporary buffers in unallocated space, of which PAD is
the most standard and most easily manageable. Depending on the
implementation, there are anywhere from hundreds to millions of bytes of
space there. An application can define buffers at PAD, PAD+n, etc. They
are easily reusable within a section of code that the programmer manages.

In multitasked Forths, each task has its own PAD workspace.

[Albert van der Horst]

In article <1989131...@frunobulax.edu>, Marcel Hendrix <m...@iae.nl> wrote:
>Bernd Paysan <bernd....@gmx.de> writes Re: FORTH Trouble--Please Show Me
>

>-- ----------------------------
>marker -sieve
>
>CREATE FLAGS 8190 ALLOT
>variable eflag
>
>: PRIMES ( -- n )
> FLAGS 8190 1 FILL
> 0 3 EFLAG @ FLAGS
> DO
> I C@
> IF DUP I + DUP EFLAG @ <
> IF EFLAG @ SWAP
> DO 0 I C! DUP +LOOP
> ELSE DROP
> THEN
> SWAP 1+ SWAP
> THEN 2+
> LOOP DROP ;
>

That benchmark is severely rigged compared to the honest Byte benchmark:
lina 1.430 mS versus .861 mS

Groetjes Albert

[Bernd Paysan]

Marcel Hendrix wrote:
> What hardware are you using? A steam-powered CPU?

An AMD E-350 Netbook CPU, as I told below. Running at 1.6GHz, it
doesn't seem to be much less efficient than the Core i7, which would run
that in 284ms instead of 321ms at the same frequency. Given that Core
i7 usually runs circles around anything AMD makes today, this isn't
really that much faster.

> On my hardware ( i7 2.66 GHz ) gForth 0.7 runs it in 171 ms, while
> iForth64 takes 79 ms and VFX 32bit 93 ms.

Sounds reasonable, roughly factor 2 vs. VFX.

>> There's something fishy going on. I don't know, maybe the Windows
>> version of Gforth 0.7.0 still suffers from GCC problems or whatever.
> [..]
>
> Then fix it :-)

GCC? Nope. It's unmaintainable ;-).

If you think about fixing the distribution: I did create a setup.exe
from the CVS head a few weeks ago, as a user discovered other problems,
and had a few wishes for the installation script (like adding the Gforth
location to PATH): it's on

http://bernd-paysan.de/gforth-0.7.9-20121007.exe

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:c5c77fa4-fa4c-465d...@q7g2000pbj.googlegroups.com...

> On Oct 22, 1:08 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> wrote:

...

> > Of course, they've never read the early B and C papers by Dennis
> > Ritchie, Brian Kernighan, Ken Thompson, and Steve Johnson
> > where this is revealed, or even realize a famous quote they've
> > likely quoted applies to arrays in C. Most C programmers don't
> > seem to understand how C fits onto assembly or is converted to it.
> > They all believe that a house (C specification) without a
> > foundation (assembly and a machine model) is perfectly valid.
> >
> > Of course, as those original authors and others like Samuel Harbison
> > and Guy Steele, Jr. have noted, that's not true either. C fits onto
> > certain processor architectures very well and doesn't fit others.
>
> Does your extensive reading on C include the ugly-fish book?
>

Yes, it does, many years ago, in book form. I bought it.

Was there a section in the .pdf that you want me to re-read?

I have a large number of C books in my library. I've read all of them too.
I'm not claiming that I remember any of them ... One book not in my C
library is the one by K&R. At the time, I deemed it "unworthy" (too simple)
by the time I started buying books on C, mostly early 1990's but upto early
2000's. Unfortunately, all of my C books have been boxed up for many years
now, except for two: Harbison and Steele's "C: A Reference Manual" 3rd. Ed.,
and Plauger's "The Standard C Library". That latter is not really needed,
but is informative if you don't have any idea of how a C library is
constructed. It's built from only 18 or so system functions and the C
language, like Forth using "primitives". The first is invaluable, if you're
a C programmer. All the other books on C and C++ were basically a waste of
money. Fortunately, I don't think I bought any "bad C" books by Schildt, or
the book "C Unleashed" by numerous self-declared C "experts" from
comp.lang.c. Today, you can get a number of C books in .pdf form for free,
such as the modern version of K&R's book, or ANSI/ISO
'C Rationale' document, or Bell Telephone's 1974 "C Reference Manual" by
Ritchie, as well as the ISO C draft specifications.


Rod Pemberton

[Hugh Aguilar]

On Oct 22, 3:10 am, stephen...@mpeforth.com (Stephen Pelc) wrote:

> On Mon, 22 Oct 2012 02:51:02 +0200, Bernd Paysan <bernd.pay...@gmx.de>
> wrote:
>
> >We did put quite some effort into Gforth to make it fast while still
> >using the C compiler - the latter to make it easy enough to port.  The
> >effort to write a compiler like the one in VFX is tremendous, and not
> >worth to repeat for more than a very few popular platforms.
>
> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430

Do you simulate the target processor at compile-time even for the
MSP430???

I can see your technique of simulating the target processor at compile-
time in your "cross-compiler" in regard to the big 32-bit processors
such as everything else in your list above, but it seems like a very
bad idea with a little 16-bit processor.

All in all, simulating the target processor at compile-time is a very
bad idea in any case --- it blows me away that you do that.

> The effort put in to designing and implementing the first two VFX
> compilers was huge. Implementing a code generator for a new CPU is
> a matter of a few weeks, including writing the assembler and
> disassembler. However, I will concede that, over the years, we
> have put more effort into the x86 code generator than we should
> have done. After initially writing a reasonable quality code
> generator, further improvements are usually a matter of incremental
> development.

Is your x86 system 32-bit or 64-bit?

I'm somewhat interested in buying VFX. Do you allow programs written
in VFX to contain the dictionary and to provide the user with a
command-line so that Forth can be used as an embedded scripting
language by the user? I'm interested in writing a CAM program to
generate gcode for CNC machines. Right now I'm learning Gambit Scheme
primarily so that it could be used for this. Lua is another
possibility. I'd rather use Forth, but I'm not aware of any Forth
system that is capable of this --- at least, not without me writing my
own mini-Forth on top of the underlying Forth system to be the
embedded scripting language.

[Mark Wills]

I'd be very surprised if VFX could not do that :-) Even my little 16-
bit hobby system can do that. In my case, a simple call to INTERPRET
gives you a command line and you just have at it and go write Forth.

VFX will have EVALUATE and possibly even more sophisticated words.

The thing about VFX that is very attractive (to me) is it's GUI
library which uses GTK+ for true cross-platform GUI functionality. You
can write a GUI that will work on Winblows, Linux, and Mac with *no
code changes whatsoever*. That's a really nice feature.

There's a page that goes into some detail here:

http://www.mpeforth.com/vfxwin.htm#guigen

[humptydumpty]

On Monday, October 22, 2012 10:51:01 PM UTC+3, Paul Rubin wrote:

> humptydumpty writes:
>
> > : derivative ( -- xt[F:x--y] ) ( F: h -- )
>
> > :noname
>
> > postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
>
> > postpone fswap compile, postpone f- postpone fliteral
>
> > postpone f/ postpone ;
>
> > ; immediate
>
> >
>
> > 3e0 1e-4 derivative fsqr execute
>

Hi!

> Thanks. I don't really understand

It's nothing magic, `derivative' compiles a new unnamed definition.
To see what compiles do `1e-4 derivative fsqr xt-see'. You will understand.

> : dsin ( F: x -- y ) 1e-4 derivative fsin execute ;

> It gave me a floating stack undeflow error as soon as I tried
> to compile the word. Any advice?

Because it wants `1e-4' at compile-time, don't have it and aborts.
I wrote example to be used only at execute-time. It cannot be used at compile-time, as Forth don't support compiling nested definitions.
To meet your new requirement we resort to:

: (derivative) ( "word[F:x--y]" -- ) ( F: h -- ;need at compile-time)
\G Compiles a 'derivative block' into current definition

postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
postpone fswap compile, postpone f- postpone fliteral
postpone f/

; immediate

: derivative ( "word[F:x--y]" -- xt[F:x--y] ) ( F: h -- )
:noname postpone (derivative) postpone ; ; immediate


1e-4 fconstant (GSTEP) immediate \ Grid Step, at compile-time

: fdsin ( F: x -- y )
(GSTEP) (derivative) fsin ;

: fd2sin ( F: x -- y )
(GSTEP) (derivative) fdsin ;

: fsqr fdup f* ;

Tests:

3e0 (GSTEP) derivative fsqr execute f. 6.00010000001205 ok
0e0 fsin f. 0. ok
0e0 fdsin f. 0.999999998333333 ok
0e0 fd2sin f. -0.0000999999993922529 ok
cr .s f.s
<0> <0> ok

> Overall I think the solution uses too much metaprogramming.

Once you get the flavour, is not that much.. ;)

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:

> Marcel Hendrix wrote:
>
>>> There's something fishy going on. I don't know, maybe the Windows
>>> version of Gforth 0.7.0 still suffers from GCC problems or whatever.
>> [..]
>>
>> Then fix it :-)
>
> GCC? Nope. It's unmaintainable ;-).

:-P

Andrew.

[Stephen Pelc]

On Mon, 22 Oct 2012 19:54:48 -0700 (PDT), Hugh Aguilar
<hughag...@yahoo.com> wrote:

>> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>
>Do you simulate the target processor at compile-time even for the
>MSP430???

Yes, but not in the sense of simulating the CPU. We just provide
Forth words, e.g. @ and CMOVE that operate on the target memory
space. We're simulating the target Forth, not the CPU.

>All in all, simulating the target processor at compile-time is a very
>bad idea in any case --- it blows me away that you do that.

We like to surprise people.

>Is your x86 system 32-bit or 64-bit?

32 bit.

>I'm somewhat interested in buying VFX. Do you allow programs written
>in VFX to contain the dictionary and to provide the user with a
>command-line so that Forth can be used as an embedded scripting
>language by the user?

Yes. Download the *free beer* eval system and read the licence.

Basically you can do what you want with a bit of protection of
our copyright. Since Forth is an interactive language it would
be foolish to remove that facility at run time.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>As you yourself have commented several times, be careful with
>benchmarks. Over the application benchmarks on the MPE website,
>the gforth-fast time is 3.90 times the VFX time on an i7.

Searching for "application benchmarks on the MPE website", I
eventually found <http://www.mpeforth.com/vfxwin.htm#bnchmrk>, and
while that says "A set of application benchmarks follow.", I don't see
any application benchmark there. There are a bunch of
micro-benchmarks (DO...LOOP to KEY?), and some mini-benchmarks, with
at least half of them synthetic (Sieve, Fibonacci, Dhrystone, probably
also the random number benchmark). Not a single application benchmark
there.

I put quite a bit of effort into collecting several applications by a
number of authors and realeasing them as a benchmark suite, with each
benchmark running on several Forth systems:
<http://www.complang.tuwien.ac.at/forth/appbench.zip>

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

[Anton Ertl]

humptydumpty <oua...@gmail.com> writes:
>On Monday, October 22, 2012 10:51:01 PM UTC+3, Paul Rubin wrote:
>> humptydumpty writes:
>>
>> > : derivative ( -- xt[F:x--y] ) ( F: h -- )
>>
>> > :noname
>>
>> > postpone fdup fdup postpone fliteral postpone f+ ' dup compile,
>>
>> > postpone fswap compile, postpone f- postpone fliteral
>>
>> > postpone f/ postpone ;
>>
>> > ; immediate
>>
>> >
>>
>> > 3e0 1e-4 derivative fsqr execute
>>
>Hi!
>
>> Thanks. I don't really understand
>It's nothing magic, `derivative' compiles a new unnamed definition.
>To see what compiles do `1e-4 derivative fsqr xt-see'. You will understand.
>
>> : dsin ( F: x -- y ) 1e-4 derivative fsin execute ;
>> It gave me a floating stack undeflow error as soon as I tried
>> to compile the word. Any advice?
>
>Because it wants `1e-4' at compile-time, don't have it and aborts.
>I wrote example to be used only at execute-time. It cannot be used at compile-time, as Forth don't support compiling nested definitions.

No nested definitions necessary here. The problem is that DERIVATIVE
parses, and if you do that, you have to decide if you want to parse
during compilation or at run-time. The better approach is to avoid
parsing by passing in the word as xt. Maybe the following will also
be easier to understand in other ways:

: derivative { xt1 F: r -- xt2 }
:noname ]]
fdup [[ r ]] fliteral f+ [[ xt1 compile, ]] fswap [[ xt1 compile, ]] f-
[[ r ]] fliteral f/ ;
[[ ;

: dsin ( rx -- ry ) 1e-4 ['] fsin derivative execute ;

1e dsin f.

Of course Paul's use of currying is totally pointless in this case,
and the memory for the anonymous definition is not reclaimed. If he
does not want to waste that memory, it is easy to write a non-curried
variant of DERIVATIVE with a stack effect like: ( xt1 r rx -- ry ).

[Stephen Pelc]

On Tue, 23 Oct 2012 11:50:37 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>There are a bunch of
>micro-benchmarks (DO...LOOP to KEY?), and some mini-benchmarks, with
>at least half of them synthetic (Sieve, Fibonacci, Dhrystone, probably
>also the random number benchmark). Not a single application benchmark
>there.

To quote from the file itself:
"These benchmarks have been collated from a variety of sources, and
were originally used to test MPE's VFX code generator and optimiser
for 32 bit Forth systems."

These tests had a specific rationale. I have no doubt that your
tests are good for their purpose, but that purpose is probably
different.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>On Tue, 23 Oct 2012 11:50:37 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>There are a bunch of
>>micro-benchmarks (DO...LOOP to KEY?), and some mini-benchmarks, with
>>at least half of them synthetic (Sieve, Fibonacci, Dhrystone, probably
>>also the random number benchmark). Not a single application benchmark
>>there.
>
>To quote from the file itself:
>"These benchmarks have been collated from a variety of sources, and
>were originally used to test MPE's VFX code generator and optimiser
>for 32 bit Forth systems."
>
>These tests had a specific rationale. I have no doubt that your
>tests are good for their purpose, but that purpose is probably
>different.

Tests? We have been talking about benchmarks, not tests. In
particular, we have been talking about application benchmarks. From
<http://en.wikipedia.org/wiki/Benchmark_(computing)>:

|Application benchmarks run real-world programs on the system.

That's what <http://www.complang.tuwien.ac.at/forth/appbench.zip>
does and your benchmark suite doesn't do.

Concerning the purpose: The main purpose of appbench is to raise the
bar in Forth benchmarking. One problem we have had in Forth is that
serious performance problems, in particular I/D-Cache synchronization
issues were not noticed or ignored by Forth implementors because they
did not show up in the microbenchmarks that most Forth implementors
use. So, when working on the performance of a Forth system, it's a
good idea to use real application benchmarks in addition to, e.g.,
microbenchmarks for particular features.

Another purpose of appbench is to compare the performance of various
Forth systems in a hopefully realistic setting. The applications in
appbench are relatively large and certainly more realistic and
idiomatic than, e.g., the recursive Fibonacci benchmark, the Byte
Sieve, Wil Baden's LZ77 code (which is an unidiomatic translation of
non-Forth code), or Dhrystone (a synthetic benchmark originally
written in Ada, later translated to C, and apparently also to Forth).

[Gerry Jackson]

On 23/10/2012 01:16, Elizabeth D. Rather wrote:
> On 10/22/12 11:27 AM, Paul Rubin wrote:
>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>> A better implementation would be to put those values in a reusable
>>> space such as PAD.
>>
>> Then they could get overwritten by something else while still in use.
>> Really, we're talking about a language feature that just doesn't fit
>> into the Forth way of doing things. The most sensible approximation is
>> probably with OOP and whatever methods Forthers normally use to reclaim
>> storage from dead objects.
>>
>
> Probably not. PAD is entirely under the control of the application
> programmer, systems are forbidden to use it.

Not quite true as a system can provide non-standard words that *can* use
PAD. Also a system can move PAD (which is the same as corrupting it as
far as an application programmer is concerned) if anything is added to
the dictionary or dataspace allotted. So you probably wouldn't want to
use PAD if creating closures etc.

>
> It is not common practice in Forth to "reclaim" storage. Instead, we
> prefer to use temporary buffers in unallocated space, of which PAD is
> the most standard and most easily manageable. Depending on the
> implementation, there are anywhere from hundreds to millions of bytes of
> space there.

A portable program can only assume PAD can hold 84 characters.

The upshot is that you have to be very careful when using PAD i.e the
dictionary and use of dataspace are static, be wary of using
non-standard words provided by a system and, if you want the program to
run on other ANS Forth systems, don't use PAD for more than 84 characters.

--
Gerry

[Stephen Pelc]

On Tue, 23 Oct 2012 15:59:31 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>|Application benchmarks run real-world programs on the system.
>
>That's what <http://www.complang.tuwien.ac.at/forth/appbench.zip>
>does and your benchmark suite doesn't do.

Thank you for the explanation.

>Concerning the purpose: The main purpose of appbench is to raise the
>bar in Forth benchmarking. One problem we have had in Forth is that
>serious performance problems, in particular I/D-Cache synchronization
>issues were not noticed or ignored by Forth implementors because they
>did not show up in the microbenchmarks that most Forth implementors
>use.

Since 2006 the file benchmrk.fth has contained code to test the effect
of code and data separation. Small scale benchmarks like the random
number test are much easier to use when analysing the impact of
such details.

[humptydumpty]

On Tuesday, October 23, 2012 1:16:23 PM UTC, Anton Ertl wrote:

Hi, Anton!

Thanks for your insights. Could you give me a hint where the use of parsing words become an abuse? Where is the borderline, if this exists?

Gforth info about parsing words: 'Parsing words are hard to use in other words, because it is hard to pass program-generated parameters through the input stream.' In what domains are used 'program-generated parameters'? Thanks.

[Hugh Aguilar]

On Oct 22, 10:59 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> On Oct 23, 3:54 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> > I'm somewhat interested in buying VFX. Do you allow programs written
> > in VFX to contain the dictionary and to provide the user with a
> > command-line so that Forth can be used as an embedded scripting
> > language by the user? I'm interested in writing a CAM program to
> > generate gcode for CNC machines. Right now I'm learning Gambit Scheme
> > primarily so that it could be used for this. Lua is another
> > possibility. I'd rather use Forth, but I'm not aware of any Forth
> > system that is capable of this --- at least, not without me writing my
> > own mini-Forth on top of the underlying Forth system to be the
> > embedded scripting language.
>
> I'd be very surprised if VFX could not do that :-) Even my little 16-
> bit hobby system can do that. In my case, a simple call to INTERPRET
> gives you a command line and you just have at it and go write Forth.
>
> VFX will have EVALUATE and possibly even more sophisticated words.

It is not a matter of a Forth not being able to do it in the technical
sense. The problem is that most Forth systems' license requires that
any software the customer (that would be me) releases can not include
the dictionary or the ability to compile Forth words. Most Forth
systems purposely destroy this part of the system when you create a
"turnkey" executable for distribution. They do this so the customer
doesn't just resell their Forth compiler as his own, with a few added
libraries that he wrote. SwiftForth is crippled like this, for
example.

I remember when I was 18 I wrote a program in SuperForth for the
Commodore-64. This was turtle graphics in 4 dimensions (W, X, Y and
Z). It displayed the 3D aspect of the 4D object, with the lines
receding to a vanishing point. The perspective could be rotated around
any of the 4 axis. Pretty cool! I've never seen anything like that
from anybody else. I couldn't sell it though, because it provided the
Forth command-line to the user similar to Logo so the user could write
functions. I wrote hypercube and some others myself as examples, but
the users were expected to write these kind of functions themselves.
It is no good without a command-line.

Now I'm learning Gambit Scheme. I'm rewriting that old turtle-graphics
program in Scheme as a learning exercise (I'm taking the advice that I
give to Gavino for myself, which is to write a program to learn, even
if the program is just a toy). This time I will be able to release the
program to the public because Gambit's license allows the REPL (that
is Scheme's term for the command-line) to be exposed to the users. I
won't be able to sell it though --- the days of selling software for
money are long past --- I missed my opportunity in the 1980s and early
1990s when people still bought shrink-wrapped software packages.

> The thing about VFX that is very attractive (to me) is it's GUI
> library which uses GTK+ for true cross-platform GUI functionality. You
> can write a GUI that will work on Winblows, Linux, and Mac with *no
> code changes whatsoever*. That's a really nice feature.

Considering that I know how to program in ANS-Forth, it would be
really great if I had an ANS-Forth system that was actually capable of
producing programs. I paid almost $500 for SwiftForth in the late
1990s, shortly after leaving Testra. That was a huge disappointment.
You really can't produce programs that have a GUI, and everybody in
the world demands GUI. It is really depressing. I've had situations
where people have wanted to hire me to write a program, but all of my
Forth experience is good for nothing as I can't write a Forth program
with a GUI, so I had to offer to use some other language that I'm not
very knowledgeable in and/or don't particularly like. It is
ridiculous! What is the point of being a Forth programmer if you can't
write Forth programs? The money I spent on SwiftForth was a huge
waste. Not only is there the GUI issue, but SwiftForth also just has
bugs. For example, any use of (LOCAL) will crash the system (although
LOCALS| does work). SwiftForth is also horribly slow compared to C/C++
and pretty much anything.

My experience with SwiftForth was so bad that I just gave up on Forth
for over a decade. My work experience with Testra wasn't helping me
get any jobs (there aren't any jobs for Forth), and Forth Inc. was a
dead-end because their SwiftForth was worthless, so I saw Forth itself
as being a dead-end. Recently (2009) I started visiting
comp.lang.forth, but I found the majority of comp.lang.forth members
to be a bunch of losers who just attack anybody who writes software
and who never write any software themselves. I tried Win32Forth, which
was supposed to provide GUI, but it was a bug-ridden mess. Their GUI-
generating stuff didn't work at all and would just crash. It was
worthless. Also, Alex McDonald, who is the representative of
Win32Forth, is a jerk --- so I dumped Win32Forth too.

I'm really close to just abandoning Forth altogether. That is just
depressing, considering that Forth programming is the only thing that
I ever became really skilled at (I know C and a variety of assembly
languages, but I'm no better than average, and maybe not even average
as I don't practice much). This is why I'm learning Scheme now. My
experience so far with Scheme is that the people involved are
intelligent and know a lot about computer science, they write software
that works, and they don't attack other people's software. There is no
Scheme equivalent of Elizabeth Rather who claims to be the greatest
expert in the world, who never writes any software, who doesn't know
what closures are or any other basic programming concepts, and who
works as a salesperson selling overpriced garbage. And no flaming
faggots either. The Scheme crowd has way more class than the Forth
crowd.

I may give VFX a shot though. It is the only Forth system that I
haven't tried yet.

[Hugh Aguilar]

On Oct 23, 3:35 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Mon, 22 Oct 2012 19:54:48 -0700 (PDT), Hugh Aguilar
>

> <hughaguila...@yahoo.com> wrote:
> >> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>
> >Do you simulate the target processor at compile-time even for the
> >MSP430???
>
> Yes, but not in the sense of simulating the CPU. We just provide
> Forth words, e.g. @ and CMOVE that operate on the target memory
> space. We're simulating the target Forth, not the CPU.

Well, that makes a lot more sense! That is how my MFX worked. I had
TARG words and HOST words, and the HOST words ran on the host computer
but accessed the target memory image (there was @ and CMOVE etc.).

This is not what you said previously in this thread though:
https://groups.google.com/group/comp.lang.forth/browse_thread/thread/c0fe67c350a5cec3

You said this:
On Dec 8 2009, 3:18 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> There are three types of compilation involved
> 1) Host compilation
> 2) Clone compilation (target CPU same as host and memory matches)
> 3) Cross compilation (target CPU is not host CPU)
>
> In the third case you have to simulate *everything* when dealing
> with both the definition and execution of defining words. It's not
> easy. You also have to extend the normal Forth compiler by at least
> two time frames. Forth cross compilers are much more complicated
> and much more subtle than they appear to be.

You said that in 2009, and I haven't taken you seriously since that
time --- because I saw you as yet another self-proclaimed cross-
compiler "expert" who doesn't know anything about cross-compiling ---
it is not all that complicated and subtle (I figured it out, so how
hard could it be?).

It is possible that I misunderestimated you though.

> >I'm somewhat interested in buying VFX. Do you allow programs written
> >in VFX to contain the dictionary and to provide the user with a
> >command-line so that Forth can be used as an embedded scripting
> >language by the user?
>
> Yes. Download the *free beer* eval system and read the licence.
>
> Basically you can do what you want with a bit of protection of
> our copyright. Since Forth is an interactive language it would
> be foolish to remove that facility at run time.

I think that it is foolish too. Chuck Moore, who should know, has said
that Forth's primary purposes is to be a domain-specific-language. I
have *never* seen a commercial Forth system that allowed this though.
SwiftForth doesn't.

This makes me a *lot* more interested in VFX --- this would be a
*huge* benefit --- I never even considered this as a possibility
before.

I've worked as a CNC programmer and machinist, and I've written
software (in Forth) to generate gcode for CNC machines. I want to
write a CAM program to do this. The user has to be able to write
programs within the system though. CAM software that depends upon the
user clicking menu options is pretty much worthless. The user has to
be able to write programs of his own to generate the gcode
representing the part that he is fabricating. If VFX allows this, and
VFX is reasonably fast (CAM programs usually involve a *lot* of
floating-point arithmetic), then VFX might be a good choice. Most
machinists aren't programmers --- they need a pretty simple language
to work with --- Forth is pretty simple though, as it has no syntax
rules at all, and it manages this without all the parenthesis of
Scheme. :-)

[Doug Hoffman]

On 10/24/12 1:05 PM, Hugh Aguilar wrote:
> On Oct 23, 3:35 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
>> On Mon, 22 Oct 2012 19:54:48 -0700 (PDT), Hugh Aguilar
>>
>> <hughaguila...@yahoo.com> wrote:
>>>> x86, 68k/Coldfire, ARM/Cortex, H8300H/H8S, MSP430
>>
>>> Do you simulate the target processor at compile-time even for the
>>> MSP430???

>>> I'm somewhat interested in buying VFX. Do you allow programs written
>>> in VFX to contain the dictionary and to provide the user with a
>>> command-line so that Forth can be used as an embedded scripting
>>> language by the user?
>>
>> Yes. Download the *free beer* eval system and read the licence.
>>
>> Basically you can do what you want with a bit of protection of
>> our copyright. Since Forth is an interactive language it would
>> be foolish to remove that facility at run time.
>
> I think that it is foolish too. Chuck Moore, who should know, has said
> that Forth's primary purposes is to be a domain-specific-language. I
> have *never* seen a commercial Forth system that allowed this though.

> This makes me a *lot* more interested in VFX --- this would be a
> *huge* benefit --- I never even considered this as a possibility
> before.

I have been using VFX recently since I switched to an Intel Macintosh.
Also have been using VFX on a Windows machine. I can tell you that it
is an *excellent* Forth overall, perhaps one of the best. No experience
with cross compiling but if that capability is as high quality as the
rest, no reason to think it isn't, then you won't be disappointed. I
recommend you try it.

-Doug

[Anton Ertl]

humptydumpty <oua...@gmail.com> writes:
>Thanks for your insights. Could you give me a hint where the use of parsing words become an abuse? Where is the borderline, if this exists?

It's a bad idea to have parsing words that are used inside and outside
colon definitions, and where the programmer wants the parsing to
happen at text interpretation time, like S", TO, and your parsing
DERIVATIVE.

Parsing words that are typically used in only one state, or are
intended to parse at run-time when compiled, such as defining words,
are less malicious, although still troublemakers: If you want to pass
a string that's not in the input stream as a parameter, how do you do
it? Ok, there is EXECUTE-PARSING (not standardized), but what if you
need to pass several string parameters?

Parsing words seem to be useful for words that are used directly by
the end user, but when called from other words, at some point such
words lead to problems. Some say that you should not do that, and
they are right: do not use parsing words.

>Gforth info about parsing words: 'Parsing words are hard to use in other words, because it is hard to pass program-generated parameters through the input stream.' In what domains are used 'program-generated parameters'? Thanks.

Everywhere. The string might come from a file, or a database, or it
might be produced by a concatenation or modification of other strings,
etc.

Please limit lines to about 70 characters. Thank you.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>>Concerning the purpose: The main purpose of appbench is to raise the
>>bar in Forth benchmarking. One problem we have had in Forth is that
>>serious performance problems, in particular I/D-Cache synchronization
>>issues were not noticed or ignored by Forth implementors because they
>>did not show up in the microbenchmarks that most Forth implementors
>>use.
>
>Since 2006 the file benchmrk.fth has contained code to test the effect
>of code and data separation. Small scale benchmarks like the random
>number test are much easier to use when analysing the impact of
>such details.

Sure, micro-benchmarks have their place, if you know what you are
targeting.

But how do you know how big the effect of what you are targeting is on
typical code? Micro-benchmarks are not at all representative of
typical code, so they cannot tell you that. An application will
hopefully be more representative of typical code; it may not be, and
that's why appbench contains several applications by several authors,
to get as diverse a benchmark as possible.

More importantly, how do you know that there is not another
performance bug like the I/D-cache synchronization issue that affects
a number of larger programs but does not show up in the small
benchmarks; with a little luck it shows up in application benchmarks.

BTW, I/D synchronization has been a problem since the Pentium, which
was introduced in 1993.

[humptydumpty]

Hi Anton!

Thank you for clarifications. I never want to replace use of data-stack
with parsing practice. Mostly wanted to write useful 'macros'.

Could you give me a hint about this?

\ Borrowed from old post in c.l.f. of J.Thomas
: _eval_ ( "code block" -- ;compile-time )
char parse evaluate ;

\ It could be an iterator, etc.. Here a generic loop:
: _LOOP_ ( "code block" -- ;compile-time )
postpone DO _eval_ postpone LOOP ; immediate

: test
cr ." start.. " 10 0 _LOOP_ | I dup * . | ." end." ;

see test

test .s cr bye

[David Thompson]

On Mon, 22 Oct 2012 04:12:16 -0400, "Rod Pemberton"
<do_no...@notemailnotz.cnm> wrote:

> "Paul Rubin" <no.e...@nospam.invalid> wrote in message
> news:7x3917h...@ruckus.brouhaha.com...
> > "Rod Pemberton" <do_no...@notemailnotz.cnm> writes:
> > > C has structs and arrays. That's what's needed.
> >
> > Well, C doesn't really have arrays ;-).
> >
>
> That's true. But, I can't seem to convince other C programmers, be it
> novices or "experts" of that. So, I've stopped placing arrays in quotes
> and preferencing it with: C as in C "arrays".
>
> And, I always seem to get one guy from comp.lang.c that insists C does have
> arrays...

>
> Of course, they've never read the early B and C papers by Dennis Ritchie,
> Brian Kernighan, Ken Thompson, and Steve Johnson where this is revealed, or
> even realize a famous quote they've likely quoted applies to arrays in C.
>

BCPL and B, and C, have arrays aka vectors in memory, but the first
two don't have them in the (named) variable.

I'm not sure which papers you mean. The most definitive I've seen is
Ritchie's for ACM's 2nd conference on the History of Programming
Languages (abbreviated HOPL2) in 1993 which explains carefully that
the replacement of a pointer (to an actual array) with an actual array
(that converts to a pointer) was one of the changes that made the
first "Embryonic" C a different language from B and even "New B".

http://cm.bell-labs.com/who/dmr/chist.html

[Bernd Paysan]

David Thompson wrote:
> I'm not sure which papers you mean. The most definitive I've seen is
> Ritchie's for ACM's 2nd conference on the History of Programming
> Languages (abbreviated HOPL2) in 1993 which explains carefully that
> the replacement of a pointer (to an actual array) with an actual array
> (that converts to a pointer) was one of the changes that made the
> first "Embryonic" C a different language from B and even "New B".

Funny enough is that Go (the C-like language made by Ken Thompson) again
has real arrays and even slices (this is something that you can expand
up to the array limits it is inside), passed as addr+len (and in case of
a slice as a pair of addr+len, one the bounds, one the actual slice).

[WJ]

Paul Rubin wrote:

> > "Closures" seems to be the one "magic" feature that everyone seems to think
> > is missing from their favorite language. What's so special about closures?
>
> They're not magic. You can do similar things with OOP or structs
> containing function pointers and data, but closures avoid a lot of
> syntactic clutter and bureaucracy compared to that. Example in Python:
>
> def square(x):
> return x*x
>
> def derivative(f, h): # approximate numerical derivative
> def df(x):
> return (f(x+h) - f(x)) / h
> return df
>
> print square(3) # prints 9
> print derivative(square,0.0001)(3) # prints approximately 6
>
> You could write something like "derivative" in C with function pointers,
> but it would be much messier.

Factor:

USING: locals ;

:: derivative ( f h -- closure )
[| x | x h + f call x f call - h / ] ;

3 sq .
3 [ sq ] 0.0001 derivative call .

9
6.000100000012054

[WJ]

Paul Rubin wrote:

> m...@iae.nl (Marcel Hendrix) writes:
> > As Forth is an interpreter (as is Python!), the space taken by words
> > like d can never be reclaimed: at any time the user may type "d". Only
> > the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted
> > space.
>
> Well, in the Python version, d (assuming it was inside some function
> definition) was the equivalent of a local, so I'd expect it to get
> cleaned up when the function returned.

I believe that Mr. Hendrix is a worshipper of the "Forth standard"
and that he therefore has no understanding of, or interest in,
garbage collection or closures.

>
> > Believe me, the better your specification for a useful piece of code that
> > absolutely needs closures, the happier both of us will be.

If Mr. Hendrix had any honesty and rationality whatsoever, he would
have said, "Show me a piece of code that absolutely cannot be
written in assembly language." By his line of "reasoning", no one
needs anything but assembly language---no, machine language!

>
> I think I said up front, there is no code that absolutely needs
> closures. They just make things easier some of the time, so you can
> complete your task faster.

One whose deities are the morons who wrote the "Forth standard"
has no interest in making programming more efficient.
He refuses to learn anything new. His holy scriptures contain
everything that he needs to know.

An ultra primitive language for ultra primitive minds and
bigoted religious fanatics.

[Brad Eckert]

On Monday, October 22, 2012 1:16:39 AM UTC-7, Rod Pemberton wrote:
> As I recall (AIR), you picked a fight with me first.

I'm seeing a pattern. The so-called trolls live in the past and to them everything is personal. But they can post useful material when they want to.

I for one appreciate Bernd's German humor in addition to his insights on Forth.

[Bernd Paysan]

WJ wrote:
> An ultra primitive language for ultra primitive minds and
> bigoted religious fanatics.

The mirror in your bathroom shows one whenever you look into it.

On last year's Forth Tagung, we spent the Thursday afternoon to have a
closer look at Factor. It's not the first Forth-Lisp-crossbreed we've come
along, we had PostScript, some German guy (Alex Burger) has written a
functional language that resembles Forth, once native, once in Java (the
Java version was called TeaTime), and HP had RPL in its calculators, which
is also such a cross-breed.

The thing we struggled most in Factor is the typechecker (or stack picture
checker). If it fails, it will not compile your definition, and it won't
give you any clue why. That's frustrating.

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:kht0kj$etf$1...@online.de...

> WJ wrote:

> > An ultra primitive language for ultra primitive minds
> > and bigoted religious fanatics.
>
> The mirror in your bathroom shows one whenever
> you look into it.
>

Did you think he attacked Forth or Python with the description:
"ultra primitive language"? You might want to re-read the entire
context without his intervening statements.

> On last year's Forth Tagung, we spent the Thursday
> afternoon to have a closer look at Factor.

Tell me. Why should I care what you did on some Thurdsay
afternoon a year ago? Are you going to report the times you
shave and shower too?

> It's not the first Forth-Lisp-crossbreed we've come
> along, we had PostScript, some German guy (Alex Burger) has
> written a functional language that resembles Forth, once native,
> once in Java (the Java version was called TeaTime), and HP had
> RPL in its calculators, which is also such a cross-breed.

All this history of other programming languages being similar in
character to Forth is on Wikipedia for the respective pages of
each language... [That's the English version of Wikipedia for
those who don't speak English.]


Rod Pemberton

[Rod Pemberton]

"Brad Eckert" <hwf...@gmail.com> wrote in message
news:22214d23-8561-4c63...@googlegroups.com...

> On Monday, October 22, 2012 1:16:39 AM UTC-7, Rod Pemberton
> wrote:

...

Well, I haven't posted for almost a week now. Was this a presence
test? Sorry, I'm still here, for now.

> > As I recall (AIR), you picked a fight with me first.
>
> I'm seeing a pattern.

Stop looking at it. After a while, you won't see it.

> The so-called trolls live in the past and
> to them everything is personal.

Attacks *are* personal. Do you want to be attacked? How would
you respond? Do you _honestly_ think you'd respond any
differently? What would you do if your attacker didn't apologize
after being confronted? What would you do if your attacker never
stated why he attacked you in the first place? What would you do
if your ignorant or inciteful attacker continued to attack you
unjustly for years?

> But they can post useful material
> when they want to.

Untrue, trolls by definition don't post _any_ useful material
_ever_. They just incite because they think they can. That's
part of their gimmick. So, if you found a so called "troll" who
posted useful material, then that person likely wasn't a troll but
a troll victim, anti-troll, posi-troll, or llort, etc ...

> I for one appreciate Bernd's German humor
> in addition to his insights on Forth.

What humor? Bernd doesn't post anything funny.

What insights? Bernd hasn't posted anything Forth related in
seven years.

Personally, I don't know what "German humor" is or is supposed to
be. I've never heard the phrase before, unlike "English humor".
Also, I'm not sure what Bernd's nationality is and didn't assume
it's German. Although, I thought he indicated he was French...
He speaks French. He sure talks about France alot. If he's
German, you'd think he'd talk about Germany sometime... Maybe, he
hates France so much he forgets to promote Germany. Or, maybe, he
hates Germany so much he wants to be French. Who knows? He's
clearly confused as is.


Rod Pemberton