1. Forum
  2. Usenet
  3. COMP.LANG.FORTH

  • Re: Vector to warm start (fig-Forth)

    From David Schultz@21:1/5 to LIT on Sun Jun 9 15:33:59 2024
    On 6/9/24 2:09 PM, LIT wrote:
    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.


    --
    http://davesrocketworks.com
    David Schultz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sjack@21:1/5 to LIT on Sun Jun 9 23:20:59 2024
    LIT <[email protected]> wrote:
    Every fig-Forth is started with a sequence:
    ...
    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.

    --
    me

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to LIT on Mon Jun 10 13:42:35 2024
    In article <[email protected]>,
    LIT <[email protected]> wrote:
    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"?

    +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
    --
    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 purring. - the Wise from Antrim -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to LIT on Mon Jun 10 17:56:46 2024
    In article <[email protected]>,
    LIT <[email protected]> wrote:
    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
    --
    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 purring. - the Wise from Antrim -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to LIT on Mon Jun 10 19:13:59 2024
    In article <[email protected]>,
    LIT <[email protected]> wrote:
    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
    --
    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 purring. - the Wise from Antrim -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sjack@21:1/5 to LIT on Thu Jun 13 02:41:19 2024
    LIT <[email protected]> wrote:

    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 :)
    --
    me

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