On 2013-03-15, at 18:55, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> On Fri, Mar 15, 2013 at 5:40 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 2013-03-14, at 18:28, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> > However, I have an instruction set that lifts the 256 literal limit to 65535 ;)
> 
> That would be very useful for this case indeed, plus maybe a double-extended jump bytecode. Then the only remaining limit would be the number of temps.
> 
> The jump limit is lifted, also to 64k.  

Nice!

> How big would you want to see temps? It is already 64, which is quite high.

Well, I have one code generation example that used 254 temps, which I had to split over several methods, and spill shared temps over into inst vars.

Although, if the limit had been 256, there would still have been that nagging feeling that every little change might break it ...

This doesn't necessarily need a VM change. The compiler could reserve the 64th temp for an array and compile accesses as at:/at:put:.

That would also avoid having to have another context size. 


- Bert -