• PAD and preemptive multi-tasking

    From Anton Ertl@21:1/5 to All on Fri Dec 20 10:10:31 2024
    Bernd Paysan have been wondering what to do about PAD in the presence
    of preemptive multitasking (but not multi-user) as implemented in
    Gforth.

    We see two possible scenarios:

    If PAD is used only directly by the user for interactive work, only
    one PAD is needed.

    OTOH, if PAD is used as temporary storage in words that may be called
    by any task, PAD needs to be part of the per-task (aka USER) data.

    My understanding is that classical multi-tasking Forth systems
    (polyForth, I guess) were also multi-user and had one dictionary per
    task, so they also had one dictionary pointer and therefore one PAD
    per task, but I have not worked with any of them and the descriptions
    I have read have been very sketchy, so this could be wrong.

    In any case, the question is how PAD is used by current programs that
    might be run on Gforth.

    - 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: https://forth-standard.org/
    EuroForth 2024: https://euro.theforth.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From albert@spenarnc.xs4all.nl@21:1/5 to Anton Ertl on Fri Dec 20 13:00:30 2024
    In article <2024Dec20.111031@mips.complang.tuwien.ac.at>,
    Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
    Bernd Paysan have been wondering what to do about PAD in the presence
    of preemptive multitasking (but not multi-user) as implemented in
    Gforth.

    We see two possible scenarios:

    If PAD is used only directly by the user for interactive work, only
    one PAD is needed.

    OTOH, if PAD is used as temporary storage in words that may be called
    by any task, PAD needs to be part of the per-task (aka USER) data.

    My understanding is that classical multi-tasking Forth systems
    (polyForth, I guess) were also multi-user and had one dictionary per
    task, so they also had one dictionary pointer and therefore one PAD
    per task, but I have not worked with any of them and the descriptions
    I have read have been very sketchy, so this could be wrong.

    This model is followed by ciforth.
    Note that ciforth manages its own memory, and it is in one segment;
    it can be huge if need be, hundreds of Gbyte.
    Three parts: forth, dictionary space , and stacks and buffers.
    [ In Fig Forth fashion the dictionary could be huge growing up and
    the same area could be used by the data stack growing down,
    accommodating some weird Euler problems.]
    In multi tasking: a new dictionary space and s&b is carved out
    from the mother dictionary space, multiple times if need be.
    The forth area is common, however, you can defined compiled words
    in your own dictionary space.
    But now you have to decide on a restricted dictionary space,
    [it can be large, Gbytes.]
    This accommodates pre-emptive and cooperating tasks alike.
    Child task area's can be forgotten as you long as you exit pre-emptive
    tasks.

    A SAVE-SYSTEM stores all the space reserved for child task area's,
    so including the empty dictionary spaces.
    A single task needs to save only the first part (forth), so this is exponentially smaller, the dictionary and s&b is not saved.

    User variable and transient areas are independant and pose no problem.
    There is no reason real "preemptive" multitasking couldn't accommodate
    multiple users, it also makes no sense.

    This is so simple because the dictionary model is a single linked list
    per wordlist. So the child tasks can link to this. This happens
    automagically by cloning user variables like CONTEXT and CURRENT.


    In any case, the question is how PAD is used by current programs that
    might be run on Gforth.

    - anton

    Groetjes Albert
    --
    Temu exploits Christians: (Disclaimer, only 10 apostles)
    Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
    Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
    And Gifts For Friends Family And Colleagues.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Rubin@21:1/5 to Anton Ertl on Fri Dec 20 13:17:54 2024
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    In any case, the question is how PAD is used by current programs that
    might be run on Gforth.

    I thought the standard required PAD to be usable as random scratch
    memory. So I'd expect Gforth to allocate one for each task. Gforth
    systems aren't likely to suffer memory shortages from doing that. It
    would be more of an issue for Polyforth.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Paul Rubin on Sat Dec 21 11:44:22 2024
    Paul Rubin <no.email@nospam.invalid> writes:
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    In any case, the question is how PAD is used by current programs that
    might be run on Gforth.

    I thought the standard required PAD to be usable as random scratch
    memory.

    The standard does not specify multi-tasking.

    So I'd expect Gforth to allocate one for each task.

    My question is: How have you used PAD?

    Gforth
    systems aren't likely to suffer memory shortages from doing that.

    Depends on the number of tasks. If PAD is not used in a way that
    requires one PAD per task, it's better not to implement that.

    - 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: https://forth-standard.org/
    EuroForth 2024: https://euro.theforth.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to dxf on Sat Dec 21 11:26:24 2024
    dxf <dxforth@gmail.com> writes:
    On 20/12/2024 9:10 pm, Anton Ertl wrote:
    Bernd Paysan have been wondering what to do about PAD in the presence
    of preemptive multitasking (but not multi-user) as implemented in
    Gforth.

    You may need to explain 'preemptive' and its relevance here.

    "Preemptive multi-tasking" means that a task switch can happen at any
    time, not just at PAUSE or when invoking I/O words as with cooperative multitasking in traditional Forth. What we have in Gforth is actually
    that the tasks can run in parallel on several CPU cores, but the
    effects on software are similar to preemptive multi-tasking (there's
    the problem of weaker memory ordering (than sequential consistency),
    but that's only an issue when you want to communicate through shared
    memory).

    The relevance is that with cooperative multi-tasking a possible usage
    pattern of PAD would be to use it between two PAUSEs, but not across
    PAUSE etc. That usage would be compatible with having only one PAD.
    With preemptive multi-tasking (and parallel processing) one would need
    to use a mutual exclusion construct around such usages (and existing
    Forth code using PAD certainly does not have that).

    - 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: https://forth-standard.org/
    EuroForth 2024: https://euro.theforth.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From josv@21:1/5 to Anton Ertl on Sat Dec 21 13:28:43 2024
    On Fri, 20 Dec 2024 10:10:31 +0000, Anton Ertl wrote:

    Bernd Paysan have been wondering what to do about PAD in the presence
    of preemptive multitasking (but not multi-user) as implemented in
    Gforth.

    We see two possible scenarios:

    If PAD is used only directly by the user for interactive work, only
    one PAD is needed.

    OTOH, if PAD is used as temporary storage in words that may be called
    by any task, PAD needs to be part of the per-task (aka USER) data.

    My understanding is that classical multi-tasking Forth systems
    (polyForth, I guess) were also multi-user and had one dictionary per
    task, so they also had one dictionary pointer and therefore one PAD
    per task, but I have not worked with any of them and the descriptions
    I have read have been very sketchy, so this could be wrong.

    In any case, the question is how PAD is used by current programs that
    might be run on Gforth.

    - anton

    I use upad instead:
    maxcounted 1+ newuser upad

    Jos

    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From albert@spenarnc.xs4all.nl@21:1/5 to Anton Ertl on Sat Dec 21 19:05:39 2024
    In article <2024Dec21.122624@mips.complang.tuwien.ac.at>,
    Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
    <SNIP>
    The relevance is that with cooperative multi-tasking a possible usage
    pattern of PAD would be to use it between two PAUSEs, but not across
    PAUSE etc. That usage would be compatible with having only one PAD.
    With preemptive multi-tasking (and parallel processing) one would need
    to use a mutual exclusion construct around such usages (and existing
    Forth code using PAD certainly does not have that).

    I have looked into that for ciforth and that is not the case.
    By duplicating the dictionary the PAD is automatically changed
    because task have separate set of user variables, notably HERE.

    Thinking of this ...
    If the parallel forth's are running in separate cores, and
    compile at the same time, the buffer used by the WANT mechanism can
    get conflicting uses.
    So I originally used PAD and changed that to a dedicated buffer,
    but it is better to change it back. This saves 4 WOC.

    You cannot use PAD to collect information during compilation,
    but that is an insanely bad idea.


    - anton
    --
    Temu exploits Christians: (Disclaimer, only 10 apostles)
    Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
    Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
    And Gifts For Friends Family And Colleagues.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From albert@spenarnc.xs4all.nl@21:1/5 to josv on Sat Dec 21 19:11:10 2024
    In article <e0ef0cb70945d70d0a1e65f66dd5af4f@www.novabbs.com>,
    josv <josv@planet.nl> wrote:

    <Discussion of the use of PAD in multi tasking>

    I use upad instead:
    maxcounted 1+ newuser upad

    I understand that you allocate a pad in the user area.
    That can be safe, but it must be part of the Forth itself
    before compilation. Otherwise you prevent a compiled program
    to allocate any user variables.


    Jos

    Groetjes Albert
    --
    Temu exploits Christians: (Disclaimer, only 10 apostles)
    Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
    Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
    And Gifts For Friends Family And Colleagues.

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