On Sat, 2005-01-29 at 21:09 +0100, J�rgen Hermanrud Fjeld wrote: > Since BitC is targeted to be fast, I wondered how you plan to handle > arrays, and the compilation of methods on arrays. > This might be of topic for the purpose of BitC, but it is certainly > important for speed and safety of matrix multiplication or other > operations on arrays. > The work shape analysis for efficient code generation in the research > language FISh [1] does demonstrate very good results in comparison to C, > and has a theoretical foundation. > Have you considered such approaches, and if, what where your > considerations?
This is well outside the class of problems that we are considering. I think that the best response on this topic is to suggest that BitC is not, over the long haul, a frozen thing. If people want to take up other research foci based on what we are doing, that would be wonderful, and we would encourage it as best we can. Much of the problem of fast floating point processing is a matter of highly aggressive optimization. One of the things the we expressly are NOT pursuing in the BitC project is aggressive optimization. The good news is that the BitC framework should lend itself to this if other people want to pursue it. > The O'Caml type system does not regard array size as a statically > checked property, neither does the extensional polymorphism. Experience in the '70s with Pascal strongly suggests that considering array size as part of time is very problematic. In particular, it is a problem when declaring formal parameters on procedures that one would like to have be more generally applicable. Later versions of Pascal introduced various kludgy workarounds. My opinion, for whatever it is worth, is that there are times when the size of a vector *is* part of its type, and times when it is not, and it should be feasible to declare the vector accordingly. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
