Hi Todd (et al);
"Todd L. Miller" wrote:
>
> Just realized that it looks like the throws rewrite will require
> function calls of the form
>
> int fn( ..., exception* e )
>
> so you should bear that in mind while moving the stuff in interp about.
OK. I factored out each of the 250 (or so) opcodes into its own method,
with the exception that I did not change the "all invoke opcodes handled
in a single function" scheme, although that should almost certainly be
changed. God, emacs macros are wonderful, powerful things.
All opcodes are now methods on class frame, of the form:
bool frame::opcode(exception_to_throw &);
I made up the exception_to_throw class for a place-holder. If you have
a predefined class I should've used instead (I looked but didn't notice
any obvious candidates), please reply ASAP, and I'll make the global
change before I commit the sources. If not, please feel utterly free to
replace it with whatever you like.
Items of note:
(1) Some poor bastard has got to go and chase around all the PC
referencing and incrementing, and localize it to each opcode method
(like we discussed, to enable "backing out" of not (yet) executable
opcodes, the opcode must not increment the PC unless it worked, and the
runOpcode demultiplexer must NOT increment the PC). Although a
separable task, this is coupled to doing the exception handling. Please
advise as to how I should or should not proceed.
(2) I think the various invoke opcodes arguably should each have its own
method, and the "common" functionality they need should become new
(protected? private?) methods. I have this opinion because I think it
might help readability/maintainability, and it would also certainly help
efficiency (we probably don't want the execution engine to "forget"
which invoke opcode it's executing, and have to go back and look it up
repeatedly, and then set control flags for how many things are on the
stack, yadda yadda yadda...). Please advise as to how I should or
should not proceed.
(3) In an attempt to be less, er, cavalier about whether the committed
sources actually RUN on the i386 target (Hi, Thomas!), I actually BUILT
the sources and ran them successfully on the i386 target. If you wish
me to do anything about items (1) & (2), I promise (cross my heart,
etc.) to verify that any changes I make actually run on the i386 target.
(4) Please let me know if you ran into the same problems that either
Thomas or I did with respect to the i386 target. Thomas, please let me
know if upgrading to Etherboot 4.2 solved your difficulties as it did
mine.
(5) I am actually taking the week off from the Day Job, so if there is
any power-tooling to be done, now is a really, Really, REALLY good
time. Please advise.
-jm
--
==== John Morrison
==== MaK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/welcome.html
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== [EMAIL PROTECTED]
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
