Re: Fussy Standard: what is modulo Address?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

porton@ex-code.com (Victor Porton) writes:

> In article <wcc1y34k92a.fsf@shell01.theworld.com>,
> 	Robert A Duff <bobduff@shell01.TheWorld.com> 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