Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!bellcore!petrus!hammond
From: hammond@petrus.UUCP
Newsgroups: net.arch,net.micro.68k
Subject: Re: M680*0 "small model"
Message-ID: <378@petrus.UUCP>
Date: Tue, 18-Jun-85 13:07:59 EDT
Article-I.D.: petrus.378
Posted: Tue Jun 18 13:07:59 1985
Date-Received: Wed, 19-Jun-85 04:48:11 EDT
References: <167@mot.UUCP> <1069@peora.UUCP> <1071@peora.UUCP> <2312@sun.uucp>
Organization: Bell Communications Research, Inc
Lines: 22
Xref: watmath net.arch:1421 net.micro.68k:933

As someone has already pointed out, the UNIX assemblers since the time
of the PDP 11 have done the span-dependent optimization for branch
instructions (i.e. select branch or branch of opposite flavor over jump)
They haven't selected the shortest addressing mode since you have to allow
for separate compilation, which means that things like pointers passed
between functions in different files must be in the long format, unless
you restrict programs to running in just 64k.  Further, global variables
generally end up with 32 bit absolute addresses.  To get rid of these
you need to integrate the assembler, loader, and library archiver to
be able to handle multiple size addresses.  This is a non-trivial task.
It gets worse for something like the NSC 32032 where you can have 7, 14,
or 30 bit offsets instead of just 16 and 32 bits.

Another problem, at least on UNIX, is that the code is mapped in the lowest
portion of the address space, which is where small absolute addresses
point.  To be most effective, the code, which can easily reference other
code locations with PC relative offsets ought not to use the region where
small absolute addresses work, so that the data can be placed there.
For most programs, global data would easily fit in the first 32k of address
space with a reduction in code size.

Rich Hammond BCR	[allegra, decvax, ucbvax]!bellcore!hammond