Just a couple of quick points here. I'll write a more detailled response to Shap in a while.
On Fri, Aug 13, 2010 at 10:07 PM, Alex Burr <[email protected]> wrote: > c) conversions between the underlying atomic types, such as signed to unsigned > etc. IMO, this would be covered if bitc allows the intrinsics to be > overloaded, > so you > are allowed to define overloaded versions which do the conversion for you. > then > you don't need > to keep two pointers to the same data with different types. (It is not obvious > from my skimming how > much overloading by type bitc allows?) There's some interaction between overloading and type inference (which can clearly be avoided by requiring enough explicit type annotation to avoid type inference.) > Both c) and d) lead me to the conclusion that you want to reduce aliassing > where > possible by keeping only one pointer to > a given piece of data, and doing any conversions on values rather than > pointers. > > On the whole, I think that if you have a function taking two pointer > arguments, > you don't want the compiler to assume > that they can be aliased, at least by default. That removes lots of > optimisations it could otherwise do. However, maybe > > this is the opposite to what you want in a systems programming language, where > you value predictability over > > speed. (If that is the case, maybe my previous paragraph is wrong). It's more the case where you've written a "routine" which is designed to work with arrays you expect to be distinct: it's not the usual thought process in current languages that, unless there's a big warning in the documentation like C's memcpy, that you can't call this with identical arguments. (That's partly what C's type based aliasing is codifying.) The motivating concern, and I agree with it, is that you can have source code which, as written, looks like a correct algorithm but if the compiler assumes arguments can't be identical then to "detect/debug" the problem you have to mentally figure out what the compiler may have done. In C there's the restrict attribute that you can use to make this declaration explicitly. My problem arises purely from the decision that int* and SIMD_Vector<int>* (or array if C had those) are decided to be just as different types as two differently declared structs, whereas in writing algorithms they're different views of the same data you might take a different times. (More a case of not appreciating the full interaction between 2 different features.) Regards, David Steven Tweed _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
