Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How forth works?
241 views
Skip to first unread message
Hannu Vuolasaho
Oct 31, 2012, 5:43:12 PM10/31/12
to
Hello everyone!
Earlier today I wrote few nice words that had create and does and I
started wondering how I just did what I did. After few hours of surfing
and reading I'm not really enlightned.
I'm interested understanding how the system behind ok prompt works. So
far I have grasped idea that QUIT reads from keyboard INTERPRET seeks
from dictionary and if found EXECUTE it and then triest convert number.
And then there is inner interpreter.
Reading source code isn't very useful as it shows how nice assembler
someone has written.
Anyway good webpage but still not exactly what I looked for is:
http://www.jimbrooks.org/web/forth/forthInternals.php
What I'm looking for is to some good information how interpreter starts
and executes like standard says. And also how the compilation is done
with branching. Which I believe is much implementation defined.
--
Hannu Vuolasaho
Earlier today I wrote few nice words that had create and does and I
started wondering how I just did what I did. After few hours of surfing
and reading I'm not really enlightned.
I'm interested understanding how the system behind ok prompt works. So
far I have grasped idea that QUIT reads from keyboard INTERPRET seeks
from dictionary and if found EXECUTE it and then triest convert number.
And then there is inner interpreter.
Reading source code isn't very useful as it shows how nice assembler
someone has written.
Anyway good webpage but still not exactly what I looked for is:
http://www.jimbrooks.org/web/forth/forthInternals.php
What I'm looking for is to some good information how interpreter starts
and executes like standard says. And also how the compilation is done
with branching. Which I believe is much implementation defined.
--
Hannu Vuolasaho
Mark Wills
Oct 31, 2012, 6:09:26 PM10/31/12
to
On Oct 31, 9:48 pm, Hannu Vuolasaho
This is an excellent starting point for understanding how a threaded
interpreter works:
http://www.eighty-twenty.org/repos/jonesforth/jonesforth.S
interpreter works:
http://www.eighty-twenty.org/repos/jonesforth/jonesforth.S
Rod Pemberton
Oct 31, 2012, 8:47:25 PM10/31/12
to
"Hannu Vuolasaho" <hannu.v...@nospam.tut.fi.invalid> wrote in message
news:slrnk936rg.lmg....@haikara.cs.tut.fi...
> I'm interested understanding how the system behind ok prompt works. So
> far I have grasped idea that QUIT reads from keyboard INTERPRET seeks
> from dictionary and if found EXECUTE it and then triest convert number.
> And then there is inner interpreter.
You found the first link, but there are other good sources out there too:
Jim Brooks "FIG-FORTH Internals"
http://www.jimbrooks.org/web/forth/forthInternals.php
Peter Knagg's "Forth: An underview"
http://dec.bournemouth.ac.uk/forth/forth.html
Bradford Rodriquez "Moving Forth" series
http://www.bradrodriguez.com/papers/
figinst.zip fig-Forth November 1980
ftp://ftp.taygeta.com/pub/forth/Archive/docs/FIGINST.ZIP
figdoc.zip fig-Forth May 1979
http://home.hccnet.nl/a.w.m.van.der.horst/figdoc.zip
PFE documentation
http://pfe.sourceforge.net/manual/index.html
eForth overview
http://www.offete.com/files/zeneForth.htm
> Reading source code isn't very useful as it shows how nice assembler
> someone has written.
>
> Anyway good webpage but still not exactly what I looked for is:
> http://www.jimbrooks.org/web/forth/forthInternals.php
>
> What I'm looking for is to some good information how interpreter starts
> and executes like standard says.
First, you have to be able to create an executable program using assembly or
another high-level language, like C, for your operating system (OS) if your
Forth is hosted, and not standalone, nor embedded. This will contain a few
small routines for the interpreter, one of which is known as NEXT. Others
are DOCOL or ENTER and EXIT or SEMIS, etc.
Second, you set the interpreter's instruction pointer (IP) to the address of
COLD. COLD is the traditional name for the initial entry routine. Then,
you call or jump to the interpreter's NEXT routine. NEXT sets the working
pointer (W), adjusts IP to the next instruction, and calls or jumps to an
executable procedure or assembled instructions at the working pointer (W) to
be executed. The interpreter is now interpreting the code. The addresses
that are called or jumped to are the CFA (code-field address) of Forth words
in the dictionary. If a Forth word is high-level Forth word, the CFA is a
special routine called DOCOL or ENTER. It saves the current interpreter
state and starts interpreting another word. There are other such low-level
CFA routines in Forth: DOVAR, DOCON, DOUSER. These are routines which
handles the contents of each type of Forth word. I.e., just as DOCOL is for
interpreted Forth words, DOCON is for Forth words that store constants. It
a low-level routine calls some assembled code or a procedure directly, that
routine is called a "primitive".
As an aside, some low-level routines you'd expect in Forth, say DOSTR to
handle Forth words consisting of strings, aren't present in Forth ...
> And also how the compilation is done
> with branching. Which I believe is much implementation defined.
>
I'm not quite sure what you're asking about here.
Rod Pemberton
news:slrnk936rg.lmg....@haikara.cs.tut.fi...
>
> Earlier today I wrote few nice words that had create and does and I
> started wondering how I just did what I did. After few hours of surfing
> and reading I'm not really enlightned.
>
CREATE and DOES> are somewhat complicated.
> Earlier today I wrote few nice words that had create and does and I
> started wondering how I just did what I did. After few hours of surfing
> and reading I'm not really enlightned.
>
> I'm interested understanding how the system behind ok prompt works. So
> far I have grasped idea that QUIT reads from keyboard INTERPRET seeks
> from dictionary and if found EXECUTE it and then triest convert number.
> And then there is inner interpreter.
Jim Brooks "FIG-FORTH Internals"
http://www.jimbrooks.org/web/forth/forthInternals.php
Peter Knagg's "Forth: An underview"
http://dec.bournemouth.ac.uk/forth/forth.html
Bradford Rodriquez "Moving Forth" series
http://www.bradrodriguez.com/papers/
figinst.zip fig-Forth November 1980
ftp://ftp.taygeta.com/pub/forth/Archive/docs/FIGINST.ZIP
figdoc.zip fig-Forth May 1979
http://home.hccnet.nl/a.w.m.van.der.horst/figdoc.zip
PFE documentation
http://pfe.sourceforge.net/manual/index.html
eForth overview
http://www.offete.com/files/zeneForth.htm
> Reading source code isn't very useful as it shows how nice assembler
> someone has written.
>
> Anyway good webpage but still not exactly what I looked for is:
> http://www.jimbrooks.org/web/forth/forthInternals.php
>
> What I'm looking for is to some good information how interpreter starts
> and executes like standard says.
another high-level language, like C, for your operating system (OS) if your
Forth is hosted, and not standalone, nor embedded. This will contain a few
small routines for the interpreter, one of which is known as NEXT. Others
are DOCOL or ENTER and EXIT or SEMIS, etc.
Second, you set the interpreter's instruction pointer (IP) to the address of
COLD. COLD is the traditional name for the initial entry routine. Then,
you call or jump to the interpreter's NEXT routine. NEXT sets the working
pointer (W), adjusts IP to the next instruction, and calls or jumps to an
executable procedure or assembled instructions at the working pointer (W) to
be executed. The interpreter is now interpreting the code. The addresses
that are called or jumped to are the CFA (code-field address) of Forth words
in the dictionary. If a Forth word is high-level Forth word, the CFA is a
special routine called DOCOL or ENTER. It saves the current interpreter
state and starts interpreting another word. There are other such low-level
CFA routines in Forth: DOVAR, DOCON, DOUSER. These are routines which
handles the contents of each type of Forth word. I.e., just as DOCOL is for
interpreted Forth words, DOCON is for Forth words that store constants. It
a low-level routine calls some assembled code or a procedure directly, that
routine is called a "primitive".
As an aside, some low-level routines you'd expect in Forth, say DOSTR to
handle Forth words consisting of strings, aren't present in Forth ...
> And also how the compilation is done
> with branching. Which I believe is much implementation defined.
>
Rod Pemberton
Hugh Aguilar
Oct 31, 2012, 8:44:31 PM10/31/12
to
On Oct 31, 2:48 pm, Hannu Vuolasaho
You might try "Threaded Interpretive Languages" (R.G.Loeliger). I read
that when I was a senior in H.S. (1984). I later lent the book out and
never got it back. :-( It may be available on pdf now though. It is
for the Z80, so you should know Z80 assembly-language to read the book
--- it documents everything however, so you don't have to just figure
it out from the source-code.
Branching isn't any more implementation-specific than anything else.
You compile BRANCH or 0BRANCH, followed by an offset. These just add
the offset to the IP (interpretive pointer) to effect the branch. All
of the primitive words are in assembly-language, so they are processor-
specific, but the overall plan is the same no matter what processor
you are using. It is theoretically possible for the same threaded-code
to run on more than one processor without recompiling, although I've
never heard of that being done. Threaded code is pretty simple ---
also, pretty slow, which is why I don't recommend messing with
threaded schemes in this modern era in which processors do branch-
prediction.
Why are you interested in the internal workings of Forth? Your
experience is: "today I wrote few nice words." You are getting way
ahead of yourself. I have said many times here that it is a mistake
for people to think of Forth as a science-fair project and immediately
delve into the internal workings. I recommend instead that you start
out by writing application programs --- that is the best way to learn
Forth. You can use my novice package:
http://www.forth.org/novice.html
that when I was a senior in H.S. (1984). I later lent the book out and
never got it back. :-( It may be available on pdf now though. It is
for the Z80, so you should know Z80 assembly-language to read the book
--- it documents everything however, so you don't have to just figure
it out from the source-code.
Branching isn't any more implementation-specific than anything else.
You compile BRANCH or 0BRANCH, followed by an offset. These just add
the offset to the IP (interpretive pointer) to effect the branch. All
of the primitive words are in assembly-language, so they are processor-
specific, but the overall plan is the same no matter what processor
you are using. It is theoretically possible for the same threaded-code
to run on more than one processor without recompiling, although I've
never heard of that being done. Threaded code is pretty simple ---
also, pretty slow, which is why I don't recommend messing with
threaded schemes in this modern era in which processors do branch-
prediction.
Why are you interested in the internal workings of Forth? Your
experience is: "today I wrote few nice words." You are getting way
ahead of yourself. I have said many times here that it is a mistake
for people to think of Forth as a science-fair project and immediately
delve into the internal workings. I recommend instead that you start
out by writing application programs --- that is the best way to learn
Forth. You can use my novice package:
http://www.forth.org/novice.html
Hannu Vuolasaho
Oct 31, 2012, 9:35:33 PM10/31/12
to
On 2012-11-01, Rod Pemberton <do_no...@notemailnotz.cnm> wrote:
> "Hannu Vuolasaho" <hannu.v...@nospam.tut.fi.invalid> wrote in message
> news:slrnk936rg.lmg....@haikara.cs.tut.fi...
>>
>> Earlier today I wrote few nice words that had create and does and I
>> started wondering how I just did what I did. After few hours of surfing
>> and reading I'm not really enlightned.
>>
>
> CREATE and DOES> are somewhat complicated.
Indeed. It took quite long to figure out how they should be used.
> "Hannu Vuolasaho" <hannu.v...@nospam.tut.fi.invalid> wrote in message
> news:slrnk936rg.lmg....@haikara.cs.tut.fi...
>>
>> Earlier today I wrote few nice words that had create and does and I
>> started wondering how I just did what I did. After few hours of surfing
>> and reading I'm not really enlightned.
>>
>
> CREATE and DOES> are somewhat complicated.
Luckily there were some good threads in here.
>
> You found the first link, but there are other good sources out there too:
>
> Jim Brooks "FIG-FORTH Internals"
> http://www.jimbrooks.org/web/forth/forthInternals.php
>
> Peter Knagg's "Forth: An underview"
> http://dec.bournemouth.ac.uk/forth/forth.html
>
> Bradford Rodriquez "Moving Forth" series
> http://www.bradrodriguez.com/papers/
>
> figinst.zip fig-Forth November 1980
> ftp://ftp.taygeta.com/pub/forth/Archive/docs/FIGINST.ZIP
>
> figdoc.zip fig-Forth May 1979
> http://home.hccnet.nl/a.w.m.van.der.horst/figdoc.zip
>
> PFE documentation
> http://pfe.sourceforge.net/manual/index.html
>
> eForth overview
> http://www.offete.com/files/zeneForth.htm
>
>>
>> What I'm looking for is to some good information how interpreter starts
>> and executes like standard says.
>
> First, you have to be able to create an executable program using assembly or
> another high-level language, like C, for your operating system (OS) if your
> Forth is hosted, and not standalone, nor embedded. This will contain a few
> small routines for the interpreter, one of which is known as NEXT. Others
> are DOCOL or ENTER and EXIT or SEMIS, etc.
>
> Second, you set the interpreter's instruction pointer (IP) to the address of
> COLD. COLD is the traditional name for the initial entry routine. Then,
> you call or jump to the interpreter's NEXT routine. NEXT sets the working
> pointer (W), adjusts IP to the next instruction, and calls or jumps to an
> executable procedure or assembled instructions at the working pointer (W) to
> be executed. The interpreter is now interpreting the code. The addresses
> that are called or jumped to are the CFA (code-field address) of Forth words
> in the dictionary. If a Forth word is high-level Forth word, the CFA is a
> special routine called DOCOL or ENTER. It saves the current interpreter
> state and starts interpreting another word. There are other such low-level
> CFA routines in Forth: DOVAR, DOCON, DOUSER. These are routines which
> handles the contents of each type of Forth word. I.e., just as DOCOL is for
> interpreted Forth words, DOCON is for Forth words that store constants. It
> a low-level routine calls some assembled code or a procedure directly, that
> routine is called a "primitive".
>
> As an aside, some low-level routines you'd expect in Forth, say DOSTR to
> handle Forth words consisting of strings, aren't present in Forth ...
systems really work and you save much reading time.
>
>> And also how the compilation is done
>> with branching. Which I believe is much implementation defined.
>>
>
> I'm not quite sure what you're asking about here.
Well I had little bit different ideas how the system works internally.
>> And also how the compilation is done
>> with branching. Which I believe is much implementation defined.
>>
>
> I'm not quite sure what you're asking about here.
After reading jonesforth assembler listing implementation of IF and
other control structures came much clearer. Also the RISC and CISC
assembler notation had fooled me.
--
Hannu Vuolasaho
Hannu Vuolasaho
Oct 31, 2012, 10:04:19 PM10/31/12
to
On 2012-11-01, Hugh Aguilar <hughag...@yahoo.com> wrote:
>
> Why are you interested in the internal workings of Forth? Your
> experience is: "today I wrote few nice words." You are getting way
> ahead of yourself. I have said many times here that it is a mistake
> for people to think of Forth as a science-fair project and immediately
> delve into the internal workings. I recommend instead that you start
> out by writing application programs --- that is the best way to learn
> Forth. You can use my novice package:
> http://www.forth.org/novice.html
I'm working on application. However when I get something I don't
>
> Why are you interested in the internal workings of Forth? Your
> experience is: "today I wrote few nice words." You are getting way
> ahead of yourself. I have said many times here that it is a mistake
> for people to think of Forth as a science-fair project and immediately
> delve into the internal workings. I recommend instead that you start
> out by writing application programs --- that is the best way to learn
> Forth. You can use my novice package:
> http://www.forth.org/novice.html
understand I usually go to the root and figure out the reason. It's much
more interesting to study system and see why I made on error. However in
this case I tried to understand the CREATE DOES> success. What I did and
how it happened. The missing piece was the system. How it works what
makes my definitions work like they do and why I can see the differences
in the dictionary. Sometimes it isn't enough to something to just work.
I want to know why it works.
And I have your novice package. It is good reference and has good ideas.
However I have never used training wheels and I'm not starting now. I
started with small motorbike :)
--
Hannu Vuolasaho
Hugh Aguilar
Oct 31, 2012, 10:43:14 PM10/31/12
to
On Oct 31, 7:04 pm, Hannu Vuolasaho
<hannu.vuolas...@nospam.tut.fi.invalid> wrote:
just a cookbook formula for making it work. I'm the same way. I am
just saying that one ought not to get too bogged down in the nitty-
gritty details prior to obtaining some practical experience --- the
essence of programming is writing programs, not tinkering with the
compiler.
BTW, I don't use CREATE DOES> at all --- that is something that can
and should be ignored entirely --- it seems complicated to you because
it is badly designed (it seems complicated to me too). CREATE DOES>
saves code memory compared to my technique, but memory is cheap these
days --- CREATE DOES> is solving a problem that hasn't been a problem
in over 20 years.
> And I have your novice package. It is good reference and has good ideas.
> However I have never used training wheels and I'm not starting now. I
> started with small motorbike :)
lol
I wouldn't really consider it to be "training wheels." I use it myself
for writing application programs!
How much customization do you really need for arrays and lists and so
forth? There are a few circumstances (mostly involving 16-bit x86
segments) in which data structures can be customized for a particular
application, but for the most part an array or list is going to be
implemented the same way for *every* application that you ever write.
That kind of low-level stuff can be written once and, assuming that it
was written in a robust manner, used repeatedly pretty much forever.
If you re-implement this stuff for every application, it will be
slightly different every time, which will hurt readability.
The data-structures in the novice package aren't a simplistic
implementation, and later on you will write an advanced implementation
yourself --- no, they are as advanced as you are ever going to get ---
the next step up is not to rewrite these basic data-structures, but
rather the next step up is to write application programs.
<hannu.vuolas...@nospam.tut.fi.invalid> wrote:
> On 2012-11-01, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
>
>
> > Why are you interested in the internal workings of Forth? Your
> > experience is: "today I wrote few nice words." You are getting way
> > ahead of yourself. I have said many times here that it is a mistake
> > for people to think of Forth as a science-fair project and immediately
> > delve into the internal workings. I recommend instead that you start
> > out by writing application programs --- that is the best way to learn
> > Forth. You can use my novice package:
> >http://www.forth.org/novice.html
>
> I'm working on application. However when I get something I don't
> understand I usually go to the root and figure out the reason. It's much
> more interesting to study system and see why I made on error. However in
> this case I tried to understand the CREATE DOES> success. What I did and
> how it happened. The missing piece was the system. How it works what
> makes my definitions work like they do and why I can see the differences
> in the dictionary. Sometimes it isn't enough to something to just work.
> I want to know why it works.
I can appreciate the idea of learning how something works, rather than
>
>
>
> > Why are you interested in the internal workings of Forth? Your
> > experience is: "today I wrote few nice words." You are getting way
> > ahead of yourself. I have said many times here that it is a mistake
> > for people to think of Forth as a science-fair project and immediately
> > delve into the internal workings. I recommend instead that you start
> > out by writing application programs --- that is the best way to learn
> > Forth. You can use my novice package:
> >http://www.forth.org/novice.html
>
> I'm working on application. However when I get something I don't
> understand I usually go to the root and figure out the reason. It's much
> more interesting to study system and see why I made on error. However in
> this case I tried to understand the CREATE DOES> success. What I did and
> how it happened. The missing piece was the system. How it works what
> makes my definitions work like they do and why I can see the differences
> in the dictionary. Sometimes it isn't enough to something to just work.
> I want to know why it works.
just a cookbook formula for making it work. I'm the same way. I am
just saying that one ought not to get too bogged down in the nitty-
gritty details prior to obtaining some practical experience --- the
essence of programming is writing programs, not tinkering with the
compiler.
BTW, I don't use CREATE DOES> at all --- that is something that can
and should be ignored entirely --- it seems complicated to you because
it is badly designed (it seems complicated to me too). CREATE DOES>
saves code memory compared to my technique, but memory is cheap these
days --- CREATE DOES> is solving a problem that hasn't been a problem
in over 20 years.
> And I have your novice package. It is good reference and has good ideas.
> However I have never used training wheels and I'm not starting now. I
> started with small motorbike :)
I wouldn't really consider it to be "training wheels." I use it myself
for writing application programs!
How much customization do you really need for arrays and lists and so
forth? There are a few circumstances (mostly involving 16-bit x86
segments) in which data structures can be customized for a particular
application, but for the most part an array or list is going to be
implemented the same way for *every* application that you ever write.
That kind of low-level stuff can be written once and, assuming that it
was written in a robust manner, used repeatedly pretty much forever.
If you re-implement this stuff for every application, it will be
slightly different every time, which will hurt readability.
The data-structures in the novice package aren't a simplistic
implementation, and later on you will write an advanced implementation
yourself --- no, they are as advanced as you are ever going to get ---
the next step up is not to rewrite these basic data-structures, but
rather the next step up is to write application programs.
Message has been deleted
Hugh Aguilar
Oct 31, 2012, 10:52:55 PM10/31/12
to
On Oct 31, 7:04 pm, Hannu Vuolasaho
offer some suggestions. :-)
Also, which Forth system are you using?
BTW: Your name seems familiar --- do I remember you from the Factor
mailing list?
<hannu.vuolas...@nospam.tut.fi.invalid> wrote:
> I'm working on application.
Would you mind telling us what your program does? We might be able to
> I'm working on application.
offer some suggestions. :-)
Also, which Forth system are you using?
BTW: Your name seems familiar --- do I remember you from the Factor
mailing list?
Elizabeth D. Rather
Nov 1, 2012, 12:33:45 AM11/1/12
to
On 10/31/12 3:35 PM, Hannu Vuolasaho wrote:
...
Standard Forth and most mainstream implementations.
As for you basic question, in addition to the links posted there are a
number of good books on Forth (I wrote two of them, but there are
others) which you can find by Googling.
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."
==================================================
...
> After reading jonesforth assembler listing implementation of IF and
> other control structures came much clearer. Also the RISC and CISC
> assembler notation had fooled me.
Watch out for jonesforth. It has many features that are different from
> other control structures came much clearer. Also the RISC and CISC
> assembler notation had fooled me.
Standard Forth and most mainstream implementations.
As for you basic question, in addition to the links posted there are a
number of good books on Forth (I wrote two of them, but there are
others) which you can find by Googling.
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."
==================================================
Brad Eckert
Nov 1, 2012, 1:22:03 PM11/1/12
to
On Wednesday, October 31, 2012 7:43:14 PM UTC-7, Hugh Aguilar wrote:
> BTW, I don't use CREATE DOES> at all --- that is something that can
> and should be ignored entirely --- it seems complicated to you because
> it is badly designed (it seems complicated to me too). CREATE DOES>
> saves code memory compared to my technique, but memory is cheap these
> days --- CREATE DOES> is solving a problem that hasn't been a problem
> in over 20 years.
>
You can factor fine without CREATE DOES>. But think "make the language fit the problem", not the other way around as with other languages. Creating a custom syntax and language for your application domain is harder without DOES>.
> BTW, I don't use CREATE DOES> at all --- that is something that can
> and should be ignored entirely --- it seems complicated to you because
> it is badly designed (it seems complicated to me too). CREATE DOES>
> saves code memory compared to my technique, but memory is cheap these
> days --- CREATE DOES> is solving a problem that hasn't been a problem
> in over 20 years.
>
Albert van der Horst
Nov 1, 2012, 6:24:24 PM11/1/12
to
In article <slrnk936rg.lmg....@haikara.cs.tut.fi>,
You can get an idea from how INTERPRET and QUIT work using SEE.
This is most helpful with the most simple and primitive Forth's.
(E.g. it would with lina, if the decompiler would reconstruct
BEGIN's and IF's instead of primitive branching.)
Alternatively some Forth's are written in Forth (metacompilation).
The source for the Launchpad is available. This too is a simple
Forth. Google for ``noforth''.
>
>--
>Hannu Vuolasaho
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
This is most helpful with the most simple and primitive Forth's.
(E.g. it would with lina, if the decompiler would reconstruct
BEGIN's and IF's instead of primitive branching.)
Alternatively some Forth's are written in Forth (metacompilation).
The source for the Launchpad is available. This too is a simple
Forth. Google for ``noforth''.
>
>--
>Hannu Vuolasaho
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Peter Knaggs
Nov 7, 2012, 5:28:04 AM11/7/12
to
Hannu Vuolasaho <hannu.vuolas...@nospam.tut.fi.invalid> wrote:
> Hello everyone!
>
> Earlier today I wrote few nice words that had create and does and I
> started wondering how I just did what I did. After few hours of surfing
> and reading I'm not really enlightned.
>
> I'm interested understanding how the system behind ok prompt works. So
> far I have grasped idea that QUIT reads from keyboard INTERPRET seeks
> from dictionary and if found EXECUTE it and then triest convert number.
> And then there is inner interpreter.
>
> Reading source code isn't very useful as it shows how nice assembler
> someone has written.
>
> Anyway good webpage but still not exactly what I looked for
> is:http://www.jimbrooks.org/web/forth/forthInternals.php
>
> What I'm looking for is to some good information how interpreter starts
> and executes like standard says. And also how the compilation is done
> with branching. Which I believe is much implementation defined.
http://dec.bournemouth.ac.uk/forth/forth.html
> Hello everyone!
>
> Earlier today I wrote few nice words that had create and does and I
> started wondering how I just did what I did. After few hours of surfing
> and reading I'm not really enlightned.
>
> I'm interested understanding how the system behind ok prompt works. So
> far I have grasped idea that QUIT reads from keyboard INTERPRET seeks
> from dictionary and if found EXECUTE it and then triest convert number.
> And then there is inner interpreter.
>
> Reading source code isn't very useful as it shows how nice assembler
> someone has written.
>
> Anyway good webpage but still not exactly what I looked for
> is:http://www.jimbrooks.org/web/forth/forthInternals.php
>
> What I'm looking for is to some good information how interpreter starts
> and executes like standard says. And also how the compilation is done
> with branching. Which I believe is much implementation defined.
I was written as an introduction to forth for my thesis, but it never made
it into the final document. An forth underview goes into some detail about
the implementation techniques used.
--
Peter Knaggs
0 new messages