Vector to warm start (fig-Forth)

[LIT]

Every fig-Forth is started with a sequence:

ORIG: NOP
JMP CLD ; vector to COLD start
NOP
JMP WRM ; vector to WARM start

The problem is: nowhere neither in the source nor
in the LST file I can find any reference to ORIG+2
address -- when using symbolic notation -- neither
to that particular memory address (addressed directly).
No Forth word uses "2 +ORIGIN".
It seems that location isn't used at all -- is it correct?

If so —- why it is there? Is it left there "just in case",
on the rule: "if ever in a need to use warm-start procedure,
you'll always find its vector at ORIG+2"?

[David Schultz]

Post by LIT
If so —- why it is there? Is it left there "just in case",
on the rule: "if ever in a need to use warm-start procedure,
you'll always find its vector at ORIG+2"?

Once upon a time you might use a system monitor to load fig-Forth from a
tape. Then to start it you had to tell the monitor to begin execution at
some address. Or maybe something went sideways and the monitor restarted
and you want to try a warm start.

For me, it was the TUTOR monitor on the MEX68KECB and a cassette tape.

[sjack]

...

Post by LIT
It seems that location isn't used at all -- is it correct?

True in my case. It's left there and unused (by me).
Long ago wrote tiny Atari error handler to pass control to the
WRM location. Not having to re-start Forth after a wayward
operation is nice.

Today have Linux segment fault signal set to pass control
directly to ERROR with message number 25 on stack resulting
in "Memory error" printout followed by abort.

Maybe someday I'll hook control-C to WRM and see how that plays.
I'm content at the present using control-C to kill a lost Forth
and return control to Bash.

[dxf]

Post by LIT
ORIG: NOP
     JMP CLD ; vector to COLD start
     NOP
     JMP WRM ; vector to WARM start
The problem is: nowhere neither in the source nor
in the LST file I can find any reference to ORIG+2
address -- when using symbolic notation -- neither
to that particular memory address (addressed directly).
No Forth word uses "2 +ORIGIN".
It seems that location isn't used at all -- is it correct?
If so —- why it is there? Is it left there "just in case",
on the rule: "if ever in a need to use warm-start procedure,
you'll always find its vector at ORIG+2"?

It is referenced in the FIG manual ...

SCR # 55
0 ( COLD START WFR-79APR29 )
1 CODE COLD ( COLD START, INITIALIZING USER AREA *)
2 HERE 02 +ORIGIN ! ( POINT COLD ENTRY TO HERE )
3 0C +ORIGIN LDA, 'T FORTH 4 + STA, ( FORTH VOCAB. )
4 0D +ORIGIN LDA, 'T FORTH 5 + STA,
5 15 # LDY, ( INDEX TO VOC-LINK ) 0= IF, ( FORCED )
6 HERE 06 +ORIGIN ! ( POINT RE-ENTRY TO HERE )
7 0F # LDY, ( INDEX TO WARNING ) THEN, ( FROM IF, )
8 10 +ORIGIN LDA, UP STA, ( LOAD UP )
9 11 +ORIGIN LDA, UP 1+ STA,
10 BEGIN, 0C +ORIGIN ,Y LDA, ( FROM LITERAL AREA )
11 UP )Y STA, ( TO USER AREA )
12 DEY, 0< END,
13 'T ABORT 100 /MOD # LDA, IP 1+ STA,
14 # LDA, IP STA,
15 6C # LDA, W 1 - STA, 'T RP! JMP, ( RUN ) -->

[LIT]

Post by dxf
It is referenced in the FIG manual ...

I was using source code for PC and a book
describing implementation for 8080. The COLD
you pasted looks way more "developed" indeed.

So in most cases this is kind of "emergency
utility" not actually used by Forth's code.

[LIT]

Post by dxf
It is referenced in the FIG manual ...
SCR # 55
0 ( COLD START WFR-79APR29 )
1 CODE COLD ( COLD START, INITIALIZING USER AREA *)
2 HERE 02 +ORIGIN ! ( POINT COLD ENTRY TO HERE )

^^^^^^^^^^^
Oh, I forgot: I actually meant "4 +ORIGIN" (not 2), of course.
Creating my initial post I measured the memory distance using
cells (wrong), not bytes.

[dxf]

Post by dxf
It is referenced in the FIG manual ...
    SCR # 55
       0 (  COLD START                                     WFR-79APR29
)
       1 CODE COLD               ( COLD START, INITIALIZING USER AREA
*)
       2    HERE  02  +ORIGIN  !  ( POINT COLD ENTRY TO HERE )

                   ^^^^^^^^^^^
Oh, I forgot: I actually meant "4 +ORIGIN" (not 2), of course.
Creating my initial post I measured the memory distance using
cells (wrong), not bytes.

For WARM that would be 6 +ORIGIN which is also referenced.

[LIT]

Post by dxf
For WARM that would be 6 +ORIGIN which is also referenced.

Not really:

ORIG: NOP
JMP CLD ; vector to COLD start
NOP
JMP WRM ; vector to WARM start

One byte for NOP and three more for JMP CLD
raise a need to skip four initial bytes, not six.

[LIT]

Post by dxf
6 HERE 06 +ORIGIN ! ( POINT RE-ENTRY TO HERE )

So in this version COLD is resetting the WARM
vector (probably in case it has been altered?),
changing the destination address alone.

[dxf]

Post by LIT

6     HERE  06 +ORIGIN !   ( POINT RE-ENTRY TO HERE )

So in this version COLD is resetting the WARM
vector (probably in case it has been altered?),
changing the destination address alone.

It is the metacompiler that's doing it - not COLD. Remember COLD
is a code definition. The metacompiler is fixing up the following
forward references:

2 NOP, HERE JMP, ( WORD ALIGNED VECTOR TO COLD )
3 NOP, HERE JMP, ( WORD ALIGNED VECTOR TO WARM )

[LIT]

Post by dxf
It is the metacompiler that's doing it - not COLD. Remember COLD
is a code definition. The metacompiler is fixing up the following
2 NOP, HERE JMP, ( WORD ALIGNED VECTOR TO COLD )
3 NOP, HERE JMP, ( WORD ALIGNED VECTOR TO WARM )

Oh, sure -- thanks.

Of course: CODE COLD etc. Actually it looked
a bit unusual to me COLD is placing HERE as
a destination address, I admit. ;)

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

Post by LIT
ORIG: NOP
JMP CLD ; vector to COLD start
NOP
JMP WRM ; vector to WARM start
The problem is: nowhere neither in the source nor
in the LST file I can find any reference to ORIG+2
address -- when using symbolic notation -- neither
to that particular memory address (addressed directly).
No Forth word uses "2 +ORIGIN".
It seems that location isn't used at all -- is it correct?
If so —- why it is there? Is it left there "just in case",
on the rule: "if ever in a need to use warm-start procedure,
you'll always find its vector at ORIG+2"?

+ORIGIN is still used in ciforth.

+ORIGIN is an array of initialised user variables:
e.g.
'R0 >DFA @ +ORIGIN @
gets the initialisation value of the return stack pointer.
This array is used to advantage in SAVE-SYSTEM also.

Traditionally -2 CELLS +ORIGIN was the warm start.
It is useful to guide signals to this address.
For instance if you got in an infinite loop
BEGIN 4 . AGAIN
you can get out by ^C.
1278217 0 !
1E0 0E0 F/ FS.
are other predicaments that don't lead to a crash.

-2 CELLS +ORIGIN SIGINT 0 _NR__signal XOS THROW
is the high level code that accomplish this. SIGINT means control-C.
_NR__signal is the nummer of a system call that does this for you.
XOS is the general call to uniX .
If you want this
WANT INSTALL-TRAPS.

I didn't manage this yet for 64 bit.

Groetjes Albert

[LIT]

Post by a***@spenarnc.xs4all.nl
Traditionally -2 CELLS +ORIGIN was the warm start.
It is useful to guide signals to this address.

"Traditionally"? Correct me, if I'm wrong -- but
usually the first address of the whole Forth system
was "0 +ORIGIN" -- and everything else was "higher".

So although feasible still "-2 CELLS +ORIGIN" looks
rather, say, "unorthodox". ;)

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

Post by LIT

Post by a***@spenarnc.xs4all.nl
Traditionally -2 CELLS +ORIGIN was the warm start.
It is useful to guide signals to this address.

"Traditionally"? Correct me, if I'm wrong -- but
usually the first address of the whole Forth system
was "0 +ORIGIN" -- and everything else was "higher".
So although feasible still "-2 CELLS +ORIGIN" looks
rather, say, "unorthodox". ;)

I stand corrected. I have looked into half a dozen fig Forth
listing that lying around here.
The most evolved version has what you describes.
Indeed it looks like
ORIG:
cold and warm vector
assorted random data
user variables initialisation.

ciforth was evolved from fig Forth.
So actually I described the ciforth model.
The order is vectors then user variables in ciforth.
+ORIGIN was mainly useful to access the random data
and later the main task was accessing the user variables.
In ciforth the random data have been moved and given names and
now +ORIGIN points to user variable initialisation.
I apparently found it useful that the offset for +ORIGIN is
the same as the user variable offset in the user area.
As you implement SAVE-SYSTEM, you discover that the
of the user pointer itself must be a user variable.

Groetjes Albert

[LIT]

BTW: while we at ciforth. Perhaps could you
-- as the author, who knows his "child" best --
recommend the simplest way to _not_ generate
CRs within blocks?

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

Post by LIT
BTW: while we at ciforth. Perhaps could you
-- as the author, who knows his "child" best --
recommend the simplest way to _not_ generate
CRs within blocks?

It is legitimate to use blocks for anything. There is nothing wrong
with generating line feeds in block files.

So I interpret the question how could I get rid of the ^J in
the .lab files that ciforth uses.
I doubt the usefulness of that, but anyway.

-------------- 8< ---- rid.frt -------------------------
: doit
1 ARG[] GET-FILE BEGIN DUP WHILE ^J $/ TYPE SPACE REPEAT ;
-------------- 8< --------------------------------------
then
lina -c rid.frt

rid forth.lab > x

Now x contains spaces instead of line feeds.

Groetjes Albert

[LIT]

Thanks, but that's "the other half" of the problem.
The main is: I wanted to make ciforth accept "ordinary"
block files. Presently any attempt to use block
file without LFs looks like this:

1 LIST
SCR # 1
0














[ ...several empty lines... ]
1 ? ciforth ERROR # -14
OK

I was hoping for kind of "switch", that could
make it work with blocks not featuring LFs,
to write edited blocks also with no LFs etc.

I'm aware of rationale behind introducing LFs,
but there's no longer need for that. Plenty of
screen editors available. If for some reason you
want to keep it present way -- adding an option
for not using LFs in block files would be useful
addition.

[sjack]

Post by LIT
recommend the simplest way to _not_ generate
CRs within blocks?

:) myfig lib -p

fload job
298 SCR !
WIPE_SCR
0 P : P HERE C/L 1+ BLANKS 1 WORD
1 P HERE 1+ SWAP LINE C/L CMOVE ;
2 P : WIPE_SCR 0 LINE B/BUF BLANKS ;
4 P Don't need an editor to write to Forth disks.
5 P The word P shown above will suffice.
6 P Key or script in lines of text.
7 P When done, UPDATE and FLUSH to save the screen.
9 P Please note, the code shown is FigForth.

SCR @ LIST
SCR # 298
0 : P HERE C/L 1+ BLANKS 1 WORD
1 HERE 1+ SWAP LINE C/L CMOVE ;
2 : WIPE_SCR 0 LINE B/BUF BLANKS ;
3
4 Don't need an editor to write to Forth disks.
5 The word P shown above will suffice.
6 Key or script in lines of text.
7 When done, UPDATE and FLUSH to save the screen.
8
9 Please note, the code shown is FigForth.
10
11
12
13
14
15

OK
bye :)