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,8e64f4db20d57eb5 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Call by reference vs. call by value Date: 1996/07/31 Message-ID: #1/1 X-Deja-AN: 171225899 references: <31F10E50.726@egr.uri.edu> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-07-31T00:00:00+00:00 List-Id: In article , Felaco wrote: >I disagree with changing the syntax. I feel that the pragma is the >least intrusive way of giving the programmer some control, but not >forcing the programmer to care when they wouldn't otherwise. Another >even simpler idea is to dictate that the compiler issue a warning when >a call is made to a subunit with the same actual parameter used as an ^^^^^^^ subprogram, I assume you mean >'in' and an 'out' (or 'in out'). How hard would this be? Impossible, since in many cases you can't tell what a given name denotes until run time (array indexing, pointer dereferencing). You could give overly pessimistic warnings, but that wouldn't be helpful, since you would have to warn for "P(X.all, Y.all);" if X and Y are of the same type, so you would get zillions of spurious warnings. Also, it's not just passing the same actual twice -- the problem can also occur if you pass overlapping things. (E.g., pass X and X(I).) Also, you need to worry about aliasing with globals, and the compiler can't see which globals are referenced. So it would have to warn about "P(X.all);", where X is a pointer, in case P accesses Y.all, and X and Y happen to point to the same thing. Also, Ada doesn't say aliasing is always wrong -- it depends on what the subprogram does, and in what order. >That's a good question - just how does the compiler determine how to >pass array parameters where rep specs or packing applies? Does it use >bit pointers, or does it just make a properly aligned copy and pass it >along? The latter. Bit pointers are less efficient than addresses on almost all machines. And if you pass a packed component by bit pointer, you have to pass *all* parameters that way (since the subprogram's code has to expect a bit pointer). A nasty distributed overhead. Alternatively, you could generate two versions of code for every subprogram, one of which expects addresses, and the other expects bit pointers. This isn't really acceptable, since it would double your code size. You could do better if you do fancy stuff at link time, but most compilers don't. So, compilers generate code that expects an address of a properly aligned thing, and in the packed case, make a copy at the call site that is properly aligned. This is what you expect -- pragma Pack means, "I want to shrink the size, and I'm willing to put up with slower access." >... If the LRM dictated that all arrays were passed by reference, >then the compiler could decide to use bit pointers (if the >architecture provided efficient means to do so) or it could just >resort to making a copy and passing a reference to it. This doesn't make sense to me. If the RM dictated by-reference, but the compiler used by-copy, then the compiler would simply be wrong. Passing a copy by reference is by-copy semantics. It doesn't matter who makes the copy (caller or callee) nor where it is allocated, nor how it is passed -- a copy is a copy. No, I think if you dictated by-ref, then you would have to introduce the Pascal rule, which says you can't pass packed components by-ref. This would be ugly, since it makes pragma Pack affect the semantics, rather than just giving an optimization hint. (Actually, pragma Pack *does* affect the semantics of shared variables in a tasking context. I find that ugly, too.) Note that Ada 95 has *some* types that require pass-by-ref (limited records, for example). If you pack something containing such a type, then the compiler simply doesn't pack that component tightly. - Bob