Why `DP` is a user variable in some Forth systems?

[Marcos Cruz]

In the fig-Forth model and other systems (DX-Forth, CamelForth, lina,
Gforth...) `DP` is a user variable. In other systems it's an ordinary
variable.

What is the point of letting users or tasks to keep their own dictionary
pointer?

--
http://programandala.net

[foxaudio...@gmail.com]

In the systems I am familiar with, it relates to having separate memory locations for number conversion, PAD and where the output of 'WORD' is placed. Since these memory locations are many times defined in relation to 'HERE' (ie DP @) assigning a different value for DP for each task lets those tasks function properly with the ability to interpret text and even compile new definitions albeit with caveats. This is most efficiently accomplished by making DP a user variable so there is separate instance of it for each task.

In true multi-user systems like PolyForth, each task also has its own dictionary space for user specific code to reside.

BF

[Elizabeth D. Rather]

Yes. You should also be aware that in some systems it has other names: H
is common. And in some systems there's separate code and data space; on
those systems HERE returns the next location in data space.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Marcos Cruz]

En/Je/On 2015-08-22, foxaudio...@gmail.com
<foxaudio...@gmail.com> escribi'o/skribis/wrote:

> In the systems I am familiar with, it relates to having separate
> memory locations for number conversion, PAD and where the output of
> 'WORD' is placed. Since these memory locations are many times defined
> in relation to 'HERE' (ie DP @) assigning a different value for DP for
> each task lets those tasks function properly with the ability to
> interpret text and even compile new definitions albeit with caveats.
> This is most efficiently accomplished by making DP a user variable so
> there is separate instance of it for each task.

Thank you for the clarificaton. I was missing those buffers are usually
relative to the dictionary pointer. Even if `PAD` and the number
conversion buffer were not an offset of `DP`, and `WORD` would use its
own space, say a string buffer, anyway it would be useful for every task
to have its own copy of all of them. So making `DP` a user variable is
simpler.

--
http://programandala.net

[Mikael Nordman]

Having DP as a user variable means that you need to reserve separate memory areas for each task.
Flashforth has a global DP so that all memory can be allocated from one area, regardless of which task is using a particular part of the memory.

[Coos Haak]

Op Sun, 23 Aug 2015 13:17:10 -0700 (PDT) schreef Mikael Nordman:

> Having DP as a user variable means that you need to reserve separate memory areas for each task.
> Flashforth has a global DP so that all memory can be allocated from one area, regardless of which task is using a particular part of the memory.

What if one task does 'here !' and the other 'here @' ?
What if both print numbers, using the words with # ?
(solution: only one task may do i/o).
Why is it a problem to simply give separate space to each task?

groet Coos

[Mikael Nordman]

The problem with having DP as a user variable is that then you need to have a memory space pre-allocated per task.
On a small system, like FlashForth, that leads to wasted memory usage.
FF can run with 512 bytes of RAM memory and multitask.

The task variables and buffers are not relative to the global DP. The global DP just tells from where to allocate the next chunk of memory.
In that sense maybe Dictionary Pointer (DP) is the the wrong name.
It should be Allocation Pointer (AP) for example.
But for historical reasons the DP is used.
So actually a DP per task would only be needed if each task has its own dictionary, which I think is unusual these days.

In FlashForth the parsing and formatting buffers are all relative to UP.
So for example the PAD and the HOLD area for number formatting are in the user area, not at HERE. There is one PAD per task, and one HOLD area per task.
They can be of zero size if a task does not need them.
This is way there are no multitasking problems.

Greetings /Mikael

[Roelf Toxopeus]

Yes!
I have worked with a Forth doing that for years.
Mach2 (Mac/Atari): multitasking, multi-user, but one dictionary, one
global DP. All terminal tasks (running QUIT) could add to the
dictionary, only OPERATOR (the main terminal task) could prune.
Like your Flashforth, each task (terminal and background) had their own
PAD and HOLD area. Never had problems. BTW I don't know what the
underlying reason was for doing it this way. But then, I couldn't care ;-)

[Roelf Toxopeus]

On 22/08/15 21:20, Elizabeth D. Rather wrote:
> On 8/22/15 3:30 AM, foxaudio...@gmail.com wrote:
>> On Saturday, August 22, 2015 at 7:41:39 AM UTC-4, Marcos Cruz wrote:
>>> In the fig-Forth model and other systems (DX-Forth, CamelForth, lina,
>>> Gforth...) `DP` is a user variable. In other systems it's an ordinary
>>> variable.
>>>
>>> What is the point of letting users or tasks to keep their own dictionary
>>> pointer?
>>>
>>> --
>>> http://programandala.net
>>
>>
>> In the systems I am familiar with, it relates to having separate memory
>> locations for number conversion, PAD and where the output of 'WORD' is
>> placed. Since these memory locations are many times defined in relation
>> to 'HERE' (ie DP @) assigning a different value for DP for each task
>> lets those tasks function properly with the ability to interpret text
>> and even compile new definitions albeit with caveats. This is most
>> efficiently accomplished by making DP a user variable so there is
>> separate instance of it for each task.
>>
>> In true multi-user systems like PolyForth, each task also has its own
>> dictionary space for user specific code to reside.
>
> Yes. You should also be aware that in some systems it has other names: H
> is common. And in some systems there's separate code and data space; on
> those systems HERE returns the next location in data space.

FYI, Mac/Atari Mach2 had separate header-space, code-space,
variable-space and pre-alllocated task-space. HERE (DP) pointed to the
code-space. CREATE and ALLOT used the code-space as well, VARIABLEs (VP)
were allocated in the variable-space.
: BUFFER: ( n -- ) 1- CELLS VARIABLE VALLOT ;

There are more variations in the wild I assume...