Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #56560 > unrolled thread

Why does the location of PAD move around?

Back to article view | Back to comp.lang.forth

Contents

  Why does the location of PAD move around? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-01 21:07 -0400
    Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-01 19:32 -0700
      Re: Why does the location of PAD move around? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-02 02:00 -0400
        Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-01 23:51 -0700
          Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-01 21:59 -1000
          Re: Why does the location of PAD move around? krishna.myneni@ccreweb.org - 2017-04-09 09:54 -0700
    Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-01 20:10 -0700
      Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-01 18:39 -1000
      Re: Why does the location of PAD move around? Mark Wills <markwills1970@gmail.com> - 2017-04-02 08:29 -0700
    Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:13 -0500
      Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-02 18:08 -0700
        Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-02 18:13 -0700
          Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-02 18:22 -0700
            Re: Why does the location of PAD move around? Julian Fondren <julian.fondren@gmail.com> - 2017-04-02 18:31 -0700
            Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-03 04:37 +0200
              Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-02 22:04 -0700
                Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 13:47 +0200
                  Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 10:53 -0500
                    Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-04 17:04 +0100
                    Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:00 +0200
                      Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 03:39 -0500
                        Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-05 19:17 +0100
              Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:44 -1000
            Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:35 -1000
            Re: Why does the location of PAD move around? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:38 -0500
            Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-05 11:25 +1000
              Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:23 -0700
                Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-07 14:26 +1000
                  Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-07 08:47 +0100
                    Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-08 10:25 +1000
                      Re: Why does the location of PAD move around? Paul Rubin <no.email@nospam.invalid> - 2017-04-07 20:37 -0700
                      Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-08 12:42 +0100
                        Re: Why does the location of PAD move around? jason.songhurst@gmail.com - 2017-04-08 20:28 -0700
                          Re: Why does the location of PAD move around? Coos Haak <htrofhc@gmail.com> - 2017-04-09 13:47 +0200
                            Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-09 08:36 -1000
                          Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-09 14:48 +0200
                        Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-10 10:31 +1000
                          Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-10 09:29 +0100
                          Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-10 11:57 +0200
        Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-03 03:43 +0200
          Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:53 -1000
    Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-02 21:31 +1000
      Re: Why does the location of PAD move around? Coos Haak <htrofhc@gmail.com> - 2017-04-02 15:12 +0200
        Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-03 10:46 +1000
          Re: Why does the location of PAD move around? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-03 03:31 +0200
            Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 19:14 -0700
          Re: Why does the location of PAD move around? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-02 21:55 -1000
            Re: Why does the location of PAD move around? "HAA" <someone@microsoft.com> - 2017-04-04 11:06 +1000
              Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-04 12:54 +0100
                Re: Why does the location of PAD move around? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:27 +0000
                  Re: Why does the location of PAD move around? Alex <alex@rivadpm.com> - 2017-04-04 19:23 +0100
            Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-07 22:04 -0700
      Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 14:21 -0700
    Why does the location of PAD move around? Mark Wills <markwills1970@gmail.com> - 2017-04-02 08:28 -0700
      Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 13:47 -0700
        Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 15:13 -0700
          Re: Why does the location of PAD move around? hughaguilar96@gmail.com - 2017-04-02 18:55 -0700

Page 1 of 3  [1] 2 3  Next page →

#56560 — Why does the location of PAD move around?

Why does the location of PAD move around?

TIB is allocated at a fixed location, but
PAD's location is relative to HERE.


Rod Pemberton
-- 
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.

[toc] | [next] | [standalone]

#56561

On Saturday, April 1, 2017 at 6:06:23 PM UTC-7, Rod Pemberton wrote:
> Why does the location of PAD move around?
> 
> TIB is allocated at a fixed location, but
> PAD's location is relative to HERE.

Asking such a question is like asking somebody to hold the bucket while you milk a male goat.

PAD was taught in the novice class at Forth Inc.. I can easily imagine an exchange like this:
-------------------------------------------------------------------------
student: Why does the location of PAD move around?

Andrew Haley: That is a very good question! Your question shows that you are paying attention to the course material and thinking about it! The answer is...
-------------------------------------------------------------------------

So, be a sport Andrew Haley --- answer Rod Pemberton's question for him! LOL

Elizabeth Rather appointed you to the Forth-200x committee because you were employed at Forth Inc. and taught the novice class there. You must certainly have fielded this question already while teaching that class. Prove to us that you are fully qualified to be a Forth-200x committee member! LOL

[toc] | [prev] | [next] | [standalone]

#56572

On Sat, 1 Apr 2017 19:32:17 -0700 (PDT)
hughaguilar96@gmail.com wrote:

> On Saturday, April 1, 2017 at 6:06:23 PM UTC-7, Rod Pemberton wrote:
> > Why does the location of PAD move around?
> > 
> > TIB is allocated at a fixed location, but
> > PAD's location is relative to HERE.  
> 
> Asking such a question is like asking somebody to hold the bucket
> while you milk a male goat.

Smart ass, ...

Well, I'm not familiar with the historical uses of PAD, yet, but it
would seem that you could store data in memory relative to PAD in either
direction (up, down), unlike TIB where characters will be stored in
only one direction relative to TIB's address.  For PAD, one of the two
directions is likely to run into the end of the dictionary.  So, if you
wanted to prevent access to the dictionary from the use of PAD's
address, what would you do?  E.g., perhaps someone wants to prevent
intentional corruption of or accidental overwriting of the dictionary.
Where would you relocated PAD to?  Would you set PAD to a fixed-sized
buffer like TIB ?  For a fixed-sized buffer, would you need to
preallocate space on both sides of PAD's address for either upward or
downward storage?  I'm looking to correctly preserve the historic uses
of PAD while also changing PAD's location to limit aberrant access to
the dictionary.  Since PAD's location moves, I can't use fixed addresses
or pointer values for comparison for buffer under- or over-flow of
PAD.  I would need to use a variable, which in my case, would also
need to be accessible via C code.  I can do that, but it complicates the
issue and slows down the code too.  The ideal solution would be to have
a fixed address for PAD , i.e., single integer value, hence non-moving.

Are you interested in the question now Hugh, or are you still going to
insist that Andrew answer because the original question was so simple?


Rod Pemberton
-- 
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.

[toc] | [prev] | [next] | [standalone]

#56576

On Sunday, April 2, 2017 at 12:59:04 AM UTC-5, Rod Pemberton wrote:
> I'm looking to correctly preserve the historic uses
> of PAD while also changing PAD's location to limit aberrant access to
> the dictionary.

I feel like you're focusing too much on that aspect.  That PAD's
location changes is not well-known because it's a feature desired by
the code using it, but because it's a hazard that must be kept in mind
when code uses it. If you switched to a static location you'd lose the
small benefits I mentioned before but I doubt much if any code would
break.

Anyway,

1. PAD is a standard word and standard programs don't expect much from
it. http://forth-standard.org/standard/usage#usage:transient

2. this is Forth so if code does break because a nonstandard property
of PAD was expected, you can load the code with a prelude that
restores that property.

  \ oops we write to PAD plus/minus a few blocks
  align 1024 4 * dup allot here allot constant pad

3. kForth defines PAD thusly (in examples/ans-words.4th -- it's CORE
EXT after all):

  CREATE PAD 512 ALLOT

kForth doesn't even have the traditional space that PAD would index
into: http://ccreweb.org/software/kforth/kforth5.html#ANS%20Forth%20Compliance

But since it documents that, people know what they're getting into.

[toc] | [prev] | [next] | [standalone]

#56578

On 4/1/17 8:51 PM, Julian Fondren wrote:
> On Sunday, April 2, 2017 at 12:59:04 AM UTC-5, Rod Pemberton wrote:
>> I'm looking to correctly preserve the historic uses
>> of PAD while also changing PAD's location to limit aberrant access to
>> the dictionary.
>
> I feel like you're focusing too much on that aspect.  That PAD's
> location changes is not well-known because it's a feature desired by
> the code using it, but because it's a hazard that must be kept in mind
> when code uses it. If you switched to a static location you'd lose the
> small benefits I mentioned before but I doubt much if any code would
> break.

The rules by which PAD *may* move are very specific: the address 
returned by PAD may move after any of these events:
	* a definition is created by a defining word
	* definitions are compiled with : or :NONAME
	* data space is allocated using ALLOT, , (comma), C, or ALIGN.

The general principal is that PAD may be defined relative to the top of 
the dictionary. In a system where code and data space are in separate 
spaces, PAD may move with changes to data space.

> Anyway,
>
> 1. PAD is a standard word and standard programs don't expect much from
> it. http://forth-standard.org/standard/usage#usage:transient

Standard programs can certainly use it, under the rules above. It is 
supposed to be an application resource; system words are forbidden to 
use it or change it except in accordance with the rules above.

> 2. this is Forth so if code does break because a nonstandard property
> of PAD was expected, you can load the code with a prelude that
> restores that property.
>
>   \ oops we write to PAD plus/minus a few blocks
>   align 1024 4 * dup allot here allot constant pad
>
> 3. kForth defines PAD thusly (in examples/ans-words.4th -- it's CORE
> EXT after all):
>
>   CREATE PAD 512 ALLOT
>
> kForth doesn't even have the traditional space that PAD would index
> into: http://ccreweb.org/software/kforth/kforth5.html#ANS%20Forth%20Compliance
>
> But since it documents that, people know what they're getting into.
>

Cheers,
Elizabbeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#56937

On Sunday, April 2, 2017 at 1:51:36 AM UTC-5, Julian Fondren wrote:
...
> 3. kForth defines PAD thusly (in examples/ans-words.4th -- it's CORE
> EXT after all):
> 
>   CREATE PAD 512 ALLOT
> 
> kForth doesn't even have the traditional space that PAD would index
> into: http://ccreweb.org/software/kforth/kforth5.html#ANS%20Forth%20Compliance
> 
> But since it documents that, people know what they're getting into.


Yes, the dynamic dictionary space allows writing

    CREATE PAD 1048576 ALLOT

or, really, any number or bytes your computer's memory or virtual memory can support, should you want or need that.

Krishna

[toc] | [prev] | [next] | [standalone]

#56562

On Saturday, April 1, 2017 at 8:06:23 PM UTC-5, Rod Pemberton wrote:
> Why does the location of PAD move around?
> 

It's a cheap way to get temporary indefinite-length memory. If it
didn't move around, it wouldn't be temporary: it would be memory
permanently reserved as a buffer, even if never used at runtime. The
offset puts it out the way of other traditional uses for unallotted
dictionary space, and puts it out of the way of one's own immediate
consumption of that space.

A downside of this is that the following statements are false:

    PAD 1 ALLOT PAD =

    PAD VARIABLE BOB PAD =

    PAD : BUFFER: ( size "name" -- ) CREATE ALLOT ; PAD =

Meaning that you may to shepherd a value of PAD through a word when
you could, of a constant, just name it again where you want it again.

> TIB is allocated at a fixed location, but
> PAD's location is relative to HERE.

Hmm. My guess: in the era of multi-user Forth system with built-in
block editors, which was also the era before it was considered
shameful to have things like limited input buffers, a TIB of some
small size was assumed to always be necessary. Even today there are
license provisions for leaving an engineering panel in a deployed
program, so to speak, and there are techniques like loading a config
file by EVALUATEing it with a restricted dictionary.

Forth is interactive, after all.

[toc] | [prev] | [next] | [standalone]

#56565

On 4/1/17 5:10 PM, Julian Fondren wrote:
> On Saturday, April 1, 2017 at 8:06:23 PM UTC-5, Rod Pemberton wrote:
>> Why does the location of PAD move around?
>>
>
> It's a cheap way to get temporary indefinite-length memory. If it
> didn't move around, it wouldn't be temporary: it would be memory
> permanently reserved as a buffer, even if never used at runtime. The
> offset puts it out the way of other traditional uses for unallotted
> dictionary space, and puts it out of the way of one's own immediate
> consumption of that space.
>
> A downside of this is that the following statements are false:
>
>     PAD 1 ALLOT PAD =
>
>     PAD VARIABLE BOB PAD =
>
>     PAD : BUFFER: ( size "name" -- ) CREATE ALLOT ; PAD =
>
> Meaning that you may to shepherd a value of PAD through a word when
> you could, of a constant, just name it again where you want it again.
>
>> TIB is allocated at a fixed location, but
>> PAD's location is relative to HERE.
>
> Hmm. My guess: in the era of multi-user Forth system with built-in
> block editors, which was also the era before it was considered
> shameful to have things like limited input buffers, a TIB of some
> small size was assumed to always be necessary. Even today there are
> license provisions for leaving an engineering panel in a deployed
> program, so to speak, and there are techniques like loading a config
> file by EVALUATEing it with a restricted dictionary.
>
> Forth is interactive, after all.


A classical memory organization is to have the dictionary growing up 
from low memory and PAD at an offset above HERE. At the top of memory 
you have the disk buffers (fixed allocation of n x 1024 bytes). Below 
the bottom disk buffer the Return Stack grows toward low memory. Some 
distance below that (at least 128 bytes, maybe more, sometimes a lot 
more) is TIB, and the data stack grows toward low memory from that, All 
of the space between the start of PAD and the top stack item is free 
space (and there's usually quite a lot of it; megabytes nowadays); the 
space above the bottom of the stack is shared by TIB and the Return 
Stack. This works really well because when Forth is processing user 
input the Return Stack is normally quite small.

In the ~40 years I was programming and involved in projects, the only 
time I recall there being an awkward conflict over these spaces was the 
first time Chuck tried a recursive area fill in a graphics application, 
and both stacks grew massively. We allocated more space, and the problem 
was solved.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#56590

What he said! 

[toc] | [prev] | [next] | [standalone]

#56580

Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote:
> 
> Why does the location of PAD move around?
> 
> TIB is allocated at a fixed location, but PAD's location is relative
> to HERE.

Multi-user systems.  Every terminal task has to have a PAD.

PAD is often defined as something like HERE 34 +, to allow space below
PAD for numeric output conversion of up to 32 bits plus a sign.  You
could statically allocate a PAD for each task, but then you'd need to
add a user variable to point to it and it would be fixed in size.  TIB
can't move around because you can say ALLOT in interpreted mode.

Andrew.

[toc] | [prev] | [next] | [standalone]

#56609

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> Multi-user systems.  Every terminal task has to have a PAD.

What stops them from clobbering each other?  I'm presuming the tasks all
have the same HERE but maybe that's wrong.

[toc] | [prev] | [next] | [standalone]

#56610

On Sunday, April 2, 2017 at 8:08:57 PM UTC-5, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> > Multi-user systems.  Every terminal task has to have a PAD.
> 
> What stops them from clobbering each other?  I'm presuming the tasks all
> have the same HERE but maybe that's wrong.

Yes. that's wrong.


On Sunday, April 2, 2017 at 7:47:04 PM UTC-5, HAA wrote:
> It may as well be fixed.  Anyone with pretentions of writing a 'portable
> program' will be going out their way not to exceed the minimums quoted.
> To do otherwise is to limit your audience which would be self-defeating.

  \ PAD EXTENDER 4.7
  \ THIS IS COMMERCIAL SOFTWARE -- DO NOT DISTRIBUTE
  \ LOAD THIS BEFORE CODE DEPENDING ON EXCESSIVE PAD LENGTH

  \ ------ STOP READING HERE ------



  \ IF YOU'RE READING THIS
  \ I SURE HOPE
  \ THAT YOU HAVE SIGNED A NDA
  \ OR YOU WILL SEEING MY LAWYER




  create pad 100 allot

[toc] | [prev] | [next] | [standalone]

#56611

Julian Fondren <julian.fondren@gmail.com> writes:
>> I'm presuming the tasks all have the same HERE but maybe that's wrong.
> Yes. that's wrong.

Hmm, ok.  Does that mean each task has its own wordlist and dictionary
area that threads to a parent dictionary?

For some reason I thought Forth's extremely lightweight tasking meant
task memory of just the two stacks and a few saved registers.  Task
locals would come from the main heap.  I got this impression from
looking at the eForth tasker on Bill Muench's site.

Is there any documentation I can find about a traditional Forth
multitasker?  The full sized Forths these days tend to use OS threads.
Brad Rodriguez's articles are tantalizing but not very detailed about
this subject.

[toc] | [prev] | [next] | [standalone]

#56613

On Sunday, April 2, 2017 at 8:23:00 PM UTC-5, Paul Rubin wrote:
> Hmm, ok.  Does that mean each task has its own wordlist and dictionary
> area that threads to a parent dictionary?
> 
> For some reason I thought Forth's extremely lightweight tasking meant
> task memory of just the two stacks and a few saved registers.

And also USER variables and some amount of dictionary space.
The OS-thread-based multitasking still works like this.

But, the closest I've gotten to classical multitasking is
extending Enth/Flux to PAUSE between sectors loaded from/
written to floppy, with a progress indicator.

[toc] | [prev] | [next] | [standalone]

#56622

In article <87h9265los.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Julian Fondren <julian.fondren@gmail.com> writes:
>>> I'm presuming the tasks all have the same HERE but maybe that's wrong.
>> Yes. that's wrong.
>
>Hmm, ok.  Does that mean each task has its own wordlist and dictionary
>area that threads to a parent dictionary?
>
>For some reason I thought Forth's extremely lightweight tasking meant
>task memory of just the two stacks and a few saved registers.  Task
>locals would come from the main heap.  I got this impression from
>looking at the eForth tasker on Bill Muench's site.
>
>Is there any documentation I can find about a traditional Forth
>multitasker?  The full sized Forths these days tend to use OS threads.
>Brad Rodriguez's articles are tantalizing but not very detailed about
>this subject.

It may look not detailed but there is not much to Forth multi-tasking,
actually.
There is some commonality between traditional and preemptive
multi tasking.

The following 4 screens taken from ciforth contain both:
one common screen for subdividing the memory of the mother task,
one screen if you want preemptive multitasking
two screens if you want cooperative multitasking

cooperative is longer because it does the bookkeeping that the
OS does for you in the preemptive case.
It is also more general. The preemptive screen contains LI?
which means that it can only be loaded on a linux system,
32 or 64 bit. An MS-Windows version would look nothing like it.

This code is tricky. For preemptive the central point is the
NR_clone  system call. For cooperative it is the PAUSE-COT
command.

For the cooperative code keep in mind that in ciforth the only
pseudoregister to switch is the return stack. The data stack pointer
was stored on the return stack and the user variables are
coupled to the return stack pointer. The interpreter pointer
is incremented as usual, executing code even if that code
is switching to another task.

So bottom line, it is small but contains a lot of sharp edges
and debugging is a bitch. Before trying to understand this
code one must read the ciforth manual about the internals,
especially the memory layout.

-----------------------------------------
( CTA  aux_for_threads )                        \ AvdH B6jan23
\ Fails unless kernel prepared for threads
WANT TASK-SIZE
TASK-SIZE 4 / CONSTANT _TASK/4

\ Return the USERAREA of a new task, aligned.
: new-u0   DP @ _TASK/4 1- OR 1+    TASK-SIZE + _TASK/4 - ;

\ Clone the task area to a area of ``TASK-SIZE'' leave TASK
: CTA   U0 @ new-u0 2DUP  MAX-USER @ CELLS MOVE
    2DUP SWAP - ( offset) SWAP 5 0 DO 2DUP I CELLS + +! LOOP
    NIP NIP   DUP _TASK/4 + DP !  1 CELLS - ;



\
-----------------------------------------
( THREAD-PET KILL-PET PAUSE-PET ) CF: ?LI \ B5dec2
 "CTA" WANTED    "-syscalls-" WANTED      HEX
\ Exit a thread. Indeed this is exit().
: EXIT-PET 0 _ _ __NR_exit XOS ;
\ Do a preemptive pause. ( abuse MS )
: PAUSE-PET 1 MS ;
\ Create a thread with dictionary SPACE. Execute XT in thread.
: THREAD-PET   ALLOT CTA CREATE   RSP@ SWAP RSP!   R0 @ S0 @
    ROT RSP!    2 CELLS - ( DSP) ,  ( TASK) ,  ( pid) 0 ,
    DOES> DUP @ >R  SWAP OVER CELL+ @ R@ 2! ( clone S: tp,xt)
    100 R> _ __NR_clone XOS DUP IF
    ( Mother) DUP ?ERRUR SWAP 2 CELLS + ! ELSE
    ( Child) DROP RSP! CATCH DUP IF ERROR THEN EXIT-PET THEN ;
\ Kill a THREAD-PET , preemptively. Throw errors.
: KILL-PET >BODY 2 CELLS + @ 9 _ __NR_kill XOS ?ERRUR ;
DECIMAL
-----------------------------------------
( TASK-TABLE NEXT-TASK PAUSE-COT) HEX \ AvdH B5nov24
 "BAG" WANTED
100 BAG TASK-TABLE   VARIABLE TASK-POINTER
: THIS TASK-POINTER @ ;
\ Make first task current.
: SET-FIRST-TASK TASK-TABLE CELL+ TASK-POINTER ! ;

\ Add running task and make it current.
TASK-TABLE !BAG   _ TASK-TABLE BAG+!   SET-FIRST-TASK

\ Switch to next task, only administration.
: NEXT-TASK   THIS CELL+ TASK-POINTER !
    THIS TASK-TABLE @ = IF SET-FIRST-TASK THEN ;
\ Switch from current task to next one.
: PAUSE-COT
    DSP@ >R RSP@ THIS !   NEXT-TASK   THIS @ RSP! R> DSP! ;
-----------------------------------------
( EXIT-COT THREAD-COT ) HEX \ AvdH B5dec2
 "TASK-TABLE" WANTED    "CTA" WANTED       "BAG-" WANTED

\ Exit: remove current task, then chain to first one.
: EXIT-COT  THIS TASK-TABLE BAG-
    SET-FIRST-TASK   THIS @ RSP! R> DSP! ;

\ Create a thread with dictionary SPACE. Execute XT in thread.
: THREAD-COT   ALLOT CTA CREATE   RSP@ SWAP RSP!   S0 @  R0 @
    ROT RSP!   3 CELLS - , ,
    DOES> $@ >R  \ R@ is rsp of new task
    @                   R@ !
    >DFA @              R@ CELL+ !
    'EXIT-COT >DFA @    R@ CELL+ CELL+ !
    R> TASK-TABLE BAG+! ;
\

-----------------------------------------

Example:

    1000 THREAD COOS    \ A small dict space to allow printing numbers
    : jantje "we gaan naar Rome" TYPE CR ;

    ' jantje COOS

Now the text is printed and the task stops. Very exciting, but only
if you know what is going on.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#56633

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> The following 4 screens taken from ciforth contain both...
> This code is tricky. 

Thanks!  I'll try to figure it out.

For preemptive the central point is the

> For the cooperative code keep in mind that in ciforth the only
> pseudoregister to switch is the return stack. The data stack pointer
> was stored on the return stack and the user variables are
> coupled to the return stack pointer. The interpreter pointer
> is incremented as usual, executing code even if that code
> is switching to another task.

I don't understand the part about the user variables being compled to
the return stack pointer, but I think the rest is pretty standard
(e.g. pushing the other registers on the return stack so only the task
RP has to be stored in the TCB).  I'm surprised about being expected to
have an 84-byte PAD for each task though I guess if memory is short, the
magic words "environmental dependency" can make PAD smaller.

[toc] | [prev] | [next] | [standalone]

#56696

In article <878tni5bg2.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>> The following 4 screens taken from ciforth contain both...
>> This code is tricky.
>
>Thanks!  I'll try to figure it out.
>
>For preemptive the central point is the
>
>> For the cooperative code keep in mind that in ciforth the only
>> pseudoregister to switch is the return stack. The data stack pointer
>> was stored on the return stack and the user variables are
>> coupled to the return stack pointer. The interpreter pointer
>> is incremented as usual, executing code even if that code
>> is switching to another task.
>
>I don't understand the part about the user variables being compled to
>the return stack pointer, but I think the rest is pretty standard
>(e.g. pushing the other registers on the return stack so only the task
>RP has to be stored in the TCB).  I'm surprised about being expected to
>have an 84-byte PAD for each task though I guess if memory is short, the
>magic words "environmental dependency" can make PAD smaller.

One could reserve an intel register to point to the user area:
: USER   , DOES>  CELLS Intel-AX + ;      12 USER BASE
Instead I use the return stack pointer. That pointer moves about
so I round it up to a multiple of 64 K and use that as the user pointer.

A TASK doesn't need a dictionary space so you can create a THREAD by
0 THREAD-COT.
Any access to HERE though, even number formatting, will crash.
If your process uses number formatting the area HERE .. HERE 114 + is used.
Use 114 THREAD-COT or better copy it from the current process:
    PAD HERE - THREAD-COT <NAME>
If your process wants to use X bytes at PAD you must create the thread
by  X 114 + THREAD-COT <NAME>
If you need another Y to ALLOT in the thread, or for creating thread
specific dictionary entries you must do
  X Y + 114 + THREAD-COT <NAME>

(In the main task the space at PAD is typically 8 Gbyte on a 64 bit
Linux ciforth, depending on installation.)

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#56712

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
> 
> One could reserve an intel register to point to the user area:
> : USER   , DOES>  CELLS Intel-AX + ;      12 USER BASE

That's traditional.

> Instead I use the return stack pointer. That pointer moves about
> so I round it up to a multiple of 64 K and use that as the user pointer.

That's neat.  I wonder if anyone on Intel uses a segment register.
Did you consider that?

Andrew.

[toc] | [prev] | [next] | [standalone]

#56714

On 4/4/2017 16:53, Andrew Haley wrote:
> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>>
>> One could reserve an intel register to point to the user area:
>> : USER   , DOES>  CELLS Intel-AX + ;      12 USER BASE
>
> That's traditional.
>
>> Instead I use the return stack pointer. That pointer moves about
>> so I round it up to a multiple of 64 K and use that as the user pointer.
>
> That's neat.  I wonder if anyone on Intel uses a segment register.
> Did you consider that?
>
> Andrew.
>

On Windows you must (minimally) address every 4k page between the 
current ESP/RSP and your proposed address (downwards, as that's the 
direction the stack grows, and any instruction will do). Pages are 
reserved but not allocated on the stack; an access to a reserved but 
unallocated page causes a guard protection exception, and the standard 
exception handler then allocates the next page down. Oddly, it's not not 
the page referred to that is allocated; it ignores the address of the 
exception, so addressing a page 64K away from the last access won't work.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#56721

In article <r_adnYKghIcRXH7FnZ2dnUU7-SWdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>>
>> One could reserve an intel register to point to the user area:
>> : USER   , DOES>  CELLS Intel-AX + ;      12 USER BASE
>
>That's traditional.
>
>> Instead I use the return stack pointer. That pointer moves about
>> so I round it up to a multiple of 64 K and use that as the user pointer.
>
>That's neat.  I wonder if anyone on Intel uses a segment register.
>Did you consider that?

On systems like Unix and MS-Windows you have little control over
segment registers. In 64 bit, the whole distinction between registers
has almost disappeared. So no, I didn't even consider it.

>
>Andrew.
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web