This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

gnu.lists merged into kawa cvs


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]