Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #26662

Re: Comparing addresses

Show all headers | View raw

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> 3.1.1 says:
>>>> 
>>>> | a-addr => c-addr => addr => u;
>>>> 
>>>> I.e., addr is a subtype of u.  Therefore I consider programs that
>>>> compare addresses with U< standard-compliant.
>>>
>>>How does that follow?
>> 
>> 6.1.2340 U< ( u1 u2 -- flag )
>> 
>> Also:
>> 
>> |A.3.1.3.3 Addresses
>> |
>> |An address is uniquely represented as a single cell unsigned number
>> |and can be treated as such when being moved to, from, or upon the
>> |stack. Conversely, each unsigned number represents a unique address
>> |(which is not necessarily an address of accessible memory). This
>> |one-to-one relationship between addresses and unsigned numbers forces
>> |an equivalence between address arithmetic and the corresponding
>> |operations on unsigned numbers.
>> 
>>>> And if you implement Forth on hardware that has system stuff around
>>>> MAX-N and where the user RAM can straddle 0, it's your job to make
>>>> sure that contiguous regions don't straddle 0.
>>>
>>>And that.  I don't quite see how a subtype relationship implies
>>>ordering.  For example, every address between FFF0 ... 0010 is of type
>>>u.
>> 
>> Ordering is defined for u (through U< and U>), and therefore for addr.
>
>I don't know that the language abve is strong enough.

It does not look strong enough, but until now it is: I have not heard
of a system that claims to be standard and does not satisfy the
condition above.  And for programs, if there is a conscious decision
involved, programmers choose unsigned operations for addresses (the
bigger problem here is that if the programmer writes a signed
operation, this big will probably not be found through testing).

Still, tightening the language is probably a good idea.

>  There would
>have to be something like
>
>  For every address A in data space, the result of A A 1+ U< shall
>  return true.
>
>(this isn't right because it doesn't apply to the last byte, but you
>get the idea)

Yes, that's not it, but that's also something that we want, because
the address beyond the end of a memory area is also computed commonly,
and the usual way to do comparisons should work for that, too.

>and I'd like also to see
>
>  For every address A in data space, the result of A 0= shall
>  return false.

That would be the condition above, plus the condition that a memory
area must not start at 0, which we also want.

Your wording is not in the style of the standard.  Maybe add something
like:

|3.3.3.7 Data space addresses
|
|The addresses 0 and MAX-U (largest usable unsigned integer) are not in
|data space.
|
|A.3.3.3.7
|
|This restriction allows programs to use a number of common programming
|techniques: 0 can be used as NIL; and unsigned comparisons can be used
|to compare all data space addresses, and also the first address beyond
|a memory region.

>No, I'm not.  I'm arguing that I can't see any language that forbids
>address overflow in a contiguous region.

Yes, it does not follow directly, only indirectly: If "addr is a
subtype of u" did not have this consequence, it would have none, so
there would be no point in specifying "addr is a subtype of u" (they
would have specified "addr is a subtype of x" instead).  In any case,
whether it already follows or not, it's probably a good idea to
tighten the language.  Will you make the RfD?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Baden's recursive Quicksort revisited "Ed" <invalid@invalid.com> - 2013-10-11 01:31 +1000
  Re: Baden's recursive Quicksort revisited albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-10 15:49 +0000
  Re: Baden's recursive Quicksort revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-10 17:42 +0000
    Re: Baden's recursive Quicksort revisited "Ed" <invalid@invalid.com> - 2013-10-18 15:16 +1000
    Re: Baden's recursive Quicksort revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-20 03:18 -0500
      Re: Baden's recursive Quicksort revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-21 16:33 +0000
  Re: Baden's recursive Quicksort revisited Hans Bezemer <the.beez.speaks@gmail.com> - 2013-10-11 12:03 +0200
    Re: Baden's recursive Quicksort revisited Alex McDonald <blog@rivadpm.com> - 2013-10-11 05:15 -0700
      Re: Baden's recursive Quicksort revisited "Ed" <invalid@invalid.com> - 2013-10-13 12:25 +1000
        Re: Baden's recursive Quicksort revisited "Alex McDonald" <blog@rivadpm.com> - 2013-10-13 08:59 +0100
          Re: Baden's recursive Quicksort revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-13 04:50 -0500
            Comparing addresses (was: Baden's recursive Quicksort revisited) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 15:17 +0000
              Re: Comparing addresses Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-15 14:34 -0500
                Re: Comparing addresses anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 14:15 +0000
                Re: Comparing addresses Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-20 02:51 -0500
                Re: Comparing addresses anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-22 11:18 +0000
                Re: Comparing addresses albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-22 13:26 +0000
                Re: Comparing addresses anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-22 13:39 +0000
                Re: Comparing addresses Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-22 13:30 -0500
                Re: Comparing addresses anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-23 07:48 +0000
                Re: Comparing addresses m.a.m.hendrix@tue.nl - 2013-10-23 23:49 -0700
                Re: Comparing addresses anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-24 09:01 +0000
        Re: Baden's recursive Quicksort revisited albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-13 12:06 +0000
          Re: Baden's recursive Quicksort revisited all2001@spambog.com (Wolfgang Allinger) - 2013-10-13 11:42 -0400
    Re: Baden's recursive Quicksort revisited "Ed" <invalid@invalid.com> - 2013-10-13 12:27 +1000
      Re: Baden's recursive Quicksort revisited Hans Bezemer <the.beez.speaks@gmail.com> - 2013-10-16 10:35 +0200
        Re: Baden's recursive Quicksort revisited Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-16 03:51 -0500
        Re: Baden's recursive Quicksort revisited albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-16 10:50 +0000
          Re: Baden's recursive Quicksort revisited anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 14:27 +0000
        Re: Baden's recursive Quicksort revisited "Ed" <invalid@invalid.com> - 2013-10-18 15:37 +1000

csiph-web