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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#56741

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
> In article <r_adnYKghIcRXH7FnZ2dnUU7-SWdnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>>
>>> 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.

OK.  Linux/glibc uses the FS segment register for thread locals, so
there is an obvious parallel.

Andrew.

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

#56755

On 4/5/2017 09:39, Andrew Haley wrote:
> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>> In article <r_adnYKghIcRXH7FnZ2dnUU7-SWdnZ2d@supernews.com>,
>> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>>>
>>>> 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.
>
> OK.  Linux/glibc uses the FS segment register for thread locals, so
> there is an obvious parallel.
>
> Andrew.
>

So does Windows in 32 bit mode. GS is used in 64 bit mode.

-- 
Alex

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

#56642

On 4/2/17 4:37 PM, Albert van der Horst wrote:
> 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.

Actually, the multitasking in polyFORTH and SwiftX is even simpler than 
Albert describes. The principles are outlined in Forth Application 
Techniques and documentation for SwiftX (included in the free eval 
downloads).

Cheers,
Elizabeth

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

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

#56641

On 4/2/17 3:22 PM, Paul Rubin 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?

They can. That's implementation-specific.

> 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.

OS Threads are very different from the traditional multitasking model.
The latter is still used in native embedded systems, though.

There are two basic kinds of tasks: Terminal tasks have the ability to
support an interactive user (TIB, interpreter, etc.), and background 
tasks are much simpler, with a minimal user area capable of executing 
definitions in common or some task's dictionary but not interacting with 
a user or source in any way.

Cheers,
Elizabeth

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

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

#56651

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?

Every task that has a terminal does, yes.  In polyFORTH, The OPERATOR
task spawns the other tasks, and their dictionaries are allocated from
OPERATOR's data space.

> 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.

Those are background tasks.  But even a background task has its own
user variables.  So, the difference between background and terminal
tasks is an input device (and therefore a TIB) and a dictionary.  So,
terminal tasks have their own HERE, PAD, etc., background tasks don't.

Andrew.

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

#56735

Paul Rubin 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.

Most mt implementations are based on the tasker provided in L&P F83
and described in FD V5N4,5.  This is a simple 'background' tasker.
PolyForth's had more features/options.  You can find a description of
theirs in the pF manual available from the Greenarrays site.
For implementations of the L&P tasker, see F83, hForth, DX-Forth etc.

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

#56765

"HAA" <someone@microsoft.com> writes:
> Most mt implementations are based on the tasker provided in L&P F83
> and described in FD V5N4,5.  This is a simple 'background' tasker.
> PolyForth's had more features/options.  You can find a description of
> theirs in the pF manual available from the Greenarrays site.
> For implementations of the L&P tasker, see F83, hForth, DX-Forth etc.

Aha, thanks.  I can get hold of a paper copy of Dr. Ting's book "Inside
F83", which always looked worth reading.  I'll also look at the
Greenarrays PolyForth manual: I hadn't thought of looking for a PF
manual there.

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

#56801

Paul Rubin wrote:
> "HAA" <someone@microsoft.com> writes:
> > Most mt implementations are based on the tasker provided in L&P F83
> > and described in FD V5N4,5.  This is a simple 'background' tasker.
> > PolyForth's had more features/options.  You can find a description of
> > theirs in the pF manual available from the Greenarrays site.
> > For implementations of the L&P tasker, see F83, hForth, DX-Forth etc.
>
> Aha, thanks.  I can get hold of a paper copy of Dr. Ting's book "Inside
> F83", which always looked worth reading.  I'll also look at the
> Greenarrays PolyForth manual: I hadn't thought of looking for a PF
> manual there.

IMO the mechanism used by Forth Inc (and consequently L&P) to
switch tasks is more complicated than it needs to be.  Executing
instructions in user variables, splitting PAUSE into two fragments,
seems a lot of effort when all that's needed is a tight loop that tests
a flag e.g.

    begin
       mov  bx, [bx+cell]    \ point to STATUS of next task
       cmp  [bx], 0             \ is task active?
    0<> until

The original method is cute - but justified?

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

#56806

On 4/7/2017 05:26, HAA wrote:
> Paul Rubin wrote:
>> "HAA" <someone@microsoft.com> writes:
>>> Most mt implementations are based on the tasker provided in L&P F83
>>> and described in FD V5N4,5.  This is a simple 'background' tasker.
>>> PolyForth's had more features/options.  You can find a description of
>>> theirs in the pF manual available from the Greenarrays site.
>>> For implementations of the L&P tasker, see F83, hForth, DX-Forth etc.
>>
>> Aha, thanks.  I can get hold of a paper copy of Dr. Ting's book "Inside
>> F83", which always looked worth reading.  I'll also look at the
>> Greenarrays PolyForth manual: I hadn't thought of looking for a PF
>> manual there.
> 
> IMO the mechanism used by Forth Inc (and consequently L&P) to
> switch tasks is more complicated than it needs to be.  Executing
> instructions in user variables, splitting PAUSE into two fragments,
> seems a lot of effort when all that's needed is a tight loop that tests
> a flag e.g.
> 
>      begin
>         mov  bx, [bx+cell]    \ point to STATUS of next task
>         cmp  [bx], 0             \ is task active?
>      0<> until
> 
> The original method is cute - but justified?
> 
> 
> 

This burns CPU, which might be OK in a standalone environment; but even 
there, it is incredibly wasteful of power. Polling will not work 
satisfactorily in many hosted environments; for example, running on an 
operating system like Linux or Windows.

-- 
Alex

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

#56825

Alex wrote:
> On 4/7/2017 05:26, HAA wrote:
> > Paul Rubin wrote:
> >> "HAA" <someone@microsoft.com> writes:
> >>> Most mt implementations are based on the tasker provided in L&P F83
> >>> and described in FD V5N4,5.  This is a simple 'background' tasker.
> >>> PolyForth's had more features/options.  You can find a description of
> >>> theirs in the pF manual available from the Greenarrays site.
> >>> For implementations of the L&P tasker, see F83, hForth, DX-Forth etc.
> >>
> >> Aha, thanks.  I can get hold of a paper copy of Dr. Ting's book "Inside
> >> F83", which always looked worth reading.  I'll also look at the
> >> Greenarrays PolyForth manual: I hadn't thought of looking for a PF
> >> manual there.
> >
> > IMO the mechanism used by Forth Inc (and consequently L&P) to
> > switch tasks is more complicated than it needs to be.  Executing
> > instructions in user variables, splitting PAUSE into two fragments,
> > seems a lot of effort when all that's needed is a tight loop that tests
> > a flag e.g.
> >
> >      begin
> >         mov  bx, [bx+cell]    \ point to STATUS of next task
> >         cmp  [bx], 0             \ is task active?
> >      0<> until
> >
> > The original method is cute - but justified?
> >
> >
> >
>
> This burns CPU, which might be OK in a standalone environment; but even
> there, it is incredibly wasteful of power. Polling will not work
> satisfactorily in many hosted environments; for example, running on an
> operating system like Linux or Windows.

A round-robin with no active tasks, or a Linux/Windows with no event to drive
them, means burning CPU.  You're only option in that case is to wind down
power consumption.

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

#56845

"HAA" <someone@microsoft.com> writes:
> A round-robin with no active tasks, or a Linux/Windows with no event
> to drive them, means burning CPU.  You're only option in that case is
> to wind down power consumption.

On Linux you'd typically have a select or epoll loop, plus a queue of
scheduled future timeouts that you'd use to create timeouts for select
or epoll.

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

#56860

On 4/8/2017 01:25, HAA wrote:
> Alex wrote:
>> On 4/7/2017 05:26, HAA wrote:
>>> Paul Rubin wrote:
>>>> "HAA" <someone@microsoft.com> writes:
>>>>> Most mt implementations are based on the tasker provided in L&P F83
>>>>> and described in FD V5N4,5.  This is a simple 'background' tasker.
>>>>> PolyForth's had more features/options.  You can find a description of
>>>>> theirs in the pF manual available from the Greenarrays site.
>>>>> For implementations of the L&P tasker, see F83, hForth, DX-Forth etc.
>>>>
>>>> Aha, thanks.  I can get hold of a paper copy of Dr. Ting's book "Inside
>>>> F83", which always looked worth reading.  I'll also look at the
>>>> Greenarrays PolyForth manual: I hadn't thought of looking for a PF
>>>> manual there.
>>>
>>> IMO the mechanism used by Forth Inc (and consequently L&P) to
>>> switch tasks is more complicated than it needs to be.  Executing
>>> instructions in user variables, splitting PAUSE into two fragments,
>>> seems a lot of effort when all that's needed is a tight loop that tests
>>> a flag e.g.
>>>
>>>       begin
>>>          mov  bx, [bx+cell]    \ point to STATUS of next task
>>>          cmp  [bx], 0             \ is task active?
>>>       0<> until
>>>
>>> The original method is cute - but justified?
>>>
>>>
>>>
>>
>> This burns CPU, which might be OK in a standalone environment; but even
>> there, it is incredibly wasteful of power. Polling will not work
>> satisfactorily in many hosted environments; for example, running on an
>> operating system like Linux or Windows.
> 
> A round-robin with no active tasks, or a Linux/Windows with no event to drive
> them, means burning CPU.  You're only option in that case is to wind down
> power consumption.
> 

That's not how Linux or Windows works or any half decent scheduler of my 
experience. As long as the processor has (1) a HALT or equivalent 
instruction and (2) can resume from the halt in response to external 
interrupts, there is no need to spin on the spot.* In Windows this is 
managed by the system idle task. The OS should always be asked to wait 
on an event on your behalf.

*There are some spin locks required in multi processor systems, but 
we're now way off the reservation.

-- 
Alex

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

#56892

PAD is relative to HERE so that when you compile you don't have.to move the name of the word after it is read in.

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

#56922

Op Sat, 8 Apr 2017 20:28:47 -0700 (PDT) schreef jason.songhurst@gmail.com:

> PAD is relative to HERE so that when you compile you don't have.to
> move the name of the word after it is read in.

You may freely use PAD when you are interpreting, PAD doesn't move then.
When you compile (using words , C, or ALLOT), HERE moves and so does PAD.
What do you mean with name and with moving that?

groet Coos

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

#56943

On 4/9/17 1:47 AM, Coos Haak wrote:
> Op Sat, 8 Apr 2017 20:28:47 -0700 (PDT) schreef jason.songhurst@gmail.com:
>
>> PAD is relative to HERE so that when you compile you don't have.to
>> move the name of the word after it is read in.
>
> You may freely use PAD when you are interpreting, PAD doesn't move then.
> When you compile (using words , C, or ALLOT), HERE moves and so does PAD.
> What do you mean with name and with moving that?

In the systems I'm familiar with, PAD is offset from HERE. In systems 
with integrated code and data space, the name is actually constructed at 
HERE, not in PAD, although it is certainly true that in such systems 
once a header & other components of a definition are constructed PAD 
will have moved.

Section 3.3.3.6 Other transient regions (in Forth94 and Forth2012) 
clearly define the circumstances under which you can count on PAD being 
stable; the short summary is that PAD will move in systems with 
integrated code & data space (data intermingled with definitions) during 
compilation (which includes interpretation). While you are executing 
compiled code that doesn't change the dictionary or allot data space it 
will not move. In systems with segregated dictionary and data space it 
will be more stable, moving only when you ALLOT more data space. In 
segregated implementations, HERE returns the next location in data 
space, not the dictionary.

Classical uses of PAD include receiving a string that will be the basis 
for a search or other processing during the running of an application.

Cheers,
Elizabeth

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

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

#56926

In article <661e478c-97c5-41d5-9057-9064e5c737ad@googlegroups.com>,
 <jason.songhurst@gmail.com> wrote:
>PAD is relative to HERE so that when you compile you don't have.to
> move the name of the word after it is read in.

You can't state it like that.
Elizabeth Rather has made it clear that that is a customary
implementation, with the advantage that it has practically unlimited
size on most desktop systems.
A system that defines PAD as a static buffer conforms to the standard.

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]

#56955

Alex wrote:
> On 4/8/2017 01:25, HAA wrote:
> > Alex wrote:
> >> On 4/7/2017 05:26, HAA wrote:
> >>> Paul Rubin wrote:
> >>>> "HAA" <someone@microsoft.com> writes:
> >>> ...
> >>> IMO the mechanism used by Forth Inc (and consequently L&P) to
> >>> switch tasks is more complicated than it needs to be.  Executing
> >>> instructions in user variables, splitting PAUSE into two fragments,
> >>> seems a lot of effort when all that's needed is a tight loop that tests
> >>> a flag e.g.
> >>>
> >>>       begin
> >>>          mov  bx, [bx+cell]    \ point to STATUS of next task
> >>>          cmp  [bx], 0             \ is task active?
> >>>       0<> until
> >>>
> >>> The original method is cute - but justified?
> >>>
> >>>
> >>>
> >>
> >> This burns CPU, which might be OK in a standalone environment; but even
> >> there, it is incredibly wasteful of power. Polling will not work
> >> satisfactorily in many hosted environments; for example, running on an
> >> operating system like Linux or Windows.
> >
> > A round-robin with no active tasks, or a Linux/Windows with no event to drive
> > them, means burning CPU.  You're only option in that case is to wind down
> > power consumption.
> >
>
> That's not how Linux or Windows works or any half decent scheduler of my
> experience. As long as the processor has (1) a HALT or equivalent
> instruction and (2) can resume from the halt in response to external
> interrupts, there is no need to spin on the spot.* In Windows this is
> managed by the system idle task. The OS should always be asked to wait
> on an event on your behalf.
>
> *There are some spin locks required in multi processor systems, but
> we're now way off the reservation.

Let's get back to your complaint above that my task switching code 'burns
CPU'.  Well so does every Forth round-robin tasker I've seen.  If you believe
my code represents a backward step, please explain in what way.

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

#56983

On 4/10/2017 01:31, HAA wrote:
> Alex wrote:
>> On 4/8/2017 01:25, HAA wrote:
>>> Alex wrote:
>>>> On 4/7/2017 05:26, HAA wrote:
>>>>> Paul Rubin wrote:
>>>>>> "HAA" <someone@microsoft.com> writes:
>>>>> ...
>>>>> IMO the mechanism used by Forth Inc (and consequently L&P) to
>>>>> switch tasks is more complicated than it needs to be.  Executing
>>>>> instructions in user variables, splitting PAUSE into two fragments,
>>>>> seems a lot of effort when all that's needed is a tight loop that tests
>>>>> a flag e.g.
>>>>>
>>>>>        begin
>>>>>           mov  bx, [bx+cell]    \ point to STATUS of next task
>>>>>           cmp  [bx], 0             \ is task active?
>>>>>        0<> until
>>>>>
>>>>> The original method is cute - but justified?
>>>>>
>>>>>
>>>>>
>>>>
>>>> This burns CPU, which might be OK in a standalone environment; but even
>>>> there, it is incredibly wasteful of power. Polling will not work
>>>> satisfactorily in many hosted environments; for example, running on an
>>>> operating system like Linux or Windows.
>>>
>>> A round-robin with no active tasks, or a Linux/Windows with no event to drive
>>> them, means burning CPU.  You're only option in that case is to wind down
>>> power consumption.
>>>
>>
>> That's not how Linux or Windows works or any half decent scheduler of my
>> experience. As long as the processor has (1) a HALT or equivalent
>> instruction and (2) can resume from the halt in response to external
>> interrupts, there is no need to spin on the spot.* In Windows this is
>> managed by the system idle task. The OS should always be asked to wait
>> on an event on your behalf.
>>
>> *There are some spin locks required in multi processor systems, but
>> we're now way off the reservation.
> 
> Let's get back to your complaint above that my task switching code 'burns
> CPU'.  Well so does every Forth round-robin tasker I've seen.  If you believe
> my code represents a backward step, please explain in what way.
> 

Any technique that requires burning CPU while doing nothing is no more 
than a historical curiosity. Anton's recent interesting summary of 
Philae's activities didn't include a paragraph about mission failure 
because a spin wait on the RTX Forth chips depleted the batteries on the 
trip from earth to asteroid.

See my other reply to Elizabeth for the Windows case.

-- 
Alex

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

#56989

In article <ocejqb$1clq$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote:
<SNIP>
>
>Let's get back to your complaint above that my task switching code 'burns
>CPU'.  Well so does every Forth round-robin tasker I've seen.  If you believe
>my code represents a backward step, please explain in what way.

The control software for the metallophones contains a round robin
scheduler. If it is within short interval before an event has
to be sent out, it busy waits for the event. Otherwise it does a
sleep for a calculated amount of milliseconds.
The bottom line is that the Linux system it runs on, doesn't slow down
noticably.

A simple general tasker cannot avoid waste without some information
when other tasks have to run. Or help from the hardware in the
form of a HALT instruction and interrupts.

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]

#56614

In article <87o9we5mc8.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> 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 is wrong. In most implementations you will note that HERE is
in fact DP @ , where DP is a so called user variable. So the intent
is there to duplicate DP for for every user (read task)
Even if there are not several user compiling at different consoles,
a task that is running in parallel, may do I/O. If it formats numbers
it will use a small area at HERE (under PAD) that better be duplicaed
for each task.

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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web