Hi Jecel,
on Tue, 09 Oct 2007 03:40:28 +0200, you wrote: [ :many | many, interesting things ]
... With agressive inlining, however, highly optimized methods will need to access more registers.
I've thought over this for [howmany?] years now, time again. It is perhaps possible to introduce inlineable blocks which don't need much more register space. Access to outer scope could be done similiar to what the B5xxx did with her display registers. And it is well known that that lad runs perfectly with just 4 display registers (and only very large sisters of her had surplus, $$ expensive display registers). The concept at work here is D[ll] with ll=the current scope level (in our case the inlined material's data). D[ll] points to D[ll-1], etc, (in our case to whom it was inlined), from which data registers can be loaded. What do you think?
Since the prefix instructions were only defined for immediate operands, their use with non immediate instructions has been defined to extend the destination and source fields. This allows up to 256 extra local registers to be used.
Yeah, that's an alternative.
The prolog and epilog code for such methods will not be trivial as they will have to deal with allocating a continuous chunk of physical registers among the various threaded lists of frames. But this shouldn't be a problem as such methods will execute for quite a while (or they wouldn't have been compiled with so much inling in the first place) making this overhead worth it.
And this is what I have today and am starting to implement. It is a bit more complex than I would like, but I feel the extra features are important for it to do well interpreting bytecodes, running highly factored native code and running deeply inlined native code.
Good luck!
Cheers Klaus
-- Jecel _______________________________________________ Hardware mailing list Hardware@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/hardware