Matthias Trute <mtr...@web.de> writes:
>> I hope that you would be interested in the following AmForth
>> development. I will send you the patch under a separate cover.
>
> I am interested. And regardless what you think of what
> follows, I appreciate your work.
>
>> http://pastebin.com/sDGsKjhb
Hello Matthias,
I can assure you that I am "ego-less" as far as AmForth is concerned. I
invite criticism, in fact, being ignored would be more painful.
> A few remarks: Your patch include some pseudo changes to
> files that are not really changed (e.g. amforth-interpreter
> with some whitespace changes). I was slightly puzzeled wether
> I mis-read the patch until I was sure, that the changes are
> purely cosmetic. changing the r0 to temp0 is something very
> close.
My editor (Emacs) apologizes. It does not like your asm code
indentation. Which one do you use, BTW.
> Second: Your patch steps behind what amforth has already
> solved years ago: If an interrupt source has to be cleared
> *within* the ISR, it will block the controller with your new code
In my soft interrupts handling scheme I am interested in Atmel's type I
interrupts only. They are described by Atmel as follows:
"""
There are basically two types of interrupts. The first type is
triggered by an event that sets the interrupt flag. For these
interrupts, the Program Counter is vectored to the actual Interrupt
Vector in order to execute the interrupt handling routine, and *hardware
clears the corresponding interrupt flag*.
"""
The other type, like the USART, does need special asm code. Your serial
driver is a case in point.
> I once spent a lot of time to deal with the reasons. I wrote
> a small article for the German Forth Group, unfortunatly (for you)
> in German. It seems, I should translate it into (my version of) English
> ASAP. There I explain the current interrupt handling in more detail.
Google Translate does magic, please forward a link.
> Basically your patch is the old interrupt handling plus queue (A solution
> I once considered too, btw.)
What I implemented is called SLIH (second level interrupt handling). It
exists in all operating systems. I don't consider myself an inventor at
all here.
> Third: What makes you sure that a queue with 8 entries
> can do the job? The code comments indicate, that you're
> not that sure yourself. The default action "Drop the interrupt"
> is IMHO the worst solution.
Note that there is an overflow mark. If the developer encounters hard
interrupts overflow he should increase this queue size (or check up his
code). This can be done through some asm .equ convenience.
> And finally: What exactly is the use case of having a reentrant
> interrupt service routine? In my understanding of interrupts, this
> is a situation, that must be avoided at any price. e.g. it does not
> make much sense to process a character from the usart if the
> previous one is not already processed. Or to stack timer events.
This is what Wikipedia says about the purpose of SLIH:
"""
A SLIH completes long interrupt processing tasks similarly to a
process. SLIHs either have a dedicated kernel thread for each handler,
or are executed by a pool of kernel worker threads. These threads sit on
a run queue in the operating system until processor time is available
for them to perform processing for the interrupt. SLIHs may have a
long-lived execution time, and thus are typically scheduled similarly to
threads and processes.
"""
FLIH (first level interrupt handlers) and SLIH (second level interrupt
handlers) were already introduced in the old IBM mainframe days.
> Re-enabling interrupts within the current ISR is no big deal. Just
> call +INT and you're done. New interrupts will arrive as they they
> are triggered.
Did you really try it, i.e., reenabling interrupts within an ISR? You
do it and your 'intcur' gets crushed.
After receipt of a data buffer from a certain communication euipment I
want to lanuch immediately a processing activity, i.e., right from the
ISR and not wait for a round robin task to visit.
By the way, it's okay to have different opinions. We already read our
stacks (".s") in different order :-)
>> P/S It includes some unrelated (though desired) stuff such as cinvert to
>> complement a byte, etc.
> There are many word that can be implemented in assembly as well.
> A theoretical use case doesn't convince me. A cinvert could be a
> factor for invert ;)
cinvert is indeed not important by Rafael's u2/ is!
Regards, Enoch.
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
