Re: [Squeak-VMdev] DING! End of Round One

[Andreas R. <and...@gm...>]

Hi Ian,

[Compact classes]
> If minimising (Context) membership test time by keeping
> CCs around is our prime goal, then I'm entirely against
> it.  It would make certain classes "privileged", in that
> you can *never* make them non-compact without breaking
> your VM.  Otherwise it means the VM can never use CC
> fields exclusively to check for membership (it would
> still have to load the class generically and test
> pointer eqv).  This kind of defeats the argument for
> keeping CCs around -- entirely.

Agreed. Let's kill them if we don't worry about the space savings then.

> I actually think it would make for the fastest possible execution
> if compact classes just went away leaving all class pointers
> explicit in the method header.  No bit fields to extract.
> No privileged CC indices to "secretly know about".  No
> branch-over-check-for-CC-index that might be zero requiring
> a punt to class header load and compare.  Instead:
> just one simple, consitent, linear thing.

Hm... this would actually be a strong argument against introducing more
immediates. They would have similar properties wouldn't they?

[Forms]
> Something is itching me about making Forms 64-bits deep while
> retaining 31-bit integers. I can't really put my finger on it,
> but the phrase "LargeInteger explosion" is floating around my
> head for some reason...

Not "64 bits deep" but "64 bits aligned". The form bits still contain 32bit
integers (otherwise we'd pay horrible prices in 32bit BitBlt versions).

[Anthony's closure work]
> Is this a modified St-80 Compiler, or one based on SmaCC?

SmaCC.

Cheers,
  - Andreas