Jonathan S. Shapiro wrote: > Yes. One of the points that I made in my pending draft, and that you also > made, is that tuples can be defined as unboxed. If they are, then we can > adopt a calling convention in which a function taking a single argument of > tuple type will have the tuple elements allocated to registers *as if* we > had performed the corresponding higher arity call in C.
Just to be sure we're on the same page, when you say "allocating to registers" what exactly do you mean? Do you mean pushing values onto the call stack, passing arguments in physical registers, or something else? Passing args in physical registers is nice when possible, but it's a platform-dependent (and type-dependent) optimization so it seems to me like it doesn't belong in the official language spec... When writing my previous posts, I wasn't aware that BitC required making all allocations explicit. That changes things a bit :) As far as explicitly tracking the heap and maintaining compositionality, have you looked into Separation Logic[1], Hoare Type Theory[2], or similar things being developed over in language-based security? I'm not sure how feasible it would be to work these formalisms into the BitC language, but they could be helpful for the compiler's analysis of programs. (FWIW, I would *love* to have a systems language that explicitly tracks allocations in the type system. I've considered developing such a language a number of times, but never got around to doing much in that direction. I'd also love to see time complexity tracked in the type system. I half remember a blog post from a while back where $FAMOUS_HACKER suggested a similar idea, and described how they tried incorporating time complexity tracking into their coding/documenting style; so it may be fruitful for getting the performance geeks to convert.) [1] http://www.cs.cmu.edu/~jcr/seplogic.pdf [2] http://www.cs.indiana.edu/~amal/papers/htthol-techrpt.pdf > And it raises another, unfortunate complication: in order to use tuples as > parameters in this way, we need to be able to form tuples over non-escaping > references, which *may* mean that we need to deal with non-escaping tuples > and non-escaping aggregates in general. This requirement is introduced by > the presence of by-reference parameter passing in BitC. Again, to be on the same page: is there a short paper/webpage on what "references" and "escaping" mean in BitC? Everyone means something different... -- Live well, ~wren _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
