The most elegant Forth interpreter.

[Albert van der Horst]

There was a lecture about why "jonesforth is popular" at the
German ForthGesellschaft meeting. I now see that jonesforth is
not merely "well documented" but it gives insight by documenting
design decisions. This triggers me to think about ciforth in the
same way. The following "lecture" I will put on my site shortly.

The most elegant Forth interpreter
==================================

ciforth contains four improvements over classic indirect
threaded Forth's.

WORD replaced by NAME

WORD tried to save the following blank delimited word at the
right place in the off chance that it might be used as the
name of a new dictionary entry.
Instead NAME returns a constant string (address, length pair)
which is a substring of the input string, ending before a blank
or the end of input. A null address means that the input is
exhausted.

FIND replaced by FOUND

FIND tried to return a word plus all needed information.
Needless to say the information is no good after 40 years.

Instead FOUND returns a single address, an object so you will,
allowing to reach down to all information belonging to the word.
This is crucial, because in the following it will be clear that
more information is needed indeed. It is natural to have a null
pointer indicating that nothing was found.

>IN replaced by IN

>IN contains an offset in the input buffer. To get at an address
manipulations are needed.

IN contains an address in the input stream.

(NUMBER) replaced by PREFIX

The manner to blend in number recognition is highly system dependant.
Exemplified by the word (NUMBER) that may or may not exists.

PREFIX works in the following way. The word `` - '' in the minimal
search order is recognized as a prefix, i.e. if -12 is searched,
the PREFIX `` - '' is returned. The interpreter executes it, with the
input pointer just after the character &- . `` - '' converts the number and
negates it. (More formal descriptions in other posts.)
This allows not just for all kind of numbers, but for strings and
other compile-time constants ("denotations") as well.
It is user extensible in a portable way which is not the case with (NUMBER).

Now I did a discovery recently. It is natural to think of the
interpreter advancing by the length of the next blank delimited word
in the input stream. This means that we must back up whenever there is
a prefix, resulting in checking for a prefix and in conditional code in
the interpreter. If however we advance by the length of the word
found, possibly a prefix, we find ourselves directly at the correct
position.

The end result is the following bloody elegant interpret loop,
that is more powerful than the traditional loops that don't handle
numbers, and shorter as well.

\ System dependant: examples are from ciforth.
: immediate? ( dea .. flag) >FFA 4 AND ;
: name-lenght ( dea .. len) >NFA @ @ ;

\ All time smallest, fully competent Forth interpreter
: INTERPRET
BEGIN NAME OVER WHILE
OVER >R
FOUND ( DUP 0= 12 ?ERROR )
DUP name-length R> + IN !
immediate? STATE @ 0= OR IF EXECUTE ELSE , THEN ( ?STACK )
REPEAT 2DROP ;

The expense of taking care of denotations is 2 lines hidden in one of the
factors of FOUND.


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

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> There was a lecture about why "jonesforth is popular" ...

> ciforth contains four improvements over classic indirect

> threaded Forth's....

Those really do seem nicer than ANS, which looks kludgy by comparison.
Retroforth also looks clean.

But, I think Jonesforth's attraction is partly from explanations all the
way to the deepest, lowest level details. And the uninitiated seem to
like that it starts from assembly language--I guess the idea of
metacompilation comes later.

I've heard a few times that there is a version of cmforth annotated by
Jay Melvin around somewhere. I'd like to see it. Does anyone know
where to find it?

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> There was a lecture about why "jonesforth is popular" ...
>> ciforth contains four improvements over classic indirect
>> threaded Forth's....
>
> Those really do seem nicer than ANS, which looks kludgy by
> comparison.

But ANS isn't a Forth, it's a specification. You can't compare the
two. The map is not the territory.

> Retroforth also looks clean.
>
> But, I think Jonesforth's attraction is partly from explanations all the
> way to the deepest, lowest level details. And the uninitiated seem to
> like that it starts from assembly language--I guess the idea of
> metacompilation comes later.

I'm sure that it's possible to create a really clean and simple
implementation of ANS Forth in the spirit of fig-FORTH, but AFAIK
no-one has ever done it. ciforth gets closer than most.

Andrew.

[Albert van der Horst]

In article <rvednfZHdr8rQuHM...@supernews.com>,

This is the idea expressed at the German conference. It would be
nice to have a true ANS Forth listing in the vain of jonesforth,
with an approval stamp of a Forth chapter to set it apart from
just some random persons effort. (No offense mister Jones, we
really appreciate your work.) An initiative for a working group
is underway.

[The goal of ciforth (computer intelligence Forth) was to have
an introspective Forth, fit for a.i. ISO compatibility takes a
back seat, although gratitious differences were avoided.]

By the way, the interpreter I showed is not incompatible with ISO,
because different actions got different names. But it is not a
"ISO-loyal" implementation if WORD and FIND are loadable extension.

>
>Andrew.

[Andrew Haley]

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> In article <rvednfZHdr8rQuHM...@supernews.com>,
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>
>>I'm sure that it's possible to create a really clean and simple
>>implementation of ANS Forth in the spirit of fig-FORTH, but AFAIK
>>no-one has ever done it. ciforth gets closer than most.
>
> This is the idea expressed at the German conference. It would be
> nice to have a true ANS Forth listing in the vain of jonesforth,
> with an approval stamp of a Forth chapter to set it apart from just
> some random persons effort. (No offense mister Jones, we really
> appreciate your work.) An initiative for a working group is
> underway.

It would be good if it could follow the tradition of fig-FORTH in the
sense that it was written entirely in Forth rather than starting with
assembly language.

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> It would be good if it could follow the tradition of fig-FORTH in the
> sense that it was written entirely in Forth rather than starting with
> assembly language.

Was an all-Forth version of fig-FORTH ever released? All the versions
I've seen contain assembly code for the primitives, that apparently came
out of a disassembler after being metacompiled. I had wondered for a
while if it was handwritten assembly code.

[Ed]

Paul Rubin wrote:
> alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> > There was a lecture about why "jonesforth is popular" ...
> > ciforth contains four improvements over classic indirect
> > threaded Forth's....
>
> Those really do seem nicer than ANS, which looks kludgy by comparison.
> Retroforth also looks clean.

> ...

There is no free lunch so what's gained in one area is often paid for
in another. As minimal systems go, the classic Forth setup would be
difficult to beat.

If one doesn't need a bare bones system or be strictly ANS compliant
then one has room to manoeuvre and Albert has come up with some
innovative solutions to old problems. Forth could do with more
free thinkers.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> It would be good if it could follow the tradition of fig-FORTH in the
>> sense that it was written entirely in Forth rather than starting with
>> assembly language.
>
> Was an all-Forth version of fig-FORTH ever released?

Absolutely. That came first. I've got the source, but only on paper.

> All the versions I've seen contain assembly code for the primitives,
> that apparently came out of a disassembler after being metacompiled.
> I had wondered for a while if it was handwritten assembly code.

Sort of. fig-FORTH was written for the 6502 and metacompiled with a
Forth, Inc system. I don't know how the 6502 assembly code listing
was created, but it was binary-identical to the code generated by the
metacompiler, or very nearly so. Variants for all other processors
were hand-translated from the 6502 version.

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> Was an all-Forth version of fig-FORTH ever released?
> Absolutely. That came first. I've got the source, but only on paper.

Hmm, I wonder if it is online someplace.

> Sort of. fig-FORTH was written for the 6502... Variants for all other

> processors were hand-translated from the 6502 version.

Wow, interesting, that is news to me. I thought it had originated on
the IBM PC or maybe CP/M. It hadn't occurred to me to look at the 6502
version. Cool.

[Paul Rubin]

Paul Rubin <no.e...@nospam.invalid> writes:
> It hadn't occurred to me to look at the 6502 version.

I just checked out http://forth.org/fig-forth/fig-forth_6502.pdf
(warning, 22mb pdf). It is similar to the PC version I saw some time
ago, i.e. probably the output of a metacompiler.

I looked at Ting's book about F83 a while back too, and that seemed to
be a very complete system, though it used a lot of asm code. I wonder
how it was bootstrapped.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
>> It hadn't occurred to me to look at the 6502 version.
>
> I just checked out http://forth.org/fig-forth/fig-forth_6502.pdf
> (warning, 22mb pdf). It is similar to the PC version I saw some time
> ago, i.e. probably the output of a metacompiler.

Hmmm, it looks like the fig-FORTH model source is missing from
http://forth.org/fig-forth/contents.html. Maybe it really isn't
available anywhere. If so I can OCR the source and contribute it back
to forth.org, although my paper copy isn't very clean.

Andrew.

[Albert van der Horst]

In article <7x61z6d...@ruckus.brouhaha.com>,

Good man, all Forth's or for that matter all compilers must contain
assembly in one way or another. Some cheat (colorforth, retroforth)
by hard coding machine instructions in hex. That is not an advantage.

fig-Forth and ciforth allow one-stop-shopping by specifying Forth
code in assembler.
Result: my fasm source contains the following instructions for
a Forth compiler/scripter/interpreter:

fasm lina.fasm

Which is even more dramatic than

gas lina.s
ld -s -N a.out -o lina

Otoh, in order to use the gnu compiler collection on a new system,
(think of building gforth)
you need to download 80 M, expand to 700 megabyte, jump through numerous
hoops.

The assembler programmers are done, before you get a chance to have a faint
idea accross of how a Forth written in Forth is organized.

[jlarso...@gmail.com]

I have to agree -- JonesForth is an excellent tutorial on how to build a minimalist Forth system from scratch. In fact, it is so good, I felt compelled to port it to Windows so even more people can grok it!

I call my port JonesForthInC. It can be downloaded from here:

http://www.dst-corp.com/james/JonesForthInC-V148.html

There is included a binary executable for those who would like to start putzing with it straight away. And, if you happen to have Microsoft Visual C++ handy, you should be able to modify and recompile it without difficulty.

Further, this discussion has helped me make up my mind about further efforts to ANS-ify JonesForthInC -- perhaps my port is just fine the way it is?

So, have at it, Forth Fans.

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:

> Good man, all Forth's or for that matter all compilers must contain
> assembly in one way or another.

Of course, "one way or the other" doesn't mean that all ways are
equally preferable.

> Some cheat (colorforth, retroforth) by hard coding machine
> instructions in hex. That is not an advantage.

The "right" way to do it is code an assembler in Forth and use it. Then
you can bootsrap the assembler from an existing Forth, instead of the
other way around.

[the_gavino_himself]

what apps have been written in this forth?

[Sp...@controlq.com]

On Mon, 29 Apr 2013, Ed wrote:

> Date: Mon, 29 Apr 2013 12:31:08 +1000
> From: Ed <inv...@nospam.com>
> Newsgroups: comp.lang.forth
> Subject: Re: The most elegant Forth interpreter.

We have standards! Free thinking will NOT be tolerated.

Cheers,
Rob. 8-)

[Elizabeth D. Rather]

In the History of Forth (by me, Chuck, and Don Colburn),
http://www.forth.com/resources/evolution/index.html, Don described the
original development of figForth:

"Bill Ragsdale, a successful Bay Area security system manufacturer,
became aware of the benefits of microFORTH, and in 1978 asked FORTH,
Inc. to produce a version of microFORTH for the 6502. FORTH, Inc.
declined, seeing much less market demand for microFORTH on the 6502 than
the more popular 8080, Z80 and 6800 CPUs.

Ragsdale then looked for someone with the knowledge of microFORTH and
intimate familiarity with the 6502 to port a version of microFORTH to
the 6502. He found Maj. Robert Selzer, who had used microFORTH for an
AMI 6800 development system on an Army project and was privately
developing a standalone editor/assembler/linker package for the 6502.
Selzer wrote a 6502 Forth assembler, and used the Army's microFORTH
metacompiler to target compile the first 6502 stand-alone Forth for the
Jolt single board computer.

Selzer and Ragsdale subsequently made substantial modifications and
improvements to the model, including exploitation of page zero and
stack-implicit addressing architectural features in the 6502. Many of
the enhancements that characterized the later public-domain versions
were made during this period, including variable-length name fields and
modifications to the dictionary linked-list threading. A metacompiler on
the Jolt could target a significantly changed kernel to a higher address
in memory. A replacement bootable image would then be recompiled by the
new kernel into the lower boot address, which could then be written out
to disk. At this point, Ragsdale had a system with which to meet his
professional needs for embedded security systems.

During this period the Forth Interest Group (FIG) was started by
Ragsdale, Kim Harris, John James, David Boulton, Dave Bengel, Tom Olsen
and Dave Wyland [FIG 1978]. They introduced the concept of a "FIG Forth
Model," a publicly available Forth system that could be implemented on
popular computer architectures.

The FIG Forth Model was derived from Ragsdale's 6502 system. In order to
simplify publication and rapid implementation across a wide variety of
architectures, a translator was written to convert Forth metacompiler
source code into text that, when input to a standard 6502 assembler,
would replicate the original kernel image. In this way, neither the
metacompiler nor its source code needed to be published. This is an
important point. Forth metacompilation is a difficult process to
understand completely. It requires the direct manipulation of three
distinct execution phases and object areas, and is not something that a
casual user wanted or needed.

By publishing assembler listings, the Forth Interest Group was able to
encapsulate a Forth run-time environment in a manner that could be
easily replicated and/or translated to the assembly language of a
different computer architecture. It was the intention of the original
team of implementors to thus stimulate the development of compatible
Forth systems and the appearance of new vendors of Forth products."

Don helped in Selzer's portion of the project.

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."
==================================================

[Bernd Paysan]

Elizabeth D. Rather wrote:
> This is an
> important point. Forth metacompilation is a difficult process to
> understand completely. It requires the direct manipulation of three
> distinct execution phases and object areas, and is not something that a
> casual user wanted or needed.

IMHO this is the key issue why JonesForth is popular amongst newbies, while
we don't like it. Newbies have a hard time with cross compilers. A fig-
Forth listing takes them from what they know (assembler) to the unknown
territory step by step, without needing to understand the cross compiler
"magic". They don't understand the assembler magic, either, but they do
understand the assembler semantics.

In any case, the "assembler magic" is a lot less than the cross compiler
magic. However, the cross compiler is a lot *easier to use*, as you write
your code in a very Forth-like language.

There's also a lot of code duplication: The cross compiler needs to create
headers and compile control structures and all that stuff, which then is
again defined in the target. It probably would be much better if the
compiler source code could be reused.

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

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Elizabeth D. Rather wrote:
>> This is an important point. Forth metacompilation is a difficult
>> process to understand completely. It requires the direct
>> manipulation of three distinct execution phases and object areas,
>> and is not something that a casual user wanted or needed.
>
> IMHO this is the key issue why JonesForth is popular amongst
> newbies, while we don't like it. Newbies have a hard time with
> cross compilers. A fig- Forth listing takes them from what they
> know (assembler) to the unknown territory step by step, without
> needing to understand the cross compiler "magic". They don't
> understand the assembler magic, either, but they do understand the
> assembler semantics.

But you don't need a metacompiler to recompile fig-FORTH: it's only
necessary to point the dictionary at high memory, compile all the
words, and then tie off the base of the dictionary chains. Then,
point the dictionary back down at low memory and do the same thing
again. The only real advantage to the assembler approach is that of
bootstrapping.

Andrew.

[Rod Pemberton]

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

> alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:

> > Good man, all Forth's or for that matter all compilers must
> > contain assembly in one way or another.
>
> Of course, "one way or the other" doesn't mean that all ways are
> equally preferable.
>

If the bootstrap code is only used to bootstrap or initialize the
execution environment, why does it matter what was done? E.g., if
the hardcoded hex is only used to start the system and never used
again it has no effect on the Forth environment. It's just code
that's custom to the specific system to get it running.

> > Some cheat (colorforth, retroforth) by hard coding machine
> > instructions in hex. That is not an advantage.
>
> The "right" way to do it is code an assembler in Forth and use

> it. Then you can boots[t]rap the assembler from an existing

> Forth, instead of the other way around.

Most environments already have an existing toolchain. Why is that
you believe 'coding another assembler from scratch' is the correct
way to do it? Yes, unfortunately, the existing toolchain is
usually C and assembly.

The bootstrap for my Forth currently needs nine additional words
for bootstraping, plus six words for the runtime. Thats in
addition to the normally available Forth primitives, variables,
and constants which are used in the process of starting. The
bootstrap words are basically used just once. Most of the
bootstrap words are just repeats of existing Forth words. I.e.,
they are defined twice: once for bootstrap, once for the user.
Otherwise, they'd be circularly referenced...

I.e., the point is the bootstrap code is only a very minimal
addition to a functioning Forth system. So, one has to ask the
question: If bootstrapping is so simple, why cross-compiling or
meta-compiling used at all for Forth? (rhetorical, IMO)


Rod Pemberton

[Bernd Paysan]

Andrew Haley wrote:
> But you don't need a metacompiler to recompile fig-FORTH: it's only
> necessary to point the dictionary at high memory, compile all the
> words, and then tie off the base of the dictionary chains. Then,
> point the dictionary back down at low memory and do the same thing
> again. The only real advantage to the assembler approach is that of
> bootstrapping.

This approach allows only limited changes. Suppose you had fig-Forth in the
middle of the development process and you have still count+3 character
headers like in Forth Inc.'s Forth. Now you want to change that, and make
count+all character headers. What now?

Also, porting to another architecture isn't possible with this approach.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>> But you don't need a metacompiler to recompile fig-FORTH: it's only
>> necessary to point the dictionary at high memory, compile all the
>> words, and then tie off the base of the dictionary chains. Then,
>> point the dictionary back down at low memory and do the same thing
>> again. The only real advantage to the assembler approach is that of
>> bootstrapping.
>
> This approach allows only limited changes. Suppose you had
> fig-Forth in the middle of the development process and you have
> still count+3 character headers like in Forth Inc.'s Forth. Now you
> want to change that, and make count+all character headers. What
> now?

You'd need first to define a smarter dictionary search and words to
create the new format. I don't think you'd need to do anything else.
It's a hell of a lot easier than changing the headers in an assembly
code listing.

> Also, porting to another architecture isn't possible with this
> approach.

Well, yes. To cross-compiler you need a cross-compiler.

Andrew.

[Elizabeth D Rather]

On 4/29/2013 11:35 AM, Bernd Paysan wrote:
> Andrew Haley wrote:
>> But you don't need a metacompiler to recompile fig-FORTH: it's only
>> necessary to point the dictionary at high memory, compile all the
>> words, and then tie off the base of the dictionary chains. Then,
>> point the dictionary back down at low memory and do the same thing
>> again. The only real advantage to the assembler approach is that of
>> bootstrapping.
>
> This approach allows only limited changes. Suppose you had fig-Forth in the
> middle of the development process and you have still count+3 character
> headers like in Forth Inc.'s Forth. Now you want to change that, and make
> count+all character headers. What now?
>
> Also, porting to another architecture isn't possible with this approach.
>

FORTH, Inc. Forth hasn't been limited to count+3 for ~30 years.

However, it's true that there are some things that require a
metacompiler. They're complicated beasties to develop from scratch
(though quite easy to manage once you have one working). Folks wouldn't
have developed them unless they had a function to perform!

[lynx]

In <517e4c3e$0$6364$e4fe...@dreader35.news.xs4all.nl> alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:

>Good man, all Forth's or for that matter all compilers must contain
>assembly in one way or another. Some cheat (colorforth, retroforth)
>by hard coding machine instructions in hex. That is not an advantage.

On this point, some clarification: colorForth doesn't cheat at all. It
was designed from the outset to leverage the PC architecture only to
bootstrap a MISC-like VM. It also has a unique way of pre-parsing and
compiling its source. As such, "hard coding" is a requirement because
it was never seriously expected that the user would try to fully
utilize the PC architecture apart from a few choice pieces of hardware.
An assembler might be nice to have, but it would essentially be a waste
of effort considering its raison d'���tre.

[Andrew Haley]

Rod Pemberton <do_no...@notemailnotq.cpm> wrote:
> "Paul Rubin" <no.e...@nospam.invalid> wrote in message
> news:7xd2tdp...@ruckus.brouhaha.com...
>> alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>
>> > Good man, all Forth's or for that matter all compilers must
>> > contain assembly in one way or another.
>>

>> > Some cheat (colorforth, retroforth) by hard coding machine
>> > instructions in hex. That is not an advantage.
>>
>> The "right" way to do it is code an assembler in Forth and use
>> it. Then you can boots[t]rap the assembler from an existing
>> Forth, instead of the other way around.
>
> Most environments already have an existing toolchain. Why is that
> you believe 'coding another assembler from scratch' is the correct
> way to do it? Yes, unfortunately, the existing toolchain is
> usually C and assembly.

Not usually, no. That's an inflexible and rather clumsy way to do it.
It's a perfectly reasonable as a way to bootstrap a Forth, though, and
once you have a Forth running you can get rid of the C and assembly
scaffolding. Going via assembler was common enough among enthusiasts
in fig-FORTH days, but even back then the professional systems didn't
do it that way.

> I.e., the point is the bootstrap code is only a very minimal
> addition to a functioning Forth system. So, one has to ask the
> question: If bootstrapping is so simple, why cross-compiling or
> meta-compiling used at all for Forth? (rhetorical, IMO)

Because a Forth system isn't a fixed thing: it can be extended and
changed easily, as applications require. That's one of the things
that give Forth its character, although this isn't just a Forth thing:
some LISPs are writeen in LISP for the same reason.

For example, I once ran out of code space in a microcontroller
application. So, I changed from direct-threaded code to byte-token
threading. It took a little while to do and the resulting code was a
bit slower, but it fitted in the ROM. Doing this kind of thing in
Forth is fairly easy, and well within the reach of application
programmers: redefine the core of the interpreter, redefine a few
compiler words, and you're done.

Andrew.

[Bernd Paysan]

Elizabeth D Rather wrote:

> On 4/29/2013 11:35 AM, Bernd Paysan wrote:
> FORTH, Inc. Forth hasn't been limited to count+3 for ~30 years.

That was an example about how a cross-compiler helped during the development
of fig-Forth. microForth, the inspirational source of fig-Forth had
count+3, and that was changed during the development of fig-Forth.

> However, it's true that there are some things that require a
> metacompiler. They're complicated beasties to develop from scratch
> (though quite easy to manage once you have one working). Folks wouldn't
> have developed them unless they had a function to perform!

Indeed. The question here is if you could do a simpler metacompiler. E.g.
the b16 assembler is generating raw binary for a target, and by going the
machine Forth route, it's a hell lot easier than the Gforth cross compiler.
I wonder if that could be an approach to make meta-compiling easier. Or at
least easier to comprehend, as the b16 assembler is called "assembler" for
good reasons.

Actually, as it uses Forth as host, it is a macro-assembler, with Forth as
macro language. This allows to define words which put arbitrary data into
the target, like headers and such. So a full-featured Forth in b16
assembler would start with the definition of some macros that create headers
(in the target)+labels (on the host) instead of just creating labels on the
host.

[Elizabeth D. Rather]

This really depends on what kind of newbie you're catering to. A person
who wants to learn Forth can do so easiest with one of the free eval
versions of the professional systems, which tend to have a lot of user
aids plus extensive documentation. Once you learn to use Forth from such
a system, it's much easier to look at ways of writing your own, if
that's what you want to do.

For a person who wants to start by writing one from scratch, starting
with a familiar HLL (or assembler) is probably the most practical. Once
again, there are a lot of books, etc., that explain how the language
should work, and what the words are supposed to do, and do it in a
recognized way rather than the idiosyncratic functionality of Jonesforth.

Neither case really requires a cross-compiler. A cross-compiler is
necessary for the person who wants to support a Forth from the ground up
on multiple platforms. I think that's a pretty small subset of Forth users.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> Also, porting to another architecture isn't possible with this
>> approach.

> Well, yes. To cross-compile[r] you need a cross-compiler.

I don't understand the obstacle. Can't you

1. Write an assembler (in Forth) that assembles for the target system
2. Include it in the origin system along with the origin assembler,
3. Point dictionary at high memory and compile everything including
both assemblers (the origin assembler is needed to compile the
origin system's CODE words)
4. Remove the origin assembler from the system source and replace all
the CODE words with versions for the target system. Patch address
of CODE in the current origin system so that it uses the target
assembler.
5. Point dictionary at low memory and compile again
6. Dump resulting system from low memory to disk or otherwise
transfer it to target system.

There may be a little hair needed to make the target assembler run on
both systems if they have different word sizes or endianness, but that
seems like standard stuff.

Do I miss something?

[Elizabeth D. Rather]

On 4/29/13 8:20 PM, Paul Rubin wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> Also, porting to another architecture isn't possible with this
>>> approach.
>> Well, yes. To cross-compile[r] you need a cross-compiler.
>
> I don't understand the obstacle. Can't you
>
> 1. Write an assembler (in Forth) that assembles for the target system

Yes.

> 2. Include it in the origin system along with the origin assembler,

Yes, but you have to make sure you know which one CODE invokes when.

> 3. Point dictionary at high memory and compile everything including
> both assemblers (the origin assembler is needed to compile the
> origin system's CODE words)

Really, the thing is that you need to set up a buffer somewhere in which
to put the target system's kernel. Can be high memory, can be anywhere
your current code isn't occupying. It's a buffer whose origin is mapped
to the origin of address space you're compiling *for*.

> 4. Remove the origin assembler from the system source and replace all
> the CODE words with versions for the target system. Patch address
> of CODE in the current origin system so that it uses the target
> assembler.

You're now dealing with the source for the target system. It's a
different set of source files, rather than a matter of "removing" and
"patching".

> 5. Point dictionary at low memory and compile again

No, low memory is what you're running from (usually). Set your
compilation pointers to that target buffer. You need to fiddle your
memory pointers such that they're controlling your target memory address
but actually placing code in the buffer. In other words, you map your
buffer origin to the start of target memory, or something like that
(depending on what your target address space is like).

> 6. Dump resulting system from low memory to disk or otherwise
> transfer it to target system.

Yes.

> There may be a little hair needed to make the target assembler run on
> both systems if they have different word sizes or endianness, but that
> seems like standard stuff.

An assembler just generates certain binary patterns based on source
specifications. Doesn't matter what system it's running *on*, just that
it's putting correct target code in the buffer that will be launched by
the target system.

>
> Do I miss something?
>

Just all the gory details :-)

[Andrew Haley]

You seem to have described a cross-compiler.

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>> Also, porting to another architecture isn't possible with this
>>>> approach.
>>> Well, yes. To cross-compile[r] you need a cross-compiler.

>> I don't understand the obstacle. Can't you ...

> You seem to have described a cross-compiler.

In this case I don't understand the objection "porting to another
architecture isn't possible with this approach". It's the same approach
except the way I described it, there were temporarily two assemblers in
the system. But another moment of thought indicates (again unless I
miss something) that only the target assembler is needed. The origin
assembler only has to be in the executable that you start with. You
don't have to run the final executable on the origin system.

Anyway the scheme is fiendishly clever but relatively uncomplicated once
understood. Now I wonder why eforth didn't use it.

[Albert van der Horst]

In article <7xhaio5...@ruckus.brouhaha.com>,

Because the meta compilers themselves are never portable.
Assembly code is.
That is why Jones, Ting and I choose assembler. At least admit that it
is a defendable choice.

[Albert van der Horst]

In article <V5ednctF4ZPsleLM...@supernews.com>,

That is exactly what I did. ciforth 1.1 is just fig forth 8086 as per
co -r1.1 ci86.gnr

>
>Neither case really requires a cross-compiler. A cross-compiler is
>necessary for the person who wants to support a Forth from the ground up
>on multiple platforms. I think that's a pretty small subset of Forth users.

Tools like m4 allowed me to go multiple platform. It is possible, and if
I might say so, not totally impracticle.

>
>Cheers,
>Elizabeth

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>>> Also, porting to another architecture isn't possible with this
>>>>> approach.
>>>> Well, yes. To cross-compile[r] you need a cross-compiler.
>>> I don't understand the obstacle. Can't you ...
>> You seem to have described a cross-compiler.
>
> In this case I don't understand the objection "porting to another
> architecture isn't possible with this approach". It's the same approach
> except the way I described it, there were temporarily two assemblers in
> the system.

Not quite: there are also steps to ensure that none of the target code
is executed. Don't forget that the target system may have a different
endianness or word size.

The point about recompiling the kernel at a higher address is that
every target word is in the dictionary as soon as it is defined, and
will be executed if it is found. It's a live system, not an image
that will be run later.

Andrew.

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:

>> Now I wonder why eforth didn't use it.
> Because the meta compilers themselves are never portable.
> Assembly code is.

That presumes you've got a usable assembler for the target. Even if you
do, you then want one in Forth, so then you have two assemblers. Why
not just one?

> That is why Jones, Ting and I choose assembler. At least admit that it
> is a defendable choice.

I think Jones chose Forth to show bootstrapping from assembler. Eforth
does have a metacompiler but it's quite messy and complicated compared
to the Fig approach. Ting supposedly chose asm because he thought it
was easier for newbies to understand asm than metacompilation. There's
a rant about that somewhere on Jeff Fox's site. I'm not sure I
understand the portability argument about ciforth. For example, I don't
see how I'd target it to a new chip.

[Andrew Haley]

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> In article <7xhaio5...@ruckus.brouhaha.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:

>>Anyway the scheme is fiendishly clever but relatively uncomplicated
>>once understood. Now I wonder why eforth didn't use it.
>
> Because the meta compilers themselves are never portable.

They're as portable as they need to be. There's nothing at all to
prevent one from being written in standard Forth. It's just
generating a bunch of bytes, after all. Most people don't bother
because they're targeting Forth X from Forth X.

> Assembly code is.

It's only portable in the sense that it'll port to the exact same
assembly language on the same processor. That's a hell of a
definition of "portable".

> That is why Jones, Ting and I choose assembler. At least admit that it
> is a defendable choice.

In which case I'd like to see someone defend it. For bootstrapping
it's perefectly reasonable, but after that, no.

Andrew.

[Albert van der Horst]

In article <7xd2tc5...@ruckus.brouhaha.com>,

I can tell you what I did for the DEC Alpha. Change all pieces of assembler
code (I have few of them.) Change the macro for headers.
Run the build system, and there it is:
Forth interpreter, Forth compiler, tests, documentation.

[Coos Haak]

Op 30 Apr 2013 14:34:50 GMT schreef Albert van der Horst:

> In article <7xd2tc5...@ruckus.brouhaha.com>,
> Paul Rubin <no.e...@nospam.invalid> wrote:
>>alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>> Now I wonder why eforth didn't use it.
>>> Because the meta compilers themselves are never portable.
>>> Assembly code is.
>>
>>That presumes you've got a usable assembler for the target. Even if you
>>do, you then want one in Forth, so then you have two assemblers. Why
>>not just one?
>>
>>> That is why Jones, Ting and I choose assembler. At least admit that it
>>> is a defendable choice.
>>
>>I think Jones chose Forth to show bootstrapping from assembler. Eforth
>>does have a metacompiler but it's quite messy and complicated compared
>>to the Fig approach. Ting supposedly chose asm because he thought it
>>was easier for newbies to understand asm than metacompilation. There's
>>a rant about that somewhere on Jeff Fox's site. I'm not sure I
>>understand the portability argument about ciforth. For example, I don't
>>see how I'd target it to a new chip.
>
> I can tell you what I did for the DEC Alpha. Change all pieces of assembler
> code (I have few of them.) Change the macro for headers.
> Run the build system, and there it is:
> Forth interpreter, Forth compiler, tests, documentation.
>
> Groetjes Albert

On my ZX Spectrum I had no assembler, but there was a Forth.
Wrote an assembler for it, and a Metaforth (with a lot of help from
Vijgeblad 3,4,5). I it took some months, but I had my own Forth.
Same procedure for CHForth on the PC, based on someone else's Forth.
Metaforth is my tool. I could have done it with Masm or Tasm, too
complicated. At the moment, a few seconds will generate a new kernel.
My documentation consists mainly of a glossary. I generate help files from
the glossary comments in the source and can turn them into html (with a
Forth program of course).

Just checked, kernel + hlp files on 486 DX4 100 MHz 18 seconds, the rest 24
seconds. E800 3 GHz needs 1.1 and 2.0 seconds.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

[Bernd Paysan]

Andrew Haley wrote:

> Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>> Because the meta compilers themselves are never portable.
>
> They're as portable as they need to be. There's nothing at all to
> prevent one from being written in standard Forth. It's just
> generating a bunch of bytes, after all. Most people don't bother
> because they're targeting Forth X from Forth X.

Gforth's cross compiler at one time did run on bigForth, iForth, and Gforth.
We don't test that, so maybe it isn't portable anymore. But it once was.

> In which case I'd like to see someone defend it. For bootstrapping
> it's perefectly reasonable, but after that, no.

It's not too difficult to find a working Forth today, so for bootstrapping,
a cross compiler written in ANS Forth is "good enough".

IMHO the reasons why newbies find assembler listings attractive is that you
"bootstrap" the newbies. You start with something they understand (the
assembler), and then bottom-up explain them how other things work.

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> I can tell you what I did for the DEC Alpha. Change all pieces of assembler
> code (I have few of them.) Change the macro for headers.
> Run the build system, and there it is:
> Forth interpreter, Forth compiler, tests, documentation.

I think you are saying that you relied on an externally supplied
assembler and build environment for the Alpha, i.e. a bunch of complex
external software that had to be there before you could even get
started. By contrast, the metacompiling approach is completely
self-contained. All you need is some kind of boot loader to get a
runnable image onto the target chip.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> IMHO the reasons why newbies find assembler listings attractive is that you
> "bootstrap" the newbies. You start with something they understand (the
> assembler), and then bottom-up explain them how other things work.

I think you're right.

Andrew.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> It's not too difficult to find a working Forth today, so for bootstrapping,
> a cross compiler written in ANS Forth is "good enough".

I remember thinking that the proposed ANS cross-compilation extensions
really did make things easier, and I didn't see a way to do the same
stuff in vanilla ANS, though maybe there is one.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> You seem to have described a cross-compiler. ...

> Not quite: there are also steps to ensure that none of the target code
> is executed.

Can you tell me how this issue was handled?

> The point about recompiling the kernel at a higher address is that
> every target word is in the dictionary as soon as it is defined, and
> will be executed if it is found. It's a live system, not an image
> that will be run later.

I'm missing something here, do you mean the new definitions in high
memory are run instead of the old ones in low memory? What if they are
CODE words compiled for a completely different CPU?

I remember believing this was why Cmforth used separate dictionaries for
interpreting and compiling, though that may be a bogus inference on my
part. The idea was that the old words would still keep working while
the cross compilation was in progress, while new definitions would still
get compiled to the right thing. I'm wondering what other ways exist to
deal with this.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> Hmmm, it looks like the fig-FORTH model source is missing from
> http://forth.org/fig-forth/contents.html. Maybe it really isn't
> available anywhere. If so I can OCR the source and contribute it back
> to forth.org, although my paper copy isn't very clean.

I'd be interested in seeing this. Even if the OCR'd text is unreliable
or absent, the page scans (if legible) would be nice to have. At this
point in history, I think the code is of more interest as something to
read for the purpose of understanding the techniques, than as something
to actually run on a computer.

[Andrew Haley]

OK. I'll be busy for the weekend and next week, so feel free to
remind me.

Andrew.

[David Schultz]

On 04/29/2013 04:01 AM, Andrew Haley wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:
>> Paul Rubin <no.e...@nospam.invalid> writes:
>>> It hadn't occurred to me to look at the 6502 version.
>>
>> I just checked out http://forth.org/fig-forth/fig-forth_6502.pdf
>> (warning, 22mb pdf). It is similar to the PC version I saw some time
>> ago, i.e. probably the output of a metacompiler.

>
> Hmmm, it looks like the fig-FORTH model source is missing from
> http://forth.org/fig-forth/contents.html. Maybe it really isn't
> available anywhere. If so I can OCR the source and contribute it back
> to forth.org, although my paper copy isn't very clean.
>

> Andrew.
>

I dug out my paper copy I purchased way back when and tried to OCR the
first page of the listing. Although Vuescan has done an excellent job in
the past for me, this time it didn't do so well. Here is a sample:

OCR output:
( INPUT-OUTPUT, TIM HER-780519 )
cons EMIT XSAVE sTx, BOT 1+ LDA, 72 # AND,
7206 JSR, XSAVE Lnx, POP JHP,

corrected:
SCR # 6
0 ( INPUT-OUTPUT, TIM WFR-780519 )
1 CODE EMIT XSAVE STX, BOT 1+ LDA, 7F # AND,
2 72C6 JSR, XSAVE LDX, POP JMP,



--
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving

[David Schultz]

On 04/29/2013 04:01 AM, Andrew Haley wrote:
> Hmmm, it looks like the fig-FORTH model source is missing from
> http://forth.org/fig-forth/contents.html. Maybe it really isn't
> available anywhere. If so I can OCR the source and contribute it back
> to forth.org, although my paper copy isn't very clean.

I spent a little time with my scanner:

http://home.earthlink.net/~schultdw/tmp/model.zip
http://home.earthlink.net/~schultdw/tmp/model.pdf

The first is a collection of the scanner .tif files while in the second
I converted them to a pdf. It is still just scanned and not OCR'd.

Both are <800K.

There are still about 11 more pages in the document which cover a simple
editor but that is a project for another day.

[Paul Rubin]

David Schultz <ab...@127.0.0.1> writes:
> http://home.earthlink.net/~schultdw/tmp/model.pdf

Thanks! I notice it starts at SCR #6, does that mean the first page is
missing?

The parts I've looked at so far are pretty enlightening about seeing
words organized into screens. I don't (yet) see any clue about how the
metacompilation worked though.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> David Schultz <ab...@127.0.0.1> writes:
>> http://home.earthlink.net/~schultdw/tmp/model.pdf
>
> Thanks! I notice it starts at SCR #6, does that mean the first page is
> missing?

Yes. It's the tile page and some error messages.

> The parts I've looked at so far are pretty enlightening about seeing
> words organized into screens. I don't (yet) see any clue about how the
> metacompilation worked though.

It was a standard Forth Inc target compiler, but you don't need that.
Unless you're cross-compiling you can just recompile it.

Andrew.

[David Schultz]

On 05/11/2013 10:59 PM, Paul Rubin wrote:
> David Schultz <ab...@127.0.0.1> writes:
>> http://home.earthlink.net/~schultdw/tmp/model.pdf
>
> Thanks! I notice it starts at SCR #6, does that mean the first page is
> missing?
>

No. The page numbers are continuous and the previous page is the
glossary and not part of this listing.

The standard fig-FORTH disc system would have a series of error messages
starting at screen 4. If you go to screen #49 of the model listing you
will find the word that handles this. (ERROR)

[visua...@rocketmail.com]

On Monday, April 29, 2013 5:01:47 AM UTC-4, Andrew Haley wrote:
> Hmmm, it looks like the fig-FORTH model source is missing from
> http://forth.org/fig-forth/contents.html.
> Maybe it really isn't available anywhere.

Fig-FORTH 1.0 for BBC Micro (6502 Assembler) is available at
http://wiki.strotmann.de/wiki/Wiki.jsp?page=FigForth%20Source%20Listing

Dirk.

[Paul Rubin]

visua...@rocketmail.com writes:
> Fig-FORTH 1.0 for BBC Micro (6502 Assembler) is available at
> http://wiki.strotmann.de/wiki/Wiki.jsp?page=FigForth%20Source%20Listing

This appears to be metacompiler output. The Forth source just posted by
David Schultz was much harder to find.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> I don't (yet) see any clue about how the metacompilation worked
>> though.
> It was a standard Forth Inc target compiler, but you don't need that.
> Unless you're cross-compiling you can just recompile it.

For one thing, where is the assembler? I don't see it anywhere in
there. It's needed if we are to end up with something that can compile
itself.

[Andrew Haley]

It was later published in Forth Dimensions; I do not know why it
wasn't in the listing, but it may be because the original version
would only work within the Forth Inc target compiler.

http://wiki.strotmann.de/wiki/Wiki.jsp?page=ProjXForthAsm

Andrew.

[Andrew Haley]

http://wiki.strotmann.de/wiki/Wiki.jsp?page=6502%20Assembler%20in%20Forth

>
> Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> http://wiki.strotmann.de/wiki/Wiki.jsp?page=6502%20Assembler%20in%20Forth

Thanks, I like it. It has kind of a primal vigour about it, if you know
what I mean. I still don't understand how the metacompilation process
is supposed to work, but one thing at a time.

[dirk....@usa.net]

On Monday, April 29, 2013 6:56:27 PM UTC-4, Andrew Haley wrote:
> I once ran out of code space in a microcontroller application.
> So, I changed from direct-threaded code to byte-token threading.
> It took a little while to do and the resulting code was
> a bit slower, but it fitted in the ROM.
> Doing this kind of thing in Forth is fairly easy, and well
> within the reach of application programmers: redefine the core
> of the interpreter, redefine a few compiler words, and you're done.

Andrew, I started using Forth for microprocessor applications in 1984, and using Forth ever since, but following your description I am not an application programmer.

Is there any tutorial showing how changing from direct-threaded code to byte-token threading works?

I have to admit that for all my applications I always used ready made Forth, starting with RSC-Forth and using RSC-Forth until 65xx micros haven't been available anymore (the last one was Mitsubishi's M38049, to which I ported RSC-Forth), now using 4E4th for micros, using UR/Forth, FPC and Win32Forth for PCs.

Now I am looking for an opportunity to change 4E4th to byte-token threading.
I never wrote my own Forth.

Would be glad if you could help.

Thanks a lot in advance!

DB

[Mark Wills]

Here's a 9900 assembler written by yours truly:


--BLOCK-00009---------
\ TurboForth Assembler
' MOV,
: _ASM? ABORT" Assembler already in memory!" ;
_ASM? FORGET _ASM?

CR .( Compiling TMS9900 Assembler V1.0) .( Please wait...)
0 CONSTANT R0 1 CONSTANT R1
2 CONSTANT R2 3 CONSTANT R3
4 CONSTANT R4 5 CONSTANT R5
6 CONSTANT R6 7 CONSTANT R7
8 CONSTANT R8 9 CONSTANT R9
10 CONSTANT R10 11 CONSTANT R11
12 CONSTANT R12 13 CONSTANT R13
14 CONSTANT R14 15 CONSTANT R15

-->

--BLOCK-00010---------
: ASM: BL WORD HEADER HERE 2+ , LATEST @ HIDDEN ;
: ;ASM $045C , LATEST @ HIDDEN ;
: ?PAIRS XOR ABORT" Conditionals not paired" ;
: ERROR CR ." Block " BLK @ . ." line " >IN @ 64 / .
1 2 ?PAIRS ;
HEX
: GOP' OVER DUP 1F > SWAP 30 < AND IF + , , ELSE + , THEN ;
: GOP CREATE , DOES> @ GOP' ;
0440 GOP B, 0680 GOP BL, 0400 GOP BLWP,
04C0 GOP CLR, 0700 GOP SETO, 0540 GOP INV,
0500 GOP NEG, 0740 GOP ABS, 06C0 GOP SWPB,
0580 GOP INC, 05C0 GOP INCT, 0600 GOP DEC,
0640 GOP DECT, 0480 GOP X,


-->

--BLOCK-00011---------
: GROP CREATE , DOES> @ SWAP 40 * + GOP' ;
2000 GROP COC, 2400 GROP CZC, 2800 GROP XOR,
3800 GROP MPY, 3C00 GROP DIV, 2C00 GROP XOP,

: GGOP CREATE , DOES> @ SWAP DUP DUP 1F > SWAP 30 < AND
IF 40 * + SWAP >R GOP' R> , ELSE 40 * + GOP' THEN ;
A000 GGOP A, B000 GGOP AB, 8000 GGOP CMP, 9000 GGOP CB,
6000 GGOP S, 7000 GGOP SB, E000 GGOP SOC, F000 GGOP SOCB,
4000 GGOP SZC, 5000 GGOP SZCB, C000 GGOP MOV, D000 GGOP MOVB,

: 0OP CREATE , DOES> @ , ;
0340 0OP IDLE, 0360 0OP RSET, 03C0 0OP CKOF,
03A0 0OP CKON, 03E0 0OP LREX, 0380 0OP RTWP,


-->

--BLOCK-00012---------
: ROP CREATE , DOES> @ + , ; 02C0 ROP STST, 02A0 ROP STWP,
: IOP CREATE , DOES> @ , , ; 02E0 IOP LWPI, 0300 IOP LIMI,
: RIOP CREATE , DOES> @ ROT + , , ;
0220 RIOP AI, 0240 RIOP ANDI, 0280 RIOP CI, 0200 RIOP LI,
0260 RIOP ORI,
: RCOP CREATE , DOES> @ SWAP 10 * + + , ;
0A00 RCOP SLA, 0800 RCOP SRA, 0B00 RCOP SRC, 0900 RCOP SRL,

: DOP CREATE , DOES> @ SWAP 00FF AND OR , ;
1300 DOP JEQ, 1500 DOP JGT, 1B00 DOP JH, 1400 DOP JHE,
1A00 DOP JL, 1200 DOP JLE, 1100 DOP JLT, 1000 DOP JMP,
1700 DOP JNC, 1600 DOP JNE, 1900 DOP JNO, 1800 DOP JOC,
1C00 DOP JOP, 1D00 DOP SBO, 1E00 DOP SBZ, 1F00 DOP TB,

: GCOP CREATE , DOES> @ SWAP 000F AND 40 * + GOP' ;
3000 GCOP LDCR, 3400 GCOP STCR, -->

--BLOCK-00013---------
: @() 020 ; : *? 010 + ; : *?+ 030 + ;
: @(?) 020 + ; : W 06 ; : @(W) W @(?) ;
: *W W *? ; : *W+ W *?+ ; : RP 05 ;
: @(RP) RP @(?) ; : *RP RP *? ; : *RP+ RP *?+ ;
: IP 03 ; : @(IP) IP @(?) ; : *IP IP *? ;
: *IP+ IP *?+ ; : SP 04 ; : @(SP) SP @(?) ;
: *SP SP *? ; : *SP+ SP *?+ ; : NXT 0C ;
: *NXT+ NXT *?+ ; : *NXT NXT *? ; : @(NXT) NXT @(?) ;
: GTE 1 ; : HI 2 ; : NE 3 ; : LO 4 ; : LTE 5 ; : EQ 6 ;
: OC 7 ; : NC 8 ; : OO 9 ; : HE 0A ; : LE 0B ; : NP 0C ;
: LT 0D ; : GT 0E ; : NO 0F ; : OP 10 ;
: CJMP CASE LT OF 1101 , 0 ENDOF GT OF 1501 , 0 ENDOF
NO OF 1901 , 0 ENDOF OP OF 1C01 , 0 ENDOF
DUP 0< OVER 10 > OR IF ERROR THEN DUP
ENDCASE 100 * 1000 + , ;
-->

--BLOCK-00014---------
: IF, CJMP HERE 2- 42 ; IMMEDIATE
: ENDIF, 42 ?PAIRS HERE OVER - 2- 2/ SWAP 1+ C! ; IMMEDIATE
: ELSE, 42 ?PAIRS 0 CJMP HERE 2- SWAP 42 [COMPILE] ENDIF,
42 ; IMMEDIATE
: BEGIN, HERE 41 ; IMMEDIATE
: UNTIL, SWAP 41 ?PAIRS CJMP HERE - 2/ 00FF AND HERE 1- C!
; IMMEDIATE
: AGAIN, 0 [COMPILE] UNTIL, ; IMMEDIATE
: REPEAT, >R >R [COMPILE] AGAIN, R> R> 2- [COMPILE] ENDIF,
; IMMEDIATE
: WHILE, [COMPILE] IF, 2+ ; IMMEDIATE
\ Wycove assembler register syntax:
: @@ @() ; : ** *? ; : *+ *?+ ; : () @(?) ;
: RT R11 ** B, ; DECIMAL
.( Assembler loaded.)
.( See http://turboforth.net/assembler.html)

[m.a.m....@tue.nl]

On Saturday, April 27, 2013 11:13:07 AM UTC+2, Albert van der Horst wrote:
> There was a lecture about why "jonesforth is popular" at the German
> ForthGesellschaft meeting. I now see that jonesforth is not merely "well
> documented" but it gives insight by documenting design decisions.
> This triggers me to think about ciforth in the same way. The
> following "lecture" I will put on my site shortly. The most elegant
> Forth interpreter

"Elegance is for tailors," as Julian used to say.

-marcel

[Paul Rubin]

dirk....@usa.net writes:
> Is there any tutorial showing how changing from direct-threaded code
> to byte-token threading works?

I think the basic idea is:

- change the address interpreter into a bytecode interpreter. For
example, assign a 1-byte code to the 128 most commonly used words
(numbering them 0-127 so that they fit in 7 bits of the byte).

- Modify the compiler to also recognize those words and emit those
codes. For the less common words, emit two bytes: the first one
with the high bit set, and the remaining 15 bits used for the
actual address of the word. That lets you address up to 32k.

> Now I am looking for an opportunity to change 4E4th to byte-token
> threading. I never wrote my own Forth.

I don't know if the approach is that useful for 4e4th given the amount
of native machine code in camlforth, and the quite limited memory of the
430/2553 processor even by Forth standards.

The MSP430 Launchpad itself is no longer as attractive as it used to be
either. For one thing, its price has more than doubled, so 4e4th would
have to change its name (if not its abbreviation). There are now a
number of comparably cheap but somewhat more flexible ARM boards that
would make better targets, from Freescale and STM and others as well.

[visua...@rocketmail.com]

On Friday, May 17, 2013 10:02:03 PM UTC-4, Paul Rubin wrote:
> dirk....@usa.net writes:
> > Is there any tutorial showing how changing from direct-threaded code
> > to byte-token threading works?
>
> I think the basic idea is:
> - change the address interpreter into a bytecode interpreter.

Sorry, but that reminds me when I was told that changing the motor of the VW1200 it only needs to remove four screws.

> For example, assign a 1-byte code to the 128 most commonly used words
> (numbering them 0-127 so that they fit in 7 bits of the byte).

I had this idea, too. I wrote a virtual engine in 1978 for the 6502 because I didn't like to type all these subroutine calls. Worked well because I had only 200 something subroutines.

> - Modify the compiler to also recognize those words and emit those
> codes.

Part two of changing the motor by removing four screws.

> For the less common words, emit two bytes: the first one
> with the high bit set, and the remaining 15 bits used for the
> actual address of the word. That lets you address up to 32k.

That's the trick I was looking for. I didn't find a solution to address more than 256 words only using one byte. That means, all application words will need 2 Bytes. That's interesting for portability, has some time penalty.

May be using vocabularies can extend the use of one byte codes?

> > Now I am looking for an opportunity to change 4E4th to byte-token
> > threading. I never wrote my own Forth.

And I never changed the motor of a VW1200.

> I don't know if the approach is that useful for 4e4th given the amount

> of native machine code in camelforth, and the quite limited memory of the

> 430/2553 processor even by Forth standards.

Thanks for this praise of CamelForth!

On Monday, April 29, 2013 6:56:27 PM UTC-4, Andrew Haley wrote:
> I once ran out of code space in a microcontroller application.

> So, I changed from direct-threaded code to byte-token threading.

That's why I asked for advice.

Paul, you are writing now "I don't know if the approach is that useful for 4e4th given ... the quite limited memory of the 430/2553 processor"
That's some kind of contradiction, I guess.

> The MSP430 Launchpad itself is no longer as attractive as it used to be
> either. For one thing, its price has more than doubled, so 4e4th would
> have to change its name (if not its abbreviation).

4E4th started as 4€-Forth - which was possible back then and a great opportunity a lot of educators took advantage of.

But as it was not possible to establish a http://www.4 €4th.eu website, so instead http://www.4e4th.eu was chosen, and 4E4th - Forth for Education was born.

You can read the whole story at
http://www.complang.tuwien.ac.at/anton/euroforth/ef12/papers/bruehl.pdf

> There are now a number of comparably cheap but somewhat more flexible
> ARM boards that would make better targets, from Freescale and STM
> and others as well.

You are welcome to join us and offer a free Forth for Education for these boards.

There are some requirements:
- There has to be a free flasher which can be integrated into the 4E4th-IDE.
- Programming has to be done directly to Flash.
- To synchronize target and IDE, some prompt extensions have to be made: for base recognition (needed for the cross-assembler) and for error recognition.

The 4E4th-IDE.exe - see http://www.4e4th-IDE.org - including Flasher, Editor and Cross-Assembler only needs 1MB on disk, much less than other IDEs (IAR needs 1GB on disk).

[Paul Rubin]

visua...@rocketmail.com writes:
> That's the trick I was looking for. I didn't find a solution to
> address more than 256 words only using one byte. That means, all
> application words will need 2 Bytes. That's interesting for
> portability, has some time penalty.

Maybe you could assign 64 of the 1-byte codes to system words and leave
the other 64 for user words. Or steal another bit or two, e.g. have
192 1-byte codes (0x00 - 0xBF) so that 11 in the upper two bits means
the next 14 bits are the address, giving you 16k addressible, etc.

But, the extra program space needed to deal with this complexity and
have the lookup tables from byte tokens to addresses might not be worth
it in the launchpad.

> On Monday, April 29, 2013 6:56:27 PM UTC-4, Andrew Haley wrote:

>> I once ran out of code space in a microcontroller application....

> Paul, you are writing now "I don't know if the approach is that useful
> for 4e4th given ... the quite limited memory of the 430/2553
> processor" That's some kind of contradiction, I guess.

I'm imagining Andrew was using a somewhat bigger processor than the
Launchpad's, but I don't know. You lose some space for the interpreter
itself, but then gain it back through the more compact instruction
coding, if the program is big enough.

I think Brad Rodriguez has some pages someplace explaining token
threading.

>> ARM boards that would make better targets, from Freescale and STM

> You are welcome to join us and offer a free Forth for Education for
> these boards.

No problem, I'll add it to my very long list of things to do in my
nonexistent free time. ;-)

> The 4E4th-IDE.exe - see http://www.4e4th-IDE.org - including Flasher,
> Editor and Cross-Assembler only needs 1MB on disk, much less than
> other IDEs (IAR needs 1GB on disk).

Sounds nice but it's Windows-only? I'd want something like this to run
in completely FOSS systems.

[Bill Leary]

wrote in message
news:c2ddf12d-0459-49d9...@googlegroups.com...

> On Friday, May 17, 2013 10:02:03 PM UTC-4, Paul Rubin wrote:
>> dirk....@usa.net writes:
>>> Is there any tutorial showing how changing from direct-threaded
>>> code to byte-token threading works?
>>
>> I think the basic idea is:
>> - change the address interpreter into a bytecode interpreter.
>
> Sorry, but that reminds me when I was told that changing the motor
> of the VW1200 it only needs to remove four screws.

This isn't true, but it appears that you knew that and are trying to make a
point. Perhaps it's worthwhile to point out that in addition to with those
four bolts, which really are all that holds the engine in the car, there are
about dozen more steps, including a couple that, if you miss them, you end
up with an engine on the floor of the garage.

Nice analogy, by the way, if one understands what's really required to pull
a VW air cooled (including the 1200) engine.

- Bill

[Andrew Haley]

dirk....@usa.net wrote:
> On Monday, April 29, 2013 6:56:27 PM UTC-4, Andrew Haley wrote:
>> I once ran out of code space in a microcontroller application.
>> So, I changed from direct-threaded code to byte-token threading.
>> It took a little while to do and the resulting code was
>> a bit slower, but it fitted in the ROM.
>> Doing this kind of thing in Forth is fairly easy, and well
>> within the reach of application programmers: redefine the core
>> of the interpreter, redefine a few compiler words, and you're done.
>
> Andrew, I started using Forth for microprocessor applications in
> 1984, and using Forth ever since, but following your description I
> am not an application programmer.
>
> Is there any tutorial showing how changing from direct-threaded code
> to byte-token threading works?

I don't think so, but you never know.

> I have to admit that for all my applications I always used ready
> made Forth, starting with RSC-Forth and using RSC-Forth until 65xx
> micros haven't been available anymore (the last one was Mitsubishi's
> M38049, to which I ported RSC-Forth), now using 4E4th for micros,
> using UR/Forth, FPC and Win32Forth for PCs.
>
> Now I am looking for an opportunity to change 4E4th to byte-token
> threading. I never wrote my own Forth.
>
> Would be glad if you could help.
>
> Thanks a lot in advance!

Hmm, it's a lot easier to do this kind of thing than describe it. How
easy it is to depends on the threading model the Forth uses.

Andrew.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:

> visua...@rocketmail.com writes:
>
>> On Monday, April 29, 2013 6:56:27 PM UTC-4, Andrew Haley wrote:
>>> I once ran out of code space in a microcontroller application....
>> Paul, you are writing now "I don't know if the approach is that useful
>> for 4e4th given ... the quite limited memory of the 430/2553
>> processor" That's some kind of contradiction, I guess.
>
> I'm imagining Andrew was using a somewhat bigger processor than the
> Launchpad's, but I don't know.

I was using an 8051 with 4kbytes of ROM (and 128 bytes of RAM). The
bytecode threading meant that the production run would fit into an
8051 rather than an 8052. Quite a bit of logic will fit in 4k with
this technique.

Andrew.

[visua...@rocketmail.com]

On Saturday, May 18, 2013 6:15:30 AM UTC-4, Bill Leary wrote:

> >> dirk....@usa.net writes:
> > Sorry, but that reminds me when I was told that changing the motor
> > of the VW1200 it only needs to remove four screws.

> This isn't true, but it appears that you knew that and are trying to make a
> point. Perhaps it's worthwhile to point out that in addition to with those
> four bolts, which really are all that holds the engine in the car, there are
> about dozen more steps, including a couple that, if you miss them, you end
> up with an engine on the floor of the garage.

It's nearly fifty years ago that somebody told me how easy it is to change a VW1200 motor (the car which I had back then for decades) by removing four screws, but he forgot to tell me the rest of it - he assumed if he can do it, everybody can do it, I guess. That's the point I tried to make.

Thanks for telling me the missing part of the story!

> Nice analogy, by the way, if one understands what's really required to pull
> a VW air cooled (including the 1200) engine.

Thanks for your understanding and explaining!
- Dirk
> - Bill

[visua...@rocketmail.com]

On Saturday, May 18, 2013 1:32:23 AM UTC-4, Paul Rubin wrote:
> Sounds nice but it's Windows-only? I'd want something like this to run
> in completely FOSS systems.

Google tells me FOSS is a research-based science program for grades K–8.
The 4E4th-IDE - Forth for Education - is targeted at grades K-8.

The 4E4th-IDE does not only run under Windows, it runs under Linux, too.

[visua...@rocketmail.com]

On Saturday, May 18, 2013 8:50:51 AM UTC-4, Andrew Haley wrote:
> I was using an 8051 with 4kbytes of ROM (and 128 bytes of RAM). The
> bytecode threading meant that the production run would fit into an
> 8051 rather than an 8052. Quite a bit of logic will fit in 4k with
> this technique.

This sounds amazing. That's just what I am looking for!
Is this public domain or proprietary?

Do you still have the source code?

May be I am able to analyze your source code - would you allow to use it for educational purposes?

Best Regards,
Dirk.

[Andrew Haley]

visua...@rocketmail.com wrote:
> On Saturday, May 18, 2013 8:50:51 AM UTC-4, Andrew Haley wrote:
>> I was using an 8051 with 4kbytes of ROM (and 128 bytes of RAM). The
>> bytecode threading meant that the production run would fit into an
>> 8051 rather than an 8052. Quite a bit of logic will fit in 4k with
>> this technique.
>
> This sounds amazing. That's just what I am looking for!
> Is this public domain or proprietary?

Proprietary, but given an existing Forth I can tell you how to do it.

> Do you still have the source code?
>
> May be I am able to analyze your source code - would you allow to
> use it for educational purposes?

Sorry, I haven't got the source and it was about twenty years ago.

Andrew.

[visua...@rocketmail.com]

On Saturday, May 18, 2013 2:38:38 PM UTC-4, Andrew Haley wrote:
> ... given an existing Forth I can tell you how to do it.

"given an existing Forth" - what do you need to be given?
Would 4e4th be okay? The 4e4th core is written at
http://www.forth-ev.de/repos/4e4th/4e-core430G2553.s43

Please tell how to do it.

Dirk.

[Bernd Paysan]

visua...@rocketmail.com wrote:

> On Saturday, May 18, 2013 1:32:23 AM UTC-4, Paul Rubin wrote:
>> Sounds nice but it's Windows-only? I'd want something like this to run
>> in completely FOSS systems.
>
> Google tells me FOSS is a research-based science program for grades K–8.

Nah, FOSS is "Free Open Source Software". And in my filter bubble, Google
tells me just that (with the first hit).

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

[visua...@rocketmail.com]

On Saturday, May 18, 2013 1:32:23 AM UTC-4, Paul Rubin wrote:

> Sounds nice but it's Windows-only? I'd want something like this to run
> in completely FOSS systems.

Thanks to Bernd I have been enlightened that the FOSS you mentioned stands not for educational purposes, but for free software.

I am waiting for a FOS - a ForthOS with a graphical user interface, then the 4E4th-IDE will be available for FOS.

Is it okay for you when meanwhile the 4E4th-IDE is running under Linux?

DB

"We are totally tolerant as long as the other behaves as expected"

[Andrew Haley]

Ouch. That Forth isn't written in Forth, but in assembly language.
This is going to make it painful to change. Why do people do this?
:-(

; ITC NEXT is defined as
; MOV @IP+,W ; 2 fetch word address into W
; MOV @W+,PC ; 2 fetch code address into PC, W=PFA

You'll need to add an indirection here. Something like

MOV.B @IP+,Y
MOV @Y,W
MOV @W+,PC

And you'll have to create a table at the bottom of memory that
contains a pointer to every word. That's going to be the tricky part:
the idea is that CREATE allocates a table index and creates the entry.

For the high level code, consider something like this:

;Z ?NEGATE n1 n2 -- n3 negate n1 if n2 negative
; 0< IF NEGATE THEN ; ...a common factor
HEADER QNEGATE,7,'?NEGATE',DOCOLON
DW ZEROLESS,qbran
DEST QNEG1
DW NEGATE
QNEG1: DW EXIT

You'll have to change all of those "DW" pseudo-ops to "DB" where each
one is the table index of each word rather than a pointer to it.
Depending on how powerful this assembler is, it might be possible to
create a macro that does it.

Andrew.

[Albert van der Horst]

In article <7xfvy8a...@ruckus.brouhaha.com>,
Paul Rubin <no.e...@nospam.invalid> wrote:
>alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> I can tell you what I did for the DEC Alpha. Change all pieces of assembler
>> code (I have few of them.) Change the macro for headers.
>> Run the build system, and there it is:
>> Forth interpreter, Forth compiler, tests, documentation.
>
>I think you are saying that you relied on an externally supplied
>assembler and build environment for the Alpha, i.e. a bunch of complex
>external software that had to be there before you could even get
>started. By contrast, the metacompiling approach is completely
>self-contained. All you need is some kind of boot loader to get a
>runnable image onto the target chip.

Maybe if you want to run on a bare Alpha, do you?
On a Linux Dec Alpha it isn't true, and that was my example.
If you want to generate a runable executable on the
DEC Alpha from scratch, you have to spend more time on that subject
alone than I have spend on the whole enchilada.
Relying on the assembler and linker on the DEC Alpha is the sensible
thing to do. Rewriting them from the barely existing docs in order
to generate one Forth executable is insanity.
--
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

[visua...@rocketmail.com]

On Sunday, May 19, 2013 5:12:59 AM UTC-4, Andrew Haley wrote:

> visualforth.com wrote:
> > On Saturday, May 18, 2013 2:38:38 PM UTC-4, Andrew Haley wrote:
> >> ... given an existing Forth I can tell you how to do it.
> > "given an existing Forth" - what do you need to be given?
> > Would 4e4th be okay? The 4e4th core is written at
> > http://www.forth-ev.de/repos/4e4th/4e-core430G2553.s43
> > Please tell how to do it.

> Ouch. That Forth isn't written in Forth, but in assembly language.
> This is going to make it painful to change. Why do people do this?
> :-(

I guess this is for two reasons:
1. To get the resulting Forth work
2. To get the resulting Forth run fast

> And you'll have to create a table at the bottom of memory that
> contains a pointer to every word. That's going to be the tricky part:
> the idea is that CREATE allocates a table index and creates the entry.

That's how I have built my own virtual engine in 1978 using 6502 machine code, before I heard about Forth. So that's not a problem for me - may be I should try this with a 6502 micro because that's one of the micros I am familiar with (the other one is the RX2000).

> For the high level code, consider something like this:

With other words - it will be better to write my own Forth!

> Depending on how powerful this assembler is, it might be possible to
> create a macro that does it.

I guess the best thing is to use our cross-assembler written in Forth and add those words which will be needed.

A while ago I had the idea it would be great to have three layers of Forth:

The lowest layer is the machine dependent layer, which can use a variety of methods to be programmed (different kinds of threading etc). There should be a minimum word set which is really standardized. This layer would make it possible to port different Forth versions on different microprocessors without the need of using machine language or assembler.

The next layer is a high level Forth layer which should be standardized, but can be available in different versions, too. Having the lowest layer available, this layer is machine independent and can be run on any microcomputer for which the lowest layer is available.

The third layer is the application layer which is written for the specific application. Because of having a standardized medium layer, this application can be run on all Forth systems following this strategy - only hardware specific parts have to be ported, which shouldn't be a problem in this case.

To not to confuse with a lot of different Forth versions, all applications and all standard deviations should run under special vocabularies, i.e. vocabulary names - this will be the fence between the standard and the extension.

May be there is such a Forth available, I don't know. It would help newcomers to use applications which are already written instead of starting from scratch.

DB

[Clyde W. Phillips Jr.]

I based my fig that I ported to ARM on figforth8088.zip

Find it, and lots of other source at:

ftp://ftp.forth.org/pub/Forth/compilers/native/dos/

Cheers, Clyde

[Paul Rubin]

visua...@rocketmail.com writes:
> Is it okay for you when meanwhile the 4E4th-IDE is running under Linux?

That would be great.

[visua...@rocketmail.com]

On Sunday, May 19, 2013 11:41:03 PM UTC-4, Paul Rubin wrote:

> visualforth.com writes:
> > Is it okay for you when meanwhile the 4E4th-IDE is running under Linux?

> That would be great.

Four weeks ago, in Garmisch-Partenkirchen at the annual Forth Conference of the German Forth Society, Carsten Strotmann showed that the 4E4th-IDE runs perfect under Linux with Wine.

[Andrew Haley]

visua...@rocketmail.com wrote:
> On Sunday, May 19, 2013 5:12:59 AM UTC-4, Andrew Haley wrote:
>> visualforth.com wrote:
>> > On Saturday, May 18, 2013 2:38:38 PM UTC-4, Andrew Haley wrote:
>> >> ... given an existing Forth I can tell you how to do it.
>> > "given an existing Forth" - what do you need to be given?
>> > Would 4e4th be okay? The 4e4th core is written at
>> > http://www.forth-ev.de/repos/4e4th/4e-core430G2553.s43
>> > Please tell how to do it.
>
>> Ouch. That Forth isn't written in Forth, but in assembly language.
>> This is going to make it painful to change. Why do people do this?
>> :-(
>
> I guess this is for two reasons:
> 1. To get the resulting Forth work
> 2. To get the resulting Forth run fast

Eh? I don't understand what you mean.

>> For the high level code, consider something like this:
>
> With other words - it will be better to write my own Forth!

Or this.

Andrew.

[Anton Ertl]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <7xfvy8a...@ruckus.brouhaha.com>,
>Paul Rubin <no.e...@nospam.invalid> wrote:
>>I think you are saying that you relied on an externally supplied
>>assembler and build environment for the Alpha, i.e. a bunch of complex
>>external software that had to be there before you could even get
>>started. By contrast, the metacompiling approach is completely
>>self-contained. All you need is some kind of boot loader to get a
>>runnable image onto the target chip.
>
>Maybe if you want to run on a bare Alpha, do you?
>On a Linux Dec Alpha it isn't true, and that was my example.
>If you want to generate a runable executable on the
>DEC Alpha from scratch, you have to spend more time on that subject
>alone than I have spend on the whole enchilada.
>Relying on the assembler and linker on the DEC Alpha is the sensible
>thing to do. Rewriting them from the barely existing docs in order
>to generate one Forth executable is insanity.

Or you do what Paul suggested: Write a boot loader that uses the
existing tool and loads the Forth image to the desired place. That
image can be made with the traditional metacompilation approach. I
think iForth uses that approach.

- 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 2013: http://www.euroforth.org/ef13/

[Albert van der Horst]

In article <2013May2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In article <7xfvy8a...@ruckus.brouhaha.com>,
>>Paul Rubin <no.e...@nospam.invalid> wrote:
>>>I think you are saying that you relied on an externally supplied
>>>assembler and build environment for the Alpha, i.e. a bunch of complex
>>>external software that had to be there before you could even get
>>>started. By contrast, the metacompiling approach is completely
>>>self-contained. All you need is some kind of boot loader to get a
>>>runnable image onto the target chip.
>>
>>Maybe if you want to run on a bare Alpha, do you?
>>On a Linux Dec Alpha it isn't true, and that was my example.
>>If you want to generate a runable executable on the
>>DEC Alpha from scratch, you have to spend more time on that subject
>>alone than I have spend on the whole enchilada.
>>Relying on the assembler and linker on the DEC Alpha is the sensible
>>thing to do. Rewriting them from the barely existing docs in order
>>to generate one Forth executable is insanity.
>
>Or you do what Paul suggested: Write a boot loader that uses the
>existing tool and loads the Forth image to the desired place. That
>image can be made with the traditional metacompilation approach. I
>think iForth uses that approach.

So much for not relying on an "externaly supplied .... build environment
for the Alpha".

>
>- anton

Groetjes Albert

[Bernd Paysan]

Anton Ertl wrote:
> Or you do what Paul suggested: Write a boot loader that uses the
> existing tool and loads the Forth image to the desired place. That
> image can be made with the traditional metacompilation approach. I
> think iForth uses that approach.

bigForth also uses that approach. The boot loader also provides some basic
tools like console I/O, so that you can easily debug your image.

On the Atari ST, where I didn't have "existing tools" (just Forth, nothing
but Forth), the boot loader was generated from Forth with the Forth
assembler. The TOS execution format wasn't too difficult (similar to MS-DOS
.com, but with a simple relocation table ;-), and the boot loader (on TOS
without the I/O stuff) was just 1k, and since it was fully PC-relative, it
didn't need the relocation table.

On all other versions of bigForth, I used some existing tools.

[Matthias Koch]

> I based my fig that I ported to ARM on figforth8088.zip

Dear Clyde,

could you please point me to a copy of your FIG-for-ARM ?

I searched for it, but I couldn't find it here:
ftp://ftp.forth.org/pub/Forth/compilers/native/misc/

Matthias

[alberhe...@gmail.com]

On Saturday, April 27, 2013 11:13:07 AM UTC+2, Albert van der Horst wrote:
> There was a lecture about why "jonesforth is popular" at the
> German ForthGesellschaft meeting. I now see that jonesforth is
> not merely "well documented" but it gives insight by documenting
> design decisions. This triggers me to think about ciforth in the
> same way. The following "lecture" I will put on my site shortly.
>
> The most elegant Forth interpreter

> ==================================
> ciforth contains four improvements over classic indirect threaded Forth's.
>
> WORD replaced by NAME
> FIND replaced by FOUND
> >IN replaced by IN
> (NUMBER) replaced by PREFIX
<SNIP>'s enclosed.

>
>
> \ All time smallest, fully competent Forth interpreter
> : INTERPRET
> BEGIN NAME OVER WHILE
> OVER >R
> FOUND ( DUP 0= 12 ?ERROR )
> DUP name-length R> + IN !
> immediate? STATE @ 0= OR IF EXECUTE ELSE , THEN ( ?STACK )
> REPEAT 2DROP ;

It is strange that nobody pointed this out. This interpreter cannot be

made standard easily. The >IN pointer is pointing at the blank ending

a name, not at the character after the blank ending the name as

*required* by the standard.

This post via google. I carefully snipped and also removed the

double spacing inserted by google.

I inserted double spacing here, to prevent google from making lines

that are too long.

I hope this experiment works, then nobody has an excuse to post
dirt via google.

>
> The expense of taking care of denotations is 2 lines hidden in one of the
> factors of FOUND.
> Groetjes Albert
>

[Lars Brinkhoff]

Andrew Haley wrote:
> Paul Rubin wrote:
>> David Schultz wrote:
>>> http://home.earthlink.net/~schultdw/tmp/model.pdf
>> Thanks! I notice it starts at SCR #6, does that mean the first
>> page is missing?
> Yes. It's the tile page and some error messages.

For completeness, could someone please scan those pages too?
Pretty please?


To reiterate, here are the screens we have so far:

6-8 Machine-dependent I/O primitives.
12-32 Vectors and code words.
33-71 High-level kernel.
72-80 Library.
87-97 Editor.


This is missing:

1-3 ??? (title page?)
4 Error messages.
5-7 ??? (more messages?)
9-11 ???
81-86 ???
98- ??? (was there anything after the editor)

[Andrew Haley]

Lars Brinkhoff <lars...@nocrew.org> wrote:
> Andrew Haley wrote:
>> Paul Rubin wrote:
>>> David Schultz wrote:
>>>> http://home.earthlink.net/~schultdw/tmp/model.pdf
>>> Thanks! I notice it starts at SCR #6, does that mean the first
>>> page is missing?
>> Yes. It's the tile page and some error messages.
>
> For completeness, could someone please scan those pages too?
> Pretty please?

OK.

Andrew.

[David Schultz]

On 07/05/2013 01:51 AM, Lars Brinkhoff wrote:
> This is missing:
>
> 1-3 ??? (title page?)
> 4 Error messages.
> 5-7 ??? (more messages?)
> 9-11 ???
> 81-86 ???
> 98- ??? (was there anything after the editor)
>

If you want that information you will have to find the original floppy
disk because none of it is in the printed document.


--
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving

[Andrew Haley]

Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> Lars Brinkhoff <lars...@nocrew.org> wrote:
>> Andrew Haley wrote:
>>> Paul Rubin wrote:
>>>> David Schultz wrote:
>>>>> http://home.earthlink.net/~schultdw/tmp/model.pdf
>>>> Thanks! I notice it starts at SCR #6, does that mean the first
>>>> page is missing?

>>> Yes. It's the title page and some error messages.

>>
>> For completeness, could someone please scan those pages too?
>> Pretty please?
>
> OK.

They are now ready to go. Please send me the best email address to
send them to. I am a...@redhat.com.

Andrew.

[g.forta...@gmail.com]

Hi Coos,

I am working on Lennart Benshop F83 Forth on Spectrum. This one includes your own work for wich I must congratulate. I was amazed of how complete this version is.

The one thing is I don't understand (certainly normal) metacompilation process and purpose and examples are never told.

Here or there on the net are some few explanations, but I am not happy with them.

Do you have some interresting links on this subject ( general and step-by step explanations ) ?

Thanks a lot for helping,

Guy from Paris