Why is that (fig-Forth for x86)?

[Zbig]

Hello,
Examining old fig-Forth I noticed a strange thing at its very beginning. Its code starts with a sequence:
ORIG: NOP ; (ORIGIN)
JMP CLD
NOP
JMP WRM

So while it looks obvious, it's also obvious that there is little chance that second jump will be ever performed. I examined the whole listing — there is no reference to that place in code; there's not anything like "ORIG+4" (nor "ORIG+6", to take just jump address), for example.
Using debugger I set a trap on that fourth line — no chance to get there neither by starting the Forth system, nor by performing COLD, ABORT, QUIT. In the end I simply replaced that "JMP WRM" with three NOPs — so far noticed no change in the functionality of the system.
So it seems it's really kind of "leftover". But I posted this question because I could see similar sequence in the other listing. So what does it mean, actually? Is it kind of "tradition" to leave that useless(?) jump there, or I'm still missing something?

[Marcel Hendrix]

On Sunday, May 8, 2022 at 7:09:49 PM UTC+2, Zbig wrote:
> Hello,
> Examining old fig-Forth I noticed a strange thing at its very beginning. Its code starts with a sequence:
> ORIG: NOP ; (ORIGIN)
> JMP CLD
> NOP
> JMP WRM
>

[..]

> So what does it mean, actually? Is it kind of "tradition" to leave that useless(?) jump there,
> or I'm still missing something?

Maybe it was used for debugging or single-stepping?

-marcel

[Zbig]

> Maybe it was used for debugging or single-stepping?

Well, that's why I've raised my question. No reference to that specific line anywhere, which has no label. I'm confused.

[Anton Ertl]

Zbig <zbigni...@gmail.com> writes:
>Hello,
>Examining old fig-Forth I noticed a strange thing at its very beginning. It=

>s code starts with a sequence:
>ORIG: NOP ; (ORIGIN)
> JMP CLD
> NOP
> JMP WRM

Wild guess: Interrupt vectors? If you press reset, the CPU jumps to
ORIG (or uses ORIG+2 asvector address. And for some other interrupt,
the same with ORIG+4/6.

- 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 2021: https://euro.theforth.net/2021

[Zbig]

> Wild guess: Interrupt vectors? If you press reset, the CPU jumps to
> ORIG (or uses ORIG+2 asvector address. And for some other interrupt,
> the same with ORIG+4/6.

Both the Forths where I found that sequence are "hosted Forths" for DOS (ordinary "com" binaries).
So rather not this case, it seems. That ORIG means just ORIGIN for address space of fig-Forth system.
I understand that much more experienced Forthers are (almost) as confused as I am?

[Zbig]

OK, if anyone's willing to take a closer look, I mean (first of all) this file: http://www.forth.org/fig86new.zip

Have a look at the lines 136 to 139.

Another strange thing seem to me code section from line 164 to 186 (including).
These lines also don't seem to be referenced anywhere(?).

[Jan Coombs]

On Sun, 8 May 2022 10:09:48 -0700 (PDT)
Zbig <zbigni...@gmail.com> wrote:

> Hello,
> Examining old fig-Forth I noticed a strange thing at its very beginning.
> Its code starts with a sequence:

ORG 100H

> ORIG: NOP ; (ORIGIN)
> JMP CLD
> NOP
> JMP WRM

With the NOP these vectors are accessible at 4 byte boundaries in the 16b
DR/PC/MS-DOS systems this is designed to run on. (search 'org 100h')

From 'Fig Forth Systems Guide.pdf':
"ABORT call ABORT, the warm start procedure" WRM?
[...] Using COLD will remove the user program.

From 'fig86new/FIG86NEW/FORTH1.TXT':
"COLD sets the <CTRL-C> interrupt vector (MS-DOS function 25h)
to the address of a code fragment which vectors the interpreter
to (ABORT)."

As happens here (from 'fig86new/FIG86NEW/FORTH.ASM'):

CTRLC:
WRM: MOV SI,OFFSET WRM1
JMP NEXT
WRM1 DW PABOR

And enters ABORT here:

DB 87H,"(ABORT",")"+80h
DW DFIND - 8
PABOR DW DOCOL
DW ABORT, SEMIS

> So what does it mean, actually?

If your code crashes, or locks up, then pressing ^C may return
you to your runnable system with user compiled code intact, or
at least get you back to DOS.

Jan Coombs
--

[Zbig]

> > Examining old fig-Forth I noticed a strange thing at its very beginning.
> > Its code starts with a sequence:
> ORG 100H
> > ORIG: NOP ; (ORIGIN)
> > JMP CLD
> > NOP
> > JMP WRM
> With the NOP these vectors are accessible at 4 byte boundaries in the 16b
> DR/PC/MS-DOS systems this is designed to run on. (search 'org 100h')

Indeed that's self-understandable — my problem to be solved is: there isn't neither any label
before "JMP WRM" nor there is anywhere in the code any reference to that line even in the
form "ORIG+4" or the like. So it doesn't seem to be used at all — but it's present there, so
if I'm missing anything, I'd like to learn more.
Found such sequence in other fig-Forth too, also it's described in "Programmiersprache Forth"
(AKA "Forth for Professionals") by Ronald Zech (chapter 7.3. pages 228-229). Mentioned and
shown in the listing — but unfortunately NOT explained.

> From 'Fig Forth Systems Guide.pdf':
> "ABORT call ABORT, the warm start procedure" WRM?
> [...] Using COLD will remove the user program.
>
> From 'fig86new/FIG86NEW/FORTH1.TXT':
> "COLD sets the <CTRL-C> interrupt vector (MS-DOS function 25h)
> to the address of a code fragment which vectors the interpreter
> to (ABORT)."
>
> As happens here (from 'fig86new/FIG86NEW/FORTH.ASM'):
>
> CTRLC:
> WRM: MOV SI,OFFSET WRM1
> JMP NEXT
> WRM1 DW PABOR

The above is interrupt handler, which is set by lines 1876 to 1879.
Still no reference to line at "ORIG+4".

> And enters ABORT here:
>
> DB 87H,"(ABORT",")"+80h
> DW DFIND - 8
> PABOR DW DOCOL
> DW ABORT, SEMIS
> > So what does it mean, actually?
> If your code crashes, or locks up, then pressing ^C may return
> you to your runnable system with user compiled code intact, or
> at least get you back to DOS.

Yes, I understand, why there is CTRL-C handler — but the above still isn't answer
to my question.

[dxforth]

FIG was designed to be portable across CPUs and host systems. Patch locations
for jumps and debugging are to be expected. IIRC +ORIGIN was used as a reference
to other fields in a Fig system. While a DOS-hosted system may have had little
need of JMP WRM there was no harm leaving it in - nor gain removing it.

[dxforth]

According to the Fig-FORTH Installation Manual:

Boot-up Parameters

This area consists of 34 bytes containing a jump to the cold start,
jump to the warm re-start and initial values for user variables and
registers. These values are altered as you make permanent
extensions to your installation.

SCR # 12
0 ( COLD AND WARM ENTRY, USER PARAMETERS WFR-79APR29 )
1 ASSEMBLER OBJECT MEM HEX
2 NOP, HERE JMP, ( WORD ALIGNED VECTOR TO COLD )
3 NOP, HERE JMP, ( WORD ALIGNED VECTOR TO WARM )
4 0000 , 0001 , ( CPU, AND REVISION PARAMETERS )
5 0000 , ( TOPMOST WORD IN FORTH VOCABULARY )
6 7F , ( BACKSPACE CHARACTER )
7 3BA0 , ( INITIAL USER AREA )
8 009E , ( INITIAL TOP OF STACK )
9 01FF , ( INITIAL TOP OF RETURN STACK )
10 0100 , ( TERMINAL INPUT BUFFER )
11 001F , ( INITIAL NAME FIELD WIDTH )
12 0001 , ( INITIAL WARNING = 1 )
13 0200 , ( INITIAL FENCE )
14 0000 , ( COLD START VALUE FOR DP )
15 0000 , ( COLD START VALUE FOR VOC-LINK ) -->

Being gospel, one's duty is to implement - not question :)

[Zbig]

> FIG was designed to be portable across CPUs and host systems. Patch locations
> for jumps and debugging are to be expected. IIRC +ORIGIN was used as a reference
> to other fields in a Fig system. While a DOS-hosted system may have had little
> need of JMP WRM there was no harm leaving it in - nor gain removing it.

Thanks, so it seems my initial „wild guess” that it's kind of „tradition” to keep that there (never mind is it later used at all) was proper. :)

[dxforth]

A potential use is systems which had a monitor ROM.

MON
Exit to the system monitor, leaving a re-entry to Forth,
if possible.

Forth could be re-entered using either COLD or WARM vectors. WARM entry would
ensure user-additions didn't get wiped.

[Jan Coombs]

Similarly, and also:

When fig forth was being developed, a typical board would have discrete
EPROM and RAM chips. The EPROM would contain the system monitor and
interrupt vectors.

The faster method is to develop the new forth image would be in RAM,
if you had enough. This can be quickly re-written using the monitor.
The development process, adding and removing test and debug code
snippets will likely change the cold and warm start handler locations,
as these are generally located at the top of the image. (This was
likely inherited from the code originally being built using a cross
compiler written in Forth.)

Having the location of a warm start vector at a constant address in
the forth image avoided the need to hook out the monitor ROM and
update the vector content there.

Probably if you were debugging fig-forth on a PC board without the
BIOS installed you would want exactly the same setup?

Jan Coombs
--

[none albert]

In article <20220509002344.69e3765a@t530>,

ciforth inherits these vectors from fig-Forth and they are still
usable.

-2 CELLS +ORIGIN is the cold start vector
-1 CELLS +ORIGIN is the warm start vector

If anything untowards happens in a linux executable, you
have a last change to do something, using a "signal handler".
Signals are e.g. ^C interrupt, invalid address etc.
It is a simple address where the executable is restarted, so
a jump.

So you have such code as:
\ Make sure any traps restart Forth at ADDRESS .
: SET-TRAPS 32 1 DO I OVER 0 __NR_signal XOS DROP LOOP DROP ;

\ Still fig tradition: warm and cold starts below origin
: SET-TRAPS-WARM -2 CELLS +ORIGIN SET-TRAPS ;

This doesn't differentiate between traps, it just executes the
word COLD.
If you want something more sophisticated then that, you must
provide code to replace COLD, to take care of specific signal
behaviour. You are wildly into system programming.

In 1980 you were required two perform two diskette changes to reboot and
this was useful. Nowadays you would be more inclined to restart
the Forth from the command line. The usefulness is ca. limited to be
able to type ^C to end an infinite loop.

>
>Jan Coombs
>--
>

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Zbig]

> Probably if you were debugging fig-forth on a PC board without the
> BIOS installed you would want exactly the same setup?

Conceivably. Thanks!

[S Jack]

On Sunday, May 8, 2022 at 12:09:49 PM UTC-5, Zbig wrote:
> So it seems it's really kind of "leftover". But I posted this question because I could see similar sequence in the other listing. So what does it mean, actually? Is it kind of "tradition" to leave that useless(?) jump there, or I'm still missing something?

Not much help here I forget the details but I'm almost sure I used both
cold and warm with DOS. I know I used warm with the Atari OS with its
system error vector pointed to warm start which printed message and
aborted. Nice that I didn't have to restart and reload the Forth.
I still have them in current system but don't have anything pointed to
the warm start; SEVG points to code that pushes an error number and
executes ERROR .
Didn't use them for debug; Fig has stack trace (which I never used).
--
me

[dxforth]

On 12/05/2022 01:32, S Jack wrote:
> On Sunday, May 8, 2022 at 12:09:49 PM UTC-5, Zbig wrote:
>> So it seems it's really kind of "leftover". But I posted this question because I could see similar sequence in the other listing. So what does it mean, actually? Is it kind of "tradition" to leave that useless(?) jump there, or I'm still missing something?
>
> Not much help here I forget the details but I'm almost sure I used both
> cold and warm with DOS. I know I used warm with the Atari OS with its
> system error vector pointed to warm start which printed message and
> aborted.

> ...

That's a credible use. For reasons unknown MVP-FORTH (based on Fig-FORTH) removed
both the WARM start vector and the built-in divide-by-zero checks. Anything that
triggered the div-zero interrupt would drop you out of Forth. The worry with
redirecting system interrupts is what happens to the system when forth does crash.

[none albert]

It is the same with exceptions that are caught.
If you can't fix the situation, that is a crash.
If you catch the exception, that by itself changes nothing to the crash.