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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!ihnp4!ucbvax!grebyn.COM!karl From: karl@grebyn.COM (Karl A. Nyberg) Newsgroups: comp.lang.ada Subject: [umd5!dca-ems.arpa!jmoody: Re: INFO-ADA Digest V88 #135] Message-ID: <8806022115.AA06505@grebyn.com> Date: 2 Jun 88 21:15:35 GMT Article-I.D.: grebyn.8806022115.AA06505 Sender: daemon@ucbvax.BERKELEY.EDU Organization: Grebyn Corporation List-Id: [Ed, - Forwarded] -- Karl -- Date: Thu, 2 Jun 88 11:59:10 EDT From: Jim Moody (DCA C342) Subject: Re: INFO-ADA Digest V88 #135 To: INFO-ADA-REQUEST@ajpo.sei.cmu.edu All, Mike Linnig posed a question about Dynamic Address Clauses. What follows is his question with my annotations. ....................................... The following package was compiled with two compilers (DEC Ada and Tartan 1750a Ada). Both allowed the declaration of X. DEC ada complained about the type conversion used for the rep clause in ANOTHER. Assuming one or both is legal, what do they mean??? Mike Linnig, Texase Instruments ------------------------------------------------------------ with SYSTEM; use SYSTEM; package DYNAMIC ADDR is subtype STUPID is SYSTEM.ADDRESS; function DYNAMIC return STUPID; -- just some function X: INTEGER; for X use at DYNAMIC; -- just what does this mean?? -- First of all, it's an incorrect order -- dependency and will raise PROGRAM ERROR -- if executed, since the body of DYNAMIC -- hasn't been elaborated yet. Leaving that -- aside (since it could be fixed by taking -- DYNAMIC outside the package spec and using -- PRAGMA ELABORATE to make sure that its -- body has been elaborated already), what it -- does is what it looks like it does. -- It looks like it places X at the address returned by -- evaluation (at elaboration time) of DYNAMIC. One -- might do such a thing to e.g. put data to be shared -- with another process at a place agreed to by the -- other process (negotiation performed via DYNAMIC). -- One might have a slow interprocess communication -- method which is OK for setting things up, but too -- slow to use for passing data back and forth. In -- such a case, the use of shared memory might be -- mandatory. Where the shared memory is might not -- be determinable until run-time. ANOTHER: INTEGER; for ANOTHER USE AT stupid(x); -- I guess we can use x as a pointer -- but is it only evaluated at package elaboration? -- I would prefer to use: for ANOTHER use at INSTANTIATION OF UNCHECKED CONVERSION INT TO STUPID(X); -- rather than the explicit type conversion. The -- compiler probably wouldn't complain about that. -- It makes it clear that you're assuming that an -- address is an integer; there are machines for -- which that isn't true: Honeywell DPS8000, for -- example, where addresses are left-justified in -- a word. -- Yes, it is evaluated at package elaboration. -- Use would be similar to the placement of X. end DYNAMIC ADDR;