[BC][VI4] Forked Squeak version

Tim Rowledge tim at sumeru.stanford.edu
Wed Jun 12 00:57:51 UTC 2002


Anthony Hannan <ajh18 at cornell.edu> is claimed by the authorities to have written:

> 
> 	First, let's make BC and VI4 the same thing.  Before, BC was a component
> of VI4, but now I will include other VI4 enhancements when building the
> BC version, and will drop the use of the term "BC" and now call it
> "VI4".
Sounds ok to me; it does after all already include the two main
candidates for the VI format change (closures and corrected compiled
method format) so let's try to get the other aspects moving. It's way
past time.

On my list to tackle are:-
 + cleaning up the split primitive number fields in the method header (in
 fact since we have named primitives sorted out these days, maybe we
 should drop the nonsense of trying to allow thousands of numbered ones.
 I suspect the freed up bits can be found useful labour pretty quickly)
 + remove the obsoleteIndexed/Named prim redirection tables since they
 are now uneeded.
 + move any named prims not yet in a plugin into a plugin
 + drop some old dead primitives
 + clean out the special object array - some residents are surely dead
 + see if we can find some more bits for hash values
 + oh, I don't know, loads more I'm sure.

Other people have in the past asked for bits in object headers to signal
persistence, immovability, immutability, inscrutability, incontinence,
in a database, in a bun, inadmissable, and probably other things. Maybe
we can provide some of them.

Not all the above are strictly image format changing, but may simply be
something worth getting in whilst already breaking backwards
compatability.

Oh, and we'll need to think of a new image version number - '6502' (or
'1969') has been used since the beginning and needs replacing to avoid
the older vms getting upset. How about:-
8086 (yuck)
1972
err...

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Never do at  compile-time what you can put off till run-time




More information about the Squeak-dev mailing list