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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b9c1962801ad6b73 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-23 06:06:46 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!yellow.newsread.com!netaxs.com!newsread.com!newsfeed.news2me.com!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Fussy Standard: what is modulo Address? User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Thu, 23 Jan 2003 14:06:01 GMT Content-Type: text/plain; charset=us-ascii References: <3e2f5c7a$0$33931$bed64819@news.gradwell.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Organization: The World Public Access UNIX, Brookline, MA Xref: archiver1.google.com comp.lang.ada:33371 Date: 2003-01-23T14:06:01+00:00 List-Id: porton@ex-code.com (Victor Porton) writes: > In article , > Robert A Duff writes: > > porton@ex-code.com (Victor Porton) writes: > > > >> > I don't think so. "Modulo" means the "mod" operator for > >> > System.Address. This is defined in 13.7.1(8). The AARM states this > >> > explicitly in 13.3(24.b) and 13.7.1(11.b). > >> > >> So, it is stated nly in AARM, not in ARM? It is a bug. > > > > The reason I put it in the AARM only is that I thought it was obvious > > what it must mean. What else could "address modulo mumble" mean besides > > the "mod" operator on type Address? So I disagree that it's a bug. > > It also may mean about the value of 'Address attribute which is > universal integer, not System.Address. 'Address returns System.Address. And that's (supposed to be) a private type, for the very reason that we don't know what sort of thing it is. > >> > The manual does not define the semantics of this "mod" operator. How > >> > could it? Address is just a private type provided by the implementer -- > >> > it could be anything. > >> > >> The manual should define relations between System.Address and > >> System.Storage_Element.Integer_Address. To define these seems being > >> just forgotten. No these relations which should be true accordingly > >> human intuition may have bad impact on reliability. > > > > I don't see the problem here. Type Address and Integer_Address are too > > hardware-dependent to say much about them (or the relationships between > > them) in the RM. > > IMO, it should be "A mod M = System.Storage_Element.To_Integer(A) mod M" > for any A of type System.Address and integer M (probably with some > restrictions related to memory segments...) The part about "probably with some restrictions related to memory segments..." is hand waving. The RM knows nothing about memory segments, so it can't make rules referring to them. The "A mod M = System.Storage_Element.To_Integer(A) mod M" is what I would expect on a simple flat-address-space machine. But it's not what I expect on *all* machines -- in particular, it can't possibly be true on a segmented machine (as you say above). It seems unhelpful for the RM to say "A mod M = System.Storage_Element.To_Integer(A) mod M" on all machines, except for some machines where it's not true. Saying "except on segmented architectures" is also unhelpful, since the term is not defined in the RM. And I have no idea how to define it in RM terms. For features at this level, it's much better to trust implementers to do something sensible. Implementers know about the particular hardware they're targetting. For a language designer to address this issue would require the language designer to imagine all *possible* hardware architectures, which is not easy. ;-) By the way, why are you picking on "mod"? There are other operators that have the same issue. For example, the "+" that takes an Address and a Storage_Offset will not necessarily behave the same as the "+" on Integer_Address. It will on simple flat-address-space machines (presuming Integer_Address is a modular type, which is what you normally expect), but on segmented machines, "+" on Address would probably wrap around within a segment, whereas "+" on Integer_Address behaves as defined for the integer type. If you're doing address arithmetic, you ought to use the operators on Address. Integer_Address is mainly for doing things like printing out addresses for debugging. - Bob