Your post is quite expansive, but I wanted to quickly respond to the bit
about value reuse:
On Thu, Apr 15, 2004 at 04:02:54PM -0400, Judson, Ross wrote:
> In particular, in an interpreter like SISC, we want to avoid continously
> transforming values into and out of Value objects. We want to be able
> to operate on the primitives directly. Looking at the SISC code, I
> wonder about the practice of having primitives return new Value objects
> as their result. SISC does this:
>
> Value result = mult(Value a, Value b)
>
> Would it not be more efficient to do (at least for numerics):
>
> mult(Value result, Value a, Value b)
>
> SISC's use of subclasses for various Value types makes this difficult,
> as a single Value can't hold all possible types. Still, in tight loops,
> a great deal of heap allocation can be avoided by using this style to
> hold intermediate results.
The problem is that you can't reuse values typically. Consider the
following Scheme session:
(define a 3)
(define b 4)
(* a b)
This will result in something like the mult call you mentioned above.
But we can't replace the value of an input Quantity with the result, or
we'd overwrite a or b.
Now, perhaps you are confused about Value. Value isn't a container, its
a superclass. So the number 3 is a Quantity which is a Value subclass.
In particular, no extra storage is consumed by doing the following:
Quantity q=Quantity.valueOf(3);
Value v=q;
In the multiplication case, we do heap allocate a new quantity for the
result of the multiplication, and we have to because of the above
reasons.
And we can't use immediate values for numbers because we can't store
ints and floats in the same cells used by other Scheme values in the
mainloop. This is a consequence of Java lacking any sort of union type.
I'll mull over the rest of your post tonight.
Scott
pgp89bkHbRjRB.pgp
Description: PGP signature
|
