herwin@pro-novapple.cts.com (Harry Erwin) (09/23/90)
I've been doing performance engineering for the new RISC machines. Is Apple thinking about releasing a RISC-based machine that emulates the IIGS? Harry Erwin -->Remember, no good deed goes unpunished... proline:pro-novapple!herwin uucp: crash!pro-novapple!herwin arpa: crash!pro-novapple!herwin@nosc.mil Telenet: herwin/trw Internet: herwin@pro-novapple.cts.com alternate Internet: /PN=Harry.Erwin/O=TRW/ADMD=Telemail/C=US/@Sprint.com
jm7e+@andrew.cmu.edu (Jeremy G. Mereness) (09/23/90)
herwin@pro-novapple.cts.com (Harry Erwin) writes: > I've been doing performance engineering for the new RISC machines. Is Apple > thinking about releasing a RISC-based machine that emulates the IIGS? > Harry Erwin -->Remember, no good deed goes unpunished... > proline:pro-novapple!herwin uucp: crash!pro-novapple!herwin > arpa: crash!pro-novapple!herwin@nosc.mil Telenet: herwin/trw > Internet: herwin@pro-novapple.cts.com > alternate Internet: /PN=Harry.Erwin/O=TRW/ADMD=Telemail/C=US/@Sprint.com No, Apple is not planning on doing so, or atleast they have made no indications and it damned well doesn't seem likely. The only announcements recently have been for Beta versions of System 7. Apple doesn't need to support the Apple //. They'll go on just fine by leaving it to rot, but holding onto the rights so that a self-respecting company could not step in and do the job correctly (if Laser tried to clone a //gs, you bet Apple would scream infringement)! It's too bad, because the machine has so much potential. User's can try to push the software to its limits, but we can't raise the hardware standards. *sigh* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |Jeremy Mereness | Support | Ye Olde Disclaimer: | |jm7e+@andrew.cmu.edu (internet) | Free | The above represent my| |a700jm7e@cmccvb (Vax... bitnet) | Software | opinions, alone. | |staff/student@Carnegie Mellon U. | | Ya Gotta Love It. | -------------------------------------------------------------------------
m.tiernan@pro-angmar.UUCP (Michael Tiernan) (09/26/90)
In-Reply-To: message from herwin@pro-novapple.cts.com
I doubt that Apple is going to be releasing any more RISC machines, the ones
that they have they aren't supporting. (Opinion that is changing slowly)
What RISC machines you say? How about the original, 65?02 based processors?
<< MCT >>
GEnie : M.Tiernan
AppleLinkPE : M Tiernan or BCS Mike
Internet : pro-angmar!m.tiernan@alphalpha.com
UUCP : ...!uunet!alphalpha!pro-angmar!m.tiernan
"God isn't dead, he's only missing in action."
- Phil Ochscromwell@acsu.buffalo.edu (mark j cromwell) (09/26/90)
In article <8139.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >In-Reply-To: message from herwin@pro-novapple.cts.com >I doubt that Apple is going to be releasing any more RISC machines, the ones >that they have they aren't supporting. (Opinion that is changing slowly) > >What RISC machines you say? How about the original, 65?02 based processors? The 65x02 aren't RISC processors. They're accumulator microprocessors. - Mark Cromwell
cbdougla@uokmax.ecn.uoknor.edu (Collin Broad Douglas) (09/27/90)
In article <8139.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >In-Reply-To: message from herwin@pro-novapple.cts.com > >I doubt that Apple is going to be releasing any more RISC machines, the ones >that they have they aren't supporting. (Opinion that is changing slowly) > >What RISC machines you say? How about the original, 65?02 based processors? > > ><< MCT >> > >GEnie : M.Tiernan >AppleLinkPE : M Tiernan or BCS Mike >Internet : pro-angmar!m.tiernan@alphalpha.com >UUCP : ...!uunet!alphalpha!pro-angmar!m.tiernan > >"God isn't dead, he's only missing in action." > - Phil Ochs Except the 6502 isn't a RISC chip. Why? well: 1. RISC machines execute an instruction per cycle. the 6502 doesn't 2. RISC machines have a large number of general purpose registers. the 6502 doesn't. I heard rumors that Apple was working on an 88000 based box that would run mac stuff. But then again, I just HEARD this :) Collin Douglas cbdougla@uokmax.ecn.uoknor.edu I wish I would 'hear' something about the GS. Even a rumor is better than nothing.
unknown@ucscb.UCSC.EDU (The Unknown User) (09/27/90)
In article <1990Sep26.194057.371@uokmax.ecn.uoknor.edu> cbdougla@uokmax.ecn.uoknor.edu (Collin Broad Douglas) writes: >In article <8139.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: > I heard rumors that Apple was working on an 88000 based box that would run > mac stuff. But then again, I just HEARD this :) I don't remember where I originally heard this, but I thought that it was basically common knowledge that the Macintoshes are going to the 88000 chip (sometime in the relatively near future)... -- /pqbdpqbdpqbd Apple II(GS) Forever! unknown@ucscb.ucsc.edu dbqpdbqpdbqp\ \"If cartoons were meant for adults, they'd be on in prime time."-Lisa Simpson/
russotto@eng.umd.edu (Matthew T. Russotto) (09/28/90)
In article <7247@darkstar.ucsc.edu> unknown@ucscb.UCSC.EDU (The Unknown User) writes: > >In article <1990Sep26.194057.371@uokmax.ecn.uoknor.edu> cbdougla@uokmax.ecn.uoknor.edu (Collin Broad Douglas) writes: >>In article <8139.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >> I heard rumors that Apple was working on an 88000 based box that would run >> mac stuff. But then again, I just HEARD this :) > > I don't remember where I originally heard this, but I thought >that it was basically common knowledge that the Macintoshes are going to >the 88000 chip (sometime in the relatively near future)... It was common rumor, anyway. I wouldn't bet on it-- there is also common speculation that Motorola is going to end the 680x0 line. That too, I wouldn't bet on. On the other hand, the 65xxx line seems pretty dead.... -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
araftis@polyslo.CalPoly.EDU (Alex Raftis) (09/28/90)
In article <1990Sep27.203148.21951@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: > >On the other hand, the 65xxx line seems pretty dead.... > Actually, the 65xxx line is far from dead. It may die in the home computer as far as Apple in concerned (I'm hoping otherwise), but it's one of the most widly used control chips, found in many small electronic devices. For that matter, someone once told me that the 6502 is one of the only chips ever certified for use as human implants. Hopefully if Apple decides to drop the Apple II directly, they'll decide to turn production over to another company like AE or Laser. If this happens we may yet get to see the 65832. BTW: Someone posted a question the other day that wasn't answered on the net. So, just what has happened with ASIC's 20Mhz 65816? -- -------------------------------------------------- Internet: araftis@polyslo.CalPoly.EDU America Online: xela (Real Life: Alex Raftis)
huang@husc9.harvard.edu (Howard Huang) (09/28/90)
I've been doing performance engineering for the new RISC machines. Is Apple thinking about releasing a RISC-based machine that emulates the IIGS? MacWeek says that Apple is currently working with Motorola's 88000 chip, but nothing will appear for at least two years. Heh heh. ---------------------------------------------------------------------------- Howard C. Huang Internet: huang@husc9.harvard.edu Junior Computer Science Major Bitnet: huang@husc9.BITNET Mather House 030, Harvard College UUCP: huang@husc9.UUCP (I think) Cambridge, MA 02138 Apple II: ftp husc6.harvard.edu -- ---------------------------------------------------------------------------- Howard C. Huang Internet: huang@husc9.harvard.edu Junior Computer Science Major Bitnet: huang@husc9.BITNET Mather House 030, Harvard College UUCP: huang@husc9.UUCP (I think) Cambridge, MA 02138 Apple II: ftp husc6.harvard.edu
herwin@pro-novapple.cts.com (Harry Erwin) (09/28/90)
In-Reply-To: message from m.tiernan@pro-angmar.UUCP
>What RISC machines you say? How about the original 65?02 based processors?
Not really a risc machine. It was based on the 6800 as a controller chip.
That's why the strange instruction set.
Harry Erwin -->Remember, no good deed goes unpunished...
proline:pro-novapple!herwin uucp: crash!pro-novapple!herwin
arpa: crash!pro-novapple!herwin@nosc.mil Telenet: herwin/trw
Internet: herwin@pro-novapple.cts.com
alternate Internet: /PN=Harry.Erwin/O=TRW/ADMD=Telemail/C=US/@Sprint.comherwin@pro-novapple.cts.com (Harry Erwin) (09/28/90)
In-Reply-To: message from cbdougla@uokmax.ecn.uoknor.edu
>RISC machines execute an instruction per cycle.
Well, they can execute more than that, but they typically don't. They average
something slower than an instruction per cycle since most code doesn't use the
parallelism in the architecture.
Harry Erwin -->Remember, no good deed goes unpunished...
proline:pro-novapple!herwin uucp: crash!pro-novapple!herwin
arpa: crash!pro-novapple!herwin@nosc.mil Telenet: herwin/trw
Internet: herwin@pro-novapple.cts.com
alternate Internet: /PN=Harry.Erwin/O=TRW/ADMD=Telemail/C=US/@Sprint.comgwyn@smoke.BRL.MIL (Doug Gwyn) (09/29/90)
In article <8139.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >What RISC machines you say? How about the original, 65?02 based processors? No, RISC architecture is not synonymous with puny, which would be a better description of the 6502 architecture. The 6502 is accumulator-oriented, its opcodes follow no regular pattern, etc. Not at all a RISC machine.
joshuat@pro-sol.cts.com (Joshua M. Thompson) (09/29/90)
> >On the other hand, the 65xxx line seems pretty dead.... > Actually, the TurboGraphx-16 game system uses a modified 6502 with a 16-bit graphics controller chip. The 6502 is a great little chip if you know how to program it effectively.
rhyde@ucrmath.ucr.edu (randy hyde) (09/30/90)
>>> its opcodes follow no regular pattern... Oh yes they do! It may not appear regular to the unaided eye, but the addressing modes are represented by various bit fields in the opcode and the basic instructions themselves are represented by other bitfields. Finally, the class of the instruction (I seem to recall that there were four basic groups) were represented by another set of bits. >>> The 6502 is accumulator-oriented... True, it's an accumulator machine, but I've never heard this term used when comparing whether the machine is RISC or CISC before! At the time the 6501 (yes, "1") was developed, the engineers were very interested in reducing the size of the instruction set. Chips like the 8080 and 6800 were selling for over $100. MOS Technologies wanted to sell their chip for $20. To do so, they needed to reduce the die size tremendously. (The size of the die was a direct factor in the cost of the chip back then). Therefore, they reduced the number of instructions present in the instruction set which directly reduced the size of the die (ever wonder why there aren't any ADD, SUB, signed branches, and other instructions common on CPUs back in 1976?). In this respect, I guess you could all the 6502 a "RISC" chip. OTOH, they also REDUCED the number of REGISTERS on the chip (compared to the 6502's peers) and increased the number of memory addressing modes (I do not consider direct page MEMORY locations registers, it is a shortened memory addressing mode (available on other processors like the 68000 and 8086)). At the time, the 6502, indeed, was considered the most CISC-like architecture around. *** Randy Hyde O-)
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/30/90)
In article <8971@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >>>> its opcodes follow no regular pattern... >Oh yes they do! It may not appear regular to the unaided eye, ... The point is, RISC architectures are designed specifically to facilitate compiler code generation. There is no way you can convince me that the 6502 meets that requirement; it lacks "orthogonality" in its opcode design. >At the time the 6501 (yes, "1") was developed, ... This history is bogus. I used to program 6800s etc. and the 6502 is close to a "knock-off" of the 6800 architecturally. >In this respect, I guess you could all the 6502 a "RISC" chip. No, the term "RISC" has more specific meaning than simply "puny", as I remarked previously. >At the time, the 6502, indeed, was considered the most CISC-like architecture >around. At the time, the labels "RISC" and "CISC" were not yet introduced. When the distinction started being commonly made, the most usual examples of CISC were the VAX-11 and MC68000 architectures.
rhyde@ucrmath.ucr.edu (randy hyde) (09/30/90)
I don't want to get started on a flame thrower war here, but a few of your comments deserve response: >> This history is bogus.. What is bogus about it? Of course the 6800 was a knock-off of the 6800. The designers who formed MOS Technologies defected from Motorola. But the 6502 introduced many new memory addressing modes (including true indexed addressing modes) which made it easier to program. >> RISC architectures are specifically designed to facilitate compiler code generation... Talk about bogus! RISC instruction sets are designed to execute fast. Period. Yes, they threw out addressing modes and instructions which have no need in HLL processing. They did not make the instruction sets easier to deal with for compiler designers. The National 32000 family is much easier to write compilers for than any RISC architecture I know of, yet it is the epitome of CISC. If you don't have a highly optimizing compiler, RISC performance is not very good. >> The term "RISC" has more specific meaning... To you, obviously. If you ask 100 different people what RISC means, you'll get 100 different answers. No one really has a good definition concerning RISC. I generally stick to many registers and a load/store architecture. That's the only definition that covers everything currently being called RISC. The 65xxx is definitely not a RISC chip under this definition. >> At the time the labels "RISC" and "CISC" where not yet introduced. No, back then "similar to the PDP-11" was what people used when they wanted to describe what we call a CISC chip today. The 6800 and 6502 were definitely referred to as "PDP-11 like" as opposed to the 8080 which most people called brain-dead. As an aside, Bill Mensch, designer of the 65c816 is attempting to market his new chips as Mr. RISC (maximum/minimum register RISC). This is total hyperbole. The '816 and '832 chips are not RISC by anyone's definition. Simple, yes. RISC, no. *** Randy Hyde O-)
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/01/90)
In article <8977@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >No, back then "similar to the PDP-11" was what people used when they wanted >to describe what we call a CISC chip today. The 6800 and 6502 were definitely >referred to as "PDP-11 like" as opposed to the 8080 which most people called >brain-dead. The 68000, not 6800, was PDP-11 like. The PDP-11, one of the all-time great computer architectures, was a "general register" machine with orthogonal addressing modes. One of its innovations was that general register # 7 was used as the PC and general register # 6 was used as the SP; thus the generic address modes available for all registers were also useful for manipulating PC and SP (although there were some special PC-only instructions too). In contrast, the DG Nova, 6800, 6502, PDP-8, DDP-516, CDC 1700, and other minis/micros of the same era were all "accumulator" machines. The one exception I know of was TI's 990, which used "register windows" in memory, a slick idea that is near what some RISC architectures now do. Certainly none of those CPUs should be thought of as "RISC"; the current thread of RISC evolution began with research at UCB and elsewhere and the first commercial RISC system in this thread was probably Pyramid's. It certainly is part of the whole package of ideas known as "RISC" that one will program them in a higher-level language, not assembler, and the architecture must therefore be designed with compiler code generation foremost in mind. Contrast this with virtually all CISC designs, such as VAX and particularly the 6502, where it is obvious that the instruction-set architect assumed that one would be programming largely in assembler.
rhyde@koufax.ucr.edu (randy hyde) (10/02/90)
Chuck Peddle himself made this comment about the 6502 (PDP-11 like). If you remember that far back, surely you know who Chuck Peddle is. When they designed the 6502, they didn't have the technology to put a PDP on a single chip. The 6502 was much closer to the ideals of the 6502 than its predecessors. The 68000 came out *FOUR* years later. Of course it's better. The 6502 was great at the time. Personally, I feel that this discussion is beginning to border on animosity. If you want to continue, send it via E-MAIL. There's no need to let tempers flair on the network (At least *I* refuse to stoop so low or get too involved in such a discussion on everyone else's time). So if you want to discuss it, E-MAIL me. Let's not bore everyone else to tears. *** Randy Hyde
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/02/90)
cromwell@acsu.buffalo.edu (mark j cromwell) writes: >In article <8139.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >>In-Reply-To: message from herwin@pro-novapple.cts.com > The 65x02 aren't RISC processors. They're accumulator microprocessors. This is a fine point. 65x02's have many features that are commonplace on RISC CPUs of today, such as a load/store architecture and fast, simple instructions. They also use an elementary form of pipelining but that is not exploited as much as it could be. However modern RISC CPUs have a lot of features that the 65x02 do not have, such as wide data busses and lots of registers. My favorite quote on the issue is "the 6502 tried to be a RISC before we knew what RISC meant." Todd Whitesel toddpw @ tybalt.caltech.edu
scottg@gnh-starport.cts.com (Scott Gentry) (10/02/90)
The 65x series is not RISC by long shot. By definition, RISC computers, apart from having a load/store architecture, execute most if not all instructions in one machine cycle. _______________________________________________________________________________ | Scott Gentry * ALPE AFL Scott * I never said that!| | 2051 Mercator Drive * GEnie W.GENTRY * But you never | | Reston, VA 22091 * UUCP: uunet!ingr!ne1300! * know! | | (703) 264-5652 * brnded!scott * Do You? | |_____________________________________________________________________________|
dcw@lcs.mit.edu (David C. Whitney) (10/02/90)
In article <0093D934263990A0.00000110@dcs.simpact.com> scottg@gnh-starport.cts.com (Scott Gentry) writes: >The 65x series is not RISC by long shot. By definition, RISC computers, apart >from having a load/store architecture, execute most if not all instructions in >one machine cycle. That's not really true. The throughput is roughly 1 instruction/cycle, but the latency is still 5-6 cycles/instruction. It's called pipelining, and the processor can be working on 5-6 instructions at the same time. While it's fetching the instruction of number 6, it's decoding number 5, fetching data on #4, executing #3, storing the result of #2, and incrementing the PC. This gets to be awfully hairy in jumping/branching, as the instruction queue has to be flushed. Also, compares have to be done before it seems logically correct to do them. For those who said RISC are designed for compilers and CISC are not, you've got it wrong. CISC are great for assembly level programming and for compilers, as they have neat instructions like MULT and ARRAYREF and crud. RISC processors do not, and because of the pipelining issue, one could go insane trying to write assembly-level code for it. Compilers MUST be written for RISC machines, and they're HARD to write. Once written correctly, though, the thing is mighty efficient, and the code runs super-duper. So, in one sense, the 6502 is RISC because its instruction set is so simple. On the other hand, it is CISC, as it is not pipelined to the extent that it's impossible to program at the assembly level. Here's an Example!! This code is the C compiler output on a Sun SPARC. A SPARC is a RISC processor. Here's the C code: main() { int i; for (i=0;i<100;i++); } Here's the SPARC code: LL0: .seg "data" .seg "text" .proc 04 .global _main _main: !#PROLOGUE# 0 ; this is all C procedure stack management sethi %hi(LF12),%g1 add %g1,%lo(LF12),%g1 save %sp,%g1,%sp !#PROLOGUE# 1 st %g0,[%fp+-0x4] ; store 0 in i L16: ld [%fp+-0x4],%o0 ; load i into a reg cmp %o0,0x64 ; compare to 0 bge L15 ; if >=, goto L15 nop ; wait L14: ld [%fp+-0x4],%o1 ; load i into another reg add %o1,0x1,%o1 ; add 1 to the reg st %o1,[%fp+-0x4] ; store the reg back in i b L16 ; goto L16 nop ; wait (this is here so it doesn't L15: ; grab the next instruction) LE12: ret ; return restore LF12 = -72 LP12 = 64 LST12 = 64 LT12 = 64 .seg "data" on the 6502, it would be: ldx #$00 loop inx cpx #$64 blt loop rts Much easier to read and to program because the pipeline isn't an issue. Now, back to your regularly scheduled Apple //-talking... -- Dave Whitney | I wrote Z-Link and BinSCII. Send me bug Computer Science MIT 1990 | reports. I need a job. Send me an offer. dcw@goldilocks.lcs.mit.edu | My opinions, you hear? MINE! dcw@athena.mit.edu | "...we came in?"
rhyde@berra.ucr.edu (randy hyde) (10/03/90)
>>> The 6502 tried to be a RISC before we knew what RISC meant...
Actually, the 6502 was trying to be a CISC before we knew what CISC meant!
You're comparing the instruction set of yesterday against todays instruction
sets and coming to the conclusion that the 6502 is a reduced instruction
set. Actually, they did reduce the number of instructions over its
contemporaries, but they did so be increasing the complexity of each
instruction (by adding lots of addressing modes). BTW, the 6502 is *NOT*
a load/store architecture. Load/store architectures only give the move
instructions (loads and stores) access to memory. The 6502 was fairly
generous about letting most applicable instructions access memory.cyliao@hardy.u.washington.edu (Chun-Yao Liao) (10/03/90)
In article <8139.apple.net@pro-angmar> m.tiernan@pro-angmar.UUCP (Michael Tiernan) writes: >I doubt that Apple is going to be releasing any more RISC machines, the ones >that they have they aren't supporting. (Opinion that is changing slowly) >What RISC machines you say? How about the original, 65?02 based processors? ^^^^^^^^^^^^^^^^^^^^^^^ I remember a while back, there was a discussion about the Achimee chipset which has a "superset" instructions of original 6502. Maybe this one helps? BTW, the chip set consistes graphic processor I believe, and gives some thing like 5 MIPS -10 MIPS... I don't remember very well. Anyone knows anything about this chipset? These are now made by VLSI. cyliao@wam.umd.edu o NeXT : I put main frame power on two chips. @epsl.umd.edu o people: We put main flame power on two guys. @bagend.eng.umd.edu o :::::::::::::::::::::::::::::::::::::::::::: xxxxx@xxxxx.xxx.xxx (reserved) o RC + Apple // + Classic Music + NeXT = cyliao
herwin@pro-novapple.cts.com (Harry Erwin) (10/03/90)
In-Reply-To: message from toddpw@tybalt.caltech.edu The first real RISC machine was the CDC Cyber 7600. Look it up. Harry Erwin -->Remember, no good deed goes unpunished... proline:pro-novapple!herwin uucp: crash!pro-novapple!herwin arpa: crash!pro-novapple!herwin@nosc.mil Telenet: herwin/trw Internet: herwin@pro-novapple.cts.com alternate Internet: /PN=Harry.Erwin/O=TRW/ADMD=Telemail/C=US/@Sprint.com
herwin@pro-novapple.cts.com (Harry Erwin) (10/03/90)
In-Reply-To: message from scottg@gnh-starport.cts.com >By definition, RISC computers, apart from having a load/store architecture, >execute most if not call instructions in one machine cycle. Not quite the case. RISC computers typically have a pipelining architecture that allows them to execute an instruction per cycle. Very few reach that rate except in carefully hand-coded software. Most do quite a bit worse in most applications. Harry Erwin -->Remember, no good deed goes unpunished... proline:pro-novapple!herwin uucp: crash!pro-novapple!herwin arpa: crash!pro-novapple!herwin@nosc.mil Telenet: herwin/trw Internet: herwin@pro-novapple.cts.com alternate Internet: /PN=Harry.Erwin/O=TRW/ADMD=Telemail/C=US/@Sprint.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/04/90)
In article <1990Oct2.155706.16241@mintaka.lcs.mit.edu> dcw@lcs.mit.edu (David C. Whitney) writes: >For those who said RISC are designed for compilers and CISC are not, >you've got it wrong. CISC are great for assembly level programming and >for compilers, as they have neat instructions like MULT and ARRAYREF >and crud. RISC processors do not, and because of the pipelining issue, >one could go insane trying to write assembly-level code for it. >Compilers MUST be written for RISC machines, and they're HARD to >write. Once written correctly, though, the thing is mighty efficient, >and the code runs super-duper. For code generation, availability of fancy instructions is not nearly as important as regularity of the instruction set architecture. It is quite difficult to cope with addressing modes that can be used with only a subset of the general data-manipulation operations, for example. This is the worst aspect of the 6502's compact opcode design, from the point of view of a compiler writer. >Here's an Example!! This code is the C compiler output on a Sun SPARC. > st %g0,[%fp+-0x4] ; store 0 in i >L16: > ld [%fp+-0x4],%o0 ; load i into a reg > cmp %o0,0x64 ; compare to 0 > bge L15 ; if >=, goto L15 > nop ; wait >L14: > ld [%fp+-0x4],%o1 ; load i into another reg > add %o1,0x1,%o1 ; add 1 to the reg > st %o1,[%fp+-0x4] ; store the reg back in i > b L16 ; goto L16 > nop ; wait (this is here so it doesn't >on the 6502, it would be: > ldx #$00 >loop inx > cpx #$64 > blt loop > rts And on a MIPS it's: # 5 for (i=0;i<100;i++); sw $0, 4($sp) $32: lw $14, 4($sp) addu $15, $14, 1 sw $15, 4($sp) blt $15, 100, $32 However, you are "comparing apples and oranges". In fact, C compilers for the 6502 are not going to generate the sequence that you exhibit. Your 6502 code is not functionally equivalent to the others, because it does not maintain the value of a memory-based variable `i' like the others. Having recently disassembled a fair amount of 6502 code output by ORCA/C, I can attest the the rather horrible convolutions that were found to be generally necessary to correctly implement the full C semantics. The RISC version is much simpler. Note that (for MIPS at least), every elementary instruction implements directly a necessary step in the logical decomposition of the C source code semantics. This is a highly desirable property when you're designing a code generator.
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/04/90)
In article <14007@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >However, you are "comparing apples and oranges". In fact, C compilers >for the 6502 are not going to generate the sequence that you exhibit. Indeed, here is the output for the 65816 from APW C: stz $EE ;i = 0; bra L0011 L000F inc $EE ;++i; L0011 lda $EE sec sbc #$0064 bvs L001C eor #$8000 L001C bpl L000F ;if ( i < 100 ) continue; And from ORCA/C: lda #$0000 sta $07 ;i = 0; L01000D lda $07 bmi L010016 L010011 cmp #$0064 bcs L01001A ;if ( !(i < 100) ) break; L010016 inc $07 ;++i; bra L01000D ;continue; L01001A ... Note that these are no improvement over the code on a RISC machine. (In all cases I omitted the function entry/exit code, used to allocate space for autos on the stack, set the DBR for ORCA/C code, etc.)
rhyde@ucrmath.ucr.edu (randy hyde) (10/04/90)
>> Apples and oranges (RISC vs. CISC) "C" code.
Throwing out code (this is a warning to both sides of this arguement)
proves nothing. First we had someone comparing the output of a
C compiler on the SPARC against hand written 6502 code. Now we're
comparing SPARC code against ORCA C output. None of this is particularly
valid.
1) The SPARC C compiler is a highly optimizing compiler (all RISC compilers
have to be optimizing or the generated code would really suck).
2) ORCA/C is not very good at straight code generation, much less optimiz-
ation. Therefore, comparing the outputs of two compilers to show how
the 6502 is better than the SPARC (or vice versa) is a worthless
exercise. All you're showing is that Sun's compiler is better than
Byteworks'. I don't think anyone argues this point.
3) Comparing assembly language code isn't particularly valid either.
I know of no one who writes in SPARC assembly code. I'm sure there
are such creatures, but they are few and far inbetween. Lots of people,
however, write in 6502/65816 assembly language. This, BTW, is a point
in favor of comparing 6502 assembly against the output of a SPARC C
compiler.
4) Comparing 6502 assembly against SPARC anything does not show that the
6502 is CISC or RISC. It simply demonstrates that the 6502 has a
different architecture. If you compared SPARC against 29000, MIPS 3000,
or the Transputer, you could reach similar conclusions to comparing
6502 against SPARC (okay, so I'm stretching it a little here).
Having talked to some other individuals on BIX (who are a little more up on
the subject than I), here's the conclusion I've come to concerning RISC.
RISC stands for (REDUCED INSTRUCTION) Set Computer; not (REDUCED INSTRUCTION
SET) Computer. A RISC machine does not necessarily have a small number
of instructions (RIS)C, although most do. Instead, the activities performed
by the CPU for each instruction are limited, i.e., each individual instruction
is reduced to the bare minimum (i.e., (RI)SC). If you view an arithmetic or
logical operation as one operation, and accessing memory as one operation, then
a typical 6502 instruction like ADD ABS requires two operations: (1) accessing
memory to get the value, and (2) adding this value to Acc. A RISC architecture
only allows (in the pure sense) one operation. That's why they have a
load/store architecture. You load ABS into a register (one operation) and
then ADD that register to Acc (the second operation). By this definition
the 6502 fails miserably as a RISC. Only about 1/2 of the instructions
are single operation instructions (about the same as the 8086, I might
point out).
*** Randy Hyde
Hopefully, this helps put the "6502 as RISC" question to bed.
Flame all you want, but raising your voice does not change the truth.