AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (11/14/88)
>Date: Thu, 10 Nov 88 17:34:41 GMT >From: Doug Gwyn <adm!smoke!gwyn@NYU.EDU> >Subject: Re: A Serious Thought About the FUTURE >[...] Also, even the 65816 still has too small a virtual >address space (64K 8-bit bytes). Although one can cope with this by >using segmenting schemes, it does get in the way. Eh? The 65816 has a 16 Meg ->physical<- address space and no support for virtual memory. There are addressing modes that can access the whole thing, with no need for segmentation. The only kind of segmentation you need is at a high level (the linker and loader level), since _executing code_ can't cross a 64K boundary. (This is a reasonable restriction, since code that _could_ cross a 64K boundary would have to _always_ use JSL/RTL rather than JSR/RTS, pushing 3-byte rather than 2-byte return addresses on the stack.) >The 68000 provides a 24M 8-bit byte linear virtual address space, >which is enough for almost any current application. The bottom line >is that the 68000 architecture is much more convenient for the >programmer. [...] The 68000 series *before* the 68030 provides a 24-bit address bus just like the 65816's, allowing 16 Megs of addressible physical memory. The 68030 supports a memory-management chip that provides a 4 Gigabyte (4096 Megabyte) virtual memory space. I don't agree that the difference in convenience is all that great, although I certainly wouldn't mind being able to do 32-bit operations all at once. --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/14/88)
In article <8811132232.aa14565@SMOKE.BRL.MIL> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: >>From: Doug Gwyn <adm!smoke!gwyn@NYU.EDU> >>[...] Also, even the 65816 still has too small a virtual >>address space (64K 8-bit bytes). Although one can cope with this by >>using segmenting schemes, it does get in the way. >Eh? The 65816 has a 16 Meg ->physical<- address space and no >support for virtual memory. There are addressing modes that can >access the whole thing, with no need for segmentation. The only >kind of segmentation you need is at a high level (the linker and >loader level), since _executing code_ can't cross a 64K boundary. >(This is a reasonable restriction, since code that _could_ cross a >64K boundary would have to _always_ use JSL/RTL rather than JSR/RTS, >pushing 3-byte rather than 2-byte return addresses on the stack.) A virtual address space doesn't necessarily have anything to do with virtual memory. It's the addressable scope of program code without having to alter any memory mapping tables or registers (such as "base" or "bank" registers). Although most accumulator-oriented 65816 instructions can be used in a "long" (24-bit) mode, many useful instructions cannot. In fact, the hodge-podge mixture of base instructions and addressing modes has always been one of the annoying features of the 65xx family architecture. The various strange addressing quirks once, for example, limited APW C arrays to 64Kb in early releases (now arrays are permitted to exceed 64Kb, at the expense of slower code generated to access them). The typical continual shuffling of the data bank register is a far cry from the 68000's simple addressing scheme. And the crucial role played by the 256-byte direct page in making many addressing modes work leads to a turf fight that requires a lot of unnecessary work to avoid. The 68000 architecture has a few quirks of its own, but it is MUCH cleaner in its overall design. On the other hand, there's always the 808* family to poke fun at! Almost anything looks good by comparison..
terranova@vms.macc.wisc.edu (John Terranova) (11/14/88)
In article <8878@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes... >The various strange addressing quirks once, for example, limited >APW C arrays to 64Kb in early releases (now arrays are permitted >to exceed 64Kb, at the expense of slower code generated to access >them). The typical continual shuffling of the data bank register >is a far cry from the 68000's simple addressing scheme. And the >crucial role played by the 256-byte direct page in making many >addressing modes work leads to a turf fight that requires a lot >of unnecessary work to avoid. > 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. BTW: I have heard that the 65816 has a very efficient instruction set (highly piplined, perhaps?) and would run rings around a 68000 running at the same clock speed. Can anyone verify or deny this for me? Just wondering. -------------------------+--------------------+---------------------------- John C. Terranova \ What the Hell do | I'm not a Computer CS, BS to be \ I know? I come | Science undergraduate, terranova@vms.macc.wisc.edu \ from Waunakee! | but I play one at school. -----------------------------+----------------+---------------------------- It's awful hard to try to make love long-distance. --Billy Joel, "Just a Fantasy" Robert Heibel: 08/30/41 - 09/21/88; R.I.P., you deserve it.
mattp@oakhill.UUCP (Matt Pressly) (11/15/88)
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
rat@circle.UUCP (David Douthitt) (11/15/88)
I'd say this was an unfair comparison fellas. For one thing, the 680x0 is a 32bitter (at least they were until the 68030 came out....) and the 65816 is a 16bit cpu. Why not compare the 65816 with the 6502 eh? Seems to me that puts things into the proper perspective. Besides, like a friend of mine tells us... It's not which is *better*, but which you are more *comfortable* with. For me that gives the 65x an edge that the 680x0 wont have for some time. -- ::: David Douthitt ::: Madison, Wisc ::: uucp mail: ...!uwvax!geowhiz!circle!rat arpa mail: rat@circle.UUCP fidonet mail: 1:121/1
gsarff@meph.UUCP (Gary Sarff) (11/16/88)
In article <871@dogie.edu>, terranova@vms.macc.wisc.edu (John Terranova) writes... >In article <8878@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes... >>The various strange addressing quirks once, for example, limited >>APW C arrays to 64Kb in early releases (now arrays are permitted >>to exceed 64Kb, at the expense of slower code generated to access >>them). The typical continual shuffling of the data bank register > >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. This is a problem with the Macintosh memory management scheme that apple chose and the C compiler, not the 68000 as such. They chose to do without an MMU on the Macintosh (yes 680x0 systems can have mmu's, I have some on my systems) and thus forcing the code to be position independent, as you no doubt know. Therefore the compiler must generate all code and data ref's as offsets from the pc or someother register, and the 68000 only allows 8 or 16 bit signed offsets, thus the 32K limit. This is a limitation of the 68000 IN THIS MODE, but the 68000 has other addressing modes, and code and data can be larger and do not have to worry about crossing some 64K boundary as the 65816 does with its 16 bit pc register that doesn't increment across bank boundaries. ------------------------------------------------------------------------ "Those whom the gods would destroy, they first make mad" He who steals my core-dump, steals trash
jsnow@esunix.UUCP (John Snow) (11/16/88)
From article <8811132232.aa14565@SMOKE.BRL.MIL>, by AWCTTYPA@UIAMVS.BITNET ("David A. Lyons"):
>
> The 68000 series *before* the 68030 provides a 24-bit address bus
> just like the 65816's, allowing 16 Megs of addressible physical
> memory. The 68030 supports a memory-management chip that provides
> a 4 Gigabyte (4096 Megabyte) virtual memory space.
>
No, the 68020 and the 68030 both support a full 32-bits of physical
address space without the need for the memory-management hardware. The
680x0 family has always had 32-bit address registers and all instructions
respected the 32-bit address space, but the 68000 and 68010 only had
24-bit address buses. With the advent of the 68020, and later the 68030,
the address bus was expanded to a full 32-bits. The memory management
hardware is only necessary if you wish to implement virtual memory -- it
does not expand the size of the address space.
--
-----------------------------------------------------------------------------
John F. Snow UUCP:{ucbvax,decvax}!decwrl!esunix!jsnow
Evans & Sutherland Computer Corp. Compuserve: 71550,1152 BIX: johnfsnow
Salt Lake City, Utah "Apple ][ forever!"jsnow@esunix.UUCP (John Snow) (11/16/88)
From article <871@dogie.edu>, by terranova@vms.macc.wisc.edu (John Terranova): > BTW: I have heard that the 65816 has a very efficient instruction set > (highly piplined, perhaps?) and would run rings around a 68000 running > at the same clock speed. Can anyone verify or deny this for me? Just > wondering. Well, let's just say that the 6502 family in general do more per clock cycle than do most other microprocessors. For this reason, the clock speed HAS to be lower because the chip needs more time between clock cycles to do everything that it is doing. Yes, if the 65816 ran at the same clock speed as a 68000, the 65816 would vastly outperform the 68000. It would also require faster and more expensive memory chips to keep up with it since it would access the RAM in one half of a clock cycle whereas the 68000 would use 3 clock cycles for its memory cycle. Actually, the 2.8 MHz 65816 in a GS compares very well with the 7.8 MHz 68000 running in a Mac. Despite the fact that it must do twice as many memory accesses to get 16-bits of information, the 65816 can execute many instructions at the same overall speed as the Mac's 68000. I sat down one day and calculated several of them and was surprised to find that many were within about 5% of the 68000's speed. The place that really slows the GS down is when it has to access slow RAM, meaning the graphics really suffer a penalty due to the graphics RAM being slow RAM. Hopefully, a future GS will remove the slow RAM from the system. -- ----------------------------------------------------------------------------- John F. Snow UUCP:{ucbvax,decvax}!decwrl!esunix!jsnow Evans & Sutherland Computer Corp. Compuserve: 71550,1152 BIX: johnfsnow Salt Lake City, Utah "Apple ][ forever!"
jb10320@uxa.cso.uiuc.edu (11/16/88)
Yeah, the 65816 is definitely more efficient than a 68000. I wrote a "Sieve" prime number program in pascal on both a GS and an Atari ST, and the ST was only a few seconds faster (5 vs. 8, I believe). The ST clock speed is three times faster than the GS's (8Mhz opposed to 2.8), so the GS is effectively twice as fast as an ST. I would expect similar results from a Macintosh. jb10320@uxa.cso.uiuc.edu [What's an IBM?!?!?!]