Path: utzoo!attcan!uunet!husc6!cs.utexas.edu!oakhill!mattp
From: mattp@oakhill.UUCP (Matt Pressly)
Newsgroups: comp.sys.apple
Subject: Re: 65816 v. 680x0
Message-ID: <1656@wynge.oakhill.UUCP>
Date: 14 Nov 88 18:46:47 GMT
References: <871@dogie.edu>
Reply-To: mattp@wynge.UUCP (Matt Pressly)
Distribution: na
Organization: Motorola Inc., Austin Tx.
Lines: 78

In article <871@dogie.edu> terranova@vms.macc.wisc.edu (John Terranova) writes:
>You are complaining about a 64K limit on arrays and, for that matter,
>single code segments?!?  You should consider yourself fortunate.  On a
>Macintosh (some claim a superior machine to the GS) you are restricted
>to 32K arrays, 32K code segments and 32K of global data.  Sounds to me
>like the 65816 compares fairly favorably (in this respect, atleast) to
>the 68000.

The 32K limitation is one imposed by the Macintosh OS, not by the 68000.
The 32k limit stems from the fact that all code segments written for the
Macintosh must be position independent.  The 68000 uses a 16 bit displacement
for PC relative addressing and for offsets in long branches.  If position
independence were not required, JMPs and direct addressing of variables in
the code segments could be used, removing this restraint completely.

The 32K limit on arrays is an artificial limit imposed by some, not all,
compilers on the Macintosh.  Although I have not really looked at the code
generated by various compilers, I imagine they generate instructions which
use indexed addressing.  There are two forms which could be used:
	
    (1) 0(a0,d0.w)  -- where d0[15:0] is sign extended and used as the
        from a0 to find the address of a particular element in the array,
        causing the size of the array to be limited to 32K (for positive
        values of the offset).
	
    (2) 0(a0,d0.l) -- all 32 bits of d0 are used as the offset into the
        array.  The array can be as large as the available memory.
	
Since integers are used for array indices in PASCAL, and PASCAL integers are
a word (16 bits) long, (1) is probably used.  However, I am almost certain 
that there are some more recent compilers for the Macintosh that do not have
the 32K size limit on arrays.

As for global variables, the  application globals which are allocated on 
the stack then referenced via address register indirect with offset (16
bit offset from register A5).  These globals would be limited to a total
of 32K for all variables used.  [Note: this limitation is not very severe,
since most programmers allocate large variables on the heap and just store
pointers to them in the global variables.]

Note that the limitation of 32K for branch offsets and PC relative offsets
does not exist on the 68020 and 68030.

Someone else mentioned zero page addressing on the 6502.  On the 68000,
there is a 64K zero page (from $FF0000 to $000000 to $007ffff).  Apple chose
to only use the range from $0 to $7fff on the Macintosh for RAM, so it has
only a 32K zero page.

Your conclusion about 65816s and 68000s does not follow from the your
previous statement about the limitations on the Macintosh, since these
limitations are caused by the system and compiler software, not the
microprocessor.

There was also a comment about the speed of the 65816 and the 68000 when
running at the same clock speed.  A 16 MHz 65816 might run as fast or faster
than a 16 MHz 68000 (all you have to do is compare clocks per instruction to
get a good idea whether or not this statement is true, although lack of a
large number of general purpose 32 bit registers and extremely un-orthogonal
architecture of the 65816 would tend to favor the 68000), but did you ever
think about why there are no 16 MHz 65816s ?  It probably cannot be done
(using the same technology) because the 65816 does more in a single clock 
cycle, requiring that clock cycle necessarily be slower.  Note that your
statement would also only apply to the 68000, but not the 68000 family in
general, as the 68020 and 68030 have fewer clock cycles per instruction than
the 68000, not to mention the much higher clock rates.









Disclaimer:  any opinions expressed above are entirely my own.
-- 

UUCP: oakhill!wynge!mattp@cs.utexas.edu