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

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

Expected BASE-LINE for Embedded Controllers

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

Contents

  Expected BASE-LINE for Embedded Controllers Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-18 11:58 +0000
    Re: Expected BASE-LINE for Embedded Controllers Matthias Trute <matthias.trute@gmail.com> - 2015-01-18 04:55 -0800
      Re: Expected BASE-LINE for Embedded Controllers Mikael Nordman <oh2aun@gmail.com> - 2015-01-18 10:20 -0800
      Re: Expected BASE-LINE for Embedded Controllers visualforth@rocketmail.com - 2015-01-20 10:45 -0800
        Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 12:34 -1000
          Re: Expected BASE-LINE for Embedded Controllers visualforth@rocketmail.com - 2015-01-20 16:40 -0800
    Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-18 22:27 +0100
      Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-18 13:45 -1000
        Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-19 18:22 +0000
      Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-19 12:06 +0100
        Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-19 18:47 +0000
          Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-19 11:22 -1000
            Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-20 11:54 +0000
          Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-20 09:49 +0100
        Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-19 20:27 +0100
        Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 11:04 -0800
          Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-20 11:33 -0800
          Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-20 23:30 +0100
            Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 14:41 -0800
              Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 00:40 +0100
                Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-20 15:53 -0800
                  Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-21 01:41 +0100
                    Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 15:38 -1000
                    Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:08 -0800
                      Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-23 16:10 +0000
              Re: Expected BASE-LINE for Embedded Controllers "Elizabeth D. Rather" <erather@forth.com> - 2015-01-20 15:25 -1000
            Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-21 10:40 +0000
    Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-19 12:00 +0100
    Re: Expected BASE-LINE for Embedded Controllers Mikael Nordman <oh2aun@gmail.com> - 2015-01-21 00:04 -0800
      Re: Expected BASE-LINE for Embedded Controllers Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-01-21 11:53 +0100
      Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-21 03:02 -0800
      Re: Expected BASE-LINE for Embedded Controllers Mark Wills <markwills1970@gmail.com> - 2015-01-21 03:07 -0800
        Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-22 15:50 +0100
          Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-22 16:39 +0000
          Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:13 -0800
            Re: Expected BASE-LINE for Embedded Controllers stephen@mpeforth.com (Stephen Pelc) - 2015-01-23 11:19 +0000
              Re: Expected BASE-LINE for Embedded Controllers albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-23 16:12 +0000
            Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-23 16:42 +0000
              Re: Expected BASE-LINE for Embedded Controllers Paul Rubin <no.email@nospam.invalid> - 2015-01-24 01:53 -0800
                Re: Expected BASE-LINE for Embedded Controllers Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-24 15:33 +0100
                Re: Expected BASE-LINE for Embedded Controllers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-25 15:48 +0000

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

#35875 — Expected BASE-LINE for Embedded Controllers

Forth Baseline Word Set Proposal

Some discussion has been bubbling in the background since before last year's 
EuroForth. The problem is seen that, for deeply embedded controls, some 
words in the CORE are not suitable candidates for inclusion in the system. 
Additionally, some useful words are not in CORE.

If we are to allow a claim of compliance to the standard for such deeply 
embedded systems we may need to look at a sensible BASE-LINE set of words 
that we should be able to count on to be there for a system that may connect 
to the embedded controller via a communications port only, without being 
over-burdened by words that are only sensible in the desk-top realm.
(Otherwise the standards declaration can get quite complicated)

Hence, trying to establish what words might be included in the Baseline set 
began via email discussions between a few of us who are more into the small 
controller markets. This can include 8-bit, 16-bit, 18-bit, 21-bit, and 32-
bit processors. 

So, the set suggested below is probably richer than an absolute minimalist 
set would be (that extreme is saved for the Umbilical Only System and may be 
as little as XC@, XC! and XCALL).

The following 71 words are suggested at this stage. 

Words for inclusion:
Memory Access:-
HERE C@ C! @ , C, ALIGN ALIGNED CELL+ CELLS CALIGN  CALIGNED CHAR+ CHARS 
! ' [']

Arithmetic:-
+ - 2* * / 2/ MOD */MOD UM*

Logic:
0= 0< 0<> = < > AND OR XOR LSHIFT RSHIFT

Stack:
DUP SWAP OVER DROP >R R> R@ ROT

Flow Control:
IF ELSE THEN BEGIN WHILE UNTIL DO I J LOOP EXECUTE

Defining:
: ; CREATE DOES> CONSTANT VARIABLE 

I/O:
KEY KEY? CR EMIT

Tools:
( \ .S

Exception Management:
CATCH THROW

Special Words: 
Some special words will have to be added for controllers FLASH and IO 
handling. These will be underlying machine specific and are therefore not 
specified in this list.

About The Exception Management Choice:
It has been felt that the Catch & Throw mechanism is the most flexible way 
of managing exceptions that may arise for different reasons. The standard 
gives a range of values pre-defined for specific error types. Minimal action 
would be the actions of ABORT (-1 or any non-zero code), see Standard 
reference 6.1.0680.

Some final Words:
It is seen that this smaller set of words, defined as a Baseline Set, would 
allow simpler starter systems for those who may be confused by the rich 
dictionary of some of the offerings. 

In the deeply embedded controller world it would also assist with preferring 
a fully certified product for such deeply embedded controllers, while also 
being able to claim full adherence to a standard.

The observant will realise that IMMEDIATE is not in the list. The need for 
this rather depends on implementation details and whether or not the 
IMMEDIATE flag is required in the word's header or not. 

Other issues of STATE also come into this category and there have been 
lengthy discussions on both factors

Please start a new thread on the specific topics of state smartness and 
immediacy rather than discuss those issues in this one.

What do you guys think?

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [next] | [standalone]

#35877

> What do you guys think?

That list is great. From my experience with
amforth projects I'd suggest to think about
DEFER and VALUE as well.

In amforth, some quite lowlevel words are deferred.
One group is KEY/EMIT/KEY?. That way I can easily
redirect the user interface to e.g. a LCD or to a
RS485 network. Other uses for DEFER are the 
TURNKEY (automatically execute action 
at startup time). Not to forget PAUSE.

http://amforth.sourceforge.net/TG/recipes/Deferred-Words.html

I use VALUEs to hide the actual storage location. That
is beyond the standard, I know, but works great. TO has
to be able to handle different data types anyway. I have
a small I2C network with various chips attached: an RTC
EEPROM, switches etc. When I associate a device (and maybe
an address inside it) with a VALUE, I can transparently 
access the data. Similar 1--wire devices. Specific to the
AVR Atmegas I use VALUE's to access the built-in EEPROM that
has an address range of its own.

http://amforth.sourceforge.net/TG/recipes/Values.html

Matthias

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

#35885

On Sunday, January 18, 2015 at 2:55:38 PM UTC+2, Matthias Trute wrote:
> > What do you guys think?
> 
> That list is great. From my experience with
> amforth projects I'd suggest to think about
> DEFER and VALUE as well.
> 
> Matthias

I think VALUE and DEFER are just simple sugarcoating.
These can be easily compiled with CREATE DOES> @ EXECUTE ...
if really needed.

So I would leave those out.

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

#35922

On Sunday, January 18, 2015 at 7:55:38 AM UTC-5, Matthias Trute wrote:
> 
> In amforth, some quite lowlevel words are deferred.
> One group is KEY/EMIT/KEY?. That way I can easily
> redirect the user interface to e.g. a LCD or to a
> RS485 network. 

RSC-Forth uses vectors containing the address of KEY/EMIT/KEY?
That way the user interface to e.g. a LCD or to a keypad or even to a RS485 network can be redirected easily. Same for interrupts.

This is very important to be able to test I/O without already having the final hardware. 

RSC-Forth, written by Randy Dumse, is a good example to look at how a good microprocessor Forth should be. It only lacks VARIABLE definitions residing in FLASH. 

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

#35926

On 1/20/15 8:45 AM, visualforth@rocketmail.com wrote:
> On Sunday, January 18, 2015 at 7:55:38 AM UTC-5, Matthias Trute wrote:
>>
>> In amforth, some quite lowlevel words are deferred.
>> One group is KEY/EMIT/KEY?. That way I can easily
>> redirect the user interface to e.g. a LCD or to a
>> RS485 network.
>
> RSC-Forth uses vectors containing the address of KEY/EMIT/KEY?
> That way the user interface to e.g. a LCD or to a keypad or even to a RS485 network can be redirected easily. Same for interrupts.
>
> This is very important to be able to test I/O without already having the final hardware.
>
> RSC-Forth, written by Randy Dumse, is a good example to look at how a good microprocessor Forth should be. It only lacks VARIABLE definitions residing in FLASH.
>

Yes, FORTH, Inc. systems have followed this practice since Day 1.

Cheeers,
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]

#35932

On Tuesday, January 20, 2015 at 5:35:00 PM UTC-5, Elizabeth D. Rather wrote:
> On 1/20/15 8:45 AM, visualforth.com wrote:
> > On Sunday, January 18, 2015 at 7:55:38 AM UTC-5, Matthias Trute wrote:
> >>
> >> In amforth, some quite lowlevel words are deferred.
> >> One group is KEY/EMIT/KEY?. That way I can easily
> >> redirect the user interface to e.g. a LCD or to a
> >> RS485 network.
> >
> > RSC-Forth uses vectors containing the address of KEY/EMIT/KEY?
> > That way the user interface to e.g. a LCD or to a keypad or even to a RS485 network can be redirected easily. Same for interrupts.
> >
> > This is very important to be able to test I/O without already having the final hardware.
> >
> > RSC-Forth, written by Randy Dumse, is a good example to look at how a good microprocessor Forth should be. It only lacks VARIABLE definitions residing in FLASH.
> >
> 
> Yes, FORTH, Inc. systems have followed this practice since Day 1.
> 
> Cheeers,
> 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."
> ==================================================

Thanks, Elizabeth, I appreciate that!
DB

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

#35887

Paul E Bennett wrote:

> Forth Baseline Word Set Proposal
>[...]
> Exception Management:
> CATCH THROW

I'd rather like to have SP@ RP@ SP! RP!, because it allows building these 
and the multitasker if you need them.  Small systems on embedded controllers 
don't often need that much of exception management, but if you want it, you 
need some building blocks to make it.

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

#35890

On 1/18/15 11:27 AM, Bernd Paysan wrote:
> Paul E Bennett wrote:
>
>> Forth Baseline Word Set Proposal
>> [...]
>> Exception Management:
>> CATCH THROW
>
> I'd rather like to have SP@ RP@ SP! RP!, because it allows building these
> and the multitasker if you need them.  Small systems on embedded controllers
> don't often need that much of exception management, but if you want it, you
> need some building blocks to make it.

Wow, none of FORTH, Inc.'s systems have SP@ etc., as we really 
discourage direct manipulation of stack pointers. Of course, they all 
have a multitasker already. I really don't think adding a multitasker is 
something you should expect to be able to do portably, as I don't see 
how you can possibly build an efficient one in high level.

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]

#35903

In article <U9GdnY4LLb8a2CHJnZ2dnUU7-LednZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 1/18/15 11:27 AM, Bernd Paysan wrote:
>> Paul E Bennett wrote:
>>
>>> Forth Baseline Word Set Proposal
>>> [...]
>>> Exception Management:
>>> CATCH THROW
>>
>> I'd rather like to have SP@ RP@ SP! RP!, because it allows building these
>> and the multitasker if you need them.  Small systems on embedded
>controllers
>> don't often need that much of exception management, but if you
>want it, you
>> need some building blocks to make it.
>
>Wow, none of FORTH, Inc.'s systems have SP@ etc., as we really
>discourage direct manipulation of stack pointers. Of course, they all
>have a multitasker already. I really don't think adding a multitasker is
>something you should expect to be able to do portably, as I don't see
>how you can possibly build an efficient one in high level.

The multitasker of ciforth is totally in highlevel, with a few references
to the stack pointers. It does use carnal knowledge, of course.
It is also simple enough to be semi portable.
Could it be more efficient in high level? Hmm. If I imagine an
optimising compiler used for it: no.

>
>Cheers,
>Elizabeth

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]

#35898

> I'd rather like to have SP@ RP@ SP! RP!, because it allows building these 
> and the multitasker if you need them.  Small systems on embedded controllers 
> don't often need that much of exception management, but if you want it, you 
> need some building blocks to make it.

While Bernd implemented Multitasking and Catch/Throw for Mecrisp-Stellaris we found that we need a way to save internal, implementation specific registers to perform a task switch; loop index and loop limit registers in this case. We solved this with opcodes in hex and comma, but this is not what a standard should call for. So in addition to have SP@ RP@ SP! RP! I would recommend to have something like save-all-internal-task-switch-critical-registers-to-stack and to fetch them back.

Matthias

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

#35904

In article <m9ioho$nl1$1@newsserver.rrzn.uni-hannover.de>,
Matthias Koch  <matthias.koch@hot.uni-hannover.de> wrote:
>> I'd rather like to have SP@ RP@ SP! RP!, because it allows
>building these
>> and the multitasker if you need them.  Small systems on embedded
>controllers
>> don't often need that much of exception management, but if you
>want it, you
>> need some building blocks to make it.
>
>While Bernd implemented Multitasking and Catch/Throw for
>Mecrisp-Stellaris we found that we need a way to save internal,
>implementation specific registers to perform a task switch; loop
>index and loop limit registers in this case. We solved this with
>opcodes in hex and comma, but this is not what a standard should
>call for. So in addition to have SP@ RP@ SP! RP! I would recommend
>to have something like
>save-all-internal-task-switch-critical-registers-to-stack and to
>fetch them back.

Oops far too much. Instead of manipulating stack do it yourself
multitasking thse two words:

(xt, iid)  INSTALL-INTERRUPT
Install xt to be executed on the implementation defined
interrupt iid.

IRET return from interrupt: obligatory end of an xt such as
installable by INSTALL-INTERRUPT

And I would scrap UM*

With BEGIN WHILE I missed REPEAT.


>
>Matthias
-- 
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]

#35907

On 1/19/15 8:47 AM, Albert van der Horst wrote:
> In article <m9ioho$nl1$1@newsserver.rrzn.uni-hannover.de>,
> Matthias Koch  <matthias.koch@hot.uni-hannover.de> wrote:
>>> I'd rather like to have SP@ RP@ SP! RP!, because it allows
>> building these
>>> and the multitasker if you need them.  Small systems on embedded
>> controllers
>>> don't often need that much of exception management, but if you
>> want it, you
>>> need some building blocks to make it.
>>
>> While Bernd implemented Multitasking and Catch/Throw for
>> Mecrisp-Stellaris we found that we need a way to save internal,
>> implementation specific registers to perform a task switch; loop
>> index and loop limit registers in this case. We solved this with
>> opcodes in hex and comma, but this is not what a standard should
>> call for. So in addition to have SP@ RP@ SP! RP! I would recommend
>> to have something like
>> save-all-internal-task-switch-critical-registers-to-stack and to
>> fetch them back.
>
> Oops far too much. Instead of manipulating stack do it yourself
> multitasking thse two words:
>
> (xt, iid)  INSTALL-INTERRUPT
> Install xt to be executed on the implementation defined
> interrupt iid.
>
> IRET return from interrupt: obligatory end of an xt such as
> installable by INSTALL-INTERRUPT

Still far too much, as it assumes a concept of how multitasking and 
interrupts work that is unspecified, and we are very far from being able 
to specify such a thing. You may be able to do some kind of multitasking 
in high level, but (as noted) not without "carnal knowledge". Just don't 
try to go there. It'll cause nothing but wrangling, misunderstandings, 
and trouble. Keep it simple.

> And I would scrap UM*

As a requirement, maybe, although I think it's very useful.

> With BEGIN WHILE I missed REPEAT.

Yep, need REPEAT.

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]

#35916

In article <osSdnSfibJoz6CDJnZ2dnUU7-dGdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 1/19/15 8:47 AM, Albert van der Horst wrote:
>> In article <m9ioho$nl1$1@newsserver.rrzn.uni-hannover.de>,
>> Matthias Koch  <matthias.koch@hot.uni-hannover.de> wrote:
>>>> I'd rather like to have SP@ RP@ SP! RP!, because it allows
>>> building these
>>>> and the multitasker if you need them.  Small systems on embedded
>>> controllers
>>>> don't often need that much of exception management, but if you
>>> want it, you
>>>> need some building blocks to make it.
>>>
>>> While Bernd implemented Multitasking and Catch/Throw for
>>> Mecrisp-Stellaris we found that we need a way to save internal,
>>> implementation specific registers to perform a task switch; loop
>>> index and loop limit registers in this case. We solved this with
>>> opcodes in hex and comma, but this is not what a standard should
>>> call for. So in addition to have SP@ RP@ SP! RP! I would recommend
>>> to have something like
>>> save-all-internal-task-switch-critical-registers-to-stack and to
>>> fetch them back.
>>
>> Oops far too much. Instead of manipulating stack do it yourself
>> multitasking thse two words:
>>
>> (xt, iid)  INSTALL-INTERRUPT
>> Install xt to be executed on the implementation defined
>> interrupt iid.
>>
>> IRET return from interrupt: obligatory end of an xt such as
>> installable by INSTALL-INTERRUPT
>
>Still far too much, as it assumes a concept of how multitasking and
>interrupts work that is unspecified, and we are very far from being able
>to specify such a thing. You may be able to do some kind of multitasking
>in high level, but (as noted) not without "carnal knowledge". Just don't
>try to go there. It'll cause nothing but wrangling, misunderstandings,
>and trouble. Keep it simple.

Isn't this what a standard is supposed to do? Letting the implementors fill
in the blanks using carnal knowledge?

Executing a procedure on an interrupt is pretty standard.
Making sure that the right registers are saved and restored
is something that the implementor should take off the hands
of the application programmer. (Matthias had a similar idea
with a word to save all volatile registers.)

An implementor could provide some iid's:
1: a character has arrived at the serial port, which has some
default setting.
2. The serial port is free to send to
3. A  millisecond interrupt.
4.: data is available on the adc port

Please note that the Linux system has a system call to install traps, which
just works. E.g. it allows me to have a loadable extension to ciforth to
interrupt an infinite loop using ^C.

>
>> And I would scrap UM*
>
>As a requirement, maybe, although I think it's very useful.

It is useful, but I can't see how to use it in the absence of
any words that could  handle the result, even print it.
(OTOH */MOD even if using an intermediate double result is quite
useful in its own right.)

>
>> With BEGIN WHILE I missed REPEAT.
>
>Yep, need REPEAT.
>
>Cheers,
>Elizabeth


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]

#35915

> (xt, iid)  INSTALL-INTERRUPT
> Install xt to be executed on the implementation defined
> interrupt iid.
> 
> IRET return from interrupt: obligatory end of an xt such as
> installable by INSTALL-INTERRUPT

I use interrupt vectors with trampolines; interrupt vector tables must/may (in some chips it is relocatable) be in Flash, so having trampolines is a must to make them changeable on-the-fly. You can install an ordinary ( -- ) Forth definition as interrupt with:

' forth-handler irq-systick !

For interrupts, I would propose to have EINT and DINT available.

Matthias

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

#35906

Matthias Koch wrote:

>> I'd rather like to have SP@ RP@ SP! RP!, because it allows building these
>> and the multitasker if you need them.  Small systems on embedded
>> controllers don't often need that much of exception management, but if
>> you want it, you need some building blocks to make it.
> 
> While Bernd implemented Multitasking and Catch/Throw for Mecrisp-Stellaris
> we found that we need a way to save internal, implementation specific
> registers to perform a task switch; loop index and loop limit registers in
> this case. We solved this with opcodes in hex and comma, but this is not
> what a standard should call for.

Before I did that, I solved that with 1 0 DO <now the loop index are saved>
LOOP <now they are restored>.  It's not as nice as the implementation-
specific way, but it's doable.

> So in addition to have SP@ RP@ SP! RP! I
> would recommend to have something like
> save-all-internal-task-switch-critical-registers-to-stack and to fetch
> them back.

Maybe.

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

#35923

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> So in addition to have SP@ RP@ SP! RP!

I cringe at the idea of standarizing words like SP@ which seem like
low-level implementation details.  Better to standard an optional
multitasking word list, that's designed for simple implementation using
primitives like SP@ but could be done other ways depending on the
underlying firmware and hardware.  For example, an FPGA implementation
might want to use hardware address translation to have an isolated stack
per task, instead of a single chunk of memory containing multiple
stacks.

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

#35924

Hear hear.

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

#35925

Paul Rubin wrote:

> Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
>> So in addition to have SP@ RP@ SP! RP!
> 
> I cringe at the idea of standarizing words like SP@ which seem like
> low-level implementation details.  Better to standard an optional
> multitasking word list, that's designed for simple implementation using
> primitives like SP@ but could be done other ways depending on the
> underlying firmware and hardware.  For example, an FPGA implementation
> might want to use hardware address translation to have an isolated stack
> per task, instead of a single chunk of memory containing multiple
> stacks.

Yes, might and possible and blah - straw man arguments at its best.  The 
usual thing with tiny Forth CPUs in hardware is that they aren't fully 
standard, and that's fine.  There's no need to bent over backwards to make 
the standard so weak that they can claim conformance, and there's no need to 
make them as large to be standard, because they do their job without.

I'd rather like to have something that works on 90% of all existing systems, 
but actually works there.  An FPGA Forth CPU might have only two stacks, not 
accessible through memory, and no way to even think about multitasking 
without instantiating more than one core (the b16 is such a thing).

The point with all those very small systems is that *you don't want* 
multitasking or exception handling in general.  And if you want it, you 
might be ok with a single background task in 90% of those cases where you 
actually want multitasking.  And that background task gets called in one or 
two places (usually KEY?), nowhere else.  Things get a lot easier if you 
only solve the problem at hand, but to do so, you need the appropriate 
tools.  Low-level tools.

SP@/RP@/SP!/RP! are these tools, defining a complete multitasking wordset 
that works well from medium to large systems is overkill for the tiny 
systems.

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

#35927

Bernd Paysan <bernd.paysan@gmx.de> writes:
> SP@/RP@/SP!/RP! are these tools, defining a complete multitasking wordset 
> that works well from medium to large systems is overkill for the tiny 
> systems.

Another example where SP@ etc can get in the way, is if you have a
VFX-like host-side compiler that places a lot of the target's stack
items in registers.  So the task switcher would save the registers like
in a conventional OS, and exposing SP@ etc. to the target would make
things messy.  It seems ok to let the switcher use carnal knowledge.

When I mentioned an FPGA processor I wasn't thinking of the tiny
b16-like category, but maybe something more like the J1.

I like the idea of standardized multitasking words, so that programs
that use them can be portable (or at least more portable than they are
now).

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

#35930

Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> SP@/RP@/SP!/RP! are these tools, defining a complete multitasking wordset
>> that works well from medium to large systems is overkill for the tiny
>> systems.
> 
> Another example where SP@ etc can get in the way, is if you have a
> VFX-like host-side compiler that places a lot of the target's stack
> items in registers.

No.  SP@ is just a normalization point.  SP@ works fine in VFX.

: test 1 2 3 + + . ;  ok
see test  
TEST 
( 080BF310    8D6DFC )                LEA       EBP, [EBP+-04]
( 080BF313    895D00 )                MOV       [EBP], EBX
( 080BF316    BB06000000 )            MOV       EBX, 00000006
( 080BF31B    E8803DF9FF )            CALL      080530A0        .
( 080BF320    C3 )                    NEXT,
( 17 bytes, 5 instructions )
 ok

Now we add an SP@ in between:

: test 1 2 3 sp@ >r + + . r> ;  
TEST is redefined  ok
see test  
TEST 
( 080BF340    8D6DF4 )                LEA       EBP, [EBP+-0C]
( 080BF343    C7450002000000 )        MOV       DWord Ptr [EBP], 00000002
( 080BF34A    C7450401000000 )        MOV       DWord Ptr [EBP+04], 00000001
( 080BF351    895D08 )                MOV       [EBP+08], EBX
( 080BF354    BB03000000 )            MOV       EBX, 00000003
( 080BF359    E82EFCF8FF )            CALL      0804EF8C        SP@
( 080BF35E    53 )                    PUSH      EBX
( 080BF35F    8B5D00 )                MOV       EBX, [EBP]
( 080BF362    035D04 )                ADD       EBX, [EBP+04]
( 080BF365    035D08 )                ADD       EBX, [EBP+08]
( 080BF368    8D6D0C )                LEA       EBP, [EBP+0C]
( 080BF36B    E8303DF9FF )            CALL      080530A0        .
( 080BF370    5A )                    POP       EDX
( 080BF371    8D6DFC )                LEA       EBP, [EBP+-04]
( 080BF374    895D00 )                MOV       [EBP], EBX
( 080BF377    8BDA )                  MOV       EBX, EDX
( 080BF379    C3 )                    NEXT,
( 58 bytes, 17 instructions )

Oh, all registers are saved, perfect.  The implementation is completely 
straight-forward: SP@ is marked as word that can't be inlined, and all those 
words are normalization points anyway.  The big difference between a Forth 
compiler and the textbook compilers is that you have this normalization 
points.

> So the task switcher would save the registers like
> in a conventional OS, and exposing SP@ etc. to the target would make
> things messy.  It seems ok to let the switcher use carnal knowledge.

No, we know how to implement SP@, we don't need someone telling us that it 
can't be done.  The problem is solved.

> When I mentioned an FPGA processor I wasn't thinking of the tiny
> b16-like category, but maybe something more like the J1.

The J1 is about as tiny as the b16 (the Verilog is even smaller, because the 
J1 has a less dense instruction encoding), has the same model of separate 
very small memory blocks for the data and return stack, and those pointers 
can't be set by the program (though there's a way to obtain its value, which 
is missing in the b16 - you can do DEPTH on J1, but not on b16; you can't do 
SP! on either).

> I like the idea of standardized multitasking words, so that programs
> that use them can be portable (or at least more portable than they are
> now).

We like that, too, but it is not the right thing for a base-line wordset for 
embedded controllers, which is the topic *here*.

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

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

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

csiph-web