amforth-devel

[Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Hello Matthias and all,

"-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
why is this "int_restore" header commented out, i.e., not available to
the high level?

Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
Interrupt Flag) but this is not the case...

May I suggest:

+int → SEI
-int → CLI
int_suspend → ( -- SREG ) CLI
int_restore → ( SREG -- )

Thanks, Enoch.

Re: [Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Enoch <ix...@ho...> writes:

> Hello Matthias and all,
>
> "-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
> why is this "int_restore" header commented out, i.e., not available to
> the high level?
>
> Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
> Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
> Interrupt Flag) but this is not the case...
>
> May I suggest:
>
> +int → SEI
> -int → CLI
> int_suspend → ( -- SREG ) CLI
> int_restore → ( SREG -- )
>
> Thanks, Enoch.
>

Here's my svn diff vis-a-vis r1366 for your consideration:

http://pastebin.com/0dhM599q

Thanks, Enoch.

>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] int_restore, etc.

[Matthias T. <mt...@we...>]

Hi,

> "-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
> why is this "int_restore" header commented out, i.e., not available to
> the high level?

uhm. yes. These words are one of very first ones, that fell out of
scope later on.


> Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
> Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
> Interrupt Flag) but this is not the case...
> 
> May I suggest:
> 
> +int → SEI
> -int → CLI

Thats fine.
> int_suspend → ( -- SREG ) CLI
> int_restore → ( SREG -- )

These words are not really needed.

\ get the I flag as a forth flag
: int? SREG c@ SREG_I and 0> ;

\ to be used in pairs within the same colon definition
\ can be nested
: critical[
    int? r> swap >r >r \ keep the current state
    -int \ turn interrupts off
    drop \ currently the content of SREG.
;

: ]critical
    r> r> if +int then >r \ will crash if not matched
;

\ test case. foo prints bar-1 baz0 qux-1

: bar ." bar" int? . ;
: baz ." baz" int? . ;
: qux ." qux" int? . ;

: foo
  bar
  critical[
    \ nothing will disturb us here
    baz
  ]critical \ now interrupts or other things may happen again
  qux ;

Re: [Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi,
>
>> "-int" (int-off.asm) counterpart is "int_restore" (int-restore.asm). So,
>> why is this "int_restore" header commented out, i.e., not available to
>> the high level?
>
> uhm. yes. These words are one of very first ones, that fell out of
> scope later on.
>
>
>> Candidly, as "+int" (int-on.asm) is a simple SEI instruction (Set Global
>> Interrupt Flag) one would expect "-int" to be a simple CLI (Clear Global
>> Interrupt Flag) but this is not the case...
>> 
>> May I suggest:
>> 
>> +int → SEI
>> -int → CLI
>
> Thats fine.
>> int_suspend → ( -- SREG ) CLI
>> int_restore → ( SREG -- )
>
> These words are not really needed.
>
> \ get the I flag as a forth flag
> : int? SREG c@ SREG_I and 0> ;
>
> \ to be used in pairs within the same colon definition
> \ can be nested
> : critical[
>     int? r> swap >r >r \ keep the current state
>     -int \ turn interrupts off
>     drop \ currently the content of SREG.
> ;
>
> : ]critical
>     r> r> if +int then >r \ will crash if not matched
> ;
>
> \ test case. foo prints bar-1 baz0 qux-1
>
> : bar ." bar" int? . ;
> : baz ." baz" int? . ;
> : qux ." qux" int? . ;
>
> : foo
>   bar
>   critical[
>     \ nothing will disturb us here
>     baz
>   ]critical \ now interrupts or other things may happen again
>   qux ;

I like these "critical[" "]critical" words, much better than int_suspend
and int_restore, but I prefer their current asm code implementation
since one would like to keep the criticial code execution to the
minimum.

Thanks, Enoch.





















>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] int_restore, etc.

[Matthias T. <mt...@we...>]

Hi,

> I like these "critical[" "]critical" words, much better than int_suspend
> and int_restore, but I prefer their current asm code implementation
> since one would like to keep the criticial code execution to the
> minimum.

A critical section frame is not particular speed sensitve.
It simply turns off interrupts temporarily. A small
forth implementation that one can understand is
far more valuable.

Code _within_ that critical section should be as small
and fast as possible indeed. But again: maintainable
forth code is of higher value than some cryptic assembler
magic.. IMHO.

Matthias

Re: [Amforth] int_restore, etc.

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi,
>
>> I like these "critical[" "]critical" words, much better than int_suspend
>> and int_restore, but I prefer their current asm code implementation
>> since one would like to keep the criticial code execution to the
>> minimum.
>
> A critical section frame is not particular speed sensitve.
> It simply turns off interrupts temporarily. A small
> forth implementation that one can understand is
> far more valuable.
>
> Code _within_ that critical section should be as small
> and fast as possible indeed. But again: maintainable
> forth code is of higher value than some cryptic assembler
> magic.. IMHO.
>
> Matthias

What matters is to keep the critical code section, where global
interrupts are turned off, as short as possible. If asm code would allow
the critical section be even 1µS shorter the asm code should stay :-)

I agree with your general philosophy of minimizing the number of low
level (asm) routines. For example, I recently took note of bm-set.asm,
bm-clr.asm and bm-toggle.asm... they don't follow this principle...

Regards, Enoch.


>
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/