On Jun 19, 2010, at 6:39 AM, Jules wrote:
I know nothing about the JVM, but I do know that on x86 you can handle
fixnum -> bignum promotion fairly cheaply. You compile two versions of
the code: one for bignums and one for fixnums. After an arithmetic
instruction in the fixnum code you check if it overflowed, and if it
did you switch to the bignum code.
while(n < 10) {
n = n + 1;
}
=>
while(n #< 10) {
a = n #+ 1;
if(overflow){ n = ToBignum(n); goto foo; }
n = a;
}
while(n.lessthan(10)) {
foo:
n = n.add(1);
}
where #< and #+ are the fixnum versions of < and +, and lessthan and
add are the bignum versions. Yeah it's slower than ignoring the
overflow, but faster than tagged 31-bit fixnums and a whole lot faster
than bignums. Can you convince the JVM to produce similar code?
You can do things like that in a closed world of a few operators and
types (although it gets unwieldy as the number of variables goes up).
And of course, inside the math ops Clojure already does things like
that.
But that is not what we are dealing with here. This is an open system,
where representational issues of functions, arguments and returns come
into play. The 'operators' +, - etc are actually function calls - they
are not special to the compiler. And your loop may also contain other
function calls:
while(n < 10) {
foo(n)
n = n + 1;
}
how do I know foo can handle the bigint once I've upgraded?
How about this?
while(n < 10) {
n = foo(n)
}
Unless you have a tagged architecture you can't have boxed/unboxed arg/
return uniformity (and even then you lose some bits of range).
Rich
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
