Re: HASH changes
Jeff Clites wrote: Okay, that makes sense then. So is the current implementation incomplete? I ask because it looks like the mark functionality won't yet quite deal with non-PObj values, etc. The mark_key (and hash, compare) functions can be passed to the extended new_hash_x() creation function. If mark_key is NULL keys aren't marked. Values are only marked if the value entries are PMCs or STRINGs. ...Also, since key and value are now void*'s, there'll be a problem on platforms where sizeof(void *) != sizeof(other types), right? (In particular, doubles will usually be larger than pointers.) No. This isn't finished yet, but another creation param can set the size of the value store (if we ever need that ...) JEff leo
Unifying call and return
Okay, so it's time to get this taken care of. Right now, the only true difference between a sub call and a return, at least at the assembly level, is that we don't pass back a return continuation when we're returning. You can, if you really want, even arguably consider a sub PMC as a frozen semi-stateleless continuation. (Not, mind, that I'd suggest it, as it'll make your brain hurt) Anyway, call and return parameter lists are almost, but not quite, the same. While that's not inherently bad, it seems pretty sub-optimal and means two sets of parameter handling code, one for inbound call parms and one for return parms. Seems silly, especially since they've got close to identical semantics (since return params can be prototyped, as we can return multiple values and may want to know what the assignment list for the return is) 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, except we don't have enough registers for that and the stuff we're passing in in I registers now. We use all 5 when making a call. One overlaps with returns (The number of PMC params) and that leaves us needing three ints. We can toss some of the inbound stuff and make them optional properties on the return continuation, which is where the return signature should live as well (with the same property name as a sub or method's PMC signature) which'd leave us needing two ints. I'm not sure if its worth trimming out things from the registers to make space, or moving the two other counts to N registers. Oh, and we need to make sure the PMC count is in the same register for calls as returns. It isn't now, which is a sloppy oversight and one we'll fix as part of this. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unifying call and return
Dan Sugalski wrote: 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
Re: Unifying call and return
"Dan Sugalski" <[EMAIL PROTECTED]> wrote > Right now, the only true difference between a sub call and a return, at > least at the assembly level, is that we don't pass back a return > continuation when we're returning If one is coding a co-routine/iterator, then perhaps even this difference might go away? Dave.
