F83
bobja...@juno.com
my question is if it isn't still the best place
for a beginner to get started with FORTH?
Bob Jaffray
Brad Eckert
Things have changed in the last 20 years. It depends whether you want
to do Forth commercially or as a hobby.
It's probably a good idea to delve into evaluation versions of the
commercial tools first before you mess around with the hobby stuff so
you have something to compare to.
Here are some links:
http://www.mpeltd.demon.co.uk
Windows and embedded Forths that generate the tightest code around.
http://www.forth.com
Windows and embedded Forths that have had the most industry
exposure. Their evaluation version of SwiftForth AFAIK has a
non-printing PDF of "The Forth Programmer's Handbook" which I highly
recommend.
http://www.forth.org
FIG's web site. I think FIG is in hibernation now, but some people
think it's dead.
http://www.colorforth.com
Chuck Moore's web site. ColorForth is very different from ANS Forth.
crypto_s...@hotmail.com
just for the heck of discovering new terrain or are you in to write
applications? Do you like to figure things out at the machine level or
does it make you turn green whenever the word "bit" or "hexadecimal"
comes up ( Quite a few of my now graduate friends literally turned
green whenever I'd talk about anything low level. ).
Personnally, I didn't really go through the whole process of checking
how other FORTHs worked or were implemented much ( It would have
distracted me from the fun of discovering things myself and maybe
figure out a better way to do things ( Optional )). I mostly only
focused on the very general "main functionalities of FORTH". Indirect
threading, direct threading, etc. ( which happens to be an
implementation detail, but nonetheless very interresting to explore,
and most importantly, the heart of the whole system ), how the
dictionary works, how words are defined ( compiled into the dictionary
), etc.. I sticked to the high level concepts and rediscovered a bunch
of things that flow naturally from the whole thought process.
For me it is an invaluable terrain of exploration. In the process I am
figuring out how to analyse problems by thinking in a way ( which
happens to be the way the brain is supposed to work under optimal
conditions ) that makes FORTH code seem as it should be.
You might nonetheless want to focus on solving problems by creating
applications under an existing FORTH while not bothering with "under
the hood" considerations. For me, the fun comes from figuring things
out at the near machine level. This allows me to acquire a profound
understanding of the underlying concepts supporting the whole system (
concepts which are seldom interresting to, sadly, a vast majority of
programmers using languages other than FORTH. The opposite seems to be
true of FORTH programmers. In any case, FORTH makes it difficult from
isolating yourself completely from the underlying concepts. You are
always very close to the machine when using FORTH ).
I agree with Brad Eckert when he says that things have changed in the
last 20 years. Who could disagree with such a statement? :).
Unfotunately, I think it doesn't mean much of anything. Nobody could
sustain an argument going towards "nothing has changed in 20 years" ;).
In reality, the main concepts underlying FORTH haven't changed much at
all. The "progess" observed either in implementation methods, etc. is a
natural progression of the initial core FORTH method which, I think,
hasn't changed at all.
Regards
Stonelock
Elizabeth D Rather
news:1117226766.0...@g14g2000cwa.googlegroups.com...
> ...
> I agree with Brad Eckert when he says that things have changed in the
> last 20 years. Who could disagree with such a statement? :).
> Unfotunately, I think it doesn't mean much of anything. Nobody could
> sustain an argument going towards "nothing has changed in 20 years" ;).
> In reality, the main concepts underlying FORTH haven't changed much at
> all. The "progess" observed either in implementation methods, etc. is a
> natural progression of the initial core FORTH method which, I think,
> hasn't changed at all.
I disagree with this somewhat. What hasn't changed much are the language
elements and basic command set (@, !, DUP, etc.). However, implementation
strategies have changed significantly, with some systems generating
optimized machine code, for example, interacting well with Windows and *nix
systems, and adding widely-supported features such as floating point, OS
file management, etc., interactive cross-compilers for embedded systems,
etc.
Actually, I'd agree with Brad's recommendation all the way.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
crypto_s...@hotmail.com
truth of la Palisse. It is an incontestable true statement which, I
think, doesn't mean much of anything to anyone without a context and so
I wanted to clarify what he said by putting FORTH in focus. If Brad was
making reference to progressions inside the FORTH context then yes,
these progressions have evolved, but if he was referring to the core
approach that is FORTH, this includes the philosophy, its
information-structuration nature and some characteristics of the
language, then it hasn't really changed. ( For the sake of the
beginner, I think it is more important to study the roots of the tree
first instead of studying its branches ).
When I say that "the "progress" observed either in implementation
methods, etc. is a natural progression of the initial core FORTH
method", I mean that all the observed progressions, may they be
implementation strategies, optimizing compilers, integration with
environments such as Windows or Unix variations, file systems, etc. are
a structural consequence of the underlying core FORTH approach, which,
I would say, hasn't changed at all.
I do not perceive those "changes" you mention as branching out outside
of the FORTH context. This would of course lead to the conclusion that
these progressions are not changes in what FORTH is. FORTH is an open
system, and those progressions, which everybody can observe, are
explorations inside FORTH, which I see to be a much broader frame of
reference than just a language.
It might seem like an odd perspective to some, but I think it yields
interresting thoughts when one starts considering FORTH to be a
structural and structuring entity in which we are evolving. What
everybody is doing here with FORTH lies within the FORTH context!
We are structuring information in a way that is particular to the FORTH
approach ;).
I do NOT recommend studying branches, unless they have some
interresting properties, but not before studying the core of the FORTH
approach first. The branches, which can be studied later, are a natural
consequence of the premises.
Regards
Stonelock
bobja...@juno.com
From: "comp.lang.forth group" <nor...@googlegroups.com>
To: "comp.lang.forth digest subscribers"
<comp.la...@googlegroups.com>
Subject: 19 new messages in 7 topics - digest
Date: Sat, 28 May 2005 07:09:59 +0000
* F83 - 4 messages, 3 authors
http://groups-beta.google.com/group/comp.lang.forth/browse_thread/thread/4=
TOPIC: F83
http://groups-beta.google.com/group/comp.lang.forth/browse_thread/thread/4b=
08ae23c4e3168c
Date: Fri 27 May 2005 10:23
From: "Brad Eckert" =20
Things have changed in the last 20 years. It depends whether you want
to do Forth commercially or as a hobby.
It's probably a good idea to delve into evaluation versions of the
commercial tools first before you mess around with the hobby stuff so
you have something to compare to.
bj: I appreciate your input. My interests are strictly hobby, but
with a view to something sensible for beginners like myself.
I started with FIG on an 8080. Everybody and his brother has
a FORTH of his own. You can learn something from them, of
course, but it doesn't lead to anything for the FORTH
community as a whole - or for beginners. Isn't that why the
ANSI standard was devised, to get beyond the continual
churning?
bj: It seems to me there ought to be a stable FORTH core
that does several things. It ought to be suitable for standalone
and embedded applications. It ought to be suitable also for
expansion as a significant operating system. It ought also to
be able to run in harmony with other operating systems,
be called by programs running under them and vice versa.
And it should be capable of creating modules and full
blown applications under other operating systems. The
fact is that all of these things _have_ already been done in
FORTH, including doing things quite easily that are clumsy
in other languages - one of the beauties of FORTH.
bj: BUT I have yet to see a stable, standard core that can
be used for all of these. I thought that PYGMY might provide
a base, but it does not follow a standard and the author
said the shadow file that goes with it is not available. Without
such a simple thing and without a stable base, I don't think
I want to proceed with that.
bj: I once had Guy Kelley's standalone FORTH on a
single-sided 5-1/4 in floppy, but I can't look at it any more
because the medium deteriorated.
Here are some links:
http://www.mpeltd.demon.co.uk
Windows and embedded Forths that generate the tightest code around.
http://www.forth.com
Windows and embedded Forths that have had the most industry
exposure. Their evaluation version of SwiftForth AFAIK has a
non-printing PDF of "The Forth Programmer's Handbook" which I highly
recommend.
http://www.forth.org
FIG's web site. I think FIG is in hibernation now, but some people
think it's dead.
bj: That's where noncommercial FORTH seemed to get its
start. There _ought_ to be a successor to F83, GPL'd and
following a standard. What is the problem with the ANSI
standard, and why hasn't it led to such an obvious successor?
bj: For my tastes F83 is way _over_ factored and sometimes
quite misfactored. It smothers the beginner with way too many
extra words, leading to chasing rabbit trails with SEE, and
guessing what all the cryptic designations mean. (By the way,
PYGMY doesn't even provide such an obvious tool.)
http://www.colorforth.com
Chuck Moore's web site. ColorForth is very different from ANS Forth.
bj: There are so many different FORTHs! But from the originator
of FORTH, why? There just doesn't seem to be the public
spirit within the FORTH community that there is in, say, LINUX.
bj: Thanks again for your input.
Date: Fri 27 May 2005 13:46
From: crypto_s...@hotmail.com=20
It really depends what you want to do. Do you want to explore FORTH
just for the heck of discovering new terrain or are you in to write
applications?
bj: Yes. I probably will not write new applications. But I would
like to do in FORTH what I used to do with dBASE. And I
would like to do it standalone - that is, without an external
operating system. It is too bad that F83 was put _under_ DOS,
and not designed to easily make it ROM-able and standalone.
FORTH should be looked on as an operating system, and not
a mere application language.
bj: I would like to use FORTH with modern BIOS routines too.
Do you like to figure things out at the machine level or
does it make you turn green whenever the word "bit" or "hexadecimal"
comes up ( Quite a few of my now graduate friends literally turned
green whenever I'd talk about anything low level. ).
bj: I don't see how anyone can think that they could program
sensibly without also learning the FORTH assembler. On
the other hand, there should by now be a full-fledged set
of high-level routines for prototyping modern applications.
Personnally, I didn't really go through the whole process of checking
how other FORTHs worked or were implemented much ( It would have
distracted me from the fun of discovering things myself and maybe
figure out a better way to do things ( Optional )).
bj: I sympathize. The fact that you have control over the whole
system is intoxicating. It is part of the problem, though. It leads
to everyone going his own way and lack of cooperation.
I mostly only focused on the very general "main functionalities
of FORTH". Indirect threading, direct threading, etc. ( which happens
to be an implementation detail, but nonetheless very interresting to
explore,
and most importantly, the heart of the whole system ), how the
dictionary works, how words are defined ( compiled into the dictionary
), etc.. I sticked to the high level concepts and rediscovered a bunch
of things that flow naturally from the whole thought process.
bj: One of the "main" funcationalities of FORTH is defining
new compilation constructs. Yes, and also subroutine threading
is another implementation detail. I look on 32-bit FORTH as still
another implementation detail. If you stick to 16-bit, you can
get your whole application in the processors cache, can't you?
Then if you factor a larger project into 64k chunks, very little
swapping need take place. On the other hand 32-bit applications
run faster in the processor, but slower because of more swapping
in and out of cache memory. So there is a trade-off. That's is my
take on it, but then I may be way off base, since I don't understand
the mechanism of caching.
(cut)
I agree with Brad Eckert when he says that things have changed in the
last 20 years. Who could disagree with such a statement? :).
Unfotunately, I think it doesn't mean much of anything. Nobody could
sustain an argument going towards "nothing has changed in 20 years" ;).
In reality, the main concepts underlying FORTH haven't changed much at
all. The "progess" observed either in implementation methods, etc. is a
natural progression of the initial core FORTH method which, I think,
hasn't changed at all.
Regards
Stonelock
bj: It seems to me one of the problems with FORTH in particular
with regard to execution is its very structure. FORTH words are
essentially CALLS and RETURNS or the equivalent. Each and
every one involves CALL-RETURN overhead. It seems to me
a FORTH coprocessor would help with this by providing a
high-speed look-ahead of non-code words reassembling them
in-line for the regular processor so-to-speak, getting rid of much
of that overhead. Has anyone thought of a solution to this?
This is one of the things that you mention about FORTH leading
to understanding about the "structure of things." It is the nature
of all programming and processing to handle things down to
primatives.
Date: Fri 27 May 2005 17:24
From: "Elizabeth D Rather" =20
<crypto_s...@hotmail.com> wrote in message=20
news:1117226766.0...@g14g2000cwa.googlegroups.com...
> ...
> I agree with Brad Eckert when he says that things have changed in the
> last 20 years. Who could disagree with such a statement? :).
> Unfotunately, I think it doesn't mean much of anything. Nobody could
> sustain an argument going towards "nothing has changed in 20 years" ;).
> In reality, the main concepts underlying FORTH haven't changed much at
> all. The "progess" observed either in implementation methods, etc. is a
> natural progression of the initial core FORTH method which, I think,
> hasn't changed at all.
I disagree with this somewhat. What hasn't changed much are the
language=
elements and basic command set (@, !, DUP, etc.). However,
implementation=
strategies have changed significantly, with some systems generating=20
optimized machine code, for example, interacting well with Windows and
*nix=
systems, and adding widely-supported features such as floating point,
OS=20
file management, etc., interactive cross-compilers for embedded
systems,=20
etc.
bj: Yes, I am aware of that. See my comment above about overfactoring,
and the need for a look-ahead for high-level words. I think the main
processor should spend most of its time executing machine code other
than CALLS and RETURNS or the equivalent. Then, there is the
compromise solution of duplicating code in-line and even translating
heavily used high-level words to in-line code. This results in bloat
to take advantage of larger memory spaces and caching techniques
upon which other languages require to execute more efficiently.
This seems to me to this is un-FORTH-like as a solution, to follow the
way of other languages! rather than solve the real CALL/RETURN
problem.
Actually, I'd agree with Brad's recommendation all the way.
Cheers,
Elizabeth
bj: I feel honored to get a response from such an old-hand
mainstay in the FORTH community. Thank you.
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
Date: Fri 27 May 2005 18:53
From: crypto_s...@hotmail.com=20
I don't and I do agree with Brad. Without a context, It happens to be a
truth of la Palisse. It is an incontestable true statement which, I
think, doesn't mean much of anything to anyone without a context and so
I wanted to clarify what he said by putting FORTH in focus. If Brad was
making reference to progressions inside the FORTH context then yes,
these progressions have evolved, but if he was referring to the core
approach that is FORTH, this includes the philosophy, its
information-structuration nature and some characteristics of the
language, then it hasn't really changed. ( For the sake of the
beginner, I think it is more important to study the roots of the tree
first instead of studying its branches ).
bj: Yes, and that is why I asked my question about whether
F83 with the tools provided with this "model" (intended as
a preliminary model, rather than a completely finished product
to be followed slavisly). I also got a beta copy of F83S,
using separate headers.
When I say that "the "progress" observed either in implementation
methods, etc. is a natural progression of the initial core FORTH
method", I mean that all the observed progressions, may they be
implementation strategies, optimizing compilers, integration with
environments such as Windows or Unix variations, file systems, etc. are
a structural consequence of the underlying core FORTH approach, which,
I would say, hasn't changed at all.
I do not perceive those "changes" you mention as branching out outside
of the FORTH context. This would of course lead to the conclusion that
these progressions are not changes in what FORTH is. FORTH is an open
system, and those progressions, which everybody can observe, are
explorations inside FORTH, which I see to be a much broader frame of
reference than just a language.
bj: I agree with this. The things mentioned are simply valuable
extensions. I remember someone implementing C in FORTH,
and someone else implementing LISP in FORTH, and still
someone else implementing BASIC and FORTRAN. It is clear
that you can do different kinds of things in our _one_
language. Great!
(cut)
Regards
Stonelock
bj: Thank you all.
Bob Jaffray
ast...@netcourrier.com
> bj: It seems to me there ought to be a stable FORTH core
> that does several things. It ought to be suitable for standalone
> and embedded applications. It ought to be suitable also for
> expansion as a significant operating system. It ought also to
> be able to run in harmony with other operating systems,
> be called by programs running under them and vice versa.
> And it should be capable of creating modules and full
> blown applications under other operating systems. The
> fact is that all of these things _have_ already been done in
> FORTH, including doing things quite easily that are clumsy
> in other languages - one of the beauties of FORTH.
>
> bj: BUT I have yet to see a stable, standard core that can
> be used for all of these. I thought that PYGMY might provide
> a base, but it does not follow a standard and the author
> said the shadow file that goes with it is not available. Without
> such a simple thing and without a stable base, I don't think
> I want to proceed with that.
>
Althought this is not the purpose, my bytecoded version of 4IM
( http://4im.atspace.com ) will probably be able to do most of what
you want.
But that's hobby stuff that some people here seem to dislike.
[...]
> bj: For my tastes F83 is way _over_ factored and sometimes
> quite misfactored.
I can't imagine something can be overfactored; if the factoring is not
appropriate the code is simply misfactored.
> It smothers the beginner with way too many
> extra words, leading to chasing rabbit trails with SEE, and
> guessing what all the cryptic designations mean. (By the way,
> PYGMY doesn't even provide such an obvious tool.)
>
Pygmy is shipped with kernel source and a good block editor, with a
text-search feature; you don't need SEE, which is a not-so-perfect tool
because when you decompile you don't get back the original code.
> http://www.colorforth.com
> Chuck Moore's web site. ColorForth is very different from ANS Forth.
>
> bj: There are so many different FORTHs! But from the originator
> of FORTH, why?
Why not? Chuck is the father of Forth. He has always been improving
Forth. This cannot be done by comforming to any kind of standard.
[...]
> bj: One of the "main" funcationalities of FORTH is defining
> new compilation constructs.
I don't think so. This is not the main feature of Forth. Of course it's
nice to have it in some situations, but that's not the "main"
functionnality. I wonder if there's even such a thing as the "main"
functionnality. Forth has many nice features that together makes for a
unique (family of) langages: syntax-free, factoring-friendly (unlike
some other langage where when you create a new function, you have to
write down the prototype here and the implementation there),
Interpret-Execute-Compile...
[...]
> I agree with Brad Eckert when he says that things have changed in the
> last 20 years. Who could disagree with such a statement? :).
> Unfotunately, I think it doesn't mean much of anything. Nobody could
> sustain an argument going towards "nothing has changed in 20 years" ;).
> In reality, the main concepts underlying FORTH haven't changed much at
> all.
Well, if someone changes too much the main concepts, one says that it
isn't Forth! Like ColorForth... :)
[...]
>
> bj: It seems to me one of the problems with FORTH in particular
> with regard to execution is its very structure. FORTH words are
> essentially CALLS and RETURNS or the equivalent. Each and
> every one involves CALL-RETURN overhead.
Beginners focus too much on that and this is wrong because it leads
them to not factor their code. If you're a beginner and worry about,
then I advise you to think first about factoring well, and then unroll
the innermost loops if speed is needed. A second argument is that Forth
can't be as fast as natively compiled langages; not to mention that
most processors are register-based. It's strength is in compactness,
and as you said may because of this perhaps you can win something by
fitting in the huge L1 and L2 caches most of the time.
Amicalement,
Astrobe
bobja...@juno.com
ast...@netcourrier.com wrote:
> >
> > bj: It seems to me there ought to be a stable FORTH core
> > that does several things. It ought to be suitable for standalone
> > and embedded applications. It ought to be suitable also for
> > expansion as a significant operating system. It ought also to
> > be able to run in harmony with other operating systems,
> > be called by programs running under them and vice versa.
> > And it should be capable of creating modules and full
> > blown applications under other operating systems. The
> > fact is that all of these things _have_ already been done in
> > FORTH, including doing things quite easily that are clumsy
> > in other languages - one of the beauties of FORTH.
> >
> > bj: BUT I have yet to see a stable, standard core that can
> > be used for all of these. I thought that PYGMY might provide
> > a base, but it does not follow a standard and the author
> > said the shadow file that goes with it is not available. Without
> > such a simple thing and without a stable base, I don't think
> > I want to proceed with that.
> >
>
> Althought this is not the purpose, my bytecoded version of 4IM
> ( http://4im.atspace.com ) will probably be able to do most of what
> you want.
> But that's hobby stuff that some people here seem to dislike.
bj: I downloaded 4IM for WinXP and tried to create a standalone
diskette. When entering MM at first and selecting NO to create
the diskette, it wrote to one which when tried did not boot.
When entering a second time and selecting YES (PROCEED) to
create the diskette, it aborted! Do you have a suggestion.
I suppose I ought to be able to poke around to find out what
the problem was but I am wondering. I am not against hobby
stuff, if it is usable. But I am very surprised at the extremely
crude appearance of the menu to the user.
bj: It was not my impression taht 4IM followed any standard.
I haven't tried putting it on a DOS diskette.
> [...]
> > bj: For my tastes F83 is way _over_ factored and sometimes
> > quite misfactored.
>
> I can't imagine something can be overfactored; if the factoring is not
> appropriate the code is simply misfactored.
bj: Did you read what I said about the CALL/RETURN overhead?
Factoring should be for program readability and usability.
But in F83 it affects performance! How do _you_ reduce
unnecessary overhead.
bj: Plus you have to slug through many extra WORDS
to see what is happening and often the names are not
descriptive enough to be of much help.
bj: And too much in F83 was written junking block handling
and making it depend on files and screens.
> > It smothers the beginner with way too many
> > extra words, leading to chasing rabbit trails with SEE, and
> > guessing what all the cryptic designations mean. (By the way,
> > PYGMY doesn't even provide such an obvious tool.)
> >
>
> Pygmy is shipped with kernel source and a good block editor, with a
> text-search feature; you don't need SEE, which is a not-so-perfect tool
> because when you decompile you don't get back the original code.
bj: I agree it doesn't get you back to the source and the all-important
stack calling information. But the display is compact on the screen
when you want to see other things at the same time! And remember
that though the source is available the shadow screens aren't!
(cut)
> [...]
> > bj: One of the "main" funcationalities of FORTH is defining
> > new compilation constructs.
> I don't think so. This is not the main feature of Forth. Of course it's
> nice to have it in some situations, but that's not the "main"
> functionnality.
bj: I count the extensibility of FORTH to be one of its
most important features. You can do computational-like
things and lisp-like things in the same environment.
>I wonder if there's even such a thing as the "main"
> functionnality. Forth has many nice features that together makes for a
> unique (family of) langages: syntax-free, factoring-friendly (unlike
> some other langage where when you create a new function, you have to
> write down the prototype here and the implementation there),
> Interpret-Execute-Compile...
(cut)
> > bj: It seems to me one of the problems with FORTH in particular
> > with regard to execution is its very structure. FORTH words are
> > essentially CALLS and RETURNS or the equivalent. Each and
> > every one involves CALL-RETURN overhead.
>
> Beginners focus too much on that and this is wrong because it leads
> them to not factor their code.
bj: That may be. I tend to use the stack too-much, and you
can get tangled up with it. But what I was referring to
was execution overhead. Granted, it is not as high as for
example with C-language CALL-RETURNs (except Intel has
provided PUSH and POP all registers in one swoop. But
I think if a person is afraid of ASSEMBLER they should
probably choose another language.) The more you factor
the more overhead there is.
> If you're a beginner and worry about,
> then I advise you to think first about factoring well, and then unroll
> the innermost loops if speed is needed. A second argument is that Forth
> can't be as fast as natively compiled langages; not to mention that
> most processors are register-based. It's strength is in compactness,
> and as you said may because of this perhaps you can win something by
> fitting in the huge L1 and L2 caches most of the time.
bj: I agree about learning to factor well. I think that
FORTH ought to be faster than "natively compiled languages."
That is why I suggested a look-ahead thread coprocessor.
But lacking that the _reason_ FORTH is not as fast _is_
the inherent CALL/RETURN overhead. Only in-line compilation
with the huge redundancy involved would aleviate that.
(I do not know what is meant by L1 and L2 caches.)
> Amicalement,
> Astrobe
bj: So what strategy should be used for in-line
compilation? - which undoes the factoring. Does it
necessarily imply 32-bit FORTH?
Bob Jaffray
Elizabeth D Rather
news:1117723588.9...@g49g2000cwa.googlegroups.com...
> ...
>> > bj: It seems to me one of the problems with FORTH in particular
>> > with regard to execution is its very structure. FORTH words are
>> > essentially CALLS and RETURNS or the equivalent. Each and
>> > every one involves CALL-RETURN overhead.
>>
>> Beginners focus too much on that and this is wrong because it leads
>> them to not factor their code.
>
> bj: That may be. I tend to use the stack too-much, and you
> can get tangled up with it. But what I was referring to
> was execution overhead. Granted, it is not as high as for
> example with C-language CALL-RETURNs (except Intel has
> provided PUSH and POP all registers in one swoop. But
> I think if a person is afraid of ASSEMBLER they should
> probably choose another language.) The more you factor
> the more overhead there is.
In the Forth implementations I work with, the CALL/RETURN overhead is
limited to those instructions alone, with no other requirement for register
saves or restores, C-like stack frame management, etc. If the word being
called is more than a few machine instructions, that extra overhead is
almost unmeasurable.
>> If you're a beginner and worry about,
>> then I advise you to think first about factoring well, and then unroll
>> the innermost loops if speed is needed. A second argument is that Forth
>> can't be as fast as natively compiled langages; not to mention that
>> most processors are register-based. It's strength is in compactness,
>> and as you said may because of this perhaps you can win something by
>> fitting in the huge L1 and L2 caches most of the time.
>
> bj: I agree about learning to factor well. I think that
> FORTH ought to be faster than "natively compiled languages."
> That is why I suggested a look-ahead thread coprocessor.
> But lacking that the _reason_ FORTH is not as fast _is_
> the inherent CALL/RETURN overhead. Only in-line compilation
> with the huge redundancy involved would aleviate that.
> (I do not know what is meant by L1 and L2 caches.)
The Forth I work with *is* a "natively compiled language" (that is, it
compiles machine code rather than strings of addresses or pointers). Small
primitives are expanded in-line, and there's an optimizer that makes the
overall result extremely efficient in both size and performance. Overall we
get performance results comparable to C. Other modern Forths use similar
techniques. That's one of the big differences between modern Forths and
those of the 80's.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Stephen Pelc
<bobja...@juno.com> wrote:
>bj: I agree about learning to factor well. I think that
>FORTH ought to be faster than "natively compiled languages."
>That is why I suggested a look-ahead thread coprocessor.
>But lacking that the _reason_ FORTH is not as fast _is_
>the inherent CALL/RETURN overhead. Only in-line compilation
>with the huge redundancy involved would aleviate that.
>(I do not know what is meant by L1 and L2 caches.)
MPE's Forths *are* native code compiling Forths. Yes, *good*
native code compilation requires a code size overhead in the
compiler itself. The default compiler settings in VFX Forth
for Windows are for performance rather than code size. However,
in an embedded system, native code compiled Forth tends to
be smaller than the equivalent threaded Forth.
68340, 256kb binary, NCC is 1-2% smaller than DTC.
In the embedded system compilers, the default settings
have a different balance. In either case, on respectable
CPUs with indexed addressing modes, many common Forth
phrases reduce to one or two machine instructions.
>bj: So what strategy should be used for in-line
>compilation? - which undoes the factoring. Does it
>necessarily imply 32-bit FORTH?
No, we have native code compilers for 8 and 16 bit
architectures where appropriate.
Stephen
--
Stephen Pelc, steph...@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
ast...@netcourrier.com
> diskette. When entering MM at first and selecting NO to create
> the diskette, it wrote to one which when tried did not boot.
> When entering a second time and selecting YES (PROCEED) to
> create the diskette, it aborted! Do you have a suggestion.
I need the abort code to diagnose. Anyway, that's not the right place
for
this, we'll see that together offline if you wish.
> I suppose I ought to be able to poke around to find out what
> the problem was but I am wondering.
No, I don't expect that, not from someone installing 4IM for the first
time.
> But I am very surprised at the extremely
> crude appearance of the menu to the user.
>
I'm puzzled by the fact that you're suprised. Many public domain Forth
have no
menu at all. Perhaps you expected colors and pull-down menus? The
"crudeness"
(crudity?) of these menus are due to the fact that I only assumed no
particular
terminal capability except that it understands BS.
>
> > [...]
> > > bj: For my tastes F83 is way _over_ factored and sometimes
> > > quite misfactored.
> >
> > I can't imagine something can be overfactored; if the factoring is not
> > appropriate the code is simply misfactored.
>
> bj: Did you read what I said about the CALL/RETURN overhead?
No, but Astobe did.
> Factoring should be for program readability and usability.
> But in F83 it affects performance! How do _you_ reduce
> unnecessary overhead.
>
Is there "necessary overhead"? Yes! and Call/return overhead might be
one
example.
However, how do I reduce it? there are several possible ways: unfold
code
by hand, create macros (immediate words) that inline code, turn some
words
into primitives. In my context of a subroutine threaded Forth I use
tail
recursion optimization (of course that's not the main reason why I'm
using
it).
> bj: Plus you have to slug through many extra WORDS
> to see what is happening and often the names are not
> descriptive enough to be of much help.
>
> bj: And too much in F83 was written junking block handling
> and making it depend on files and screens.
>
It seems that F83 could be better...
[...]
> bj: I agree it doesn't get you back to the source and the all-important
> stack calling information. But the display is compact on the screen
> when you want to see other things at the same time! And remember
> that though the source is available the shadow screens aren't!
>
IRCC Pygmy is a shareware Forth, and you get the shadow screens only if
you register.
> > [...]
> > > bj: One of the "main" funcationalities of FORTH is defining
> > > new compilation constructs.
>
> > I don't think so. This is not the main feature of Forth. Of course it's
> > nice to have it in some situations, but that's not the "main"
> > functionnality.
>
> bj: I count the extensibility of FORTH to be one of its
> most important features. You can do computational-like
> things and lisp-like things in the same environment.
>
Sorry, I read "new control-flow constructs" instead of what you wrote.
[...]
> >
> > Beginners focus too much on that and this is wrong because it leads
> > them to not factor their code.
>
> bj: That may be. I tend to use the stack too-much, and you
> can get tangled up with it.
It's good you admit that, rather than saying there's something wrong
with
the langage.
> But what I was referring to
> was execution overhead. Granted, it is not as high as for
> example with C-language CALL-RETURNs (except Intel has
> provided PUSH and POP all registers in one swoop. But
> I think if a person is afraid of ASSEMBLER they should
> probably choose another language.) The more you factor
> the more overhead there is.
>
This raises the issue, and maybe we should answer to this first, how to
factor the good way. Should one factor according to a lenght treshold
(that is,
I don't factor if the sequence is less that 3 words long) or according
to
a frequency treshold ( when I see a sequence more than 3 times) ?
[...]
>
> bj: I agree about learning to factor well. I think that
> FORTH ought to be faster than "natively compiled languages."
I'm afraid it cannot be on processors that are register oriented.
Comparing
Forth with native langages in this context is like comparing Forth and
C on
a stack-oriented processor. On a Pentium, Forth has to run on top of
some
sort of emulator.
> That is why I suggested a look-ahead thread coprocessor.
If you are ready to buy a hardware solution, the best is to buy a Forth
processor!
> But lacking that the _reason_ FORTH is not as fast _is_
> the inherent CALL/RETURN overhead. Only in-line compilation
> with the huge redundancy involved would aleviate that.
But in this option, you give away something else: either compiler
simplicity, or
compactness or compilation speed. That's why I don't like it and prefer
to
solve speed issues on a case-by-case basis.
> (I do not know what is meant by L1 and L2 caches.)
>
First and Second level cache. Sorry, I realize that this has
disappeared 10 years
ago. When I'm doing Forth, I'm kind of living in the past :D
Amicalement,
Astrobe
A.L.
I discovered Forth again (after how long break?... Since punched card
times era... I think...) when I wanted to program some stuff for
PalmOS. Quartus Forth is a marvel, and it seems like the Only Right
Way to write quickly small applications for Palm. Maybe you should
start playing with Quartus?... This is real fun!
A.L.
P.S, Quartus guys, I will send you check promptly :)
nbri...@quartus.net
> Way to write quickly small applications for Palm. Maybe you should
> start playing with Quartus?... This is real fun!
A. L. -- thanks!
--
Neal Bridges
Quartus Handheld Software
http://www.quartus.net
bobja...@juno.com
bj: I am still interested in this question. First, Leo Brodie's books
were originally oriented toward F83, as was Martin Tracy's. Second,
Ting's book "Inside F83" is readily available. Third, there is a
migration path via F83S (F83 with separate headers and further
extensions). Only the lack of a easily accessible F83 binary seems to
be a barrier to some. (In my case, I have only web access without FTP.
But I have my original diskettes. I wish I had my originals of Guy
Kelly's FORTH.) So, with the documentation and literature, isn't F83
still the best starting point?
Bob Jaffray
Elizabeth D Rather
news:1119027334.1...@f14g2000cwb.googlegroups.com...
> ...
> bj: I am still interested in this question. First, Leo Brodie's books
> were originally oriented toward F83, as was Martin Tracy's. Second,
> Ting's book "Inside F83" is readily available. Third, there is a
> migration path via F83S (F83 with separate headers and further
> extensions). Only the lack of a easily accessible F83 binary seems to
> be a barrier to some. (In my case, I have only web access without FTP.
> But I have my original diskettes. I wish I had my originals of Guy
> Kelly's FORTH.) So, with the documentation and literature, isn't F83
> still the best starting point?
There are some pretty good books about ANS Forth. I've published two, which
are available through our web site www.forth.com, and one (Forth
Programmer's Handbook) is included as a pdf with all our products, including
the free evaluation versions. Stephen Pelc is working on one, also
available on line, which is being discussed in another thread here. And
contemporary Forths tend to be far better documented than F83 ever was, as
well as being generally easier to use and more consistent with today's
platforms (both hardware and software).
Albert van der Horst
Elizabeth D Rather <erath...@forth.com> wrote:
>
>There are some pretty good books about ANS Forth. I've published two, which
>are available through our web site www.forth.com, and one (Forth
>Programmer's Handbook) is included as a pdf with all our products, including
>the free evaluation versions. Stephen Pelc is working on one, also
>available on line, which is being discussed in another thread here. And
>contemporary Forths tend to be far better documented than F83 ever was, as
>well as being generally easier to use and more consistent with today's
>platforms (both hardware and software).
Take my ciforth as an example. It is comparable with F83 as far
as simplicity is concerned. It is comparable to fig/Forth regards
the way to build. It is ISO-compatible.
But on the documentation front:
it has a pdf documentation with all the niceties, chapter flapout,
extensive indices, through clickable references, proportional fonts.
Thanks to all the tool-builders out there, on Linux.
(ciforths run on Linux and Windows, and more.)
>Cheers,
>Elizabeth
Groetjes Albert
--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Stephen Pelc
<bobja...@juno.com> wrote:
>bj: I am still interested in this question. First, Leo Brodie's books
>were originally oriented toward F83, as was Martin Tracy's. Second,
>Ting's book "Inside F83" is readily available. Third, there is a
>migration path via F83S (F83 with separate headers and further
>extensions). Only the lack of a easily accessible F83 binary seems to
>be a barrier to some.
...
>So, with the documentation and literature, isn't F83
>still the best starting point?
The majority of the widely available desktop Forths
are based on ANS. Most of the embedded work we do now
uses 32 bit CPUs. The code quality of many modern Forths
is far better than that of older ITC and DTC Forths.
Brodie's books are wonderful, but were not even based
on Forth-83.
You can download my new effort from:
http://www.mpeltd.demon.co.uk/books.htm
Ziggy
> <bobja...@juno.com> wrote in message
> news:1119027334.1...@f14g2000cwb.googlegroups.com...
>> ...
>> bj: I am still interested in this question. First, Leo Brodie's books
>> were originally oriented toward F83, as was Martin Tracy's. Second,
>> Ting's book "Inside F83" is readily available. Third, there is a
>> migration path via F83S (F83 with separate headers and further
>> extensions). Only the lack of a easily accessible F83 binary seems to
>> be a barrier to some. (In my case, I have only web access without FTP.
>> But I have my original diskettes. I wish I had my originals of Guy
>> Kelly's FORTH.) So, with the documentation and literature, isn't F83
>> still the best starting point?
>
> There are some pretty good books about ANS Forth. I've published two,
> which are available through our web site www.forth.com, and one (Forth
> Programmer's Handbook) is included as a pdf with all our products,
> including
> the free evaluation versions. Stephen Pelc is working on one, also
> available on line, which is being discussed in another thread here. And
> contemporary Forths tend to be far better documented than F83 ever was, as
> well as being generally easier to use and more consistent with today's
> platforms (both hardware and software).
>
> Cheers,
> Elizabeth
>
Ouch.. Any special deals for students or non commercial use on SwiftForth?
Elizabeth D Rather
news:SImte.67806$x96.53219@attbi_s72...
> Elizabeth D Rather wrote:
>
>> <bobja...@juno.com> wrote in message
>> news:1119027334.1...@f14g2000cwb.googlegroups.com...
>>> ...
>>
>> which are available through our web site www.forth.com, and one (Forth
>> Programmer's Handbook) is included as a pdf with all our products,
>> including
>> the free evaluation versions. Stephen Pelc is working on one, also
>> available on line, which is being discussed in another thread here. And
>> contemporary Forths tend to be far better documented than F83 ever was,
>> as
>> well as being generally easier to use and more consistent with today's
>> platforms (both hardware and software).
>>
>> Cheers,
>> Elizabeth
>
> Ouch.. Any special deals for students or non commercial use on SwiftForth?
The free evaluation version of SwiftForth includes all documentation and
functionality, missing only source and the ability to make a distributable
turnkey application. And there are various discounts available that will be
offered to you after you download it.