DLLCC numeric arg optimization dillema

The Cairo C interface is double happy. This is both good and bad. It's good, because it's the most expressive and easy to coerce up to. DLLCC is good about being able to have an Integer or a Float or a Double passed as an arg to a DLLCC function. It coerces it upwards, and does it in place as it copies it onto the stack (for those with source, you can see where it does this in pdCallC.h).

There's a problem though. Smalltalk programs love to make Fractions. And there is no code there to automatically put Fractions on the stack as it goes. This means that you have to do the coercion work up in the Image by sending asDouble to all of your arguments. But this is terribly inefficient (when compared with just letting the marshaling macros do it in the VM). It's extra message overhead. It means allocating 24 bytes of extra object just to act as a "trampoline" which makes unnecessary object churn.

Interestingly, in looking at it, I think the marshalling is misleading too. A <C: func(double arg)> will happily deal with SmallInteger maxValue. But not SmallInteger maxValue + 1. The only kind of integer it will marshall for you is a Small one. No large ones period. So the VM has some really good code for making my DLLCC invocations efficient. But it's not complete. So I end up not being able to take advantage of it at all. One might argue, that it would be best to do no across-type marshalling, since it can only do it in _some_ of the cases, and pays a price to do so.

Another option... would be to make the double kind be able to take Fractions (and LargeIntegers). To do this, I think you'd have to:

a) have a macro/function in the VM that does something similiar to what Fraction>>asDouble does (kind of interesting that).

b) register Fraction as a "known" class in VM.

c) add the branches in the pushDouble macro to detect and deal with LargeIntegers (dealing with failing when it is out of range)

d) anything else?

I'm curious what others' thoughts are.