|
From: Tim R. <ti...@su...> - 2004-04-08 23:57:55
|
In message <017b01c41dbd$c16ac180$6688b8d9@R22>
"Andreas Raab" <and...@gm...> wrote:
> > Decoupling GC from Primitives
> > This seems like an all-around win, although not really V4-related.
> > i would love it if someone would take it upon themselves to spec
> > this and estimate difficulty, so we can review it, and then actually
> > do it.
>
> Sounds good. I'm not sure I'll find the time to do it myself but I'll see if
> I can stick it in one lazy afternoon (say, wasn't there an easter weekend
> somewhere? hm...)
allocateChunk:, sufficientSpaceAfterGC: are first targets of course,
then the callers to provide a back out route. I think the VM changes are
quite small.
I've managed to track down the (ancient) code for returning error codes
from prims - from 2.7 days believe it or not. It's mostly Parser changes
but the curent compiler stuff has changed enought that there appears to be
quite a disconnect. Essentially the idea is to add an optional named temp to
each prim calling method with a default (the brilliantly named
'primErrorReturnVariable') if the writer can't be bothered. This temp is
always the first one and so the VM know where to stick the return object.
Image code can use it to find out what happened and obviously one of the main
interests here is to know that a GC is needed.
Since it's such a tiny piece of code I've attached it FYI.
I hope we can get round to this: I've been asking for it for several
years...
>
> > Flat Rectangles
Chief advantage is a reduction in allocation traffic; one object
instead of three etc. You do have to be careful about some inadvertent
semantic changes though; currently
aRect origin x:foo
will actually change the x value of aRect's origin point. A flat
rectangle would almost certainly implement #origin as
^originX@originY
and thus aRect origin x: foo would have a rather different effect.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Strange OpCodes: IOP: Insult OPerator
|