Hi,
[Andrew Valencia <vandys@cisco.com> writes]
> This is exactly the problem the HP 300 port was faced with. I was planning
> on dumping P-code as a part of the interrupt registry. The P-code would be
> just sufficient to query hardware, check/clear bits, and report a boolean
> value back. The kernel interrupt handling would recognize a level which had
> various P-code registries, and would call each registry. When one returned
This is an interesting idea. It certainly avoids a number of messy
issues (some of which Tim mentioned). I remember that the Alliant
real-time user mode interrupt handling code was fairly complicated
in this regard. As an aside, the comment just before the kernel jumped
to the user's interrupt handler went something like "why does this feel
like jumping off a !@#$% bridge".
One question: have you considered using a threaded interpreter as opposed
to a p-code interpreter? Threaded interpreters claim to run very quickly
and to be easy to extend. The extensiblity factor would come in
to play if, in the future, someone needs to do more complicated
processing than testing and setting of bits.
Mike Larson
Received on Fri Nov 11 05:58:00 1994
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:10 PDT