[Hardware] RISC42 history (was: Assembly Language)
Klaus D. Witzel
klaus.witzel at cobss.com
Tue Oct 9 12:43:35 UTC 2007
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
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.
> -- Jecel
> Hardware mailing list
> Hardware at lists.squeakfoundation.org
More information about the Hardware