• Why is that (fig-Forth for x86)?

    From Zbig@21:1/5 to All on Sun May 8 10:09:48 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Zbig@21:1/5 to All on Sun May 8 10:30:04 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Zbig@21:1/5 to All on Sun May 8 11:05:14 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Hendrix@21:1/5 to Zbig on Sun May 8 10:20:08 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Zbig on Sun May 8 17:34:46 2022
    Zbig <zbigniew2011@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Zbig@21:1/5 to All on Sun May 8 11:20:00 2022
    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(?).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Coombs@21:1/5 to Zbig on Mon May 9 00:23:44 2022
    On Sun, 8 May 2022 10:09:48 -0700 (PDT)
    Zbig <zbigniew2011@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
    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Zbig@21:1/5 to All on Sun May 8 17:13:50 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to Zbig on Mon May 9 14:27:20 2022
    On 9/05/2022 04:05, Zbig wrote:
    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?

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to All on Mon May 9 16:57:44 2022
    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 :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Zbig@21:1/5 to All on Mon May 9 00:39:21 2022
    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. :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to Zbig on Mon May 9 18:34:14 2022
    On 9/05/2022 17:39, Zbig wrote:
    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. :)

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Coombs@21:1/5 to dxforth on Mon May 9 11:38:31 2022
    On Mon, 9 May 2022 18:34:14 +1000
    dxforth <dxforth@gmail.com> wrote:

    On 9/05/2022 17:39, Zbig wrote:
    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. :)

    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.

    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
    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From none) (albert@21:1/5 to jan4comp.lang.forth@murray-microft. on Mon May 9 14:11:47 2022
    In article <20220509002344.69e3765a@t530>,
    Jan Coombs <jan4comp.lang.forth@murray-microft.co.uk> wrote:
    On Sun, 8 May 2022 10:09:48 -0700 (PDT)
    Zbig <zbigniew2011@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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Zbig@21:1/5 to All on Mon May 9 05:55:55 2022
    Probably if you were debugging fig-forth on a PC board without the
    BIOS installed you would want exactly the same setup?

    Conceivably. Thanks!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From S Jack@21:1/5 to Zbig on Wed May 11 08:32:59 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to S Jack on Thu May 12 12:17:44 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From none) (albert@21:1/5 to dxforth@gmail.com on Thu May 12 12:53:59 2022
    In article <t5hqo9$t09$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote: >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.

    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)