Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!psuvax1!news From: melling@cs.psu.edu (Michael D Mellinger) Newsgroups: comp.sys.next Subject: Re: What NeXT *should* do next. Message-ID: Date: 24 Mar 90 07:24:47 GMT References: <1378@shelby.Stanford.EDU> <9967@batcomputer.tn.cornell.edu> <424@toaster.SFSU.EDU> <35@isl.stanford.edu> Sender: news@cs.psu.edu (Usenet) Organization: Penn State University Computer Science Lines: 50 In-Reply-To: awang@isl.Stanford.EDU's message of 24 Mar 90 05:51:54 GMT In article <35@isl.stanford.edu> awang@isl.Stanford.EDU (Avery Wang) writes: In article melling@cs.psu.edu (Michael D Mellinger) writes: >answer(they're betting their futures on it). The MIPS R4000 is >suppose to execute 50mips at 25Mhz. That's performance!! And what is ^^^^^^^^^^^^^^^ So that's one instructions per half cycle. How can this be? Is the MIPS R4000 some sort of multiprocessor? How does it handle conditional branching? -Avery No that's 2 instructions per cycle! By putting more functional units (integer, FPU...) on a microprocessor and running them in parallel more work can be done. The Intel 860 and the ROMP II in the new IBM/6000 employ these techniques. Branching can be handled by putting an instruction after the branch that will be execute irregardless of whether the branch is taken or not. That way the micro. always has something to do. This is not the only way branches are handled. I think the 68040(RISCish) assumes that the branch will be taken and executes the next instruction hoping the branch will be taken and throws away the result if it isn't. The architecture people are playing all kinds of games. Steve, and company, got to throw away the Mac(old technology) and start over again to come up with something pretty great. You can do this if you don't have to worry about compatibility. The 68040 must also be compatible so it had to be evolutionary. You just can't throw out instructions to gain performance and to save silicon if your chip already has an installed base of millions. Wouldn't it be better if NeXT used a microprocessor that has its origins in the mid 80's instead of the late 70's (??). If a faster micro. is used then less optimization(read assembly programming) of programs is needed and software developers can spend more time adding functionality to their wares. Also, this means that NeXT can change micro. every couple of years without having to worry about losing its software base; it can ported in days instead of months. Software, software and software are the three biggest problems for any new platform. OS/2, NeXT, Unix(that old new standard(s)) are in a race. Whoever wins this software race wins the big bucks and survives the next five years. How about it? Should NeXT go with the micro. that will run at 50 mips at 25Mhz(extrapolating: 100mips at 50Mhz.) or the 68040 running at 50Mhz(~50 mips?)? -Mike