Re: Shared Generic Instance Code

[dewar@merv.cs.nyu.edu (Robert Dewar)]

<<Could you be a bit more specific about what you mean by "cheating
on operations like Unchecked_Conversion"?  In what sense did RR "cheat"?>>

Please note that the "cheat" here is in quotations for a very good reason,
and it was probably wrong of me to use such a loaded word even in quotes.

What RR does is to simply convert everything to the longest floating-point
type, and the generic bodies semantics are entirely determined by the
resulting longest floating-point semantics.

Mostly that's fine, since the RM allows extra precision to be used at
any time, and a compiler is free to do all caculations in longest form
floating-point, as long as it does not let things go out of range (in
Ada 95, since the predefined floating-point types are unconstrained,
even that is allowed if you are using these predefined types).

But there are cases where you can definitely tell that something funny
is going on, and one is unchecked conversion. If you do an unchecked
conversion within the generic body of a formal type T whose actual is
32-bit floating-point, you will see an image of the 64-bit conversion
of the number. That's "wrong", although RR argued that the semantics
of unchecked conversion are not well enough defined to say that this
is wrong. I mildly disagree, but the important thing is that the ACVC
tests do not test this case, so the RR implementation is valid in the
sense that it can be validated. I don't think we ever really clearly
resolved the issue of whether it is conforming. It's a marginal issue
certainly.

More significant in practical terms is the cost of going to this
"widest type" approach. In the case of integer arithmetic for example,
this may mean that a simple integer division becomes a call to the
expensive runtime 64-bit software division routine, even though all
types are in fact a generic formal which in an instance is normal
32-bit integer which could be handled efficiently. The macro aproach
will of course do the efficient thing in this case.

If you follow the idea of sometimes-share, then if you have a single
generic formal of type range <> a reasonable approach would be to
have N separate versions of the body, one for each integer base type
in the implementation. There are three problems with this approach:

  1. It introduces a lot of complexity into the compiler, linker etc.

  2. It does not scale well. What if there are ten integer formals
     and 5 base types. We certainoly can't generate 5**10 versions
     of the body, so we have to gt into the even greater complexity
     of delaying the decisions on what bodies to generate -- by no
     means impossible -- the DEC compiler does this, at least to some
     degree.

  3. The DEC patent may intefere (I offer no opinion on whether this
     patent is valid or not, but note that the mere existence of even
     an invalid patent is problematic).

There are lots of subtleties in the sometimes share case. For example,
suppose you have a generic with a formal of (<>) and the generic uses
'Image. It is highly likely that Wide_Character has to be handlede
very specially, since I canno imagine an implementation that actually
materializes the image table for wide character. In the all sharing
case you have to thunk the image function (as well as lots of other
similar things).

Note that this tunking is really complicated by the fact that you cannot
tell what might need thunking by looking at the generic spec. This means
tha the only simple approach is to thunk everything (in the RR case,
they could have thunk'ed unchecked conversoin -- the reason they did
not is that they did not want to pay the efficiency price).;