Hello, a Forth newbie here!

I read the newsgroup's FAQ and the gforth manual, but have still some
questions.

How can I get GForth to compile? Or can it only interprete? If GForth
can't, is there a Forth compiler for Linux?

Kindregards
Peter Wiehe

Peter Wiehe <info@pwiehe.de> writes:
>How can I get GForth to compile? Or can it only interprete? If GForth
>can't, is there a Forth compiler for Linux?

Gforth compiles to threaded code, and optionally generates native
code; e.g., a recent development version of gforth-fast compiles:

: cubed dup dup * * ;

into the following code (that you can see with see-code):

$7FEF739927A0 dup 1->2
7FEF73639BD2: mov r15,r8
$7FEF739927A8 dup 2->3
7FEF73639BD5: mov r9,r15
$7FEF739927B0 * 3->2
7FEF73639BD8: imul r15,r9
$7FEF739927B8 * 2->1
7FEF73639BDC: imul r8,r15
$7FEF739927C0 ;s 1->1
7FEF73639BE0: mov rbx,[r14]
7FEF73639BE3: add r14,$08
7FEF73639BE7: mov rax,[rbx]
7FEF73639BEA: jmp eax

The stuff add the addresses prefixed with '$' is the threaded code,
the stuff in between the native code.

See https://gforth.org/ for how to install a recent development
snapshot.

There are also native code compilers for Forth that don't have any
threaded-code mechanisms inside (like what you see in the native code
for ";s"). E.g., SwiftForth compiles CUBED to:

44CBA0 -8 [RBP] RBP LEA 488D6DF8
44CBA4 RBX 0 [RBP] MOV 48895D00
44CBA8 -8 [RBP] RBP LEA 488D6DF8
44CBAC RBX 0 [RBP] MOV 48895D00
44CBB0 0 [RBP] RAX MOV 488B4500
44CBB4 RBX MUL 48F7E3
44CBB7 RAX RBX MOV 488BD8
44CBBA 8 [RBP] RBP LEA 488D6D08
44CBBE 0 [RBP] RAX MOV 488B4500
44CBC2 RBX MUL 48F7E3
44CBC5 RAX RBX MOV 488BD8
44CBC8 8 [RBP] RBP LEA 488D6D08
44CBCC RET C3 ok

VFX compiles CUBED to

( 004E3E60 488BD3 ) MOV RDX, RBX
( 004E3E63 480FAFDA ) IMUL RBX, RDX
( 004E3E67 480FAFDA ) IMUL RBX, RDX
( 004E3E6B C3 ) RET/NEXT

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <20231120223306.51d4ba0b@peter-OptiPlex-7010>,
Peter Wiehe <info@pwiehe.de> wrote:
>Hello, a Forth newbie here!
>
>I read the newsgroup's FAQ and the gforth manual, but have still some
>questions.
>
>How can I get GForth to compile? Or can it only interprete? If GForth
>can't, is there a Forth compiler for Linux?

Of course there is a compiler that generates elf executables: ciforth.
lina found on github i.a.

>
>Kindregards
>Peter Wiehe
>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

Peter Wiehe wrote:
> How can I get GForth to compile? Or can it only interprete? If GForth
> can't, is there a Forth compiler for Linux?

Anton Ertl answered the main question.

Side notes only:

The kernel of most Forth systems is compiled of course
(assembler or C) and offers extension by user words. However high-level
words (eg between : and ;) are often translated to token/bitcode sequences
that are interpreted, but run fast.

IOW the choice of a Forth system depends more on what you want to do with it.
Programming small MCU devices? Desktop scripting? Your own experimental
toolbox for testing algorithms in assembler or C?

If you are more familiar with C you could also try MinForth from Sourceforge
(or pforth or Ficl because I am not selling anything). There is a Linux
and a Windows package. It is small but still provides all ANS/ISO Forth
word sets, and IMHO it is rather easy to understand.
Main feature: it can transpile Forth words to C.

In article <50280d57-5bc4-461b-99ee-77f05d93a863n@googlegroups.com>,
Brian Fox <brian.fox@brianfox.ca> wrote:
>On Monday, November 20, 2023 at 4:33:19 PM UTC-5, Peter Wiehe wrote:
>> Hello, a Forth newbie here!
>>
>> I read the newsgroup's FAQ and the gforth manual, but have still some
>> questions.
>>
>> How can I get GForth to compile? Or can it only interprete? If GForth
>> can't, is there a Forth compiler for Linux?
>>
>> Kindregards
>> Peter Wiehe
>
>To further expand on this question, it sounds like your are looking for a way to compile Forth to standalone executable program.
>GForth and most Forth systems are more like LISP in that they are image based. You compile your code into the image.
>The entire image can be saved and run as an application on many systems but your are bringing along lots of extra stuff.
>(although in some cases it is still less than some libraries in other languages.
>To do what I think you are looking for, you may be able to use the GForth cross-compiler but I have never used it.
>
>https://gforth.org/manual/Cross-Compiler.html

I regret that even knowledgeable persons like yourself are not aware of the
existance of lina despite my ongoing campaign since the year 2003 on this
newsgroup.

To rub it in
---------------------------------------------------------------
~/PROJECT/ciforths/ciforth: cat >hello.frt
: rome ." we gaan naar Rome" CR ;
~/PROJECT/ciforths/ciforth:
~/PROJECT/ciforths/ciforth: lina -c hello.frt
~/PROJECT/ciforths/ciforth: hello
we gaan naar Rome
~/PROJECT/ciforths/ciforth: objdump -x hello

hello: file format elf64-x86-64
hello
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0000000000400078

Program Header:
LOAD off 0x0000000000000078 vaddr 0x0000000000400078 paddr 0x0000000000400078 align 2**12
filesz 0x000000000000fd88 memsz 0x0000000004004000 flags rwx

Sections:
Idx Name Size VMA LMA File off Algn
SYMBOL TABLE:
no symbols

---------------------------------------------------------------
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

Thanks for all the answers, they were really helpful.

Sorry that my question was unclear. I didn't mean compiling the Forth
interpreter to an executable, but I meant compiling my little
programwritten in Forth to a binary.

I will check ciforth, lina etc. And yes, my background so far is C.

I have another question which seems to be related because the error
message seems to imply that:

I get this error in GForth on Linux:

-----------------
Interpreting a compile-only word
>>>begin<<< game_loop game_end until
-----------------

So "begin" is not suitable for interpreting? Seems strange to me. Or
what is the reason why this code produces an error message?

Kind regards
Peter Wiehe

On 11/21/23 1:39 PM, Peter Wiehe wrote:
> -----------------
> Interpreting a compile-only word
>>>> begin<<< game_loop game_end until
> -----------------
>
> So "begin" is not suitable for interpreting? Seems strange to me. Or
> what is the reason why this code produces an error message?
>
> Kind regards
> Peter Wiehe
>

This seems obvious to an old timer like me that bought a copy of R.G.
Loeliger's book when it came out:

https://www.amazon.com/Threaded-Interpretive-Languages-Design-Implementation/dp/007038360X

BEGIN marks the current position within a word that is being compiled.
It does that by pushing the value of HERE on the stack. Some systems,
like fig-FORTH, would include another tag value on the stack used for
compiler security. When a word intended to close that loop was executed,
it would check for that tag. If it matched what it wanted, it would
compile a branch back to the location left on the stack.

So obviously completely useless while interpreting.

I find Forth very fun to work with mostly because it makes you break
things into small functions. Which are easy to write and test. With
complicated functions keeping track of what is one the stack gets to be
a pain.

--
http://davesrocketworks.com
David Schultz

Peter Wiehe <info@pwiehe.de> writes:
>I get this error in GForth on Linux:
>
>-----------------
>Interpreting a compile-only word
>>>>begin<<< game_loop game_end until
>-----------------
>
>So "begin" is not suitable for interpreting? Seems strange to me. Or
>what is the reason why this code produces an error message?

BEGIN is a control-flow word, and control structures are implemented
by compiling unconditional or conditional branches; that only works
while compiling code inside colon definitions. Also, this is not just
an implementation choice, BEGIN leaves something on the control-flow
stack (which is the same as the data stack on Gforth and most other
systems) during compilation which is then consumed by the UNTIL in
this example. This works because the data stack is otherwise mostly
unused when compiling words.

A number of people have found the limitation of BEGIN etc. to colon
definitions inconvenient, and have implemented various forms of
interpreted control structures (e.g., by switching to compile state
and temporarily compiling the code after the BEGIN).

However, all of the approaches I have seen have some other limitation,
so we did not implement any such approach in Gforth, except that there
is, e.g., [begin] ... [until], which uses a completely different
mechanism.

- 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: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On 22/11/2023 6:39 am, Peter Wiehe wrote:
> Thanks for all the answers, they were really helpful.
>
> Sorry that my question was unclear. I didn't mean compiling the Forth
> interpreter to an executable, but I meant compiling my little
> programwritten in Forth to a binary.

That's still somewhat unclear - to me at least.

One may call forth an incremental compiler with the user controlling
the process. It implies two states - interpreting and compiling - and
the ability to enter/exit each. Once the application (or parts thereof)
is compiled the user can interpret (execute) it. Alternatively complete
applications may be 'turnkeyed'. The latter involves disabling 'the
forth interpreter' and saving the image as a binary executable. How
it's done varies from forth to forth and not necessarily every forth
has the option.

In article <20231121203956.538b2b29@peter-OptiPlex-7010>,
Peter Wiehe <info@pwiehe.de> wrote:
>Thanks for all the answers, they were really helpful.
>
>Sorry that my question was unclear. I didn't mean compiling the Forth
>interpreter to an executable, but I meant compiling my little
>programwritten in Forth to a binary.
>
>I will check ciforth, lina etc. And yes, my background so far is C.
>
>I have another question which seems to be related because the error
>message seems to imply that:
>
>I get this error in GForth on Linux:
>
>-----------------
>Interpreting a compile-only word
>>>>begin<<< game_loop game_end until
>-----------------
>
>So "begin" is not suitable for interpreting? Seems strange to me. Or
>what is the reason why this code produces an error message?
>
>Kind regards
>Peter Wiehe
>

It is easy to add. Available after
WANT -scripting-
in ciforth.
I have it in my electives screen, routinely loaded in
program development.

( NEW-IF -scripting- ) \ AvdH B2sep21
1 : NEW-IF ; \ Get rid!
2 "T]" WANTED ":2" WANTED
3 :2 IF T] POSTPONE IF ; IMMEDIATE
4 :2 DO T] POSTPONE DO ; IMMEDIATE
5 :2 ?DO T] POSTPONE ?DO ; IMMEDIATE
6 :2 BEGIN T] POSTPONE BEGIN ; IMMEDIATE
7 :2 THEN POSTPONE THEN POSTPONE T[ ; IMMEDIATE
8 :2 LOOP POSTPONE LOOP POSTPONE T[ ; IMMEDIATE
9 :2 +LOOP POSTPONE +LOOP POSTPONE T[ ; IMMEDIATE
10 :2 REPEAT POSTPONE REPEAT POSTPONE T[ ; IMMEDIATE
11 :2 UNTIL POSTPONE UNTIL POSTPONE T[ ; IMMEDIATE
12 :2 AGAIN POSTPONE AGAIN POSTPONE T[ ; IMMEDIATE
13
14 \ Last scripting block!
15 CREATE -scripting-

\ While compiling, T[ just throws away the state pushed by T].
\ Interpreting:
\ Start compiling at temporary place : return START and STATE.
: T] STATE @ 0= IF SWAP-DP HERE THEN STATE @ ] ;
\ Execute code at START dropping STATE, restore dictionary.
: T[ 0= IF POSTPONE (;) SWAP-DP POSTPONE [ >R THEN ; IMMEDIATE

1. You can replace the :2 by a : . It is used to repress the
redefined messages.
2. SWAP-DP swaps HERE to a a temporary buffer.
3. (;) --> EXIT
HERE .. >R --> :NONAME EXECUTE

That is system dependant, but easy enough.
If you want it, it is just an easy fix.

It highlights the usefulness of loadable libraries,
if you don't want it, you can ignore it and
it doesn't show up in WORDS.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

David Schultz schrieb am Dienstag, 21. November 2023 um 21:10:00 UTC+1:
> I find Forth very fun to work with mostly because it makes you break
> things into small functions. Which are easy to write and test. With
> complicated functions keeping track of what is one the stack gets to be
> a pain.

If the stack depth becomes too unwieldy, I use locals. Programming and
debugging is then also faster.

But in my practical code there is actually relatively little stack movement.
It's more like a sequence of calls to individual forth or application words.

In article <20231121203956.538b2b29@peter-OptiPlex-7010>,
Peter Wiehe <info@pwiehe.de> wrote:
>Thanks for all the answers, they were really helpful.
>
>Sorry that my question was unclear. I didn't mean compiling the Forth
>interpreter to an executable, but I meant compiling my little
>programwritten in Forth to a binary.

Compiling Forth is so fast that it doesn't makes sense to compile
to "object files". In fact they are popular mainly for companies
to hide the source, and be able to sell a facility separate
from a utility program.

Compiling Forth to ELF executables OTOH makes sense, because the user
doesn't have to install a run time system like python, perl, lisp and,
most of the times, Forth.

>Kind regards
>Peter Wiehe
>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 22/11/2023 8:50 pm, minforth wrote:
> David Schultz schrieb am Dienstag, 21. November 2023 um 21:10:00 UTC+1:
>> I find Forth very fun to work with mostly because it makes you break
>> things into small functions. Which are easy to write and test. With
>> complicated functions keeping track of what is one the stack gets to be
>> a pain.
>
> If the stack depth becomes too unwieldy, I use locals.

Locals don't eliminate unwieldy - they only make it manageable.

> Programming and debugging is then also faster.

For C programmers perhaps. A forth programmer would ask what's
wrong about this code that it has become unwieldy.

dxf schrieb am Mittwoch, 22. November 2023 um 11:39:15 UTC+1:
> On 22/11/2023 8:50 pm, minforth wrote:
> > David Schultz schrieb am Dienstag, 21. November 2023 um 21:10:00 UTC+1:
> >> I find Forth very fun to work with mostly because it makes you break
> >> things into small functions. Which are easy to write and test. With
> >> complicated functions keeping track of what is one the stack gets to be
> >> a pain.
> >
> > If the stack depth becomes too unwieldy, I use locals.
> Locals don't eliminate unwieldy - they only make it manageable.
> > Programming and debugging is then also faster.
> For C programmers perhaps. A forth programmer would ask what's
> wrong about this code that it has become unwieldy.

I know it's always the same red bandanna called locals you're barking at.
I don't want to see you stack juggling complex vectors. :o)

On 22/11/2023 11:16 pm, minforth wrote:
> dxf schrieb am Mittwoch, 22. November 2023 um 11:39:15 UTC+1:
>> On 22/11/2023 8:50 pm, minforth wrote:
>>> David Schultz schrieb am Dienstag, 21. November 2023 um 21:10:00 UTC+1:
>>>> I find Forth very fun to work with mostly because it makes you break
>>>> things into small functions. Which are easy to write and test. With
>>>> complicated functions keeping track of what is one the stack gets to be
>>>> a pain.
>>>
>>> If the stack depth becomes too unwieldy, I use locals.
>> Locals don't eliminate unwieldy - they only make it manageable.
>>> Programming and debugging is then also faster.
>> For C programmers perhaps. A forth programmer would ask what's
>> wrong about this code that it has become unwieldy.
>
> I know it's always the same red bandanna called locals you're barking at.
> I don't want to see you stack juggling complex vectors. :o)

I'm not ready to believe that without locals forth would be a complete
failure. So yes, I will question things I've carried over from other
languages.

Le lundi 20 novembre 2023 à 22:33:19 UTC+1, Peter Wiehe a écrit :
> Hello, a Forth newbie here!
>
> I read the newsgroup's FAQ and the gforth manual, but have still some
> questions.
>
> How can I get GForth to compile? Or can it only interprete? If GForth
> can't, is there a Forth compiler for Linux?
>
> Kindregards
> Peter Wiehe
Hi,
You can also use eForth Linux: https://github.com/MPETREMANN11/eForth-LINUX/tree/main/__documentation/EN