|
From: Tim R. <ti...@su...> - 2004-04-09 01:02:54
|
In message <p05210605bc99dfc4d28a@[192.168.1.100]>
Dan Ingalls <Da...@Sq...> wrote:
> First of these is the split primitive field of method headers. I think there's good agreement on returning to a 9-bit field and doing away with (or converting to named access) all those that were using higher indices. I have a specific proposal which I will document soon on the web site, but it is essentially what Tim suggested, except I would drop of the loadInstVar range so we leave room for 50 or so unused inedexed primitives at the top. My reasoning is that, ugly or not, indexed primitives are the easiest way for curious hackers to experiment with new capabilities in Squeak.
>
> [By the way, it looks like "External primitive support primitives" 570-574 are still in use and would need to be slid down]
Whoops, forgot about them for a moment. Still, this shouldn't be a
problem since there appears to be 110 primitiveObsoleteIndexedPrimitive
in the primitiveTable as well as 50 primitiveFail (some of which are
needed I guess).
> CompiledMethods
> A major question to decide is whether to split up bytecodes and literals (and source pointer) as in Tim's NewCompiledMethod work. This adds a little space overhead, but it certainly makes things simpler. I'm going to assume that we go with Tim's 2-object format, and throw in a "serendipity" field for fun this summer.
IIRC the difference is:-
header
bytecodes
literals
other ivars
or
header
bytecodes
other ivars
indexed literals
The difference is that to allow adding ivars in subclasses the second
option means the VM has to check the number of fixed fields so it can
find the literals correctly. So it's an extra object or an extra size
check on every send (well one could cache it in some limited
implementations but you lose subclassability). I'd go for the extra
object, personally.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Bug? That's not a bug, that's a feature. -T. John Wendel
|