[bitc-dev] Retrospective: The Issues with Type Classes
bklooste at gmail.com
Wed Apr 18 03:24:19 PDT 2012
On Tue, Apr 17, 2012 at 4:59 AM, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> On Sun, Apr 15, 2012 at 9:35 PM, Bennie Kloosteman <bklooste at gmail.com>
>> >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.
I know whats involved but hard coding 256 combinations is better than
stopping the project if there is no other solution - It will work and
the other common choice of special system types (C, Java ,C#) is
not pretty either ...
More information about the bitc-dev