Re: [Amforth] Useful?

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

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

> Matthias Trute <mt...@we...> writes:
>
> Hello Matthias,
>
>> Hi Enoch,
>>
>>>> Enochs code is a macro, assembling one single instruction SBI into
>>>> dictionary and naming it.
>>>> Calling that word will execute the SBI instruction.
>>>>
>>>> Michael
>>> 
>>> I confirm, the code works.
>>
>> Well. I think its definitly worth some documentation. It is
>> not obvious how to use it.
>
> Easy:
>
> Suppose we have a relay connected to PORTA.0
>
> PORTA 0 port:hi! relay_on
> PORTA 0 port:lo! relay_off
>
> We can do the same of-course via bitnames.frt but the above is
> accomplished through a single instruction.
>
> BTW, bitnames.frt, IMO, needs to be simplifed in two respects:
> 1. It is extremely rare for a port to be of bidirectional use.
> 2. Port address can be limited to 0..255.
>
> My own version follows:
>
> ----------------------------------------------------------------------
>
> \ define a port: 0 ≤ portadr ≤ $FF, 0 ≤ bitno ≤ 7.
> : port: create  ( portadr bitno -- )
>     1 swap lshift			\ make it a bitmask
>     >< or ,				\ mask at high byte
>   does>  ( -- portmask portadr )	
>     @i dup >< $ff and swap $ff and
> ;
>
> : hi?  ( portmask portadr -- f )
>     c@ and 0>
> ;
>
> : lo?  ( portmask portadr -- f )
>     c@ and 0=
> ;
>
> synonym port@ hi?
>
> : hi!  ( portmask portadr -- )
>     dup >r c@ or r> c!
> ;
>
> : lo!  ( portmask portadr -- )
>     dup >r c@ swap invert and r> c!
> ;
>
> : port!  ( portmask portadr f -- )
>     if hi! else lo! then
> ;
>
> : toggle  ( portmask portadr -- )
>     over over lo? port!
> ;
>
> \ PORTx.y is output
> : out!  ( portmask portadr -- )
>     1- hi!
> ;
>
> \ PINx.y is input
> : in!  ( portmask portadr -- )
>     1+ lo!
> ;
>
> ----------------------------------------------------------------------
>
>>> I suggest that these simple macros would become standard library
>>> offerings.
>>
>> I'll think about it. see above ;)
>>
>>>  Without these atomic bit set/clear one needs to wrap code by
>>> -int/+int if register bits are shared by different interrupt
>>> routines.
>>
>> Any given and active forth ISR is never interrupted itself by
>> another interrupt. The communication between ISR and the
>> main program is close but different (IMHO).
>
> That's no good. Interrupt routines MUST BE interruptible or otherwise
> they would introduce unacceptable latency. For example, suppose we are
> doing some signal processing and we need to take A/D samples at regular
> intervals... By the way, let the programmer worry about avoiding re-entrancy.

Sorry, correction: Re-enabling the interrupt system inside the interrupt
routine is the programmer's responsibility (after clearing the
appropriate interrupt flag, of-course).

Thanks, Enoch.

> The docs gave me the impression that this is the case... i.e., until the
> T flag is set the interrupt system is off but later we invoke the
> interrupt service word just as usual... 
> I'll have to visit your asm code :-(
>
> If the above is corrected the importance of those atomic
> (uninterruptible) SBI/CBI instructions becomes clear.
>
> Thanks, Enoch.
>
>> Matthias
>>
>>
>> ------------------------------------------------------------------------------
>> 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/
>
>
> ------------------------------------------------------------------------------
> 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