> 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.
I didn't have a class ready, but exception_to_throw is not one of
the prettier (or shorter) class names I've ever come accross :)
> (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.
If the runOpcode demultiplexer can't increment the PC -- which
makes sense -- another nice emacs macro ought to take care of that bit of
the rewrite (thought it means we'll be weeding out myPC--; ... myPC++;
statements for a while!); as for whether or not to proceed, IIRC, you've
got plenty on your plate right now anyway. I don't know when I'll be
able to resume work on jjos+decaf; probably but not certainly this
weekend, so you're in the clear for big changes.
> (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.
This sounds like a good idea; hopefully it will also eliminate
some of those ugly switch/case statements from the invocation code. It
might be worthwhile and/or necessary to make more than one protected
helper function, especially if the various invoke-common bits are spread
around and/or throw radically different exceptions. Again, you've
probably got quite a bit to handle already, but you'll probably get to
this before I do.
> (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.
No. I tested the second-to-last set of changes I made against the
i386 build (with the full 9.6MB ramdisk) and it worked fine; on the other
hand, the two computers were on a null-ethernet cable, which might have
affected things. (I couldn't get one to find the other when plugged into
the wall network here; I don't know if that's a problem with Etherboot or
the wall network...)
> (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.
AFAIK, the only major thing we must get done before we can
integrate classpath is throws.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
