scripting

[a***@spenarnc.xs4all.nl]

There was a lecture on interpreted control structure in Zeptoforth.
That was in the forth2020 conference of april 2024
I was surprised. In particular it doesnot work for looping
building up the dictionary, e.g.

CREATE CRCTable
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP , LOOP
This IMO is the most useful application.
Other disadvantage of this implementation was that an error leads
to a restart.

The following simple mechanism is in ciforth, and a small
adaptation runs on gforth 7.3, presumably portably, or at least
quasi portably.
It compiles temporarily to a kind of far PAD, then abandons the code
after executing it.
I commented the word TRIM out, this isn't portable (but instrumental
to ciforth classes.)

---------
( SWAP-DP T] T[ scratch_dictionary_area ) \ AvdH A9mar31
VARIABLE FAR-DP \ Alternative DP
HERE 10000 CELLS ALLOT FAR-DP !
\ Use alternative dictionary area or back.
: SWAP-DP DP @ FAR-DP @ DP ! FAR-DP ! ;
\ \ Remove all words from the scratch area.
\ : TRIM HERE 'FORGET-VOC FOR-VOCS DROP ;

\ 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 EXIT SWAP-DP POSTPONE [ >R THEN ; IMMEDIATE


( NEW-IF -scripting- ) \ AvdH B2sep21
: IF T] POSTPONE IF ; IMMEDIATE
: DO T] POSTPONE DO ; IMMEDIATE
: ?DO T] POSTPONE ?DO ; IMMEDIATE
: BEGIN T] POSTPONE BEGIN ; IMMEDIATE
: THEN POSTPONE THEN POSTPONE T[ ; IMMEDIATE
: LOOP POSTPONE LOOP POSTPONE T[ ; IMMEDIATE
: +LOOP POSTPONE +LOOP POSTPONE T[ ; IMMEDIATE
: REPEAT POSTPONE REPEAT POSTPONE T[ ; IMMEDIATE
: UNTIL POSTPONE UNTIL POSTPONE T[ ; IMMEDIATE
: AGAIN POSTPONE AGAIN POSTPONE T[ ; IMMEDIATE

\ Last scripting block!
---------
With the above code you could go on after and error, forfeiting 10000
CELLS of the dictionary, or just use SWAP-DP .

Scripting is since time immemorial in ciforth library.

Example for gforth:
~/PROJECT/ciforths/ciforth: gforth
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
INCLUDE script.frt redefined IF redefined DO redefined ?DO redefined BEGIN redefined THEN redefined LOOP redefined +LOOP redefined REPEAT redefined UNTIL redefined AGAIN ok
10 0 DO I . LOOP 0 1 2 3 4 5 6 7 8 9 ok
BEGIN FOOBAR REPEAT
:3: Undefined word
BEGIN >>>FOOBAR<<< REPEAT
Backtrace:
$7F73F67DAA68 throw
$7F73F67F0D58 no.extensions
$7F73F67DE3A0 compiler-notfound1
HERE . 140136033719632 ok
SWAP-DP ok
HERE . 140136033800808 ok
10 0 DO I . LOOP 0 1 2 3 4 5 6 7 8 9 ok

In this example you see that gforth restores HERE after
an error,sometimes. (But not in all cases.)

Hopes this helps.
Groetjes Albert

[Travis Bemann]

Post by a***@spenarnc.xs4all.nl
There was a lecture on interpreted control structure in Zeptoforth.
That was in the forth2020 conference of april 2024
I was surprised. In particular it doesnot work for looping
building up the dictionary, e.g.
CREATE CRCTable
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP , LOOP
This IMO is the most useful application.

The reason for this is that interpreted control structures in zeptoforth
really are not interpreted at all. Rather, they are treated as saving
the RAM HERE pointer for later restoration and temporarily putting
zeptoforth into compilation state, with the HERE pointer pointing into
RAM, until all the outstanding control structures are closed, where then
all the newly compiled code is executed and then promptly forgotten and
the original RAM HERE pointer is restored (and if the HERE pointer
previously pointed into flash, pointing HERE into flash again).

As a result new code or data cannot be written to the dictionary,
because it will all be forgotten at the end. Also, words that are not
valid in compilation state cannot be used for the very reason that
zeptoforth *is* in compilation state between the initiating controlling
control structure and its closing.

Post by a***@spenarnc.xs4all.nl
Other disadvantage of this implementation was that an error leads
to a restart.

An error results in the HERE pointer being rolled back to its
original position, unless a crash occurs, which may or may not be
successfully recovered from, but after which it is wise to treat
zeptoforth to be in an undefined state and reboot once one is done
debugging the crashed state. (Is this what you mean by "a restart"?)

Post by a***@spenarnc.xs4all.nl
The following simple mechanism is in ciforth, and a small
adaptation runs on gforth 7.3, presumably portably, or at least
quasi portably.
It compiles temporarily to a kind of far PAD, then abandons the code
after executing it.
I commented the word TRIM out, this isn't portable (but instrumental
to ciforth classes.)

zeptoforth makes no assumptions about the position of the top edge of
the main task's dictionary because new tasks are allotted from high
memory down, and if memory were allotted in high memory it would either
be overwritten by new tasks, or would be permanently lost if a new task
were created, depending on how exactly this were implemented.

Travis

[a***@spenarnc.xs4all.nl]

Post by Travis Bemann

Post by a***@spenarnc.xs4all.nl
There was a lecture on interpreted control structure in Zeptoforth.
That was in the forth2020 conference of april 2024
I was surprised. In particular it doesnot work for looping
building up the dictionary, e.g.
CREATE CRCTable
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP , LOOP
This IMO is the most useful application.

The reason for this is that interpreted control structures in zeptoforth
really are not interpreted at all. Rather, they are treated as saving
the RAM HERE pointer for later restoration and temporarily putting
zeptoforth into compilation state, with the HERE pointer pointing into
RAM, until all the outstanding control structures are closed, where then
all the newly compiled code is executed and then promptly forgotten and
the original RAM HERE pointer is restored (and if the HERE pointer
previously pointed into flash, pointing HERE into flash again).

If you noticed, that was approximately what I do.
It works on gforth, it is pretty portable.
I have not the complication dealing with flash.

<SNIP>

Post by Travis Bemann
zeptoforth makes no assumptions about the position of the top edge of
the main task's dictionary because new tasks are allotted from high
memory down, and if memory were allotted in high memory it would either
be overwritten by new tasks, or would be permanently lost if a new task
were created, depending on how exactly this were implemented.

You are talking about tasks, and the option to compile code in each tasks?
I can see that this complicate things.

Post by Travis Bemann
Travis

[dxf]

Post by a***@spenarnc.xs4all.nl
...
CREATE CRCTable
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP , LOOP
This IMO is the most useful application.

One hopes not since ...

CREATE CRCTable 100 CELLS ALLOT

: !CRC ( -- ) CRCTable 100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP OVER ! CELL+ LOOP DROP ; !CRC FORGET !CRC

[a***@spenarnc.xs4all.nl]

[a***@spenarnc.xs4all.nl]

Post by dxf

Post by a***@spenarnc.xs4all.nl
...
CREATE CRCTable
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP , LOOP
This IMO is the most useful application.

One hopes not since ...
CREATE CRCTable 100 CELLS ALLOT
: !CRC ( -- ) CRCTable 100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP OVER ! CELL+ LOOP DROP ; !CRC FORGET !CRC

A political correct versies for gforth would be

"
CREATE CRCTable 100 CELLS ALLOT
MARKER FORGET-MARKER

:NONAME CRCTable 100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC64_POLYNOMIAL XOR THEN
LOOP OVER ! CELL+ LOOP DROP ; EXECUTE

FORGET-MARKER
"

( FORGET is no longer in gforth.)

Groetjes Albert

[minforth]

Well, it works, but .. my 5 cents:

IMO scripts are useful snippets of code that should be kept
in a collection, e.g. in a directory. Similar to m-scripts
in Matlab. Whether they are compiled or interpreted is
irrelevant, as long as the usefulness is not affected.

Compiling in Forth is fast and convenient. So what's the
point of of inventing new interpretable control words
such as interpretable DO ?DO I J LEAVE UNLOOP LOOP +LOOP
or other nightmares?

Even today local identifiers are compiled into a temporary
wordlist. Temporary code space in the heap or wherever
is not rocket science either. IOW all the tools are there.

And "use and forget" is only one strategy. Sometimes
"use and keep" is better.