This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
gnu.lists merged into kawa cvs
- To: kawa at sources dot redhat dot com
- Subject: gnu.lists merged into kawa cvs
- From: Per Bothner <per at bothner dot com>
- Date: 09 Mar 2001 00:19:45 -0800
Ok, I've finished checking in the latest batch of Kawa changes.
Remember to use the -d option to update: 'cvs -z 9 update -d'
to get the new directory.
In addition to using the new gnu.lists package, another change is
worth noting: If the expected type of a + or - is a prmitive type such
as <int>, and the operands are compatible, then Kawa will generate
code to use primtive Java arithmetic, for greatly improved speed. For
the "expected type" to be <int>, the operation should be the value to
a set!, let, as, or function call with known argument type. For the
operands to be compatible with <int>, they have to be an integegral
type but it can be <integer> or a primitive type. The logic is that
adding an <int> and an <integer> shoudl yield an <integer> - but if we
know the result will be coerced back to an <int>, we can safely do the
operation usng <int>s. Notice the code generated for list->string in
kawa/lib/strings.class: An 'iadd' instruction is generated for the
'(+ i 1)'. It would not be difficult to generate an 'iinc' instructions.
Notice that we are still doing int->IntNum conversion for the
NumberCompare.$Gr$Eq. That is the main performance problem
compared to writing the code in Java, and this would be easy
enough to fix. Next time I feel the urge ...
I'm more troubled by the code generated for string->list.
I am not sure why it feels the need to allocate a closure;
that needs to be investigated.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/