umh@vax5.cit.cornell.edu (05/14/91)
Much as we all hate intel processors, it's always interesting to see what new perversions they come up with. Does anyone know what will make the 586 different from a 486? Will it be just like 386->486, so some more cache and a little faster, or is there more to it than that? While we're on the subject, how about the 68050? Maynard Handley
melling@cs.psu.edu (Michael D Mellinger) (05/15/91)
In article <1991May14.002130.4740@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes:
Much as we all hate intel processors, it's always interesting to see what
new perversions they come up with. Does anyone know what will make the 586
different from a 486? Will it be just like 386->486, so some more cache and
a little faster, or is there more to it than that?
I think it's the MIPS R4000. :-)
-Mikemmm@cup.portal.com (Mark Robert Thorson) (05/15/91)
umh@vax5.cit.cornell.edu (Maynard Handley) says: >Much as we all hate intel processors, it's always interesting to see what >new perversions they come up with. Does anyone know what will make the 586 >different from a 486? Will it be just like 386->486, so some more cache and >a little faster, or is there more to it than that? Normally, Intel doesn't make their first announcement of new products on Usenet, but I've been granted permission to answer your questions in general terms. Although from the programmer's point of view the software model of the 586 is an upward-compatible superset of the 486, the underlying implementation is radically different, especially with regard to the cache. While the 486 has a unified instruction/data cache, the 586 has separate caches for the CS, SS, DS, ES, FS, and GS segments. Although this does not significantly accelerate code written for the "flat" model used by Unix and OS/2, more than 90% of all 86-family applications were written for an earlier model which encouraged programmers to divide their memory references into independent code, stack, and up to four data spaces. These programs will benefit enormously from the new "hex-cache" architecture. A novel method has been developed for reducing the cost of floating-point performance to the end user. Each 586 has 100 bytes of EPROM for storing passwords unique to each chip. When a user decides to upgrade to hardware floating point, he simply calls Intel and buys the password for enabling the on-chip FPU. Each password is good for 10 gigaflops, i.e. you get 10,000,000,000 floating point operations. (An 8-bit password is sufficient, because three consecutive failed password attempts permanently disables the FPU). When you buy your 100th password, the FPU becomes permanently enabled. This benefits the consumer because it allows him to buy exactly what he needs, rather than overspending on unused performance. It also cuts out the middleman, allowing the end-user to reap the cost savings of dealing directly with Intel. A new native machine model, based on the i860, will be used. Binary compatibility with existing operating system software will be preserved through the introduction of "virtual 386/486" mode, an execution mode in which the 586 emulates the current model. The pin configuration is footprint-compatible with the 486, however compatibility with existing sockets was sacrificed in order to introduce a new PGA package with 1 mm diameter pins. The higher conductivity of these pins is important for reducing on-chip power and ground noise. :-)
morse@quark.mpr.ca (Daryl Morse) (05/15/91)
In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: umh@vax5.cit.cornell.edu (Maynard Handley) says: >>Much as we all hate intel processors, it's always interesting to see what >>new perversions they come up with. Does anyone know what will make the 586 Is this guy psychic or what??? >A novel method has been developed for reducing the cost of floating-point >performance to the end user. Each 586 has 100 bytes of EPROM for >storing passwords unique to each chip. When a user decides to upgrade >to hardware floating point, he simply calls Intel and buys the password >for enabling the on-chip FPU. Each password is good for 10 gigaflops, >i.e. you get 10,000,000,000 floating point operations. (An 8-bit >password is sufficient, because three consecutive failed password attempts >permanently disables the FPU). When you buy your 100th password, the FPU >becomes permanently enabled. This benefits the consumer because it allows >him to buy exactly what he needs, rather than overspending on unused performance. >It also cuts out the middleman, allowing the end-user to reap the cost savings >of dealing directly with Intel. It's a darn good thing the military doesn't use Intel stuff for their digital flight control or weapons control systems. Can you imagine a pilot cranking through a 9G turn when a message appears on the screen saying "Please call Intel for your new FPU password". Or how about an Intel processor running a respirator? Imagine the anesthesiologist giving a patient a nudge, "Got a quarter, I have to phone Intel for some more FLOPS". Surely this isn't deja vu from April Fool's day? -- Daryl Morse | Voice : (604) 293-5476 MPR Teltech Ltd. | Fax : (604) 293-5787 8999 Nelson Way, Burnaby, BC | E-Mail: morse@quark.mpr.ca Canada, V5A 4B5 | quark.mpr.ca!morse@uunet.uu.net
kludge@grissom.larc.nasa.gov ( Scott Dorsey) (05/15/91)
In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >Although from the programmer's point of view the software model of the 586 >is an upward-compatible superset of the 486, the underlying implementation >is radically different, especially with regard to the cache. While the >486 has a unified instruction/data cache, the 586 has separate caches for >the CS, SS, DS, ES, FS, and GS segments... >A novel method has been developed for reducing the cost of floating-point >performance to the end user. Each 586 has 100 bytes of EPROM for >storing passwords unique to each chip. When a user decides to upgrade >to hardware floating point, he simply calls Intel and buys the password >for enabling the on-chip FPU... This is a joke, right? Please tell me that this is a joke. --scott
eric@oakhill.sps.mot.com (Eric Quintana) (05/15/91)
ward@vlsi.waterloo.edu (Paul Ward) writes: >In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >>A novel method has been developed for reducing the cost of floating-point >>performance to the end user. Each 586 has 100 bytes of EPROM for >>storing passwords unique to each chip. When a user decides to upgrade >>to hardware floating point, he simply calls Intel and buys the password >>for enabling the on-chip FPU. Each password is good for 10 gigaflops, >Novel !! I'll say. This is going to be a real winner. We'll sell you the >FPU, but you can't use it unless you pay us. No thanks. >BTW, don't give me this crap about it benefitting the end-user. It will cost >Intel EXACTLY the same amount to manufacture the chip, whether or not the >consumer uses the FPU. >Paul Ward Before this gets out of hand, PLEASE reread the original article. It sure looks like a joke to me (and very funny too). -- Eric Quintana eric@oakhill.sps.mot.com Motorola Microprocessor Design (512) 891-2915
gmc@Quotron.COM (Greg Christy) (05/15/91)
In <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >A novel method has been developed for reducing the cost of floating-point >performance to the end user. Each 586 has 100 bytes of EPROM for >storing passwords unique to each chip. When a user decides to upgrade >to hardware floating point, he simply calls Intel and buys the password >for enabling the on-chip FPU. Each password is good for 10 gigaflops, >i.e. you get 10,000,000,000 floating point operations. (An 8-bit >password is sufficient, because three consecutive failed password attempts >permanently disables the FPU). When you buy your 100th password, the FPU >becomes permanently enabled. This benefits the consumer because it allows >him to buy exactly what he needs, rather than overspending on unused performance. >It also cuts out the middleman, allowing the end-user to reap the cost savings >of dealing directly with Intel. Is there a slot on the chip for quarters? This also is a novel way for some virus program to permanently disable your FPU for you. A real benefit for the consumer. Thanks but no thanks. How about this novel concept: Charge a reasonable price for the chip and let the user use the FPU whenever he needs to? Greg
sef@kithrup.COM (Sean Eric Fagan) (05/16/91)
Yes, this thing is a *joke*. How to tell? Look: In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >umh@vax5.cit.cornell.edu (Maynard Handley) says: >While the >486 has a unified instruction/data cache, the 586 has separate caches for >the CS, SS, DS, ES, FS, and GS segments. Although this does not significantly >accelerate code written for the "flat" model used by Unix and OS/2, more than >90% of all 86-family applications were written for an earlier model which >encouraged programmers to divide their memory references into independent >code, stack, and up to four data spaces. These programs will benefit >enormously from the new "hex-cache" architecture. DOS and OS/2 programs don't *know* about the FS and GS segments. In addition, one would have to deal with self-modifying code (which is why the '486 has a single cache, I believe). And, of course, 8086 "segments" are really no such thing. Can we get back to something else now? Even unix-bashing would be more amusing... -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
wilson@schaefer.math.wisc.edu (Bob Wilson) (05/16/91)
>A novel method has been developed for reducing the cost of floating-point >performance to the end user. Each 586 has 100 bytes of EPROM for >storing passwords unique to each chip. When a user decides to upgrade >to hardware floating point, he simply calls Intel and buys the password >for enabling the on-chip FPU. Each password is good for 10 gigaflops, >i.e. you get 10,000,000,000 floating point operations. (An 8-bit >password is sufficient, because three consecutive failed password attempts >permanently disables the FPU). When you buy your 100th password, the FPU >becomes permanently enabled. This benefits the consumer because it allows >him to buy exactly what he needs, rather than overspending on unused performance. >It also cuts out the middleman, allowing the end-user to reap the cost savings >of dealing directly with Intel. I can't believe all the people who can't see a good joke! While some of the responses may themselves be intended to push the joke further, others seem clearly to have taken the original posting seriously! I thought it was clever, and made some neat points about how Intel DOES act, but let's quit wasting bandwidth flaming at something Intel HASN'T done. Bob Wilson
kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG) (05/16/91)
In article <1991May15.161816.22653@oakhill.sps.mot.com>, eric@oakhill.sps.mot.com (Eric Quintana) writes: |> |> Before this gets out of hand, PLEASE reread the original article. |> It sure looks like a joke to me (and very funny too). |> Spoilsport. We were having such a good time. ----------------------------------------------------------------------------- == jeff kenton Consulting at kenton@decvax.dec.com == == (617) 894-4508 (603) 881-0011 == -----------------------------------------------------------------------------
jfw@ksr.com (John F. Woods) (05/16/91)
eric@oakhill.sps.mot.com (Eric Quintana) writes: >>BTW, don't give me this crap about it benefitting the end-user. It will cost >>Intel EXACTLY the same amount to manufacture the chip, whether or not the >>consumer uses the FPU. >Before this gets out of hand, PLEASE reread the original article. >It sure looks like a joke to me (and very funny too). That's what convinces me it's real. ;-)
jb7m+@andrew.cmu.edu (Jon C. R. Bennett) (05/16/91)
Its a joke people, calm down :-) jon
hsu@eng.umd.edu (Dagwood splits the Atom) (05/16/91)
In article <1991May15.161816.22653@oakhill.sps.mot.com> eric@oakhill.sps.mot.com (Eric Quintana) writes: >ward@vlsi.waterloo.edu (Paul Ward) writes: >>In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >>>A novel method has been developed for reducing the cost of floating-point >>>performance to the end user. >>Novel !! I'll say. This is going to be a real winner. We'll sell you the >>FPU, but you can't use it unless you pay us. No thanks. >Before this gets out of hand, PLEASE reread the original article. >It sure looks like a joke to me (and very funny too). Why is this so funny? The most disturbing thing seems to me that except for the bit about 1mm pins and the passwords being in *E*PROM, it sounds entirely plausible. And what a terrific marketing idea, too, just the sort of thing the PC market would soak up. Heck, they love the Intel SX processors, don't they? And how do we know you're really from Motorola? Don't they all post from portal.com as well? :-) ahem, -dave -- David Hsu hsu@eng.umd.edu "I don't want to achieve immortality U of Md Systems Research Ctr through my work. I want to achieve College Park, Md 20742-3311 immortality through not dying." +1 301 405 3689 - Woody Allen
ian@argosy.UUCP (Ian L. Kaplan) (05/16/91)
In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >A novel method has been developed for reducing the cost of floating-point >performance to the end user. Each 586 has 100 bytes of EPROM for >storing passwords unique to each chip. When a user decides to upgrade >to hardware floating point, he simply calls Intel and buys the password >for enabling the on-chip FPU. Each password is good for 10 gigaflops, >i.e. you get 10,000,000,000 floating point operations. (An 8-bit >password is sufficient, because three consecutive failed password attempts >permanently disables the FPU). When you buy your 100th password, the FPU >becomes permanently enabled. This benefits the consumer because it allows >him to buy exactly what he needs, rather than overspending on unused performance. >It also cuts out the middleman, allowing the end-user to reap the cost savings >of dealing directly with Intel. I note that this article is posted from Portal, not an iNTEL address, by someone claiming to have knowledge and permission to discuss the 586 "in general terms". However, the above paragraph strikes me as so bizzare that it makes me wonder if this is not just a subtle joke by an iNTEL basher (and, as other posters have noted, there are many of these) who, in his fevered mind, has come up with something even more baroque than then 486 architecture. If so, I appluad the creativity shown. However, the world is a strange place and the notions that run through the heads of marketing and sales people can sometimes be astounding. Perhaps iNTEL has had so much success that they think they own the market, which has caused them to loose touch with reality. I personally cannot imagine this scheme of applying to iNTEL for a password to use the floating point portion of the chip I already own. Especially since I have to get one every 10GFLOPS. I don't think that 10GFLOPS is really that much computation (at least not where I come from, he says with a Texas drawl) and I am going to be pretty steamed if after 6 months my computer starts doing floating point in software (or not at all) because my "floating point allocation" has run out. I then have to fork over more money to iNTEL until I completely buy the "floating point capability" on the instalment plan. Rather than deal with this absurdity, I will buy a computer based on a MIPS chip, a SPARC or even, horrors, the 680xx. I really hope that iNTEL attempts to implement this scheme (assuming that this is not a joke), because it will hasten the movement away from iNTEL processors. Many vendors are complaining about the greed iNTEL has shown in chip pricing. This wierd scheme will fan the complaints into rage. Especially when you consider that other chip vendors will provide high performance floating point support with out all this bother and extra cost. So, if this was satire, I am at least partially taken in. If it is for real, all I can say to iNTEL is GO FOR IT! I will buy stock in MIPS. Ian Kaplan ian@maspar.com I think that it should be obvious that I speak only for myself, not MasPar Computer Corp.
ckp@grebyn.com (Checkpoint Technologies) (05/16/91)
In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >umh@vax5.cit.cornell.edu (Maynard Handley) says: > >>Much as we all hate intel processors, it's always interesting to see what >>new perversions they come up with. Does anyone know what will make the 586 >>different from a 486? Will it be just like 386->486, so some more cache and >>a little faster, or is there more to it than that? > >Normally, Intel doesn't make their first announcement of new products on >Usenet, but I've been granted permission to answer your questions in >general terms. [ answers deleted ] I think you should have had more smileys on this. :-) :-) :-) I suspect too many readers will miss the one you put. -- Richard Krehbiel, private citizen ckp@grebyn.com (Who needs a fancy .signature?)
jap@convex.cl.msu.edu (Joe Porkka) (05/16/91)
mmm@cup.portal.com (Mark Robert Thorson) writes: >umh@vax5.cit.cornell.edu (Maynard Handley) says: > >>Much as we all hate intel processors, it's always interesting to see what >>new perversions they come up with. Does anyone know what will make the 586 >>different from a 486? Will it be just like 386->486, so some more cache and >>a little faster, or is there more to it than that? > >Normally, Intel doesn't make their first announcement of new products on >Usenet, but I've been granted permission to answer your questions in >general terms. >A novel method has been developed for reducing the cost of floating-point >performance to the end user. Each 586 has 100 bytes of EPROM for >storing passwords unique to each chip. When a user decides to upgrade You *can't* be serious. Can you???? Iv'e never much liked Intel stuff but this really takes the cake.
mmm@cup.portal.com (Mark Robert Thorson) (05/16/91)
Gee, didn't you notice the smiley at the end? That was your signal not to take it seriously. Some people sure are cynical, especially with regard to Intel. They'd _never_ do something like what I described :-)
rbw00@ccc.amdahl.com ( 213 Richard Wilmot) (05/17/91)
In article <1991May14.002130.4740@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes: >Much as we all hate intel processors, it's always interesting to see what >new perversions they come up with. Does anyone know what will make the 586 >different from a 486? Will it be just like 386->486, so some more cache and >a little faster, or is there more to it than that? > May we hope that the 586 will be SELF-VIRTUALIZABLE so that I can run multiple different operating systems concurrently. >Maynard Handley -- Dick Wilmot | I declaim that Amdahl might disclaim any of my claims. (408) 746-6108
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (05/17/91)
>BTW, don't give me this crap about it benefitting the end-user. It will cost >Intel EXACTLY the same amount to manufacture the chip, whether or not the >consumer uses the FPU. This is not an accurate assessment. The manufacturing cost may be the same, but the cost of on-line support is lower if you don't support the FPU. Hopefully, a Motorola "spokesman" will shortly produce an equally amusing summary of the 68050.
uh311ae@sunmanager.lrz-muenchen.de (Henrik Klagges) (05/17/91)
morse@quark.mpr.ca (Daryl Morse) writes: >In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: > umh@vax5.cit.cornell.edu (Maynard Handley) says: >>>Much as we all hate intel processors, it's always interesting to see what >>>new perversions they come up with. Does anyone know what will make the 586 >Is this guy psychic or what??? No, he is not psychic. He is absolutely right. Cheers ! Rick@vee.lrz-muenchen.de
Michael.Marsden@newcastle.ac.uk (Michael Marsden) (05/17/91)
mmm@cup.portal.com (Mark Robert Thorson) writes: > [...] >A novel method has been developed for reducing the cost of floating-point >performance to the end user. Each 586 has 100 bytes of EPROM for >storing passwords unique to each chip. When a user decides to upgrade >to hardware floating point, he simply calls Intel and buys the password >for enabling the on-chip FPU. Each password is good for 10 gigaflops, >i.e. you get 10,000,000,000 floating point operations. (An 8-bit >password is sufficient, because three consecutive failed password attempts >permanently disables the FPU). When you buy your 100th password, the FPU ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A chip with THIS feature would make a very nice target for malicious virus code.... :-) ... not to mention the excitement it would lend to life-critical applications. Just imagine the entire [insert your favorite airline] fleet crashing simultaneously because they forgot to pay for the next 10 GFs! -Mike Mars PS sigh, and its not even the 1st of April...
chen@digital.sps.mot.com (Jinfu Chen) (05/17/91)
As much as I hate the marketing plot, the manufacture costs are not the same with or without a FPU/MMU. It may cost exactly the same in the wafer fab. However, Intel (or Moto for this matter) can save some cost in final testing by by-passing the FPU test suite.
bill@bilver.uucp (Bill Vermillion) (05/17/91)
In article <1991May15.172113.12392@schaefer.math.wisc.edu> wilson@math.wisc.edu (Bob Wilson) writes: >I can't believe all the people who can't see a good joke! While some >of the responses may themselves be intended to push the joke further, >others seem clearly to have taken the original posting seriously! I >thought it was clever, and made some neat points about how Intel DOES >act, but let's quit wasting bandwidth flaming at something Intel >HASN'T done. >Bob Wilson It WAS well written. Then I started sensing the joke with the "password" requirement. Seems that most people just totally overlooked the last paragraph. -------------------------------------------------------------------- The pin configuration is footprint-compatible with the 486, however compatibility with existing sockets was sacrificed in order to introduce a new PGA package with 1 mm diameter pins. The higher conductivity of these pins is important for reducing on-chip power and ground noise. :-) -------------------------------------------------------------------- That should have convinced almost anyone, if they had thought about it. And there was a smiley there too. -- Bill Vermillion - UUCP: ...!tarpit!bilver!bill : bill@bilver.UUCP
bygate@sst.Columbia.NCR.COM (Terrence A. Bygte) (05/18/91)
In article <1991May14.002130.4740@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes: >Much as we all hate intel processors, it's always interesting to see what >new perversions they come up with. Does anyone know what will make the 586 >different from a 486? Will it be just like 386->486, so some more cache and >a little faster, or is there more to it than that? > The latest version of the 'EE Times' (13 May 1991) has a short article on Intel 32-bit processors. The article talked about a number of items. As far as the 586 goes, I got the impression that they will keep a CISC instruction set with the underlying arch. being based on RISC principles. Gee, that sounds familiar 8-). -- Terrence A. Bygate 803-791-6826 | NCR E&M Columbia- NST Platform Development|After all, even a fool may be thought <Terry.Bygate@Columbia.NCR.COM> | wise and intelligent if he stays <...uunet!ncrlnk!ncrcae!terry.bygate> | quiet and keeps his mouth shut.
davidsen@yeti.crd.GE.COM (william E Davidsen) (05/18/91)
In article <a3Li023807T001@JUTS.ccc.amdahl.com>, rbw00@ccc.amdahl.com ( 213 Richard Wilmot) writes: |> May we hope that the 586 will be SELF-VIRTUALIZABLE so that I can run |> multiple different operating systems concurrently. The best info I've heard (on 386users mailing list of course) is that there will be two CPUs and one FPU, and the FPU will be shared when needed. The story going around is that someone at Intel asked what the best support for wandows would be: X or MS, and the answer was "a second CPU to run the damn window manager." It is not impossible that Intel took this to heart. I'm also told that the SCO MPX extension to run multiple CPUs on UNIX will run with this chip because it follows some set of rules for how additional CPUs should appear. I also hear that the cache is up to 32k.
sasebb@zen.unx.sas.com (Edmund Burnette) (05/18/91)
I enjoyed the responses to your post almost as much as the article itself. Very well done. I was willing to believe the first paragraph, so you had me going there for a while. Of course, you've got it all wrong. Instead of passwords, they have implemented a scheme that slowly reduces the clock speed. This gives a gradual reduction in performance as opposed to the sudden drop that occurred with the password scheme. After about a year of average use, the CPU will be running at an effective 1MHz rate. You can replace the chip with a new one, of course, or purchase a special recharging unit that snaps onto the chip, plugs into the wall, and increases the speed of the CPU at approximately 5MHz/hour. One drawback of this method is that if you don't let the CPU run all the way down, it keeps a "memory" of its previous level so it won't hold the speed as long. (Utilities are available to drain the CPU faster to eliminate this problem). :-) -- Edmund Burnette, SAS Institute Inc. (919)677-8000 | sasebb@unx.sas.com SAS Campus Drive, Cary, NC 27513 (919)677-8123(fax) | ...!mcnc!sas!sasebb
pkl@ee.mu.OZ.AU (Peter Kenneth LAWREY) (05/18/91)
In article <1991May15.132623.25795@vlsi.waterloo.edu> ward@vlsi.waterloo.edu (Paul Ward) writes: >In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >>(An 8-bit >>password is sufficient, because three consecutive failed password attempts >>permanently disables the FPU). When you buy your 100th password, the FPU >>becomes permanently enabled. This benefits the consumer because it allows >>him to buy exactly what he needs, rather than overspending on unused >>performance. It also cuts out the middleman, allowing the end-user to reap >>the cost savings of dealing directly with Intel. > >Novel !! I'll say. This is going to be a real winner. We'll sell you the >FPU, but you can't use it unless you pay us. No thanks. > This means you can write a virus that makes 4 or more attempts at the password and disable you FPU. Erratum: Read 'the end-user' as 'Intel and the end-user' above. (I'm not saying this is a bad thing) This allows Intel to charge for the chip propotionally to how badly the end-user wants it.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/18/91)
In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) wrote >for enabling the on-chip FPU. Each password is good for 10 gigaflops, >i.e. you get 10,000,000,000 floating point operations. Note that at one megaflop (and if the 586 FPU can't achieve that, who wants it?) 10,000,000,000 floating point operations is about 3 HOURS of FP computation. Whatever you think about Intel, they aren't going to expect people to buy passwords every few _hours_! I swallowed the "hex cache" hook, line, and sinker, but this gem told me it was a joke. It was a wee bit alarming that so many comp.arch readers failed to do the arithmetic to check this... -- There is no such thing as a balanced ecology; ecosystems are chaotic.
dhinds@elaine18.Stanford.EDU (David Hinds) (05/18/91)
In article <5814@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >In article <42347@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) >wrote >>for enabling the on-chip FPU. Each password is good for 10 gigaflops, >>i.e. you get 10,000,000,000 floating point operations. > >Note that at one megaflop (and if the 586 FPU can't achieve that, who >wants it?) 10,000,000,000 floating point operations is about 3 HOURS >of FP computation. Whatever you think about Intel, they aren't going >to expect people to buy passwords every few _hours_! Seriously, though, (and apart from the issue of how to properly implement such a scheme), is this really that outrageous in principle? I'll bet it would take most PC users an awful long time to use up a billion flops. Is a pay-per-use scheme that unreasonable? You could have a phone service type scheme, where you could pay a flat price for the chip for unlimited service, or various other rates depending on your level of use. Maybe the chip would carry a meter, and someone could stop by to read it once every few months. I might really like having the latest, fastest CPU available to me all the time, though I only expect to use it maybe 5% of that time over all. I confess I can't think of a really good way to do this for PC's that would not be more trouble than it is worth. -David Hinds dhinds@cb-iris.stanford.edu
david@kessner.denver.co.us (David Kessner) (05/19/91)
Hey! Could be worse-- Intel could put OS/2 functions in 'microcode'! I wonder if they will offer a 586sz, a 586 sans OS/2 and 8086 emulation. :):):) -- David Kessner - david@kessner.denver.co.us | 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | Reunite PANGEA! Why can't everyone have three or four line .sig's? |
pkl@ee.mu.OZ.AU (Peter Kenneth LAWREY) (05/20/91)
I also noticed that a 586 running at say 4 MFLOPS (if it can do this) would use up a password every hour and have no passwords left after a week of continuous use. Not advisable for the i860 (:->
mcnally@wsl.dec.com (Mike McNally) (05/20/91)
In article <1991May19.072710.865@kessner.denver.co.us>, david@kessner.denver.co.us (David Kessner) writes: |> Hey! Could be worse-- Intel could put OS/2 functions in 'microcode'! |> I wonder if they will offer a 586sz, a 586 sans OS/2 and 8086 emulation. :):):) Does anybody remember the 8086 support chips with iRMX or CP/M in them? I do. -- * "In the Spirit as my automatics, * Mike McNally * Lystra and Zelda were one third * Coolie * as large as the infinite Cosmos." * DEC Western Software Lab * --- D. S. Ashwander * mcnally@wsl.dec.com
jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (05/22/91)
In article <1991May18.161515.22428@leland.Stanford.EDU> dhinds@elaine18.Stanford.EDU (David Hinds) writes: >Seriously, though, (and apart from the issue of how to properly implement >such a scheme), is this really that outrageous in principle? I'll bet it >would take most PC users an awful long time to use up a billion flops. Is >a pay-per-use scheme that unreasonable? You could have a phone service >type scheme, where you could pay a flat price for the chip for unlimited >service, or various other rates depending on your level of use. Maybe >the chip would carry a meter, and someone could stop by to read it once >every few months. I might really like having the latest, fastest CPU >available to me all the time, though I only expect to use it maybe 5% of >that time over all. I confess I can't think of a really good way to do >this for PC's that would not be more trouble than it is worth. Intel's Rent-A-Chip (tm) and Rent-to-Own services. They could probably get away with it only because 386s + 387s and 486s cost more than the mother board and ram combined in many PCs. Also it would be nice if they guarenteed the chip while it was being rented. The built-in part eliminates the need for a collection service. Rent-A-7404 might be little silly, however. My God, what am I saying? I hope there arn't any marketing people reading comp.arch... -- /* jallen@ic.sunysb.edu */ /* Amazing */ /* Joe Allen 129.49.12.74 */ int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0) +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2 ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
floyd@ims.alaska.edu (Floyd Davidson) (05/22/91)
In article <1991May21.191242.4591@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: > [...] >My God, what am I saying? I hope there arn't any marketing people reading >comp.arch... That is the real problem with this joke. It was funny as hell, but what if some Intel marketing people see it? Look how many people here couldn't tell it was a joke. How many of... Oh never mind... -- Floyd L. Davidson | Alascom, Inc. pays me, |UA Fairbanks Institute of Marine floyd@ims.alaska.edu| but not for opinions. |Science suffers me as a guest.
mmm@cup.portal.com (Mark Robert Thorson) (05/22/91)
mjs@hpfcso.FC.HP.COM (Marc Sabatella) says: > Hopefully, a Motorola "spokesman" will shortly produce an equally amusing > summary of the 68050. The design of the 68050, at least a few months ago when I left that group (flunked the piss test), has four on-chip execution units for executing more than one instruction per clock cycle. This architecture will be the first superscalar CISC processor, hence its nickname "ROTC" (i.e. "Revenge of the CISC's"). The goal of superscalar execution might seem to be in conflict with our two major design constraints: binary compatibility with earlier 680x0 processors, and expansion of the instruction set to include graphics primitives required by a certain major personal computer manufacturer. The goal and the constraints were satisfied through a novel architecture, in which the microcode memory is moved off-chip, into the general address space. This doesn't hurt performance, because each of the four execution units is equipped with an on-chip microcode cache, in addition to a ROM implementing a RISC-like subset of the family instruction set. With the microcode in memory, the instruction decoder can also be eliminated from the chip. In fact, it has been replaced with a pseudo- Huffman decoder. A binary program in the 680x0 instruction set is compiled into microcode, then Huffman-coded; these two steps occur in software. The chip then executes the program by pulling appropriate parts through the hardware Huffman decoder, and loading them into the appropriate on-chip cache(s). Because microcode programs tend to be rather small programs, and because formal proofs of program correctness can only be applied to small programs, and because we felt that our instruction-execution programs are the most critical programs to get correct, it was decided that all microcode would be formally verified. (This line of reasoning was suggested by a Berkeley professor who clearly had our best interests at heart.) A few of us voiced objections to this plan, favoring instead the "quick and dirty" approach of using test suites composed from the large body of existing 680x0 code. I guess our point of view was the result of brain damage, however, because when the random drug tests came back we were all dismissed--leaving the "clean and sober" group to plow ahead with their more arduous plan. :-)
jeffl@NCoast.ORG (Jeff Leyser) (05/22/91)
In post <1991May22.014604.13983@ims.alaska.edu>, floyd@ims.alaska.edu (Floyd Davidson) says:
!!In article <1991May21.191242.4591@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes:
!!> [...]
!!>My God, what am I saying? I hope there arn't any marketing people reading
!!>comp.arch...
!!
!!That is the real problem with this joke. It was funny as hell, but
!!what if some Intel marketing people see it? Look how many people
!!here couldn't tell it was a joke. How many of... Oh never mind...
Wait I know! Whoever came up with the originally idea -- PATENT IT! That'll
fix 'em. ;^)
--
Jeff Leyser jeffl@NCoast.ORGcook@news.colorado.edu (Richard L. Cook) (05/22/91)
>!!what if some Intel marketing people see it? Look how many people >!!here couldn't tell it was a joke. How many of... Oh never mind... >Wait I know! Whoever came up with the originally idea -- PATENT IT! That'll Hayes has already applied for the patent. -- Richard cook@spot.Colorado.EDU | cook@Colorado.BITNET | +1.303.492.2148 Social Science Data Analysis Center, University of Colorado, Boulder
feustel@netcom.COM (David Feustel) (05/23/91)
You're raising the possibility that the drug test results were rigged to get you and your buddies off the project. Would you care to state for the record whether you felt the drug tests were accurate? -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: feustel@netcom.com or feustel@cvax.ipfw.indiana.edu
ram@shukra.Eng.Sun.COM (Renu Raman) (05/23/91)
>You're raising the possibility that the drug test results were rigged >to get you and your buddies off the project. Would you care to state >for the record whether you felt the drug tests were accurate? >-- >David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 I can answer that easily. No they were not! The testing equipment used the new 68EC030, with 256 KB of parity less DRAM. In many cases test failure could be attributed to 1 bit errors in the DRAM. This shows why parity is very important! So, what is it that the 586 does not have? renu raman smiley is hidden somewhere -- -------------------------------- Renukanthan Raman ARPA:ram@sun.com M/S 16-11, 2500 Garcia Avenue, TEL :415-336-1813 Sun Microsystems, Mt. View, CA 94043
iwm@doc.ic.ac.uk (Ian Moor) (05/23/91)
david@kessner.denver.co.us (David Kessner) says: >Hey! Could be worse-- Intel could put OS/2 functions in 'microcode'! >I wonder if they will offer a 586sz, a 586 sans OS/2 and 8086 emulation. :):):) And they charge MORE for the version WITHOUT OS/2! -- Ian W Moor Internet: iwm@doc.ic.ac.uk JANET: iwm@uk.ac.ic.doc Department of Computing, That which you call a crime when one man does it, Imperial College. you call government when done by many. 180 Queensgate London SW7 UK.
peter@ficc.ferranti.com (peter da silva) (05/23/91)
You forgot the smiley, man. And all these people are taking you seriously. Perhaps a few issues of "life in the 21st century" are in order? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
jfjr@mbunix.mitre.org (Freedman) (05/23/91)
In article <1991May23.022846.8853@netcom.COM> feustel@netcom.COM (David Feustel) writes: >You're raising the possibility that the drug test results were rigged >to get you and your buddies off the project. Would you care to state >for the record whether you felt the drug tests were accurate? >-- >David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 >EMAIL: feustel@netcom.com or feustel@cvax.ipfw.indiana.edu I have found that, in regard to urine tests, neatness counts.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/24/91)
In article <1991May23.153404.16581@linus.mitre.org>, jfjr@mbunix.mitre.org (Freedman) writes: : In article <1991May23.022846.8853@netcom.COM> feustel@netcom.COM (David Feustel) writes: : >You're raising the possibility that the drug test results were rigged : >to get you and your buddies off the project. Would you care to state : >for the record whether you felt the drug tests were accurate? : I have found that, in regard to urine tests, neatness counts. I thought urine tests were always passed? -- I rejoiced that at least So-and-So could spell "hierarchical", but the _real_ explanation was that he couldn't spell "heir". -me
chrisj@pdx041.intel.com (Chris Jones) (05/24/91)
In article <1991May22.014604.13983@ims.alaska.edu>, floyd@ims.alaska.edu (Floyd Davidson) writes: > In article <1991May21.191242.4591@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: >> My God, what am I saying? I hope there arn't any marketing people reading >> comp.arch... >> >> That is the real problem with this joke. It was funny as hell, but >> what if some Intel marketing people see it? Look how many people >> here couldn't tell it was a joke. How many of... Oh never mind... You think YOU'RE worried about Intel marketing people reading this column... :-) Seriously folks, I've enjoyed reading this discussion and watching the mayhem that a couple of funny postings can cause. I notice that there are a lot of intel-bashers out there. OK, so maybe not everybody agrees with the latest and greatest(?) coming out of this company, but remember a cople of things: 1) Intel is a business, and by nature wants to make money. 2) REAL mode might be a thing of the past if not for... well, you know. Wish I could comment. :-) --Chris +----------------------------------+------------------------------------------+ { Chris S Jones, Intel Corp. | The opinions expressed above probably do } { 5200 NE Elam Young Pkwy, JF1-58 | not reflect the opinions of Intel. If } { Hillsboro, OR 97124 | they actually do reflect the opinions of } { chrisj@ichips.intel.com | Intel, it is purely coincidental, since } { (503) 696-4022 | Intel would never comment on such matters} +----------------------------------+------------------------------------------+
mmm@cup.portal.com (Mark Robert Thorson) (05/26/91)
In article <1991May23.022846.8853@netcom.COM> feustel@netcom.COM (David Feust >You're raising the possibility that the drug test results were rigged >to get you and your buddies off the project. Would you care to state >for the record whether you felt the drug tests were accurate? Did you miss the previous 30 or 40 postings in this thread? Perhaps you forgot who wrote the bogus description of the 586? Note the smiley at the end. Anyway, I'm sure Motorola is much better off without us :-)
jpc@fct.unl.pt (Jose Pina Coelho) (05/28/91)
In article <1991May24.153126.1468@ichips.intel.com> chrisj@pdx041.intel.com (Chris Jones) writes: > 2) REAL mode might be a thing of the past if not for... well, you know. If not for messy dog, but how would you load the tables for PM ? -- Jose Pedro T. Pina Coelho | BITNET/Internet: jpc@fct.unl.pt Rua Jau N 1, 2 Dto | UUCP: ...!mcsun!unl!jpc 1300 Lisboa, PORTUGAL | Home phone: (+351) (1) 640767 - If all men were brothers, would you let one marry your sister ?
feustel@netcom.COM (David Feustel) (05/29/91)
I'm a natural straight man. I don't practice; it comes naturally. -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: feustel@netcom.com or feustel@cvax.ipfw.indiana.edu
brandis@inf.ethz.ch (Marc Brandis) (05/29/91)
In article <JPC.91May28160504@terra.fct.unl.pt> jpc@fct.unl.pt (Jose Pina Coelho) writes: >In article <1991May24.153126.1468@ichips.intel.com> >chrisj@pdx041.intel.com (Chris Jones) writes: >> 2) REAL mode might be a thing of the past if not for... well, you know. >If not for messy dog, but how would you load the tables for PM ? If would not be a problem to load the tables if you define the initial values in the segment shadow registers. Assume that all segments would point to some segment at a given physical address (e.g. 0), have a given limit (e.g. 4 Gigabytes) and some reasonable protection settings. Now define that interrupts are disabled after reset. The first thing that you could do were to setup the tables that you need. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
dana@locus.com (Dana H. Myers) (05/30/91)
In article <1991May24.153126.1468@ichips.intel.com> chrisj@ichips.intel.com writes: > 2) REAL mode might be a thing of the past if not for... well, you know. Of course, the 80376 doesn't support Real mode. -- * Dana H. Myers KK6JQ | Views expressed here are * * (213) 337-5136 | mine and do not necessarily * * dana@locus.com | reflect those of my employer *
dana@locus.com (Dana H. Myers) (05/30/91)
In article <JPC.91May28160504@terra.fct.unl.pt> jpc@fct.unl.pt (Jose Pina Coelho) writes: > >In article <1991May24.153126.1468@ichips.intel.com> >chrisj@pdx041.intel.com (Chris Jones) writes: >> 2) REAL mode might be a thing of the past if not for... well, you know. >If not for messy dog, but how would you load the tables for PM ? Easy, the CPU comes up in protected with the on chip descriptors initialized to some well known values which allow access to the entire chip address range. Until you force a descriptor reload by loading a segment register or intersegment jump/call, these values would be in effect. This is how the 80376 works. The 80376 is a 386 without real mode, Virtual/86 mode, or a paging unit. -- * Dana H. Myers KK6JQ | Views expressed here are * * (213) 337-5136 | mine and do not necessarily * * dana@locus.com | reflect those of my employer *
herrickd@iccgcc.decnet.ab.com (05/31/91)
In article <42390@cup.portal.com>, mmm@cup.portal.com (Mark Robert Thorson) writes: > Gee, didn't you notice the smiley at the end? That was your signal not > to take it seriously. Some people sure are cynical, especially with > regard to Intel. They'd _never_ do something like what I described :-) Another facet of this that no-one commented on - it came right at the end of a heavy flame war on news.admin because Ed Vielmetti posted a similar joke with no smiley. This one calmed down faster. dan herrick
chased@rbbb.Eng.Sun.COM (David Chase) (05/31/91)
herrickd@iccgcc.decnet.ab.com writes: >mmm@cup.portal.com (Mark Robert Thorson) writes: >> Gee, didn't you notice the smiley at the end? >Another facet of this that no-one commented on - it came right at the >end of a heavy flame war on news.admin because Ed Vielmetti posted >a similar joke with no smiley. I was quite surprised that so many people failed to spot the posting as a well-written joke, smiley or not. I'm not sure, but I'd swear that people have been writing parody, satire, and sarcasm since before there were smiley faces, and somehow they got the message across. Not everyone on the net is Swift or Voltaire, but an intended joke is almost always immediately obvious, even if it isn't funny. Generally, I think smileys are vile -- sort of like visual canned laughter. Do we really need them? So, here's an obligatory architectural musing: How about those sound chips? Howcome I have to call a library routine to get at them? I want direct access to the sound chip from the language that I program in, so that the programs that I write can give users audio feedback, but I want portability, too, so I'll get a similar effect on a Sun, Macintosh, or NeXT. For instance, we can introduce a new escaped character in C strings "\h", for "Humor" (similar to "\a" for "Audible Alert"), which will cause the sound chip to emit a chuckle. "\H" emits a belly-laugh. I leave it to the standards committees to decide on the full mapping of noises to escape sequences. Compiler writers and language designers need to provide access to these valuable architectural features so that we can get on with the task of enhancing our mailers and news readers; after all, a great deal of user time, CPU time and disk space is spent in the use of these valuable applications, so we should ensure that they are of the highest possible quality. David Chase Sun
sef@kithrup.COM (Sean Eric Fagan) (05/31/91)
In article <14251@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes: >I'm not sure, but I'd swear >that people have been writing parody, satire, and sarcasm since before >there were smiley faces, and somehow they got the message across. Not >everyone on the net is Swift or Voltaire, but an intended joke is >almost always immediately obvious, even if it isn't funny. It's amusing that you mention Swift. "A Modest Proposal" was taken seriously by at least one or two people in Parliament. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sl@wimsey.bc.ca (Stuart Lynne) (05/31/91)
In article <14251@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes: }herrickd@iccgcc.decnet.ab.com writes: >>mmm@cup.portal.com (Mark Robert Thorson) writes: }>> Gee, didn't you notice the smiley at the end? }>Another facet of this that no-one commented on - it came right at the }>end of a heavy flame war on news.admin because Ed Vielmetti posted }>a similar joke with no smiley. } }I was quite surprised that so many people failed to spot the posting }as a well-written joke, smiley or not. I'm not sure, but I'd swear }that people have been writing parody, satire, and sarcasm since before }there were smiley faces, and somehow they got the message across. Not }everyone on the net is Swift or Voltaire, but an intended joke is Not everyone is Swift or Voltaire and please remember that they where roundly "flamed" by many of their contempories. The sarcasm and satire was not that obvious. -- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca
herrickd@iccgcc.decnet.ab.com (06/02/91)
In article <13869@exodus.Eng.Sun.COM>, ram@shukra.Eng.Sun.COM (Renu Raman) writes: > > So, what is it that the 586 does not have? > It doesn't have the parity price system so beloved by some American farmers. dan herrick herrickd@iccgcc.decnet.ab.com