> 1. The code would be cleaner, shorter and more flexible if you used an
> ASSERT macro. For example, I saw a couple of places with this kind of thing:
You're right, and I'm amazed I didn't realize this on my
own. Thanks.
> 2. There seem to be quite a few places where exceptions should be thrown
> (illegal monitor state, out of memory etc) but aren't. I'd be interested in
> trying to help out in this area when the interpreter's up and running.
Unfortunately, C++ exceptions aren't supported on the i386 build
yet, so I never gave much thought to them. They are, clearly, the Right
Way to do things*. I'll be looking into some static-link fu for
dynamic_cast<>(), so maybe I'll look into exceptions at the same time.**
I don't think, basically, that I should spend time kludging something up
that wouldn't work as well anyway.
Anyway, I hope you get more time to look at the code; your
comments will be valuable.
-_Quinn
* outline:
decaf_main () {
try { /* everything before the call that starts the intreperter */ }
catch ( Exception e ) {
/* Try to do something intelligent, e.g. a garbage collection
and try again; if still no good, abort. */
}
scheduler->start();
}
Frame::interpret() {
try { /* switching on the bytecode */ }
catch ( Exception e ) {
/* throw e into Java. (Unless we want try and
do something intelligent first. Exceptions are JavaObject
subclasses, so this shouldn't be too hard;
return to scheduler after exception-handling frame
is on the thread's stack, to be run on the next
iteration. */
}
}
**: dynamic_cast<>() should be entirely user-space. Messing about with
the frame stack, etc, may not be, which means it wouldn't work.
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
