It seems context is always defined as a variable.
Would there be a problem if it was defined as a USER so
multiple tasks could have their own search context at the same time?
Jos

Jos Ven schrieb am Freitag, 5. Mai 2023 um 10:17:54 UTC+2:
> It seems context is always defined as a variable.
> Would there be a problem if it was defined as a USER so
> multiple tasks could have their own search context at the same time?

To hold a task-specific search-order you need a task-specific array/list.
Whether you call this array/list or a pointer to it CONTEXT is implementation
defined.

Op vrijdag 5 mei 2023 om 10:34:07 UTC+2 schreef minforth:
> Jos Ven schrieb am Freitag, 5. Mai 2023 um 10:17:54 UTC+2:
> > It seems context is always defined as a variable.
> > Would there be a problem if it was defined as a USER so
> > multiple tasks could have their own search context at the same time?
> To hold a task-specific search-order you need a task-specific array/list.
> Whether you call this array/list or a pointer to it CONTEXT is implementation
> defined.

> CONTEXT is implementation defined.
That is the problem.
Under Gforth, Win32forth context is defined as a variable.
There a variable is a kind of global within Forth then
all tasks get the same context.

In article <8e360ba4-7f02-4a0b-ba1b-aa2977b2127cn@googlegroups.com>,
Jos Ven <josv@planet.nl> wrote:
>It seems context is always defined as a variable.
>Would there be a problem if it was defined as a USER so
>multiple tasks could have their own search context at the same time?
>Jos

In a decent design (ciforth) the list of context wordlist is
naturally allocated in the space of USER variables.
Otherwise it would not make sense to allow processes to compile their
own separated definitions.

Groetjes Albertg
--
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 spinning. - the Wise from Antrim -

On Friday, May 5, 2023 at 4:17:54 AM UTC-4, Jos Ven wrote:
> It seems context is always defined as a variable.
> Would there be a problem if it was defined as a USER so
> multiple tasks could have their own search context at the same time?
> Jos

FigForth defined CONTEXT as a user variable.
People seemed to forget about multi-tasking and multi-user features
in Forth as time went on.
Once you have an O/S underneath I guess it matters less.

Brian Fox schrieb am Freitag, 5. Mai 2023 um 17:39:34 UTC+2:
> On Friday, May 5, 2023 at 4:17:54 AM UTC-4, Jos Ven wrote:
> > It seems context is always defined as a variable.
> > Would there be a problem if it was defined as a USER so
> > multiple tasks could have their own search context at the same time?
> > Jos
> FigForth defined CONTEXT as a user variable.
> People seemed to forget about multi-tasking and multi-user features
> in Forth as time went on.
> Once you have an O/S underneath I guess it matters less.

AFAIK Forth never had a decent interrupt handler or timer. That was
the main shortcoming, while seemingly savvy people argued enthusiastically
about pros and cons of cooperative round-robin scheduling. Water under
the bridge...

On 5/5/23 11:25 AM, minforth wrote:

> AFAIK Forth never had a decent interrupt handler or timer. That was
> the main shortcoming, while seemingly savvy people argued enthusiastically
> about pros and cons of cooperative round-robin scheduling. Water under
> the bridge...

I found adding interrupt handling to an ARM version of eForth pretty
easy. It helps that so much context is saved to the stack before the ISR
begins.

--
http://davesrocketworks.com
David Schultz

Jos Ven <josv@planet.nl> writes:
>It seems context is always defined as a variable.

In Gforth it's a deferred word that is filled with a colon definition
that produces an address of a search-order entry.

>Would there be a problem if it was defined as a USER so
>multiple tasks could have their own search context at the same time?

No problem in principle; of course it depends on the individual system
what you need to do to support searching in multiple tasks.

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

Jos Ven <josv@planet.nl> writes:
>Under Gforth, Win32forth context is defined as a variable.

Not in the Gforth versions I have looked at (0.7 and the current
development version).

>There a variable is a kind of global within Forth then
>all tasks get the same context.

In Gforth we have discussed whether we want to support compilation
(and, more generally, text interpretation) in multiple tasks, and
decided against it.

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

In article <r1-dnQcSYJea1sj5nZ2dnZfqnPdg4p2d@earthlink.com>,
David Schultz <david.schultz@earthlink.net> wrote:
>On 5/5/23 11:25 AM, minforth wrote:
>
>> AFAIK Forth never had a decent interrupt handler or timer. That was
>> the main shortcoming, while seemingly savvy people argued enthusiastically
>> about pros and cons of cooperative round-robin scheduling. Water under
>> the bridge...
>
>I found adding interrupt handling to an ARM version of eForth pretty
>easy. It helps that so much context is saved to the stack before the ISR
>begins.

Many Forths have support for interrupts, but there is not really
a common ground. Forth's for single board computers (MSP430,
Arduino, 8051) have supported it because it enhances the usability
of those boards.
See e.g.
https://home.hccnet.nl/anij/nof/noforth.html
and link through to Egel project.
It contains several examples using interrupts, and you are right,
it is not a big deal using interrupts on those stand alone Forths.
A different situation occurs on Linux/MS-Windows because the
OS jealously guards those interrupts.

>--
>http://davesrocketworks.com
>David Schultz
>
--
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 spinning. - the Wise from Antrim -

Op zaterdag 6 mei 2023 om 12:30:06 UTC+2 schreef Anton Ertl:
> Jos Ven <jo..> writes:
> >Under Gforth, Win32forth context is defined as a variable.
> Not in the Gforth versions I have looked at (0.7 and the current
> development version).
> >There a variable is a kind of global within Forth then
> >all tasks get the same context.
> In Gforth we have discussed whether we want to support compilation
> (and, more generally, text interpretation) in multiple tasks, and
> decided against it.
> - 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 2022: https://euro.theforth.net

Hi,

> >Under Gforth, Win32forth context is defined as a variable.

Sorry, you are right.
I should have looked better when I got into problems.
Thanks for the correction.

Jos

Op zaterdag 6 mei 2023 om 12:30:06 UTC+2 schreef Anton Ertl:
> Jos Ven <jo...> writes:
> >Under Gforth, Win32forth context is defined as a variable.
> Not in the Gforth versions I have looked at (0.7 and the current
> development version).
> >There a variable is a kind of global within Forth then
> >all tasks get the same context.
> In Gforth we have discussed whether we want to support compilation
> (and, more generally, text interpretation) in multiple tasks, and
> decided against it.
> - 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 2022: https://euro.theforth.net

Hi,
My problem was as follows:
2 tasks are using the same word.
In a first attempt the context was saved at the start of the word and restored at the exit.
That did not work.
Now the context of the whole program is changed before the 2 tasks are running.
That solved my problem.
Jos