From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,37680a99b5e22b2b X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Shared Generic Instance Code Date: 1997/04/04 Message-ID: #1/1 X-Deja-AN: 230675436 References: <5hrkhkINN9ip@snoopy.cis.ohio-state.edu> <1997Apr1.201631.28634@ocsystems.com> <5i23k6$hkq@mulga.cs.mu.OZ.AU> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-04T00:00:00+00:00 List-Id: <> 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).;