Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!UIAMVS.BITNET!AWCTTYPA From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") Newsgroups: comp.sys.apple Subject: 65816 v. 680x0 Message-ID: <8811132232.aa14565@SMOKE.BRL.MIL> Date: 14 Nov 88 05:47:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 X-Unparsable-Date: Sunday 13 Nov 88 8:16 PM CT >Date: Thu, 10 Nov 88 17:34:41 GMT >From: Doug Gwyn >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