Ken Fox <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> +-----+----------------------+ >> | ctp | interpreter state | >> +-----+----------------------+ >> | >> +------------+ >> | >> +------+-----+-----------+----------------------+ >> | prev | ctx | lexicals | volatiles | >> +------+-----+-----------+----------------------+ >> | p a r r o t r e g i s t e r s |
> A very strong architecture for sure. > > + no lexical fetch overhead > That alone is worth the price of admission. No register allocator > needed because the HLL only needs volatiles for anonymous temporaries > which are easily allocated during expression parsing. Yep, I mentioned that. > I would make a couple changes: [ ... ] I'm not gonna touch calling conventions. Actually by swapping the two register ranges above it's fully compatible. > +-----+----------------------+ > | ctp | interpreter state | > +-----+----------------------+ > | > +--------------+------+-----+-----------+----------------------+ > | caller's out | prev | ctx | lexicals | volatiles | > +--------------+------+-----+-----------+----------------------+ > Merge with the variable sized stack frame proposal and expose > prev+ctx as registers. prev is the current (return) continuation, which is unvisible except for the returncc opcode. Exposing it means a visible full continuation with all the drawbacks. ctx has some stack top pointers e.g. for the control stack and other stuff. So C<push ctx_ctrl, eh> would push an exception handler. Other members are flags e.g. warnings on/off. This would be very similar to a hardware CPUs control registers: C<bor ctx_warn, .WARNING_UNDEF>. > Sorry for the de-lurk. I'd be glad to have you here. > - Ken leo
