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

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

Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack

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

Contents

  Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack mfanyikazi@gmail.com - 2015-03-16 09:30 -0700
    Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack jenfhaomndgfwutc@murmic.plus.com - 2015-03-16 17:13 +0000
      Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack mfanyikazi@gmail.com - 2015-03-17 02:40 -0700
        Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-03-18 01:53 +0000
          Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack rickman <gnuarm@gmail.com> - 2015-03-17 23:21 -0400
    Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-16 22:24 +0000
      Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack rickman <gnuarm@gmail.com> - 2015-03-17 14:01 -0400
        Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack JUERGEN <epldfpga@aol.com> - 2015-03-17 11:59 -0700
          Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack rickman <gnuarm@gmail.com> - 2015-03-17 16:28 -0400
          Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-18 15:30 +0000
            Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack Bernd Paysan <bernd.paysan@gmx.de> - 2015-03-18 22:12 +0100
    Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-03-16 18:57 -0400
      Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack mfanyikazi@gmail.com - 2015-03-17 02:52 -0700
        Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-03-17 18:03 -0400
        Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-18 14:39 +0000
    Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack mfanyikazi@gmail.com - 2015-03-17 02:58 -0700
    Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-17 16:48 +0000
    Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-18 12:16 +0100
      Re: Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-18 12:43 +0100

#37295 — Is it possible to have the following words (RP@ RP! SP@ SP!) on hardware data and return stack

I have a forth programming problem that is messing up my week , I am trying to port eforth's multitasker into a Forth CPU that has a hardware data and return stack. I don't know how to save and restore the stack pointers when the CPU uses hardware stacks.

If anyone has a link or some documentation on how this can be done , or alternative Forth words to RP@ RP! SP@ SP! that allows the emulation of a context switching mechanism with forth please share , I will be much grateful to learn from you.

[toc] | [next] | [standalone]

#37298

On Mon, 16 Mar 2015 09:30:34 -0700 (PDT)
mfanyikazi@gmail.com wrote:

> I have a forth programming problem that is messing up my week , I am trying to port eforth's multitasker into a Forth CPU that has a hardware data and return stack. I don't know how to save and restore the stack pointers when the CPU uses hardware stacks.
> 
> If anyone has a link or some documentation on how this can be done , or alternative Forth words to RP@ RP! SP@ SP! that allows the emulation of a context switching mechanism with forth please share , I will be much grateful to learn from you.

Which forth core, or is it custom?  

Jan Coombs 
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

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

#37323

> Which forth core, or is it custom?  


James Bowman's J1 FPGA 

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

#37365

On Tue, 17 Mar 2015 02:40:14 -0700 (PDT)
mfanyikazi@gmail.com wrote:
 
> James Bowman's J1 FPGA 

The j1 can return the stack pointers, but not set them, so you will 
need to extend it to do multi-tasking.  
 
I'd do the task switch in hardware like NC4016 (in old app note?):  

Add two new hardware registers, and map them into j1 I/O space:
  task-selector - to select a task, must initialise to zero. 
  last-task - last task to run, must initialise to zero. 

Make multiple copies of DSP and RSP, only an extra 10 latches per task, 
plus mux code to select active pair using task-selector

Use larger memories for D and R stacks, and drive most significant
address bits with task-selector


: pause ( ? -- ? ) (R ? -- ? )  \ simplest - runs tasks 0 to last-task
         \ call to pause has pushed curr task return address
    dup  \ push TOS register onto stack 
    \ wrap task selector, even if out of range
    task-selector @ 1+  dup last-task @ >=  if  drop 0  then  
    task-selector !  \ switch stacks, (or not if single tasking) 
    noop  \ may need delay for h/w here
    drop  \ refill task TOS register 
    ;     \ exit to address retrieved from R stack


: my-task ( -- )  \ code for task
    begin  pause ( do something )  again ;

: setup-task ( c-addr task# -- )  \ hookup task
    task-selector !  execute pause  ;

' my-task  1  setup-task  \ setup task 1

1 last-task !  \ allow task 1 to run
0 last-task !  \ single task only


Warning: All from memory, deliberately crude and obvious, more 
could be moved into hardware, and refined, ... 

Would you like some help to test this? 

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

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

#37370

On 3/17/2015 9:53 PM, Jan Coombs <Jan-54 wrote:
> On Tue, 17 Mar 2015 02:40:14 -0700 (PDT)
> mfanyikazi@gmail.com wrote:
>
>> James Bowman's J1 FPGA
>
> The j1 can return the stack pointers, but not set them, so you will
> need to extend it to do multi-tasking.
>
> I'd do the task switch in hardware like NC4016 (in old app note?):
>
> Add two new hardware registers, and map them into j1 I/O space:
>    task-selector - to select a task, must initialise to zero.
>    last-task - last task to run, must initialise to zero.
>
> Make multiple copies of DSP and RSP, only an extra 10 latches per task,
> plus mux code to select active pair using task-selector

If you are talking about up to 16 tasks the task selector should use 
distributed memory, not registers.  For 17 to 32, use two distributed 
memory sets with a mux.   Above that the muxes start to get expensive so 
a block RAM could be used.

The problem is the same as having a hardware stack, the hard coded limit 
on the number of tasks.


> Use larger memories for D and R stacks, and drive most significant
> address bits with task-selector
>
>
> : pause ( ? -- ? ) (R ? -- ? )  \ simplest - runs tasks 0 to last-task
>           \ call to pause has pushed curr task return address
>      dup  \ push TOS register onto stack
>      \ wrap task selector, even if out of range
>      task-selector @ 1+  dup last-task @ >=  if  drop 0  then
>      task-selector !  \ switch stacks, (or not if single tasking)
>      noop  \ may need delay for h/w here
>      drop  \ refill task TOS register
>      ;     \ exit to address retrieved from R stack
>
>
> : my-task ( -- )  \ code for task
>      begin  pause ( do something )  again ;
>
> : setup-task ( c-addr task# -- )  \ hookup task
>      task-selector !  execute pause  ;
>
> ' my-task  1  setup-task  \ setup task 1
>
> 1 last-task !  \ allow task 1 to run
> 0 last-task !  \ single task only
>
>
> Warning: All from memory, deliberately crude and obvious, more
> could be moved into hardware, and refined, ...
>
> Would you like some help to test this?
>
> Jan Coombs
>


-- 

Rick

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

#37313

In article <21045760-f834-4d9c-9bb0-d13f2c1ff3b4@googlegroups.com>,
 <mfanyikazi@gmail.com> wrote:
>I have a forth programming problem that is messing up my week , I am
>trying to port eforth's multitasker into a Forth CPU that has a hardware
>data and return stack. I don't know how to save and restore the stack
>pointers when the CPU uses hardware stacks.

The definition of SP@ (beter DSP@) return an address (in dataspace)
from where you can @ the top of the stack. This address doesn't exist,
so you cannot implement DSP@. Bottom line you have to rethink the
problem and trying to port eforth's multitasker (or any multitasker that
uses words like DSP@ DSP! , like the ones in ciforth) is probably a
bad idea. You can make the stack diagram of how you start a parallel
execution the same, but that's about it.

>
>If anyone has a link or some documentation on how this can be done , or
>alternative Forth words to RP@ RP! SP@ SP! that allows the emulation of
>a context switching mechanism with forth please share , I will be much
>grateful to learn from you.

You'll have to study the particular processor carefully. Maybe you'll
have to sidestep the issue, a multi tasker is not often needed in
full glory. If you need the multitasker as part of a large working
application that you don't have the time to study in detail, it is
time to tell your boss that the CPU is a bad fit.

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]

#37341

On 3/16/2015 6:24 PM, Albert van der Horst wrote:
> In article <21045760-f834-4d9c-9bb0-d13f2c1ff3b4@googlegroups.com>,
>   <mfanyikazi@gmail.com> wrote:
>> I have a forth programming problem that is messing up my week , I am
>> trying to port eforth's multitasker into a Forth CPU that has a hardware
>> data and return stack. I don't know how to save and restore the stack
>> pointers when the CPU uses hardware stacks.
>
> The definition of SP@ (beter DSP@) return an address (in dataspace)
> from where you can @ the top of the stack. This address doesn't exist,
> so you cannot implement DSP@. Bottom line you have to rethink the
> problem and trying to port eforth's multitasker (or any multitasker that
> uses words like DSP@ DSP! , like the ones in ciforth) is probably a
> bad idea. You can make the stack diagram of how you start a parallel
> execution the same, but that's about it.
>
>>
>> If anyone has a link or some documentation on how this can be done , or
>> alternative Forth words to RP@ RP! SP@ SP! that allows the emulation of
>> a context switching mechanism with forth please share , I will be much
>> grateful to learn from you.
>
> You'll have to study the particular processor carefully. Maybe you'll
> have to sidestep the issue, a multi tasker is not often needed in
> full glory. If you need the multitasker as part of a large working
> application that you don't have the time to study in detail, it is
> time to tell your boss that the CPU is a bad fit.

Rather than rethink the software, I would rethink the hardware.  A soft 
CPU is not cast in stone.  You can add instructions.  With a hardware 
stack you can go a couple of ways.  One is to add instructions to 
save/restore the stack pointer (which do exist, but not as a software 
accessible register which is what needs to be changed).  Or you can 
change the stack so it is larger (likely a requirement anyway) and 
partitioned for a fixed number of processes.  Then there would be a 
register added to select the process to be run.

All this will require a bit of thought to make sure it works correctly 
for context switches.  There can be gotchas at the transitions, but this 
has all been done before and there are lots of references on how to make 
it work.

-- 

Rick

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

#37343

On Tuesday, March 17, 2015 at 6:02:11 PM UTC, rickman wrote:
> On 3/16/2015 6:24 PM, Albert van der Horst wrote:
> > In article <21045760-f834-4d9c-9bb0-d13f2c1ff3b4@googlegroups.com>,
> >   <mfanyikazi@gmail.com> wrote:
> >> I have a forth programming problem that is messing up my week , I am
> >> trying to port eforth's multitasker into a Forth CPU that has a hardware
> >> data and return stack. I don't know how to save and restore the stack
> >> pointers when the CPU uses hardware stacks.
> >
> > The definition of SP@ (beter DSP@) return an address (in dataspace)
> > from where you can @ the top of the stack. This address doesn't exist,
> > so you cannot implement DSP@. Bottom line you have to rethink the
> > problem and trying to port eforth's multitasker (or any multitasker that
> > uses words like DSP@ DSP! , like the ones in ciforth) is probably a
> > bad idea. You can make the stack diagram of how you start a parallel
> > execution the same, but that's about it.
> >
> >>
> >> If anyone has a link or some documentation on how this can be done , or
> >> alternative Forth words to RP@ RP! SP@ SP! that allows the emulation of
> >> a context switching mechanism with forth please share , I will be much
> >> grateful to learn from you.
> >
> > You'll have to study the particular processor carefully. Maybe you'll
> > have to sidestep the issue, a multi tasker is not often needed in
> > full glory. If you need the multitasker as part of a large working
> > application that you don't have the time to study in detail, it is
> > time to tell your boss that the CPU is a bad fit.
> 
> Rather than rethink the software, I would rethink the hardware.  A soft 
> CPU is not cast in stone.  You can add instructions.  With a hardware 
> stack you can go a couple of ways.  One is to add instructions to 
> save/restore the stack pointer (which do exist, but not as a software 
> accessible register which is what needs to be changed).  Or you can 
> change the stack so it is larger (likely a requirement anyway) and 
> partitioned for a fixed number of processes.  Then there would be a 
> register added to select the process to be run.
> 
> All this will require a bit of thought to make sure it works correctly 
> for context switches.  There can be gotchas at the transitions, but this 
> has all been done before and there are lots of references on how to make 
> it work.
> 
> -- 
> 
> Rick

Just a general question: How deep should the R and D stack be?
( independent of the Multitasking ), I heard 32 - 128 range should be ok?
And the n x y per task I assume on top?

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

#37353

On 3/17/2015 2:59 PM, JUERGEN wrote:
>
> Just a general question: How deep should the R and D stack be?
> ( independent of the Multitasking ), I heard 32 - 128 range should be ok?
> And the n x y per task I assume on top?

I would suggest looking at Koopman's book on stack processors.  I 
wouldn't have a number other than what you might find there.  I believe 
I have heard the number 16 and the GA144 only has a 10 deep stack.

-- 

Rick

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

#37403

JUERGEN <epldfpga@aol.com> writes:
>Just a general question: How deep should the R and D stack be?
>( independent of the Multitasking ), I heard 32 - 128 range should be ok?

Looking at
http://www.complang.tuwien.ac.at/misc/stack-caching-data/

I see the following stack needs

compile: >32 (but not by much)
cross: 31
gray: >32
prims2x: >32

OTOH, Chuck Moore thinks that 6-deep stacks are sufficient.  I guess,
if the software is written or adapted for a given stack depth, you can
live with much shallower stacks than for software written for deep
stacks.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#37408

Anton Ertl wrote:

> JUERGEN <epldfpga@aol.com> writes:
>>Just a general question: How deep should the R and D stack be?
>>( independent of the Multitasking ), I heard 32 - 128 range should be ok?
> 
> Looking at
> http://www.complang.tuwien.ac.at/misc/stack-caching-data/
> 
> I see the following stack needs
> 
> compile: >32 (but not by much)
> cross: 31
> gray: >32
> prims2x: >32
> 
> OTOH, Chuck Moore thinks that 6-deep stacks are sufficient.  I guess,
> if the software is written or adapted for a given stack depth, you can
> live with much shallower stacks than for software written for deep
> stacks.

Chuck's cores have very little memory, so only small programs fit into them.  
For these small programs, the 6 elements are probably ok, for somewhat 
larger programs, it's no longer ok.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#37317

On Mon, 16 Mar 2015 12:30:34 -0400, <mfanyikazi@gmail.com> wrote:

> I have a forth programming problem that is messing up my week , I am
> trying to port eforth's multitasker into a Forth CPU that has a hardware
> data and return stack. I don't know how to save and restore the stack
> pointers when the CPU uses hardware stacks.
>
> If anyone has a link or some documentation on how this can be done , or
> alternative Forth words to RP@ RP! SP@ SP! that allows the emulation of
> a context switching mechanism with forth please share , I will be much
> grateful to learn from you.

Where present, RP and SP return the address of the memory
location where the pointers to the return stack and data
stack are stored.  So, RP@ and SP@ should return the stack
pointers themselves and place them onto the data stack.
Of course, RP and SP are implemented in registers on most
implementations and therefore don't have an address.  This
is usually why RP and SP aren't present in most Forth systems.

Do RP@ RP! SP@ SP! work correctly for this eForth?

a) If so, you just need to execute RP@ and SP@ and then ! them
into some defined VARIABLEs or perhaps even into ALLOTed dictionary
space.  When the context switch is finished, you @ the variables
and use RP! and SP! to restore them.  If you're doing multiple
context switches, you'll need multiple sets of two variables,
i.e., an array, or perhaps a stack.

b) If not, then you'll need to implement RP@ RP! SP@ SP! as
"primitives" (or low-level words), likely using assembly. The
hardware stack pointers for the data and return stack should
or could be stored in registers.  So, you'd need assembly code
to push or pop both registers used for RP and SP to or from the
data stack.  You'll need to understand the code for eForth here
as well as the assembly for the Forth CPU that you're using.


Rod Pemberton

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

#37324

> Do RP@ RP! SP@ SP! work correctly for this eForth?

Nope they can't work since both stacks are circular in nature and the only offset into the stacks is through the digits 0x00 - 0x1f there is no memory addressing scheme used since they are separate from main memory and act more like LIFO stacks, even making he words PICK and ROLL requires a tremendous hack that the original author of the Forth system that runs on that CPU has to do. This is really complicated , but since it's James Bowman's J1 FPGA I think the only thing to do is ask him how to memory map the stack such that I can extend the stacks using main memory , if this is possible then I can find a way to extend the user area per task so that I can save and restore the states .. but one more problem ... both the stacks are circular which makes it add to the problem that accessing the pointer to the stack does not really mean returning the accurate value since the stack may be overwritten by other stacks ... a problem that seems to be amplified when using a circular stack design. hmmm .. I don't know if he will agree :)

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

#37360

On Tue, 17 Mar 2015 05:52:03 -0400, <mfanyikazi@gmail.com> wrote:
> Rod Pemberton wrote:

>> Do RP@ RP! SP@ SP! work correctly for this eForth?
>
> Nope they can't work since both stacks are circular in nature and the
> only offset into the stacks is through the digits 0x00 - 0x1f there is
> no memory addressing scheme used since they are separate from main
> memory and act more like LIFO stacks, even making he words PICK and ROLL
> requires a tremendous hack that the original author of the Forth system
> that runs on that CPU has to do. This is really complicated , but since
> it's James Bowman's J1 FPGA I think the only thing to do is ask him how
> to memory map the stack such that I can extend the stacks using main
> memory , if this is possible then I can find a way to extend the user
> area per task so that I can save and restore the states .. but one more
> problem ... both the stacks are circular which makes it add to the
> problem that accessing the pointer to the stack does not really mean
> returning the accurate value since the stack may be overwritten by other
> stacks ...

I know that  *none*  of the other people posting here, are about to do
any actual work which could help you, unlike me.  They pretend to be
nice, but tell other people to killfile those they dislike.  I believe
that actions speak louder than words, so if anyone here happens to say
something bad about me, I think you should just ignore them.

I went to James Bowman's website and attempting to find out if he
uses SP and RP in his code.  It seems J.B. uses SP named as 'dsp'
in nucleus for DEPTH's definition:

http://www.excamera.com/files/j1demo/docforth/nuc.fs.html

So, you should be able to construct SP@ and SP! like so:

: SP@ dsp @ ;
: SP@ dsp ! ;

I don't see an RP equivalent in his nucleus, basewords, or cross
assembler .fs files.

R@ might be about the only place where RP might normally be used. However,
he uses rT in R@ which I'm assuming moves the top of the return stack
into the top of the data stack T . So, an RP named as 'rsp' or somesuch
might simply be unimplemented since it was unneeded.

> a problem that seems to be amplified when using a circular
> stack design. hmmm .. I don't know if he will agree :)

It doesn't matter if he agrees with you.  You're using his processor
to do what you want.  You're not there to satiate whatever ego he has,
if any, unless he's employed you.

Personally, I don't see the circular buffers being something critical.
If you do, you can always set up your own stacks as long as some method
exists in his variation of eForth to allocate memory, e.g., ALLOT or
ALLOCATE etc.


Rod Pemberton

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

#37395

mfanyikazi@gmail.com writes:
>
>> Do RP@ RP! SP@ SP! work correctly for this eForth?
>
>Nope they can't work since both stacks are circular in nature and the only =
>offset into the stacks is through the digits 0x00 - 0x1f there is no memory=
> addressing scheme used since they are separate from main memory and act mo=
>re like LIFO stacks, even making he words PICK and ROLL requires a tremendo=
>us hack that the original author of the Forth system that runs on that CPU =
>has to do. This is really complicated , but since it's James Bowman's J1 FP=
>GA I think the only thing to do is ask him how to memory map the stack such=
> that I can extend the stacks using main memory , if this is possible then =
>I can find a way to extend the user area per task so that I can save and re=
>store the states .. but one more problem ... both the stacks are circular w=
>hich makes it add to the problem that accessing the pointer to the stack do=
>es not really mean returning the accurate value since the stack may be over=
>written by other stacks ... a problem that seems to be amplified when using=
> a circular stack design. hmmm .. I don't know if he will agree :)

So each stack has 32 elements.  The way to implement the multitasker
is to reserve 32 cells per stack in the user area.  When you switch
the task, you store all 32 stack elements from each stack to these
buffers in the user area, switch the user area, and load all the stack
elements from these buffers in the user area.  The fact that it is
circular does not really matter.  You don't get lightning-fast context
switches with this design, but at least it should work.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#37325

>A context switch is really best done in assembler, because there you have direct >access to the registers. I don't know if your eforth has an included assembler; >the Forths I've always used have, and I think it's an essential facility for >things like this.

>Basically, you want to push R and the Interpreter pointer (if it's ITC) on to >the data stack and then save the data stack pointer. A whole context switch can >be done in under a dozen machine instructions.

>Cheers,
>Elizabeth

Well the CPU doesn't seem to have the assembly words capable of doing that , it's a very minimal FPGA design by James Bowman , I like it's compactness and ability to process Forth words ..

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

#37336

mfanyikazi@gmail.com writes:
>I have a forth programming problem that is messing up my week , I am trying to port eforth's multitasker into a Forth CPU that has a hardware data and return stack. I don't know how to save and restore the stack pointers when the CPU uses hardware stacks.
>
>If anyone has a link or some documentation on how this can be done , or alternative Forth words to RP@ RP! SP@ SP! that allows the emulation of a context switching mechanism with forth please share , I will be much grateful to learn from you.

Please use lines of about 72 chars.

If the hardware stacks are not represented in memory, a (slow) way to
implement these words is to dump the contents of the stack to memory
and producing a pointer to that memory, and then (for SP! RP!) to load
the contents of the memory stack at that point into the hardware
stack.

Doing that in a way that works for the multi-tasker may be pretty
involved, and it may be easier to write a new multitasker; it has to
do these jobs, though: dump the hardware stack to one memory buffer,
then load the hardware stack from another memory buffer.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

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

#37386

mfanyikazi@gmail.com writes:
> I have a forth programming problem that is messing up my week , I am
> trying to port eforth's multitasker into a Forth CPU that has a
> hardware data and return stack.

Are you aware of this, or is it your repository?

http://github.com/samawati/j1eforth

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

#37390

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> mfanyikazi@gmail.com writes:
>> I am trying to port eforth's multitasker into a Forth CPU
> Are you aware of this, or is it your repository?

Sorry, I see now in that other thread it's indeed yours.

[toc] | [prev] | [standalone]

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

csiph-web