On Sun, Apr 15, 2012 at 9:35 PM, Bennie Kloosteman <[email protected]>wrote:
> >Shap wrote > > > > This is not true. It is true that you cannot inline across the dynamic > > library boundary without a JIT system, but that was never my concern. My > > concern was the inability to inline **ground operations** such as integer > > addition. > > > An important distinction . > > But these form a handful of common instructions surely you could > handle this with some nasty hack eg a mini Jit when you load the app > that parses it and replaces calls to xyz... You could do that, or you could simply pre-generate specializations for the likely cases. The problem is that the combinatorics are daunting. In contrast to C, where pre-generating over 'int' would handle most cases, we elected not to do implicit widening and narrowing of integer types. And replacing a procedure call with an add instruction actually isn't a simple exercise. It changes all of the branch spans in the procedure, which requires them to be rewritten. Depending on how constants were stored, it may also change constant offsets. It's certainly not as complex as full JIT, but it's plenty complex. > Isnt not inlining dlls a bigger issue ? eg a dll can have Math. Min > and other common constructs. I do not believe so. Math.Min *really* wants to go in something like a header file - which is part of why we have a distinction in BitC between interface units and implementation units. A distinction, I might add, that personally don't like very much and would prefer to eliminate. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
