Anyway, time to unify. The question, then, is what gets kept and what gets
tossed. The return spec says we pass in the number of P, I, S, and N
params we're returning, which is fine,
I don't think we need these counts. If the call is prototyped, the caller knows the type and count of registers. If the function might return a varying amount of return values, depending, what the caller specified in I3, the runtime checks and register setup on both sides take by far more time, then what could be achived IMHO.
When the call is unprototyped the count of P-Regs is enough.
We can toss some of the inbound stuff and make them optional properties on
the return continuation,
I1 for call conventions is redundant, the overflow array P3 has the count.
... which is where the return signature should live as well (with the same property name as a sub or method's PMC signature)
Prototyped returns with a signature as property seems too heavy to me.
But first I'd like to have some clarification. E.g. "compile-time prototype" vs unprototyped. Where and how do we have these prototypes? What happens if a library sub is called either prototyped or not e.g. from 2 different languages?
Currently we are already spending about 1/3 of the fib[1] Benchmark in register setup for calling conventions. This doesn't take much time for JIT, but all other run cores have a severe runtime penalty. We should really try to reduce the needed register setup to a bare minimum.
[1] examples/benchmarks/fib.*
Dan
leo
