barry@pico.math.ucla.edu (Barry Merriman) (10/10/90)
Those dissapointed by the lack of media converage of the big NeXT unveiling last month should note Time (or one of its clones) had a little blurb on it last week. However, it wasn't positive---they accused Steve of hawking vapor, saying he currently has no 040 CPUs in the pipeline, and that Improv is months away from completion. Say it ain't so, Steve!? -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet)
mcguire@cs.tamu.edu (Tim McGuire) (10/11/90)
barry@pico.math.ucla.edu (Barry Merriman) writes: >Those dissapointed by the lack of media converage of the big NeXT >unveiling last month should note Time (or one of its clones) >had a little blurb on it last week. >However, it wasn't positive---they accused Steve of hawking vapor, >saying he currently has no 040 CPUs in the pipeline, and that >Improv is months away from completion. >-- >Barry Merriman I haven't see the article mentioned, but my sources (who are NeXT PR people, so you can color that any way you wish) say that NeXT has enough '040s for their immediate needs. They tell me that the first large batch of 68040s had a bug which did not affect any of the NeXT software because mach does not use the affected opcode. This bug does sink most of the other companies who would use the 40. So NeXT took delivery of the entire batch and can thus release an 040 machine well ahead of everyone else. Someone who doesn't know the above, but does know that no 040s are shipping could make the accusation you mentioned. I have know knowledge of Improv other than I saw a NeXT rep running it and was impressed. If anyone knows more than I do about this, feel free to correct me. Tim McGuire mcguire@cs.tamu.edu
madler@piglet.caltech.edu (Mark Adler) (10/11/90)
WHAT?! You mean I'm going to be getting an 040 with a bug? INTENTIONALLY?? I don't like the sound of this at all. Mark Adler madler@piglet.caltech.edu
mcguire@cs.tamu.edu (Tim McGuire) (10/11/90)
Fellow NeXTer madler@piglet.caltech.edu (Mark Adler) writes: > >WHAT?! You mean I'm going to be getting an 040 with a bug? INTENTIONALLY?? >I don't like the sound of this at all. > I've been sitting on this info (rumor??? lie????) for over two weeks now, waiting to see if someone would bring it up. No one has, so I decided to test the waters. I don't know any more than what I originally stated. IMHO, a bug in a processor is somewhat disconcerting, but if everyone involved was aware of what not to do to set it off, when doing low level stuff, then it might not be so bad. Can anyone give us more info? Am I the only one who has heard this? Were my allergy pills reacting with the pizza I had the night before? ;-) Tim McGuire mcguire@cs.tamu.edu
bin@primate.wisc.edu (Brain in Neutral) (10/11/90)
From article <8969@helios.TAMU.EDU>, by mcguire@cs.tamu.edu (Tim McGuire): > They tell me that the first large batch of 68040s had a bug which did not > affect any of the NeXT software because mach does not use the affected > opcode. This bug does sink most of the other companies who would use the 40. > So NeXT took delivery of the entire batch and can thus release an 040 machine > well ahead of everyone else. Hmm, maybe Mach itself doesn't use the opcode, but what's to stop *any* piece of application software from using it - and crashing? -- Paul DuBois dubois@primate.wisc.edu "Was all of this because I wore a big man's hat?"
keithp@xavier.tamu.edu (Keith D Perkins) (10/12/90)
>I haven't see the article mentioned, but my sources (who are NeXT PR people, >so you can color that any way you wish) say that NeXT has enough '040s for >their immediate needs. >They tell me that the first large batch of 68040s had a bug which did not >affect any of the NeXT software because mach does not use the affected >opcode. This bug does sink most of the other companies who would use the 40. >So NeXT took delivery of the entire batch and can thus release an 040 machine >well ahead of everyone else. I don't think anybody will be getting bad 68040 chips. I hazzard a guess that NeXT was able to start developing on the 68040 much ealier than everyone else because they could use the bad chips. As I see it, NeXT still waited for Motorola to start shipping the chips in volume before they started shipping their machines, so its likely that the bad chips were only in the development platforms running at NeXT Corp.. After all that NeXT has done to get these machines on the market, it would be real doubtful that they would have overlooked something this basic. Keith Perkins Texas A&M University
mikel@Apple.COM (Mikel Evins) (10/12/90)
In article <8978@helios.TAMU.EDU> mcguire@cs.tamu.edu (Tim McGuire) writes: >Fellow NeXTer madler@piglet.caltech.edu (Mark Adler) writes: >> >>WHAT?! You mean I'm going to be getting an 040 with a bug? INTENTIONALLY?? >>I don't like the sound of this at all. ... >IMHO, a bug in a processor is somewhat disconcerting, but if everyone involved >was aware of what not to do to set it off, when doing low level stuff, then >it might not be so bad. I hope this is not true. If it were, then presumably at some point NeXT machines would be coming out without the bug in silicon. At that point it becomes possible that a programmer who doesn't have the bug will write some useful software that uses the affected op-code, and, of course, that software would not function properly on machines with the bug.
moose@svc.portal.com (10/12/90)
In article <1990Oct10.232037.8263@nntp-server.caltech.edu> madler@piglet.caltech.edu (Mark Adler) writes: > >WHAT?! You mean I'm going to be getting an 040 with a bug? INTENTIONALLY?? >I don't like the sound of this at all. Having done some work one the '040 machines (not much, but that is soon to change (I hope :->)), I must tell you that you are getting worked up over nothing at all. The machine is fine. It runs fine. It runs fast. It is fun to use. It did not crash on me. It did not break my software. It is fine. It is ok. Are you getting my point? -- Michael Rutman | moose@svc.portal.com Cubist | makes me a NeXT programmer Software Ventures | That's in Berkeley smile, you're on standard disclaimer | <fill in with cute saying>
peb@Autodesk.COM (Paul Baclaski) (10/12/90)
In article <8969@helios.TAMU.EDU>, mcguire@cs.tamu.edu (Tim McGuire) writes: > They tell me that the first large batch of 68040s had a bug which did not > affect any of the NeXT software because mach does not use the affected > opcode. This bug does sink most of the other companies who would use the 40. > So NeXT took delivery of the entire batch and can thus release an 040 machine > well ahead of everyone else. Hmmm, I would want a free replacement 040 in the future--you never know when you might be using a compiler that used it... Paul E. Baclaski peb@autodesk.com
galanter@casbah.acns.nwu.edu (Philip Galanter) (10/12/90)
>>They tell me that the first large batch of 68040s had a bug which did not >>affect any of the NeXT software because mach does not use the affected >>opcode. This bug does sink most of the other companies who would use the 40. >>So NeXT took delivery of the entire batch and can thus release an 040 machine >>well ahead of everyone else. I have heard this form various NeXT folks as well, but it sure sounds goofy. So what instruction could possibly be so expendable, by NeXT _and_ any other developer/development system/compiler? Maybe some kind of low level thing that _only_ the OS should be dealing with, like virtual memory paging or something? Anybody out there from NeXT have the technical info that would help the above make sense? Thanks, Phil ============================================================================== Academic Computing & Network Services ~ AppleLink: A42 ~ ~ 627 Dartmouth Place ~ ~Advanced Technology Group Manager ~ galanter@nwu.edu ~ ~ Evanston, IL 60208 ~ ~ ~ ~ ~Northwestern University ~ ~CompuServe: 76474,154 ~ fax: 708-491-4548 ~ ~ ~ ~ ~ ~ ~ Philip Galanter~ ~ ~ NeXT>gambuh.acns.nwu.edu ~ ph: 708-491-4050 ==============================================================================
mcguire@cs.tamu.edu (Tim McGuire) (10/12/90)
In article <332@casbah.acns.nwu.edu> galanter@casbah.acns.nwu.edu (Philip Galanter) writes: >>>They tell me that the first large batch of 68040s had a bug which did not >>>affect any of the NeXT software because mach does not use the affected >>>opcode. > >I have heard this form various NeXT folks as well, but it sure sounds goofy. >So what instruction could possibly be so expendable, by NeXT _and_ any other >developer/development system/compiler? Maybe some kind of low level thing >that _only_ the OS should be dealing with, like virtual memory paging or >something? Anybody out there from NeXT have the technical info that would >help the above make sense? I started this panic, so let me see if I can calm it down some. I still haven't heard what the problem is exactly, so I may be wrong, but let me give you the following scenario: Many moons ago, person X had a machine with a Z80 cpu. This chip had a very nice set of opcodes for port i/o. But X's machine didn't use them, since it had *memory mapped* i/o. I assume that the only way the port opcodes would be necessary is if X changed the cpu over to another motherboard. So, it the bug in question only affects hardware that the NeXT (due to its architecture) will never use, there will be no problem unless you plan on pulling the cpu chip and putting it in some other machine. Now, does this sound reasonable? Tim McGuire mcguire@cs.tamu.edu
daugher@cs.tamu.edu (Dr. Walter C. Daugherity) (10/13/90)
In article <3258@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >From article <8969@helios.TAMU.EDU>, by mcguire@cs.tamu.edu (Tim McGuire): >> They tell me that the first large batch of 68040s had a bug which did not >> affect any of the NeXT software because mach does not use the affected >> opcode. This bug does sink most of the other companies who would use the 40. >> So NeXT took delivery of the entire batch and can thus release an 040 machine >> well ahead of everyone else. > >Hmm, maybe Mach itself doesn't use the opcode, but what's to stop *any* >piece of application software from using it - and crashing? >-- >Paul DuBois >dubois@primate.wisc.edu > > "Was all of this because I wore a big man's hat?" The main reason software developers won't use any buggy 68040 instructions which aren't on the 68030 is that they will want as large a market as possible. Thus they should use 68030 instructions only so they can sell their wares to run on old or new NeXT's. (Listen up, you budding software entrepreneurs :-).) Nevertheless, IMHO NeXT is most likely to wait and ship clean 68040's. They really don't need to give their critics any ammunition, however irrelevant (see above). ------------------------------------------------------------------------------- Walter C. Daugherity Internet, NeXTmail: daugher@cs.tamu.edu Knowledge Systems Research Center uucp: uunet!cs.tamu.edu!daugher Texas A & M University BITNET: DAUGHER@TAMVENUS College Station, TX 77843-3112 CSNET: daugher%cs.tamu.edu@RELAY.CS.NET ---Not an official document of Texas A&M---
rca@cs.brown.edu (Ronald C.F. Antony) (10/13/90)
In article <3258@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >From article <8969@helios.TAMU.EDU>, by mcguire@cs.tamu.edu (Tim McGuire): >> They tell me that the first large batch of 68040s had a bug which did not >> affect any of the NeXT software because mach does not use the affected >> opcode. This bug does sink most of the other companies who would use the 40. >Hmm, maybe Mach itself doesn't use the opcode, but what's to stop *any* >piece of application software from using it - and crashing? There are two modes the processor can be running in: one is the supervisor mode and the other is the user mode. Applications can only use user mode instructions. Only the kernel is allowed to use the priviledged instructions. So if the bug is in the supervisor mode instruction set and MACH doesn't use it and you don't plan to implement your own operating system on top of NeXT's hardware, there shouldn't be any problem at all. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Bernhard Shaw | rca@cs.brown.edu or antony@browncog.bitnet
henry@zoo.toronto.edu (Henry Spencer) (10/14/90)
In article <1990Oct11.173420.2020@svc.portal.com> moose@svc.portal.com writes: >... The machine is fine. It runs fine. It runs fast. It is >fun to use. It did not crash on me. It did not break my software. It is >fine. It is ok. Are you getting my point? What's your point? That you've tested it and it works fine? That's what every software/hardware developer says, and most of them are telling the truth, despite all the bugs that show up later. All you're telling us is that the thing will work when used *exactly* the way you used it. That is some assurance that the thing is not totally broken, but most companies wouldn't ship totally-broken systems anyway. (There are exceptions.) It doesn't tell us anything about problems lurking in obscure corners. Realistically, folks, the odds are good that there is at least one bug in the 68040 that *nobody* knows about yet. You simply can't buy a machine built with a leading-edge part like that without some risk of hardware bugs. -- "...the i860 is a wonderful source | Henry Spencer at U of Toronto Zoology of thesis topics." --Preston Briggs | henry@zoo.toronto.edu utzoo!henry
shwake@raysnec.UUCP (Ray Shwake) (10/16/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >Realistically, folks, the odds are good that there is at least one bug in >the 68040 that *nobody* knows about yet. You simply can't buy a machine >built with a leading-edge part like that without some risk of hardware bugs. Ah, but the same thing could be said about the Intel 486, the latest Sparc or MIPS set, the IBM RS set, etc. (I assume Henry wasn't speaking only about the latest Moto.)