Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!mit-eddie!smh
From: smh@mit-eddie.UUCP (Steven M. Haflich)
Newsgroups: net.lang.c
Subject: Re: pointer -> long conversion - (nf)
Message-ID: <2410@mit-eddie.UUCP>
Date: Sat, 21-Jul-84 09:00:50 EDT
Article-I.D.: mit-eddi.2410
Posted: Sat Jul 21 09:00:50 1984
Date-Received: Sun, 22-Jul-84 03:16:44 EDT
References: <10@ism780b.UUCP>
Organization: MIT, Cambridge, MA
Lines: 24

>>Since when should pointers be sign-extended on a 68000, or any other
>>machine?  Unless someone comes up with a meaning for the notion of a
>>negative address, pointers should always be zero-extended.
>>-- Jim Balter, INTERACTIVE Systems (ima!jim)

Typical language execution environments on typical architectures (e.g.
C on a 68000) have two kinds of allocated memory.  The stack grows
automatically with things like procedure invocation.  The heap is
managed by explicit user calls (e.g. malloc/free).

On machines with huge virtual address spaces, it is quite reasonable to
keep addresses for the two separate.  Typically, virtual stack space
could grow downward from 0xffffffff while the heap grows upward from
0x0.  On a small dedicated-application system with limited physical
memory, and in which it is certain neither the stack and heap will grow
beyond 32K, it would be quite reasonable to keep pointers inside data
structures as 16-bit *signed* quantities.  In effect, one is modelling
memory as a range around zero (0xffff8000..0x00007fff) instead of the
usual notion of positive-number addressing (0x0..0x0000ffff).

I know it smells of crock.  You didn't say it had to be a *good* reason,
did you?

Steve Haflich, MIT