On 27 February 2015 at 19:17, Jonathan S. Shapiro <[email protected]> wrote:
> On Fri, Feb 27, 2015 at 1:58 AM, Keean Schupke <[email protected]> wrote: > >> I see your point, however do we ever require arities to match exactly? >> You can always supply more arguments to a curried functions (up to the >> max-arity) without allocation, so we only need a "minimum arity" for any >> function. We already know the 'maximum arity' as this is the fully-curried >> arity which is implicit in the type already. >> > > From a type system perspective I agree that you can supply as many > arguments as the function type supports. The problem is that you can't pass > two arguments in the same register. > > Imagine that we have an arity-concrete function f having type > > fn 2 'a 'b -> fn 2 'c -> 'e > > > Assume for simplicity that 'e will not unify to a function type, so we > don't have to consider the possibility of more formal argument positions > materializing. > > So now we have an application, say: > > f 1 2 3 > > > and you imply, correctly, that we can gather those arguments into some > kind of holding structure without doing any heap allocation or building any > closures. > > Except that f expects to get its first argument - in this case 1 - in a > particular register (say %eax) as part of the calling convention. > Meanwhile, the procedure returned by f *also* expects to get it's first > argument - in this case 3 - in a particular register (also %eax). An **in > general** we can't rewrite f or the function that it returns. > > So no, there's really no benefit to trying to stage that additional > argument **in general** until we are ready to call the procedure that > accepts it. We'll just end up moving it back and forth to memory > unnecessarily if we try to do that. > > > Now: if you are trying to say that this might be fine **as an > optimization** when we are able to statically resolve f and rewrite it, > then I agree completely. It may even be an important optimization, > especially in the case where f returns a closure, and rewriting f would > eliminate the need for the closure formation. Whether we eliminate a > closure or not, it's also important to know that we can do this rewrite in > order to support inlining. > > So: it's great as an optimization under the right conditions, but that's > not the topic of this thread. > Registerisation is an optimisation, at the language level we should assume there are infinite slots for arguments, which get passed on the stack. Putting arguments into registers should be an optimisation pass. This is what 'C' does and its plenty fast enough... Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
