Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!microsoft!brianw From: brianw@microsoft.UUCP (Brian Willoughby) Newsgroups: comp.sys.apple Subject: Re: Souped-Up GS Summary: 65832 vs 80386 Message-ID: <7530@microsoft.UUCP> Date: 28 Aug 89 00:27:24 GMT References: <8908240922.aa13041@SMOKE.BRL.MIL> <29229@srcsip.UUCP> Reply-To: brianw@microsoft.UUCP (Brian Willoughby) Organization: Microsoft Corp., Redmond WA Lines: 50 In article <29229@srcsip.UUCP> shankar@bedrock.UUCP (Subash Shankar) writes: >In article <8908240922.aa13041@SMOKE.BRL.MIL> SEWALL@UCONNVM.BITNET (Murph Sewall) writes: > >>Western Design is promising production quantities of the 65832 next year. >>Maybe we'd all be better of if Apple invested their energy on developing >>a 32 bit Apple II (?) > >Would we? >I suppose this would result in improvements in handling 24-bit addresses, >but since the 65832 still has only a 8-bit databus, I wouldn't expect >much improvements for most code. And I'm not holding my breath >waiting for an on-time announcement of production quantities of the >65832. >--- Don't get me wrong, I'm a 16 bit 6502 fan, but I've been wondering just how much trouble is takes to use the different data sizes on the 65C8xx. Every time you switch sizes, you have to flip the M or X bits using a 2 byte, 3 cycle instruction. Also, I would assume that you have to use a consistent method of calling subroutines (i.e. always having M and X set to 16 bit on subroutine entry). But what if you are in the middle of some 8 bit string manipulation code, and want to make a call to 'printf' for output? If you've chosen a 16 bit default between subroutine calls, then you have to switch out of 8 bit mode, only to reselect it when you print out the 8 bit characters. The way the instruction set has ended up, I hate to see what the 65832 does to utilize 32 bit data. Anyone have any benchmarks for the 65C816 which can be compared to the other processors out there? The 80386 has the same trouble when selecting register data sizes. The old 8086 had 8 and 16 bit opcodes, which pretty much filled up the available opcode patterns. Now that 32 bit registers are available (but not always used) Intel had to add an opcode size override, which makes only the immediately following instruction use a different size (i.e. mov ax,memory becomes 32 bit when it used to be a 16 bit instruction). As you can probably guess, code that is largely 32 bit would suffer a great deal if a byte prefix were added to every 32 bit opcode, so to complicate matters even further, Intel has a bit in the segment descriptor which selects the default size for that segment of code. Now, in a 32 bit default segment, the opcode size override prefix selects 16 bit data. Arrrgghhhhh! At least the 65816 stays in 16 bit mode once you select it, instead of only affecting one instruction at a time. But which method works out better? I don't know... Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP