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

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

double tasking with two interpreters

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

Contents

  double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-27 15:47 -0700
    Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-27 13:58 -1000
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-27 18:35 -0700
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-27 20:14 -0700
        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-27 18:38 -1000
    Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-28 12:08 -0400
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 09:21 -0700
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-28 10:11 -0700
        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 07:24 -1000
          Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 11:11 -0700
            Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 11:23 -1000
              Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 14:36 -0700
                Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 12:52 -1000
                  Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 17:14 -0700
                    Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 15:33 -1000
                      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 18:53 -0700
                        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 22:34 -1000
                        Re: double tasking with two interpreters Dirk Bruehl <dirk.bruehl@usa.net> - 2012-05-29 14:57 -0700
            Re: double tasking with two interpreters Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-29 22:16 +0200
              Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-29 10:57 -1000
                Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-29 14:23 -0700
          Re: double tasking with two interpreters Rugxulo <rugxulo@gmail.com> - 2012-05-29 00:22 -0700
      Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-28 12:42 -0400
        Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-28 13:07 -0400
          Re: double tasking with two interpreters Coos Haak <chforth@hccnet.nl> - 2012-05-28 21:39 +0200
        Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-29 12:56 +0000
      Re: double tasking with two interpreters Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-29 22:12 +0200
    Re: double tasking with two interpreters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-29 08:19 +0000
    Re: double tasking with two interpreters stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-29 11:52 +0000
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-29 11:17 -0700
        Re: double tasking with two interpreters stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-29 20:15 +0000
          Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 09:12 -0700
            Re: double tasking with two interpreters Dirk Bruehl <dirk.bruehl@usa.net> - 2012-05-30 20:20 -0700
      Re: double tasking with two interpreters Dirk Bruehl <dirk.bruehl@usa.net> - 2012-05-29 11:25 -0700
    Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-29 12:52 +0000
      Re: double tasking with two interpreters stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-29 13:29 +0000
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-29 08:29 -0700
        Re: double tasking with two interpreters John Passaniti <john.passaniti@gmail.com> - 2012-05-29 14:24 -0700
          Re: double tasking with two interpreters Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-30 01:59 -0700
            Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 03:05 -0700
              Re: double tasking with two interpreters Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-30 03:19 -0700
                Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 08:24 -0700
            Re: double tasking with two interpreters John Passaniti <john.passaniti@gmail.com> - 2012-05-30 07:20 -0700
              Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-31 11:32 +0000
                Re: double tasking with two interpreters John Passaniti <john.passaniti@gmail.com> - 2012-06-01 07:07 -0700
      Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-29 11:55 -0400
        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-29 08:23 -1000
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-29 11:39 -0700
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-29 12:26 -0700
        Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-30 09:34 +0000
          Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 03:02 -0700
            Re: double tasking with two interpreters Arnold Doray <invalid@invalid.com> - 2012-05-30 14:10 +0000
              Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 08:34 -0700
                Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-31 11:44 +0000
                  Re: double tasking with two interpreters Alex McDonald <blog@rivadpm.com> - 2012-05-31 07:02 -0700
            Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-31 07:17 -0700
      Re: double tasking with two interpreters David Kuehling <dvdkhlng@gmx.de> - 2012-05-31 10:09 +0200
        Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-31 02:07 -0700

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

#12590

On May 30, 11:05 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Mark Wills <markrobertwi...@yahoo.co.uk> writes:
> > though being 16-bit makes them a lot better IMHO. 8-bit processors
> > rapidly become a fiddly pain in the arse if you want to do any math -
> > 16 bit makes it a bit easier, especially as they usually come with 32
> > bit multiply and divide,
>
> The cheap msp430's that run in the launchpad don't have mul/div either.
> The multiplier in the models that have it is fairly fast as such things
> go, though.

You haven't said what your application actually *is*. (Apologies if I
missed it). Are you *sure* you even need to run two tasks? Could it
not be done in one task with a state machine?

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

#12607

Mark Wills <markrobertwills@yahoo.co.uk> writes:
> You haven't said what your application actually *is*. (Apologies if I
> missed it). Are you *sure* you even need to run two tasks? Could it
> not be done in one task with a state machine?

Well I'm thinking sort of generically.  Yes of course it's always
possible to write these things with state machines, but using tasks or
coroutines is often more natural.

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

#12604

On Wednesday, May 30, 2012 4:59:26 AM UTC-4, Mark Wills wrote:
> Not at all. Why use an 8-bit part, if you can buy a 
> 16-bit part for the same price? Have you actually 
> looked at the price of the MSP430 family in quantity? 

Yep, we have.  And when you actually take the time to compare the actual features we are using (number of GPIOs, amount of RAM, amount of flash) the Freescale 8-bit parts still win.  That won't always be the case, but in our specific case, it is.  

The Freescale 8-bit parts we're using also win in other ways.  First, we're very familiar with them, know their quirks, and have loads of experience with the tools; time to market matters.  Second, we're already using those 8-bit microcontrollers in other designs, so we can drive up the quantities.  Third, we're extremely happy with our supply chain and support FAE's and we get price breaks because of *other* products we buy.

> [...] 8-bit processors rapidly become a fiddly pain in the arse 
> if you want to do any math - 16 bit makes it a bit easier, 
> especially as they usually come with 32 bit multiply and divide, 
> whereas most 8 bit parts have no MUL/DIV at all.

The Freescale parts we're using (in the HCS08 family) do have 8x8 multiply and 16x8 divide.  But that doesn't matter at all to us.  First, we're not programming them in assembly language, but in C.  And the C compiler's libraries provide not only full 32x32 multiply and divide but also floating point.  Second, we're not using these microcontrollers for math-intensive operations.  Our use is primarily for control.  That being said, even the slow floating point library routines are many times faster than what we need.

> Regarding your 8 bit MCU driving 32 12 segment 
> displays, how, and why? Why wouldn't you use 
> discrete bar drivers? That's what they're for.
> Did your 8 bit MCU have 32 ADCs? Clearly not. 
> So how did you multiplex 32 audio signals into 
> (possibly one?) ADC channel, [...]

The front panel connects to the rest of the system using a SPI channel.  Like in all reasonable audio equipment, no audio is going to the front panel.  These systems are digital audio signal processors and power amplifiers; there are separate DSPs handling the processing of audio.  Related to metering, it's the DSPs that handle peak detection, level hold, and ballistics.  The front panel is only responsible for getting metering data and displaying it.  This frees the DSPs and main microcontroller from having to service the front panel.  As for why we don't use dedicated bar drivers is because it's less expensive to have the little 8-bit microcontroller drive that LED matrix directly.

> [...] And how did you do this fast enough that the 
> displays were accurate? I presume the bar
> displays were scaled in db's? How did you multiplex 
> the input, perform the calculation (I guess it 
> could be a simple look-up), and the multiplex the 
> output fast enough to update 32 bar graph's in real 
> time?

The DSP handles the math.  The 8-bit microcontroller handles the control aspects of the front panel.

For many applications-- especially control-oriented-- 8-bit microcontrollers are still more than enough to get the job done, leverage existing experience, and have excellent support, and often come in at lower prices.  Do they always make sense?  No, of course not.  We had a design that started off with an 8-bit HCS08 microcontroller (a QE128), but in that specific application we did actually have to do real-time impedance calculations.  That required being able to sample at 48kHz, which the part could do, but it couldn't keep up all it's other duties that we placed on it.  So in that case, we moved to the MCF51 version of the part, which is the exact same pin-out but replaces the 8-bit CPU with a 32-bit CPU.  Recompile, fix some minor portability issues, and presto-- it works fine with plenty of margin.

You're free to continue to offer suggestions, but your Derren Brown skills of mind-reading are pretty poor.  I'll be happy to discuss details of the design in private email.  But really, the details aren't important.  This sub-thread is about the reality that these days many hardware designs are best achieved not with a singular processor, but with multiple processors each dedicated to a subsystem.  And there, depending on what you're trying to accomplish, there are still many places where 8-bit microcontrollers win.

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

#12631

In article <2f556466-f84d-4bd0-817a-59eba3e8a429@googlegroups.com>,
John Passaniti  <john.passaniti@gmail.com> wrote:
<SNIP>
>
>You're free to continue to offer suggestions, but your Derren Brown skills =
>of mind-reading are pretty poor.  I'll be happy to discuss details of the d=
>esign in private email.  But really, the details aren't important.  This su=
>b-thread is about the reality that these days many hardware designs are bes=
>t achieved not with a singular processor, but with multiple processors each=
> dedicated to a subsystem.  And there, depending on what you're trying to a=
>ccomplish, there are still many places where 8-bit microcontrollers win.

I respect your judgement. Still in one of my last jobs they were
moving all control to work via a dedicated industrial PC that emulates
PLC's. The main program was in Java, and the bottom line was that I
couldn't count 1 mS pulses myself in Java and had to write a remote
control for the PLC and have written the lowlevel part in a different
PLC-compatible language. This makes a Forther cringe, probably.

Still somehow I thought it made a lot of sense. What they were moving
away from had was a couple of boards with 8-bit controllers. They face
the problem that those go end of life. Then the board has to be
redesigned and the program has to be adapted to a new processor.

Of course the PLC-computer has a lot of plug in modules for different
controls. Presumably these are black boxes with ... your 8 bit micro
controllers. But now the responsability for personal injury and
mission critical aspects is with very experienced designers of black
boxes.

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]

#12655

On Thursday, May 31, 2012 7:32:26 AM UTC-4, Albert van der Horst wrote:
> I respect your judgement. Still in one of 
> my last jobs they were moving all control 
> to work via a dedicated industrial PC that 
> emulates PLC's. [...]

You don't have to respect my judgement.  The only thing you (and that's the generic "you" here) have to respect is that different embedded systems have different requirements and constraints.  So there is no singular right answer and that answer will change over time.  Statements about the irrelevance of 8-bit microcontrollers appear to be lost on chip manufacturers who in response to demand are still producing them.  Statements about the design decision to not factor embedded system hardware by using multiple microcontrollers appear to be lost on most every non-trivial design I've come across in the past 25 years.

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

#12554

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
news:m4sbr2.dy0@spenarnc.xs4all.nl...
> In article <7xmx4tckcg.fsf@ruckus.brouhaha.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
> > I'm looking at the MSP430, whose instruction architecture is sort of
> > like a PDP-11, with less regularity in the address modes, but the upside
> > is that it has 16 registers (a few of them special purpose) instead of
> > 8.  [...]  The MSP430 variant I'm looking at has just 128 bytes of ram,
> > so it's not plentiful.  [...]
> >
> >Is this silly?
>
> With all due respect yes. The greatest problem with 128 bytes of
> RAM is to fit 2 stacks and a user area. With 2 tasks those areas
> have to be duplicated.
>

16 registers
128 bytes of ram
2KB of rom

I think he already decided to cross-compile.  I'd assume his dictionary and
program are both entirely in rom and not in ram.  I.e., fixed dictionary,
fixed program, no user areas.  If so, I'd think the ram is almost entirely
available for stacks.

He could try 32 bytes per stack for 4 stacks.  He could adjust them as
needed.  I.e., if control-flow uses more stack, then, 48 bytes each for 2
control-flow stacks and 16 bytes each for 2 data stacks, or vice-versa.

I'm not sure how much stack a typical Forth program uses.  I know I'm using
two 256 byte stacks on a 32-bit machine without issues, so far ...  That's
nothing.  I set them really low while I was getting the interpreter working.
I.e., I'd guess that's roughly equivalent to two 64 byte stacks on an 8-bit
machine.

However, all that depends on his Forth system variables.  I have eleven
variables and six constants in mine so far.  Does he need a DP (dictionary
pointer) or LAST if his dictionary is static/fixed?  He needs data/parameter
stack pointer and return/control-flow stack pointer.  The initial S0/SP0 or
R0/RP0 can be hardcoded.  He may or may not need >IN or BLK.  So, he
might need around 10 or so ram locations for variables.

He also has alot of registers.  He could move some of those Forth system
variables into registers.  Or, he could shift stack items into registers.
He could ke ep constants, like zero, in register.  E.g., he could keep the
three top stack items of the data stacks in registers.  That would eliminate
much manipulation of the ram portion of the stack.  I.e., DUP, SWAP, OVER,
etc will operate only the registers.  Of course, the sequences for DROP,
pushing a value to the stack, and shifting a stack (ROLL) become larger.


What can he do to reduce rom usage?

1) use DTC (or ITC) instead of STC
2) implement the inner/address interpreter but do not implement the
outer/text interpreter
3) eliminate the dictionary headers, i.e., non-searchable
4) avoid Forth words that could be more difficult to implement,
e.g., ROLL DOES>
5) limit characters to A-Z and 0-9
6) compute characters instead of using a table
...


Rod Pemberton

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

#12561

On 5/29/12 5:55 AM, Rod Pemberton wrote:
> "Albert van der Horst"<albert@spenarnc.xs4all.nl>  wrote in message
> news:m4sbr2.dy0@spenarnc.xs4all.nl...
...
>> With all due respect yes. The greatest problem with 128 bytes of
>> RAM is to fit 2 stacks and a user area. With 2 tasks those areas
>> have to be duplicated.
>>
>
> 16 registers
> 128 bytes of ram
> 2KB of rom

Well, if you've followed other parts of this thread you'll see that he's 
found larger versions of the MSP430 that work in this board.

> I think he already decided to cross-compile.  I'd assume his dictionary and
> program are both entirely in rom and not in ram.  I.e., fixed dictionary,
> fixed program, no user areas.  If so, I'd think the ram is almost entirely
> available for stacks.
>
> He could try 32 bytes per stack for 4 stacks.  He could adjust them as
> needed.  I.e., if control-flow uses more stack, then, 48 bytes each for 2
> control-flow stacks and 16 bytes each for 2 data stacks, or vice-versa.
>
> I'm not sure how much stack a typical Forth program uses.  I know I'm using
> two 256 byte stacks on a 32-bit machine without issues, so far ...  That's
> nothing.  I set them really low while I was getting the interpreter working.
> I.e., I'd guess that's roughly equivalent to two 64 byte stacks on an 8-bit
> machine.

It's quite possible to run simple programs with 32 bytes per stack (16 
items, on a 16-bit processor).

A terminology caution: the "control flow stack" mentioned in ANS Forth 
is actually the Data Stack used during compilation, not the Return Stack 
at run-time as you seem to imply.

> However, all that depends on his Forth system variables.  I have eleven
> variables and six constants in mine so far.  Does he need a DP (dictionary
> pointer) or LAST if his dictionary is static/fixed?  He needs data/parameter
> stack pointer and return/control-flow stack pointer.  The initial S0/SP0 or
> R0/RP0 can be hardcoded.  He may or may not need>IN or BLK.  So, he
> might need around 10 or so ram locations for variables.

He is not compiling, so certainly needs no dictionary management. 
However, HERE can specify data space, e.g. a buffer for temporary use. 
We don't know if he wants to manage text input, although I suspect not. 
That would take some space.

> He also has alot of registers.  He could move some of those Forth system
> variables into registers.  Or, he could shift stack items into registers.
> He could ke ep constants, like zero, in register.  E.g., he could keep the
> three top stack items of the data stacks in registers.  That would eliminate
> much manipulation of the ram portion of the stack.  I.e., DUP, SWAP, OVER,
> etc will operate only the registers.  Of course, the sequences for DROP,
> pushing a value to the stack, and shifting a stack (ROLL) become larger.

See the discussion elsewhere in this thread about register usage.

> What can he do to reduce rom usage?
>
> 1) use DTC (or ITC) instead of STC

ITC is usually smaller than DTC on a 16-bit processor.

> 2) implement the inner/address interpreter but do not implement the
> outer/text interpreter
> 3) eliminate the dictionary headers, i.e., non-searchable

Goes with ditching the text interpreter, and standard practice on 
embedded systems.

> 4) avoid Forth words that could be more difficult to implement,
> e.g., ROLL DOES>

ROLL should be avoided on the grounds of good programming practice :-) 
But DOES> actually saves space in the target, as it is a means of 
avoiding repeating code sequences.

> 5) limit characters to A-Z and 0-9

Can't imagine how that helps. An 8-bit char handles all ASCII, just not 
extended chars.

> 6) compute characters instead of using a table

Doesn't everyone?

Cheers,
Elizabeth

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

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

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

#12563

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> With all due respect yes. The greatest problem with 128 bytes of
> RAM is to fit 2 stacks and a user area. With 2 tasks those areas
> have to be duplicated.

I think it's not too bad.  A GA144 node has 10 data stack and 8 return
stack slots or so, which don't seem to be its biggest constraint, and
this processor is sort of comparable.  In the two-task setup if the code
follows reasonable practices, it should be possible to statically figure
out the max stack depths for each task, and allocate memory accordingly.
3-5 words (2 bytes/word) for each stack (especially with a bit of
compiler inlining to save return slots) is likely to be enough for the
sort of thing I have in mind, plus there might be a few static
variables.  Programming in assembler it's probably feasible for some
sensible programs to use no ram at all, other than the registers.

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

#12566

On May 29, 2:39 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Programming in assembler it's probably feasible for some
> sensible programs to use no ram at all, other than the registers.

The prospect for several tasks using no *extra* RAM goes up if your
task switching relies on:
   ( -- )
... side tasks, since other than the stacks, you have effectively 11
cellwide variables to work with before you need to go out to RAM.

For the stacks, the relevant stack depth (for both stacks) is the
greatest of the deepest that the main task stack gets, or the deepest
that the main task stack is when it PAUSEs, plus the deepest a side
stack goes. So if the deepest a side task goes is four cells, and the
deepest that the main task is when calling PAUSE is four cells, seven
cells plus TOS will do, and the main task can be as much as eight deep
between PAUSE. Similar for the RSTACK though with likely lower amounts
both ways.

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

#12587

In article <7xlika6dca.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>> With all due respect yes. The greatest problem with 128 bytes of
>> RAM is to fit 2 stacks and a user area. With 2 tasks those areas
>> have to be duplicated.
>
>I think it's not too bad.  A GA144 node has 10 data stack and 8 return
>stack slots or so, which don't seem to be its biggest constraint, and
>this processor is sort of comparable.  In the two-task setup if the code
>follows reasonable practices, it should be possible to statically figure
>out the max stack depths for each task, and allocate memory accordingly.
>3-5 words (2 bytes/word) for each stack (especially with a bit of
>compiler inlining to save return slots) is likely to be enough for the
>sort of thing I have in mind, plus there might be a few static
>variables.  Programming in assembler it's probably feasible for some
>sensible programs to use no ram at all, other than the registers.

But the GA144 is not programmed in Forth! It is programmed in restricted
colorforth aka GA144 assembler.

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]

#12588

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> But the GA144 is not programmed in Forth! It is programmed in restricted
> colorforth aka GA144 assembler.

Maybe I should just implement the GA "exchange" or coroutine jump
instruction.  It swaps the program counter with the top of the return
stack, making no attempt to have separate stacks or registers per task.

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

#12602

On Wed, 30 May 2012 03:02:35 -0700, Paul Rubin wrote:

> Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>> But the GA144 is not programmed in Forth! It is programmed in
>> restricted colorforth aka GA144 assembler.
> 
> Maybe I should just implement the GA "exchange" or coroutine jump
> instruction.  It swaps the program counter with the top of the return
> stack, making no attempt to have separate stacks or registers per task.

Isn't that similar to R stack manipulation? 

AIUI, the coroutine jump method is not meant for toggling between 
stateful tasks, since state is lost. For toggling between tasks wouldn't 
you would have to add saving the registers, which is equivalent to 
Elizabeth's suggestion?

I can't see how you can get away with using just one pair of data/return 
stacks, unless you assume that each task either leaves a clean stack or 
does not require the contents of the stack to be preserved during a 
switch. Or you could copy the stack to some safe area during the switch. 
Much easier to have two pairs of stacks. 128 bytes is plenty, I think. 

Cheers,
Arnold

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

#12608

Arnold Doray <invalid@invalid.com> writes:
> Isn't that similar to R stack manipulation? 

I'm not sure how to do that operation with standard Forth words.
You have to be able to jump into the middle of another word.

> AIUI, the coroutine jump method is not meant for toggling between 
> stateful tasks, since state is lost. 

They'd no longer be independent tasks.  Each would have to know what the
other was doing.  But, they could pass stack args to each other, which
is nice.

> I can't see how you can get away with using just one pair of data/return 
> stacks, unless you assume that each task either leaves a clean stack or ...

No I think it works out quite nicely.  It's not the same thing as
independent multitasking, but it has very low overhead, especially if
the top of the return stack is in a register, so you'd just swap two
registers.

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

#12630

In article <7xbol5el8z.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Arnold Doray <invalid@invalid.com> writes:
>> Isn't that similar to R stack manipulation?
>
>I'm not sure how to do that operation with standard Forth words.
>You have to be able to jump into the middle of another word.
>
>> AIUI, the coroutine jump method is not meant for toggling between
>> stateful tasks, since state is lost.
>
>They'd no longer be independent tasks.  Each would have to know what the
>other was doing.  But, they could pass stack args to each other, which
>is nice.

>
>> I can't see how you can get away with using just one pair of data/return
>> stacks, unless you assume that each task either leaves a clean stack or ...
>
>No I think it works out quite nicely.  It's not the same thing as
>independent multitasking, but it has very low overhead, especially if
>the top of the return stack is in a register, so you'd just swap two
>registers.

The difference between
    XCHG  %ESI, [%EBP]
and
    XCHG  %ESI, %EBP

Come on, don't you have other things to worry about?

I have used it and I can tell you, the manipulation to have
the data available is the main overhead.

I use the name CO in ciforth, maybe Chuck's name `` ;: '' is better.
Does it catch on (that name I mean) ?

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]

#12634

On May 31, 12:44 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <7xbol5el8z....@ruckus.brouhaha.com>,
> Paul Rubin  <no.em...@nospam.invalid> wrote:
>
>
>
>
>
>
>
>
>
> >Arnold Doray <inva...@invalid.com> writes:
> >> Isn't that similar to R stack manipulation?
>
> >I'm not sure how to do that operation with standard Forth words.
> >You have to be able to jump into the middle of another word.
>
> >> AIUI, the coroutine jump method is not meant for toggling between
> >> stateful tasks, since state is lost.
>
> >They'd no longer be independent tasks.  Each would have to know what the
> >other was doing.  But, they could pass stack args to each other, which
> >is nice.
>
> >> I can't see how you can get away with using just one pair of data/return
> >> stacks, unless you assume that each task either leaves a clean stack or ...
>
> >No I think it works out quite nicely.  It's not the same thing as
> >independent multitasking, but it has very low overhead, especially if
> >the top of the return stack is in a register, so you'd just swap two
> >registers.
>
> The difference between
>     XCHG  %ESI, [%EBP]
> and
>     XCHG  %ESI, %EBP
>
> Come on, don't you have other things to worry about?

With the execution frequency of the XCHG, it may be a concern. The
first XCHG with a memory operand issues a LOCK, which (depending on
processor; later x86 processors appear better in this respect) is
reported to slow down operations significantly. I've not done any
benchmarking on this; YMMV.

>
> I have used it and I can tell you, the manipulation to have
> the data available is the main overhead.
>
> I use the name CO in ciforth, maybe Chuck's name `` ;: '' is better.
> Does it catch on (that name I mean) ?
>
> Groetjes Albert
>
> --
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst

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

#12635

On May 30, 6:02 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
> > But the GA144 is not programmed in Forth! It is programmed in restricted
> > colorforth aka GA144 assembler.
>
> Maybe I should just implement the GA "exchange" or coroutine jump
> instruction.  It swaps the program counter with the top of the return
> stack, making no attempt to have separate stacks or registers per task.

Yes, as long as your side-tasks are ( -- ) stack-effect words, that'll
work ~ push the side-routine xt on the return stack, call CO, as soon
as the co-routine completes, execution resumes after CO. PAUSE can
push a dedicated side-task register to the return stack, but you also
get co-routine support as well.

The side-task chain could work the same way either way ~ each side-
task over-writes the side-task register with the xt of the next side-
task in the chain, goes about its business, and when its done,
execution of the main task loop picks up where it was paused.

In the bigger processor, you could walk along a side-task queue or
chain, but for the smaller processor, baking the task sequence in is
most space-efficient.

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

#12627

>>>>> "Albert" == Albert van der Horst <albert@spenarnc.xs4all.nl> writes:

> In article <7xmx4tckcg.fsf@ruckus.brouhaha.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
[..]
>> I'm wondering if it's a known, sensible method, to simply have two
>> copies of the address interpreter, one of them using (say) R0 through
>> R4, and the other using R5 through R9, to hold the DP, RP, TOS, etc.
>> Then a task switch would just mean jumping from one interpreter to
>> the other.
>> 
>> Is this silly?

> With all due respect yes. The greatest problem with 128 bytes of RAM
> is to fit 2 stacks and a user area. With 2 tasks those areas have to
> be duplicated.

Some of the german Forthers I met at Linuxtag suggested to not even give
the second task its own stacks.  Instead running it like an interrupt on
top of the stack of the currently running word.  Yes the second task
would need to balance stacks at PAUSE.  Very accaptable compromise for a
task blinking LEDs or doing some simple state-machine I/O processing.

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

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

#12629

David Kuehling <dvdkhlng@gmx.de> writes:
> Some of the german Forthers I met at Linuxtag suggested to not even give
> the second task its own stacks.  Instead running it like an interrupt on
> top of the stack of the currently running word.  Yes the second task
> would need to balance stacks at PAUSE.  Very accaptable compromise for a
> task blinking LEDs or doing some simple state-machine I/O processing.

Yes, this is what I'm planning to do now, basically the colorforth EX
instruction (swap P and top of R).  I might make an RTUCK primitive
for when a task does want to save something before pausing but it's
probably saner to allocate a few registers for these purposes.

[toc] | [prev] | [standalone]

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

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

csiph-web