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.
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.
> 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.
> 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
This is an excellent starting point for understanding how a threaded
interpreter works:
> 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.
> 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:
> 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.
> 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.
> 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
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
>> 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. Luckily there were some good threads in here.
>> 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 ...
Even bigger thanks. This makes much sense. I have been wondering how the 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.
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.
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.
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.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
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.
> 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 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."
==================================================
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>.
>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.
>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.
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
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.
> 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.
