Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!crdgw1!sunroof!hammondr
From: hammondr@sunroof.crd.ge.com (richard a hammond)
Newsgroups: comp.arch
Subject: Re: 68000 architecture
Message-ID: <705@crdgw1.crd.ge.com>
Date: 9 Jun 89 12:40:57 GMT
References: <1989May30.171335.473@utzoo.uucp> <658@geovision.UUCP> <40938@bbn.COM> <660@geovision.UUCP> <1989Jun8.142409.22589@cs.rochester.edu>
Sender: news@crdgw1.crd.ge.com
Reply-To: hammondr@sunroof.crd.ge.com (richard a hammond)
Organization: General Electric Corp. R&D, Schenectady, NY
Lines: 21

In <660@geovision.UUCP>, gd@geovision.UUCP (Gord Deinstadt) wrote:
> ...
> Actually, I don't mind the absolute addresses being signed; it's a
> fairly minor issue.  It's the signed offsets in base+offset mode that
> burn me up.  You *can* work around it (ie. still get a 64k address
> range with 16-bit offsets) by fudging all your
> base addresses by 32768; but you shouldn't have to.  Especially
> considering that this was in the days when people still wrote
> a lot of assembler.  (Gosh, did people actually do that when
> I was young? ;-P)

But, read the processor's User Manual for the LINK instruction, the
instruction which one would normally use to adjust a frame pointer.
"A negative displacement is specified to allocate stack area."
Hence, all your local, dynamic variables would be at negative offsets
from the frame pointer, while incoming arguments to the subroutine
would be at positive offsets from the frame pointer.  While this might
not be all that important for the assembly language programmer, it
made porting the portable C compiler (and thus UNIX) easy.

Rich Hammond