Bootstrapping a Forth in 40 lines of Lua code
eduar...@gmail.com
I'm almost submitting an article called "Bootstrapping a Forth in 40
Lines of Lua Code" to a book called "Lua Programming Gems"
(<http://www.lua.org/gems/>). The current draft of the article is at:
http://angg.twu.net/miniforth-article.html
and I'd welcome any feedback.
That article has a very atypical bias. In the late 80s and early 90s I
used HS-Forth - a commercial Forth-79 for the IBM-PC - a lot, and what
I most liked about it was that its memory model and data structures
were very clean and very well documented; after a tiny bit of reverse
engineering to understand some missing details I knew enough of its
internals to implement little languages on top of it. Then in 1994 I
switched to (GNU/)Linux and I had to abandon HS-Forth; and all the
Forths that I tried from that point on I found frustrating, and most
of them more or less tried to follow the ANS Standard.
More later. Cheers,
Eduardo Ochs
eduar...@gmail.com
http://angg.twu.net/
none Byron Jeff
eduar...@gmail.com <eduar...@gmail.com> wrote:
>Hello comp.lang.forth,
>
>I'm almost submitting an article called "Bootstrapping a Forth in 40
>Lines of Lua Code" to a book called "Lua Programming Gems"
>(<http://www.lua.org/gems/>). The current draft of the article is at:
>
> http://angg.twu.net/miniforth-article.html
>
>and I'd welcome any feedback.
I'm a novice, but I'll take a crack. I think that this passage in the
abstract:
"...and an inner interpreter, that runs bytecodes; the outer interpreter
switches between an 'immediate mode', where words as executed as soon as
they are read, and a 'compile mode', where the words being read are
assembled into bytecodes to define new words."
that the word bytecodes isn't the right context. While token threaded
interpreters fit the model, none of the other forth threading models
(indirect, direct, subroutine) really do. In each of those instances,
the address of where the code can be located (either indirectly or
directly) is what is compiled. None of these address native optimized
code compilers either.
In short, I would suggest not using the word bytecode here.
Other than that it looks pretty good.
BAJ
Marcel Hendrix
> I'm almost submitting an article called "Bootstrapping a Forth in 40
> Lines of Lua Code" to a book called "Lua Programming Gems"
> (<http://www.lua.org/gems/>). The current draft of the article is at:
> http://angg.twu.net/miniforth-article.html
> and I'd welcome any feedback.
Title of the page:
"Boostraping a Forth in 40 lines of Lua code"
It's an remarkably adequate description, but I think you want to change it :-)
First line of the article:
"The core of a conventional Forth system [...] and an inner interpreter, that runs bytecodes;"
Not true. I have seen lots of useful Forths, and none of them used bytecodes.
I admit to really hate these kind of articles. They are of course fine
to show to the Lua crowd how superior their favorite language is.
How would a Lua fan react to a Forth person writing "Bootstrapping the essence
of Lua in 10 lines of Forth code?"
-marcel
John Passaniti
> First line of the article:
> "The core of a conventional Forth system [...] and an inner interpreter, that runs bytecodes;"
>
> Not true. I have seen lots of useful Forths, and none of them used bytecodes.
Haven't read many technical articles have you? You quoted from the
abstract. The purpose of the abstract is to provide a summary of the
rest of the article and the Forth implementation it describes. It isn't
a statement about all Forths.
> I admit to really hate these kind of articles. They are of course fine
> to show to the Lua crowd how superior their favorite language is.
That's what you got from the article? Did you even read it?
Quoted from the end of the article is perhaps the best reason for this
article:
"I do not intend to claim that miniforth is
compact - in terms of memory usage -, or
efficient, or useful for practical applications.
But the natural ways for doing things in Forth
were different from the ways that are natural
in today's systems; and I believe that
miniforth can be used to give to people
glimpses into interesting ways of thinking
that have practically disappeared, and that
have become hard to communicate."
Yeah, clearly the author is trying to show how superior Lua is. Duh.
> How would a Lua fan react to a Forth person writing "Bootstrapping the essence
> of Lua in 10 lines of Forth code?"
If you spent any time in the Lua mailing list, you would see a community
of people from a number of problem domains who are in general anything
but hostile to new ways of thinking. To the extent that this article
may help people who are trying to understand threaded Forth models in
terms of a language they know, I think it's a very good thing.
But to answer your question, the Lua crowd would probably *love* such an
article. The Lua authors have expressed in the past the desire to have
alternate implementations of Lua beside the C-based virtual machine. So
feel free to write that article. I'm sure the Lua authors (and the
*vast* majority of the community) would be more than happy to see an
alternate implementation.
eduar...@gmail.com
Thanks for all the criticism. I am already trying to change the
article - but don't expect online changes in the next 12 hours at
least, as I need to do some chores on the street and I will have to
work on a paper copy while I'm out.
To Marcel Hendrix:
> How would a Lua fan react to a Forth person writing "Bootstrapping
> the essence of Lua in 10 lines of Forth code?"
some people would love that - and some people may be even trying to
implement something along these lines, but they haven't got anything
very satisfactory yet, so they haven't made their work very visible.
Take a look at:
http://luaforge.net/docman/view.php/83/98/ANoFrillsIntroToLua51VMInstructions.pdf
The Lua VM is very well-known, and if you lurk at the #lua channel at
FreeNode for a few hours or take a look at the archives of the lua
mailing list - http://lua-users.org/lists/lua-l/ - you will see that
lots of users know the innards very well, and they change them when
they need to too. There is something very Forth-ish about Lua, and the
Lua users with some experience on Forth make no secret about that.
> Not true. I have seen lots of useful Forths, and none of them used
> bytecodes.
The Forths that were mind-openers to me used bytecodes. And, if I
remember correctly (I don't have the files at hand now), HS-Forth had
tools to compile Forth source to subroutine-threaded code - but the
author preferred to use his indirect-threaded bytecode (that, by the
way, corresponds to Figure 2 in the article) for most tasks, and only
recompile programs into subroutine-threaded code at the very, and only
when needed.
If we have a "real Forth" running bytecodes, and if we have a way to
program support for new kinds of bytecodes easily, then it should be
easy to link that Forth with Lua and make it able to run Lua bytecodes
too. But writing such a beast in C and Asm would be too much work for
me now - and I thought that it could be better to prototype some of
these ideas from Lua, first on a "memory" that would be a Lua table,
not an array of bytes, and only then on some Lua object (written in C)
that would let me write directly to the real memory... and only after
that move to a real Forth.
Cheers, more later, I have to rush to the dentist now...
Eduardo Ochs
eduar...@gmail.com
http://angg.twu.net/
P.S. (to Marcel): I tried to buy a copy of iForth for Linux in 1996 or
1997, I think - but it turned out that I would have to spend the price
of the system, plus customs taxes, plus shipping, plus US$50 for an
international bank transfer - and that was too much for my
3rd-world-student budget...
Anton Ertl
>The Forths that were mind-openers to me used bytecodes. And, if I
>remember correctly (I don't have the files at hand now), HS-Forth had
>tools to compile Forth source to subroutine-threaded code - but the
>author preferred to use his indirect-threaded bytecode
But indirect threaded code is not a bytecode in the usual sense: it
uses more than one byte to encode an instruction. Better write
"Virtual machine code" ("VM code" for short) instead of "bytecode".
Despite that minor quibble, from skimming your article I think that it
is quite nice, and may give a good impression of Forth to some in the
Lua community.
Concerning knowing the innards of the system, Gforth and Win32Forth
are still based on threaded code (I think this is changing in
Win32Forth), and many other systems still have properties that come
from that heritage (e.g., mixing data and code). Many modern systems
tend to be complex, though, which makes it a lot of work to understand
the system completely. However, there are a number of systems that
are intended to be simple, e.g., eForth.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/
Marcel Hendrix
[..]
> The Forths that were mind-openers to me used bytecodes. And, if I
> remember correctly (I don't have the files at hand now), HS-Forth had
> tools to compile Forth source to subroutine-threaded code - but the
> author preferred to use his indirect-threaded bytecode (that, by the
> way, corresponds to Figure 2 in the article) for most tasks, and only
> recompile programs into subroutine-threaded code at the very, and only
> when needed.
If you mean Harvard-Softworks Forth, written by Jim Callahan: it was
indirect-threaded, yes. But I do not know what you mean by 'byte-codes'
in this context. This term is usually reserved for some kind of
token-threading (see "4th" for a publicly available approximation of
this idea).
> P.S. (to Marcel): I tried to buy a copy of iForth for Linux in 1996 or
> 1997, I think - but it turned out that I would have to spend the price
> of the system, plus customs taxes, plus shipping, plus US$50 for an
> international bank transfer - and that was too much for my
> 3rd-world-student budget...
The situation has improved ( https://order.kagi.com/cgi-bin/store.cgi?storeID=AMP&& ),
if you have a credit-card!
Anyway, with a good story, iForth is free.
Wanting (not necessarily succeeding) to bootstrap the essence of Lua in Forth
would be such a story.
-marcel
Bruce McFarling
wrote:
> The Forths that were mind-openers to me used bytecodes.
HS-Forth used lists of addresses to compiled words, not lists of byte
codes.
If you define a byte code for ENTER that starts executing a following
list of addresses, and a mechanism for terminating the list, its
certainly possible to mix the two, with byte codes for primitives and
colon definitions compiling a list of addresses. EG, with 16-bit
addresses on a little endian system, when the high byte if 0, the low
byte is a byte code executed in line. Then a byte code for EXIT in the
low byte completes the execution of the address list.