clif@intelca.UUCP (Clif Purkiser) (10/23/85)
I think my orginal posting got lost in the net bit bucket in the sky.
If this material is repeated my apologies.
Wed. Oct 16, Intel announced the 80386 the newest 32-bit microprocessor along
with an entire family of 386 products. While the entire list of press releases
and Intel announcements would take too long to enumurate I thought I would
highlight some of the more important portions of the 80386 introduction.
The introduction consisted of speeches by Intel executives and two
demonstrations of the 80386's incrediable functionality. An Intel 310
system was shown running Xenix 286 uith a 386 used in place of the 286.
This demonstration was followed by Lotus, SideKick, and Flight Simulator
all running on a PC-AT using an 386 to 286 adaptor board. Flight Simulator
proved to be the hit of the show since it is the acid test of
IBM PC compatibility, and looks great on a 8' x 10' screen.
Additional demos included RMX-286 (Intel's real time OS) running
at 16 MHz on a 386/20 board, and Daisy Systems CAD tools for board and
system level designs using a real 386.
In addition to the 80386 the following products were also introduced
386/20 A 386 based MultiBus I board featuring a 64K byte cache
and a High Speed 32-bit memory interface supporting up to
16 megabytes of dual-port system memory.
386/100 A MULTIBUS II single board computer with the same memory
configurations as the 386/20 with special purpose message
passing silicon.
PSCOPE 386 A ROM based high-level software debugger for the 80386.
ICE 386 An In Circuit Emulator which provides full speed emulation of
the 80386. It provides an excellent tool for hardware and
software integration.
Languages The following languages were announced for the 80386
ASM, C, PLM, FORTRAN, and ADA
Software Tools A complete system of software tools including a
Builder, Binder,Mapper, Librarian, and numerics
support libraries.
All software tools are orginally hosted on Xenix 286 based systems
(in particular a Xenix 286/310 microcomputer) Hosting of these tools
on other computers is planned for the near future.
Weitek and Intel also announced an agreement under which both companies will
develop and market a chip that provides an interface between the 80386 and
Weitek's 1164 and 1165 64-bit floating point processors. The Weitek chip
set provides floating-point performance in excess of 2 MFLOPS. Systems
using the 80386 when combined with the Weitek Chip set will offer
performance of 4 million Whetstones per second.
Finally, AT&T and Intel announced the signing of a contract for porting
of the Unix* System V Operating System to the 80386. The port is one
of the first agreements for the Networking features of the System V operating
system, and is a continuation of the AT&T-Intel partnership to bring state of
the art Unix System V technology to Intel microprocessors.
Additional information is available on these products by contacting your
local Intel sales office or by calling toll free
(800) 538-1876, ask for operator 386 and receive a packet of information
about the 80386 (data sheet, product announcements etc).
I am also posting a fairly short description of the 80386 itself.
If you have additional comments you may contact me via e-mail. If
time allows I will attempt to answer other questions. However I
suspect most answers will be to call the above number.
Clif Purkiser
386 Product Marketing
{amd hplaps pur-ee}!intelca
Unix is a trademark of AT&T
ICE-386, PSCOPE-386, MULTIBUS, RMX are all trademarks of Intelandrew@amdahl.UUCP (Andrew Sharpe) (10/27/85)
> Finally, AT&T and Intel announced the signing of a contract for porting > of the Unix* System V Operating System to the 80386. The port is one > of the first agreements for the Networking features of the System V operating > system, and is a continuation of the AT&T-Intel partnership to bring state of > the art Unix System V technology to Intel microprocessors. Well, I'm curious. Who's going to do this port? It won't be Intel, because they didn't do the 286 port; DRI did. Might it be Interactive Systems, who took over maintenance from DRI? (DRI wasn't interested in maintaining it themselves, or I would still be working there). -- Andrew Sharpe ...!{ihnp4,cbosgd,hplabs}!amdahl!andrew ***************************************** ___________ * The views expressed above are solely * ,/| _____ | * my cat's opinions, and do not reflect * | | |___ /| | * the views of the employees, nor the * | | | | | | * management, of Amdahl Corporation. * | | | | | | * * | | |__| | | * * | | / | | ,| * * | ~~~~~ |/ ***************************************** ~~~~~~~~~~~
freed@aum.UUCP (Erik Freed) (10/27/85)
> Wed. Oct 16, Intel announced the 80386 the newest 32-bit microprocessor along > with an entire family of 386 products. While the entire list of press releases > and Intel announcements would take too long to enumurate I thought I would > highlight some of the more important portions of the 80386 introduction. > BLAH BLAH BLAH etc etc I object to this press release hype here in net.micro. This seems to me to be a DEFINITE NO-NO for this newgroup. This is not technical data it is corporate back-patting. Please don't lower this newsgroup to this level!!!!!!! If this needs to be on the net, there are better places for it. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
gnu@l5.uucp (John Gilmore) (10/28/85)
While I think a better place for the long text might have been in mod.newprod, I definitely think that the capabilities of the 386 are a fit subject for these forums. And it's hard to describe the product you've been sweating over for a year or three without a little hype getting in there -- as I've demonstrated to you-all before :-}. Keep up the info flow!
mojo@kepler.UUCP (Morris Jones) (10/28/85)
In article <392@aum.UUCP> freed@aum.UUCP (Erik Freed) writes: >I object to this press release hype here in net.micro. This seems to me to be >a DEFINITE NO-NO for this newgroup. This is not technical data it is corporate >back-patting. Please don't lower this newsgroup to this level!!!!!!! If this >needs to be on the net, there are better places for it. Well now I enjoyed the posting very much! a) I appreciate having the information b) I like hearing it from people so close to the project c) The article was very readable as well as being worth reading. There isn't much on USENET that you can say that about. My only objection was that I got the announcement twice. I despise Intel architectures and segments and groups and classes. But I still was very happy to send a note of congratulations and good luck to the project manager. It was kind of him to share a little of his team's celebration with us! Hey, we might be spending a lot of time writing for his damn chip. It's nice to hear about it from the horse's mouth, as early as we did. -- Mojo ... Morris Jones, MicroPro Product Development {ptsfa,hplabs,glacier,lll-crg}!well!micropro!kepler!mojo
freeman@spar.UUCP (Jay Freeman) (10/29/85)
[] >> Wed. Oct 16, Intel announced the 80386 the newest 32-bit microprocessor along >> with ... > BLAH BLAH BLAH etc etc >I object to this press release hype here in net.micro. I think announcements of new chips are appropriate here, particularly when they are related to topics of past controversy. People who enjoy feuding as much as we seem to should welcome more grist for our mill. :-) -- Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)
rcd@opus.UUCP (Dick Dunn) (10/30/85)
> I object to this press release hype here in net.micro. This seems to me to be > a DEFINITE NO-NO for this newgroup. This is not technical data it is corporate > back-patting. Please don't lower this newsgroup to this level!!!!!!! If this > needs to be on the net, there are better places for it. I posted a (mildly critical) followup to the 386 announcement before I encountered this (not so mild) response. I went back and re-read the parent article. I also realized that I'd seen info about the 386 in a glossy trade [rm]ag at least a week before the article appeared in net.arch. The more I think about it, the more I tend to agree with the assessment above--but I'd still be happy if we could pry some substantive information from Intel instead of chasing them away completely. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...At last it's the real thing...or close enough to pretend.
roy@medstar.UUCP (Roy Talledo) (10/30/85)
> BLAH BLAH BLAH etc etc > > I object to this press release hype here in net.micro. This seems to me to be > a DEFINITE NO-NO for this newgroup. This is not technical data it is corporate > back-patting. Please don't lower this newsgroup to this level!!!!!!! If this > needs to be on the net, there are better places for it. > -- Some of us are interested in the 80386 since it appears to be a very nice processor. I don't think that the newgroup has been disrupted. There are articles that are even less informative than the 80386 announcement that appear in this newsgroup on a daily basis. The announcement may be better suited for newprod, but I didn't get offended by it being in this newsgroup. Roy -- Roy A. Talledo Medical Systems Technology & Research (MedSTAR) Atlanta, GA uucp: ..!{akgua,gatech}!medstar!roy
slerner@sesame.UUCP (Simcha-Yitzchak Lerner) (10/30/85)
<>
For those who haven't received their '386 info packets yet, a nice
feature that I wish all chips would include:
4 hardware breakpoint registers!! These registers will break not only
on execution, but also on data access to any of the defined addresses.
Oh boy! Software only 'ICE' features. What will they think up next?
:-)
--
Opinions expressed are public domain, and do not belong to Lotus
Development Corp.
----------------------------------------------------------------
Simcha-Yitzchak Lerner
{genrad|ihnp4|ima}!wjh12!talcott!sesame!slerner
{cbosgd|harvard}!talcott!sesame!slerner
talcott!sesame!slerner@harvard.ARPA dfh@scirtp.UUCP (David F. Hinnant) (10/31/85)
Some marketing guy from Intel writes: > > Wed. Oct 16, Intel announced the 80386 the newest 32-bit microprocessor along > with an entire family of 386 products. While the entire list of press releases > and Intel announcements would take too long to enumurate I thought I would > highlight some of the more important portions of the 80386 introduction. > > The introduction consisted of speeches by Intel executives and two > demonstrations of the 80386's incrediable functionality. An Intel 310 ^^^^^^^^^^^ Wow. Really? And I supposed this is an unbiased opinion too. > blah blah blah... > > Additional information is available on these products by contacting your > local Intel sales office or by calling toll free > > (800) 538-1876, ask for operator 386 and receive a packet of information > about the 80386 (data sheet, product announcements etc). > > Clif Purkiser > 386 Product Marketing > {amd hplaps pur-ee}!intelca > > Unix is a trademark of AT&T > ICE-386, PSCOPE-386, MULTIBUS, RMX are all trademarks of Intel Hey dude, gimme a break. If I wanted marketing propaganda garbage, I'd call my local Intel office. This crap doesn't belong here. Just because you don't have your own newsgroup doesn't mean you can litter net.micro and net.arch with marketing verbage. -- David Hinnant SCI Systems, Inc. {decvax, akgua}!mcnc!rti-sel!scirtp!dfh
dfh@scirtp.UUCP (David F. Hinnant) (10/31/85)
> While I think a better place for the long text might have been in mod.newprod, > I definitely think that the capabilities of the 386 are a fit subject for > these forums. And it's hard to describe the product you've been sweating > over for a year or three without a little hype getting in there -- as I've > demonstrated to you-all before :-}. > > Keep up the info flow! I too appreciate information, but I don't want marketing glossies coming out of my CRT screen too! I don't understand what all the furor over the 386 is. I fail to see why anyone would 'sweat' over the 386 unless they knew they HAD to use it on their next project. What can it do that the 68020 can't do better? -- David Hinnant SCI Systems, Inc. {decvax, akgua}!mcnc!rti-sel!scirtp!dfh
mark@tove.UUCP (Mark Weiser) (10/31/85)
I was glad to read about the 386 here. It was the first information other
than a mention I had seen. Better would have been more info and less hype,
but lots worse would have been no posting at all. On balance I'd say its
better to have this info than not.
-mark
--
Spoken: Mark Weiser ARPA: mark@maryland Phone: +1-301-454-7817
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742dww@stl.UUCP (David Wright) (10/31/85)
In article <225@l5.uucp> gnu@l5.uucp (John Gilmore) writes: >While I think a better place for the long text might have been in mod.newprod, .... >Keep up the info flow! As we don't seem to get mod.newprod in Europe, I for one am glad that 80386 info WAS posted to net.micro. I already knew much of the technical stuff (we usually get pre-release stuff on a confidential basis), but I didn't know what SW-etc. products would be announced nor the planned announcement date, so I was interested to see the posting. I don't think commercial announce- ments of general technical interest should be banned, so long as they are to an appropriate group, and only once per product. It was certainly more relevant than a lot of the stuff I see in net.micro!
ray@othervax.UUCP (Raymond D. Dunn) (11/01/85)
The 386 announcement on the net was not by itself objectionable, indeed I enjoyed the obvious enthusiasm for a "job well done" (we hope) by the poster. A new processor product announcement is obviously of general interest to the net readership, both Intelites and others. The followup (non)descriptive posting was however questionable, and the solicitation for information requests *by e-mail over the net* should definitely not have appeared. There are *competitors* of Intel on the net, why should they be bearing the cost of supplier-customer communications? I recently posted an article in net.news.group & net.micro.amiga on this subject, specifically being concerned that net.micro.amiga is turning into a dialogue between Commodore-Amiga and their software developers. Ray Dunn. ...philabs!micomvax!othervax!ray
sambo@ukma.UUCP (Father of micro-ln) (11/02/85)
In article <533@scirtp.UUCP> dfh@scirtp.UUCP (David F. Hinnant) writes: >I fail to see why anyone would 'sweat' over the 386 unless they knew they >HAD to use it on their next project. What can it do that the 68020 can't do >better? Run several MS-DOS programs simultaneously with full 8086 compatibility, with each program in its very own 1 MByte address space. Or how about running a program that requires 64 terabytes of memory? By the way, do I note a bit of unwillingness to listen to someone (or something) just be- cause he (it) is black? -- Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma.uucp@anl-mcs.arpa, or even anlams!ukma!sambo@ucbvax.arpa UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo, or cbosgd!ukma!sambo "Micro-ln is great, if only people would start using it."
pauls@tekecs.UUCP (Paul Sweazey) (11/04/85)
> --but I'd still be happy if we could pry some substantive > information from Intel instead of chasing them away completely. > -- > Dick Dunn They DID give me something substantive...an 800 number, and a few days later the spec sheet (spec book?). The 386 is a brilliant melding of marketing expedience and technical excellence. Perhaps, rather than griping, you should use the phone. Paul Sweazey {decvax,ucbvax,etc}!tektronix!tekecs!pauls
jer@peora.UUCP (J. Eric Roskos) (11/04/85)
> Or how about running a program that requires 64 terabytes of memory? The latest fad in making better microcomputers seems to be in adding some more address bits... now we've got a microcomputer that can run programs "that require 64 terabytes of memory". I'd like to see the memory system for such a computer! It certainly would be big. [Oh, they're "virtual" terabytes, you say! So now we need a 64 terabyte paging device... not to mention questions like "how long would it take just to access 64 terabytes of memory sequentially"... This is not meant to be critical of larger address spaces, just the way they are casually mentioned as a big feature of a small machine.] > By the way, do I note a bit of unwillingness to listen to someone (or > something) just be-cause he (it) is black? I thought they were gold and purple? :-) PS - by the way, if our calculations are right, using 100ns memory (and assuming you just accessed the memory and didn't do anything else, e.g., instruction fetches, etc.), it would take 74.07 days just to read through a 64 terabyte memory one time... -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
lmpopp@watdaisy.UUCP (Len Popp) (11/04/85)
In article <391@sesame.UUCP> slerner@sesame.UUCP (Simcha-Yitzchak Lerner) writes: ><> > >For those who haven't received their '386 info packets yet, a nice >feature that I wish all chips would include: > >4 hardware breakpoint registers!! The 32000 family MMU (32082, I think) has had this feature for a couple of years. There are two registers with breakpoint addresses and conditions. A breakpoint can be triggered on execution, read or write of the virtual or physical address. There is also a count register specifying the number of breakpoints to ignore before breaking. A nice feature, yes, but not a groundbreaking innovation. Len Popp lmpopp@watdaisy
john@anasazi.UUCP (John Moore) (11/04/85)
In article <532@scirtp.UUCP> dfh@scirtp.UUCP (David F. Hinnant) writes: >Some marketing guy from Intel writes: >Hey dude, gimme a break. If I wanted marketing propaganda garbage, I'd call >my local Intel office. This crap doesn't belong here. Just because you don't >have your own newsgroup doesn't mean you can litter net.micro and net.arch >with marketing verbage. > >-- > David Hinnant Hey, Dude, give us a break! The Intel 386 is going to impact an awful lot of us on the net, and I think it is pretty nice to get a description here and be able to direct questions to the folks that know. If you don't like the hyperbole, consider that if you had worked on the project, you might be a bit proud of it also and consider it quite an accomplishment. Finally, I think that, from what I read, the 386 corrects many of the inexcusable architectural boo-boos Intel committed on the 8086/186/286 line. Since many of us are forced to use these products by market pressure, it is great to know that in the future things will be better. So... if you don't like the posting, I suggest that in the future you hit "n" and skip it. Don't censor it on my behalf! -- John Moore (NJ7E/XE1HDO) {decvax|ihnp4|hao}!noao!terak!anasazi!john {hao!noao|decvax|ihnp4|seismo}!terak!anasazi!john (602) 952-8205 (day or evening) 5302 E. Lafayette Blvd, Phoenix, Az, 85018 (home address)
henry@utzoo.UUCP (Henry Spencer) (11/05/85)
> >... What can it [the 386] do that the 68020 can't do better? > > Run several MS-DOS programs simultaneously with full 8086 compatibility, > with each program in its very own 1 MByte address space. Running old software is best done by recompiling portable source. Or, in the case of much MSDOS software, throwing it out and reimplementing. The parts about "simultaneous" and "very own address space" are nothing special. If one really wants to make a decent machine [stipulating that the 386 is such, I haven't got full specs yet] act like a bunch of brain-damaged ones, consider the awesome inefficiency of emulating things like screen updates one instruction at a time. (Or does the 386 have some better hooks for emulating memory-mapped virtual i/o devices?) Yes, Virginia, there are MSDOS programs that do their own screen updates. Lots of them. > Or how about running a program that requires 64 terabytes of memory? Name one. Name one disk with enough space to serve as backing store, too. Note that you can't exploit that space without resorting to the disastrously inefficient "large model" code, either. Practically all real 386 programs are going to run "small model", which fortunately isn't much of a problem when that means 32-bit addresses. > By the way, do I note a bit of unwillingness to listen to someone (or > something) just because he (it) is black? No, you detect a strong note of skepticism about Intel processors, after four (five if you count the 432) botches in a row. Maybe the skepticism is unjustified in this case; I reserve judgement until I see spec sheets. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (11/05/85)
> For those who haven't received their '386 info packets yet, a nice > feature that I wish all chips would include: > > 4 hardware breakpoint registers!! These registers will break not only > on execution, but also on data access to any of the defined addresses. > Oh boy! Software only 'ICE' features. What will they think up next? You mean, what will they borrow from National next? The 32000 family MMU has had this sort of thing all along. Does the 386 have branch- history registers? (The 32000 MMU does.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
BHUBER@usc-ecl.arpa (11/06/85)
In response to your message sent 1 Nov 85 22:23:23 GMT I must have missed something in the recent message traffic about the 80386. What caused you to say ". . . unwillingness to listen to someone (or something) just because he (it) is black?" I can only assume that the reference is to race, and I have seen nothing in the prior discussion alluding to race. Race has nothing to do with this issue. Bud P.S., maybe I am being overly sensitive..... -------
sambo@ukma.UUCP (Father of micro-ln) (11/06/85)
In article <6112@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >consider the awesome inefficiency of emulating things like screen updates >one instruction at a time. (Or does the 386 have some better hooks for >emulating memory-mapped virtual i/o devices?) Yes, Virginia, there are >MSDOS programs that do their own screen updates. I am talking about something outside my expertise (all areas are outside my expertise), but if I understand the Intel literature correctly, you can do paging on top of emulating the 8086 in "virtual 86 mode." Then you can set the page(s) where the screen is to "not present," and then do a trap every time it is accessed. Alternatively, you could set that page as "read-only," so that you would do a trap only on writes. According to Intel, this is not as fast as one might like, but when running both 8086 code and 80386 code, the 80386 is quite fast. -- Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma.uucp@anl-mcs.arpa, or even anlams!ukma!sambo@ucbvax.arpa UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo, or cbosgd!ukma!sambo "Micro-ln is great, if only people would start using it."
ted@cdp.UUCP (11/06/85)
Micro-port in Aptos California is my bet. -- Ted Goldstein Consultant
asgard@well.UUCP (J. R. Stoner) (11/07/85)
In article <7475@watdaisy.UUCP> lmpopp@watdaisy.UUCP (Len Popp) writes: >> >>For those who haven't received their '386 info packets yet, a nice >>feature that I wish all chips would include: >> >>4 hardware breakpoint registers!! > >The 32000 family MMU (32082, I think) has had this feature for a couple of >years. There are two registers with breakpoint addresses and conditions. >A breakpoint can be triggered on execution, read or write of the virtual or >physical address. There is also a count register specifying the number of >breakpoints to ignore before breaking. In actual fact National Semiconductor has removed the breakpointing registers from the 32082 after CPU step K was released. -- From the mania of: J. R. (May the farce be with you) Stoner, Esq.
crs@lanl.ARPA (11/07/85)
> > (800) 538-1876, ask for operator 386 and receive a packet of information > > about the 80386 (data sheet, product announcements etc). > > > > Clif Purkiser > > 386 Product Marketing > > {amd hplaps pur-ee}!intelca > > > > Unix is a trademark of AT&T > > ICE-386, PSCOPE-386, MULTIBUS, RMX are all trademarks of Intel > > Hey dude, gimme a break. If I wanted marketing propaganda garbage, I'd call > my local Intel office. This crap doesn't belong here. Just because you don't > have your own newsgroup doesn't mean you can litter net.micro and net.arch > with marketing verbage. > > -- > David Hinnant Some of us find new product announcements as useful here as we do in other technical publications. Exercise your 'n' key. -- All opinions are mine alone... Charlie Sorsby ...!{cmcl2,ihnp4,...}!lanl!crs crs@lanl.arpa
msc@saber.UUCP (Mark Callow) (11/08/85)
J. R. (May the farce be with you) Stoner, Esq. writes > In actual fact National Semiconductor has removed the breakpointing registers > from the 32082 after CPU step K was released. Wrong. The latest 32032 CPU rev is H. The latest 32082 MMU rev is M. The errata (excuuse me, "User Information") sheet for the Rev M 32082, dated 8th August 1985, says that "physical breakpoints cannot be used reliably". However the part definitely still contains two breakpoint registers. -- From the TARDIS of Mark Callow msc@saber.UUCP, sun!saber!msc@decwrl.dec.com ...{decwrl,ucbvax}!sun!saber!msc, ...{amdcad,ihnp4}!saber!msc
jack@boring.UUCP (11/08/85)
In article <259@well.UUCP> asgard@well.UUCP (J. R. Stoner) writes: > >In actual fact National Semiconductor has removed the breakpointing registers >from the 32082 after CPU step K was released. > >-- >From the mania of: >J. R. (May the farce be with you) Stoner, Esq. I surely hope this is mania! Can anyone deny or confirm this? And, if it is true, does this mean that they've replaced it with something else? -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
wb6rqn@yojna1.UUCP (Brian Lloyd) (11/08/85)
*** REPLACE THIS LINE WITH YOUR FLAMAGE *** Can we possibly keep the, "my favorite processor is wonderful, yours sucks...", stuff where it belongs -- in net.religion. Thanx. Brian Lloyd ...![bellcore!cp1]!yojna1!wb6rqn
tim@ISM780B.UUCP (11/08/85)
> The followup (non)descriptive posting was however questionable, and the > solicitation for information requests *by e-mail over the net* should > definitely not have appeared. There are *competitors* of Intel on the net, > why should they be bearing the cost of supplier-customer communications? There are two ways to handle forwarding of mail. The restrictive way would be for each site to only forward mail that relates to the work at that site. The other way is for everybody to forward, even if the items being forwarded are to/from the competition. The second is what is commonly done. The price you pay for handling other peoples random traffic is that they handle yours. If Intel forwards mail to their neighbors without restriction ( I don't know if they do or not ), then their is nothing wrong with what they did. Yes, it would be tacky for someone to route a 386 info request through Motorola, for example, but presumably a person looking for 68020 info could route his request through Intel.
baba@spar.UUCP (Baba ROM DOS) (11/09/85)
From the TARDIS of Mark Callow: >J. R. (May the farce be with you) Stoner, Esq. writes >> In actual fact National Semiconductor has removed the breakpointing registers >> from the 32082 after CPU step K was released. > >Wrong. > >The latest 32032 CPU rev is H. True, but the 320*16* CPU rev K was released some time ago. I suspect that is what J. R. was referring to. They made it to rev N on that part before it more-or-less stabilized. > The latest 32082 MMU rev is M. >The errata (excuuse me, "User Information") sheet for the Rev M >32082, dated 8th August 1985, says that "physical breakpoints >cannot be used reliably". > >However the part definitely still contains two breakpoint registers. Much as the human body still contains a vermiform appendix. Baba
henry@utzoo.UUCP (Henry Spencer) (11/10/85)
> ... if I understand the Intel literature correctly, you > can do paging on top of emulating the 8086 in "virtual 86 mode." Then > you can set the page(s) where the screen is to "not present," and then do > a trap every time it is accessed. Alternatively, you could set that page > as "read-only," so that you would do a trap only on writes. According to > Intel, this is not as fast as one might like... "not as fast as one might like" is the understatement of the century, actually. This is a serious performance problem in virtual-machine work when the machine has memory-mapped i/o devices. For the screen, you might be able to live with a scheme in which the system scanned the page table every 60th of a second to identify "screen" pages which had been modified, and then did something appropriate with them. Trapping every screen-update write is a performance disaster. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (11/10/85)
My suggestion is that "new product" postings to normal newsgroups should
follow the rule Usenix suggested for submitted papers some years ago: if
a substantial fraction of the paper is things your competitors would love
to know, then it is adequately technical.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrymdm@ecn-pc.UUCP (Mike D McEvoy) (11/10/85)
In article <6112@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> By the way, do I note a bit of unwillingness to listen to someone (or >> something) just because he (it) is black? >No, you detect a strong note of skepticism about Intel processors, after >four (five if you count the 432) botches in a row. Maybe the skepticism >is unjustified in this case; I reserve judgement until I see spec sheets. AW, COME ON HENRY! Although the the 8080/8088/8086/80186/80286 doesn't have a sensuous organization like the 68000/68020, only a twit would say INTEL botched it considering the 10 to 1 ratio between Intel and Motorola shipped units. (and I know your not a twit) Having designed with both companies products and SUPPORT services, I must admit that INTEL does do a few things right.... Even MOTOROLA would admit that. Now Henry, be nice to those poor INTEL people who indirectly brought us the PC, PC-AT,......... Big Mac
msc@saber.UUCP (Mark Callow) (11/11/85)
> From the TARDIS of Mark Callow: > >J. R. (May the farce be with you) Stoner, Esq. writes > >> In actual fact National Semiconductor has removed the breakpointing registers > >> from the 32082 after CPU step K was released. > > > >Wrong. > > > >The latest 32032 CPU rev is H. > > True, but the 320*16* CPU rev K was released some time ago. I suspect that > is what J. R. was referring to. They made it to rev N on that part before > it more-or-less stabilized. He may have had the 32016 in mind. However, the breakpoint registers are in the 32082 MMU (as he said) and they haven't been removed from the current rev M part. The only support required of the CPU is the NMI trap which is unlikely to go away. Therefore the CPU rev is irrelevant to this discussion. -- From the TARDIS of Mark Callow msc@saber.UUCP, sun!saber!msc@decwrl.dec.com ...{decwrl,ucbvax}!sun!saber!msc, ...{amdcad,ihnp4}!saber!msc
henry@utzoo.UUCP (Henry Spencer) (11/14/85)
> ... only a twit would say INTEL botched it considering the 10 to 1 ratio > between Intel and Motorola shipped units. Which would you say is better musically: Beethoven or the Rolling Stones? Now, which sells better? Have you looked at sales figures for the RK07 or the RL01? Intel has made a lot of money, at everyone else's expense: they have probably succeeded in setting the industry back ten years. I agree that Intel does some things right, but I almost wish they didn't. Their support gets them customers their trashy processors don't deserve. > ... Now Henry, be nice to those poor > INTEL people who indirectly brought us the PC, PC-AT,......... Sounds like a hanging offence to me! -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
peter@graffiti.UUCP (Peter da Silva) (11/14/85)
> AW, COME ON HENRY! Although the the 8080/8088/8086/80186/80286 doesn't have a > sensuous organization like the 68000/68020, only a twit would say INTEL > botched it considering the 10 to 1 ratio between Intel and Motorola shipped I must be a twit. The success of Intel can be spelled in 3 letters: I, B, and M. Any processor IBM chose would end up outselling the others 10:1 or more simply because IBM has the premier marketing department. > right.... Even MOTOROLA would admit that. Now Henry, be nice to those poor > INTEL people who indirectly brought us the PC, PC-AT,......... Oh, you noticed. There is no way that I'm going to be nice to people responsible, even indirectly, for making the IBM-PC the de-facto standard microcomputer in the US. That's damning by faint praise if ever I heard it. -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
mdm@ecn-pc.UUCP (Mike D McEvoy) (11/15/85)
In article <6139@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Intel has made a lot of money, at everyone else's expense: they >have probably succeeded in setting the industry back ten years. Let's see, 10 years ago.... Ah yes, the 8080 was just introduced... I believe a company called MITS introduced the Altair 8800.... The machine which really started the PC revolution.... Seems to me, this may qualify INTEL as the company that set the industry ahead 10 years. Last I checked Henry, the free world revolved around one person making money at anothers expense.... If you are arguing against capitalism, I think you are on the wrong net. Going back further, if I remember correctly, INTEL introduced the first "general purpose" micro, the 4004. They are not just one of the large chip companies, they had alot to do with the industry starting in the first place. >I agree that Intel does some things right, but I almost wish they didn't. >Their support gets them customers their trashy processors don't deserve. > >> Now Henry, be nice to those poor >> INTEL people who indirectly brought us the PC, PC-AT,......... > >Sounds like a hanging offence to me! In the free market system, those who prduce trashy processors that are a waste of good sand do one thing.... lose the stockholders a great deal of money and upset a few fools that design the product in anyway.. The only product that INTEL produced that fulfilled this was the 432. That's one of the best track records around in this industry. I'm not in love with their chip architecture myself, but one should give the devil his due. INTEL has succeded in producing more successful micro products than anyone else and has provided the customers with the tools to get the product to market as well as an upgrade path from their earlier devices (8080-8086) to the next generation technology. This is fact... This is also what keeps them a broad base of loyal customers.... They must have one hell of alot of stupid customers...... Who have alot of stupid customers ..... that buy alot of products with ..... trashy processors in them.... That work..... Big Mac 317-497-0509
phil@amdcad.UUCP (Phil Ngai) (11/16/85)
In article <435@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >I must be a twit. The success of Intel can be spelled in 3 letters: I, B, >and M. Any processor IBM chose would end up outselling the others 10:1 or >more simply because IBM has the premier marketing department. Now Peter, this is begging the question. Remember, IBM is out to make money. When they choose a device, they try to make the best choice they can. So you have to say that either IBM is a twit, which I won't accept for a company as successful as they are, or that the 8086 was the best choice AT THE TIME. Sure we have better choices now, but that's irrelevant. So how come no one complains about the wimpy 6502 in Apple IIs? What is this selective myopia? I think you're all just a bunch of IBM-phobes. -- Raise snails for fun and profit! Race them for amusement! Then eat the losers! Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
e-smith@utah-cs.UUCP (Eric L. Smith) (11/17/85)
In article <6386@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >So how come no one complains about the wimpy 6502 in Apple IIs? What is >this selective myopia? I think you're all just a bunch of IBM-phobes. Maybe because even though the 6502 is brain-damaged by today's standards, even Apple is not trying to pass it off as state-of-the-art, vs. IBM's PC-AT (80286, only 6MHz!). -- ------------------------------------------------------------------------------- Eric L. Smith (801) 581-8100 e-smith@utah-cs.arpa ...decvax!utah-cs!e-smith 3118 Merrill Engineering, University of Utah, Salt Lake City, UT 84112 The opinions expressed herein do not necessarily represent those of the University of Utah, my friends, enemies, computer, or even me. :-) Is this the most magnificant fire you have seen or am I crazy?
radzy@calma.UUCP (Tim Radzykewycz) (11/17/85)
In article <435@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >>Any processor IBM chose would end up outselling the others 10:1 In article <6386@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >IBM is out to make money. When they choose a device, they >try to make the best choice they can. So you have to say >that ... the 8086 was the best choice AT THE TIME. What you say is correct, but the inferences you make are not. IBM is out to make money. This means that IBM will make the best choice they can *FROM THE MARKETING POINT OF VIEW*. The technical issues come up *after* IBM has decided what kind of product to make. In this case, IBM chose to make an 8-bit system for cost reasons before they chose the 8088. That is the main reason that I, at least, consider the IBM-PC a flop. By the way, the 68000 was out a short while before the 808x came out. The reason IBM didn't chose that beast was that IBM was stuck on an 8-bit system -- they didn't think people would be willing to pay the extra $800 (or so) for a 16-bitter. >So how come no one complains about the wimpy 6502 in Apple IIs? What is >this selective myopia? I think you're all just a bunch of IBM-phobes. Probably we are all "just a bunch of IBM-phobes", however, you should consider the popularity of the IBM-PC v.s. the popularity of the Apple II. Then, you'll know why we aren't complaining about the partial processor in the Apple II. For your information, if IBM had chosen the 6502, 6809, 8080, 8085, or a bunch of other losers, we would be griping just as much (or more -- after all, those chips are far worse than the 808x). -- Tim (radzy) Radzykewycz, The Incredible Radical Cabbage calma!radzy@ucbvax.ARPA {ucbvax,sun,csd-gould}!calma!radzy
wdm@ecn-pc.UUCP (Tex) (11/17/85)
In article <426@ecn-pc.UUCP> mdm@ecn-pc.UUCP (Mike D McEvoy) writes: >In article <6139@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >>Intel has made a lot of money, at everyone else's expense: they >>have probably succeeded in setting the industry back ten years. > >Let's see, 10 years ago.... Ah yes, the 8080 was just introduced... >I believe a company called MITS introduced the Altair 8800.... The machine >which really started the PC revolution.... Ok, Intel did make one good (for the time) processor, the 8080. But that was more than ten years ago. They really haven't changed their architecture since then. While the rest of the micro world was learning the joys of modern architecture, Intel was busily trying to figure out how to stuff 8-bit performance into a 16-bit micro. > >Last I checked Henry, the free world revolved around one >person making money at anothers expense.... If you are arguing against >capitalism, I think you are on the wrong net. This is a very interesting definition of capitalism, but I especially like how you come up with a lousy definition of capitalism and then use it to bash Henry. > >>I agree that Intel does some things right, but I almost wish they didn't. >>Their support gets them customers their trashy processors don't deserve. >> >>> Now Henry, be nice to those poor >>> INTEL people who indirectly brought us the PC, PC-AT,......... >> >>Sounds like a hanging offence to me! Think what the world would be like now if IBM had decided to go with the Motorola family of chips for the PC series. WOW!! We would really have some systems out there. IBM chose Intel for business, not technical, reasons. I don't think Motorola would have sold IBM twelve percent of their stock. Besides, IBM and Motorola compete (or will be shortly) in a number of areas. > >In the free market system, those who prduce trashy processors that are a >waste of good sand do one thing.... lose the stockholders a great deal of >money and upset a few fools that design the product in anyway.. > >I'm not in love with their chip architecture myself, but one should give >the devil his due. INTEL has succeded in producing more successful micro >products than anyone else and has provided the customers with the tools >to get the product to market as well as an upgrade path from their earlier >devices (8080-8086) to the next generation technology. Of course, from a computer architecture point of view the 8080 and the 8086 are the SAME generattion of technology. I would also be interested in how you define successful. Is it just the one that makes alot of money? If you want to say that the 808X family is the most successful, the credit has to go to IBM, not Intel. >This is fact... >This is also what keeps them a broad base of loyal customers.... >They must have one hell of alot of stupid customers...... >Who have alot of stupid customers ..... >that buy alot of products with ..... >trashy processors in them.... >That work..... Nobody said they didn't work. They're just clumsy and make life difficult for the people that must use them. If you want upward compatiblity, write everything in a portable language, and recompile (I know it is not so simple, but porting properly written code is not that tough). I for one am glad that DEC didn't decide to build PDP-8 compatibility in to the VAX, but I guess if they did they would have set the industry ahead ten years. Or something like that. > >Big Mac > >317-497-0509 > >
phil@amdcad.UUCP (Phil Ngai) (11/17/85)
In article <62@calma.UUCP> radzy@calma.UUCP (Tim Radzykewycz) writes: >In this case, IBM chose to make an 8-bit system for cost >reasons before they chose the 8088. That is the main reason >that I, at least, consider the IBM-PC a flop. Sure is a popular flop. The funny part is, if IBM had waited however many years it took for Moto to come out with the 68008, the 8 bit version of the 68K, you probably would be happier with the IBM-PC. Yet it would still be an 8-bit system. >Probably we are all "just a bunch of IBM-phobes", however, >you should consider the popularity of the IBM-PC v.s. the >popularity of the Apple II. Then, you'll know why we aren't >complaining about the partial processor in the Apple II. For >your information, if IBM had chosen the 6502, 6809, 8080, >8085, or a bunch of other losers, we would be griping just as >much (or more -- after all, those chips are far worse than >the 808x). I don't know what you have against processors like the Z-80, my H19 has one in it and it works just fine. Anyway, you seem to be saying you don't like the IBM-PC because too many other people like it. Hmmm. Sounds to me like you want IBM to provide you with the perfect toy and are annoyed because they ignored you and came out with a product that the marketplace wanted instead. -- Raise snails for fun and profit! Race them for amusement! Then eat the losers! Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
cdshaw@watrose.UUCP (Chris Shaw) (11/19/85)
I have two points to make: 1) Shut up about capitalism/whatever of Intel. A debate on this level is counter-productive, doesn't belong in this group, and cannot be effectively conducted in screen-size chunks. 2) The whole thing about the 8086 is that it is, to some degree, upward compatible from 8080. So you get 8080 -> 8086 -> 186 -> 286 -> 386, each better than the last in some way or another. Why? Market share. A fundamental lesson learned very early on (50's) by computer makers is that if you introduce a new & different cpu, you have to re-code all those dusty decks of payroll, acct receivable, etc, thus wasting valuable time to actually use your shiny new machine. If you keep the instruction set (and so on) the same, only faster, you get your performance instantly. Your competitor doesn't beat you to market in the time it takes to re-code all the old software. Your customers are also familiar with your machines, because in a sense they are all the same. The classic, ultimate example of this is the 370 series. The 3090 can run essentially the same software as the 370/158. The time difference for these machines is probably 15 years (don't know for sure). Thus, Joe Insurance Co. hasn't had to change its software because of software for the last 15 years. CPU upgrades are a joke. At Waterloo recently, 2 4341's were swapped for 2 4381's in the space of about 5-10 hours. Nobody noticed, except for speed. Chris Shaw watmath!watrose!cdshaw or cdshaw@watmath University of Waterloo In doubt? Eat hot high-speed death -- the experts' choice in gastric vileness !
jchapman@watcgl.UUCP (john chapman) (11/19/85)
. . > The classic, ultimate example of this is the 370 series. The 3090 can run > essentially the same software as the 370/158. The time difference for these > machines is probably 15 years (don't know for sure). > . . > Chris Shaw watmath!watrose!cdshaw or cdshaw@watmath > University of Waterloo > In doubt? Eat hot high-speed death -- the experts' choice in gastric vileness It goes further than that (even! :-) ) it would probably run 360 software too (since the 370 ran 360 stuff) -- John Chapman ...!watmath!watcgl!jchapman Disclaimer : These are not the opinions of anyone but me and they may not even be mine.
kbb@faron.UUCP (Kenneth B. Bass) (11/19/85)
In article <426@ecn-pc.UUCP> mdm@ecn-pc.UUCP (Mike D McEvoy) writes: >In article <6139@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >>Intel has made a lot of money, at everyone else's expense: they >>have probably succeeded in setting the industry back ten years. > >Let's see, 10 years ago.... Ah yes, the 8080 was just introduced... >I believe a company called MITS introduced the Altair 8800.... The machine >which really started the PC revolution.... > >Seems to me, this may qualify INTEL as the company that set the industry >ahead 10 years. Last I checked Henry, the free world revolved around one >person making money at anothers expense.... If you are arguing against >capitalism, I think you are on the wrong net. > >Going back further, if I remember correctly, INTEL introduced the first >"general purpose" micro, the 4004. They are not just one of the large chip >companies, they had alot to do with the industry starting in the first place. > >>I agree that Intel does some things right, but I almost wish they didn't. >>Their support gets them customers their trashy processors don't deserve. >> >>> Now Henry, be nice to those poor >>> INTEL people who indirectly brought us the PC, PC-AT,......... >> >>Sounds like a hanging offence to me! > >In the free market system, those who prduce trashy processors that are a >waste of good sand do one thing.... lose the stockholders a great deal of >money and upset a few fools that design the product in anyway.. The only >product that INTEL produced that fulfilled this was the 432. That's one of >the best track records around in this industry. > >I'm not in love with their chip architecture myself, but one should give >the devil his due. INTEL has succeded in producing more successful micro >products than anyone else and has provided the customers with the tools >to get the product to market as well as an upgrade path from their earlier >devices (8080-8086) to the next generation technology. This is fact... >This is also what keeps them a broad base of loyal customers.... >They must have one hell of alot of stupid customers...... >Who have alot of stupid customers ..... >that buy alot of products with ..... >trashy processors in them.... >That work..... > >Big Mac > >317-497-0509 Don't forget about CP/M. INTEL's original development system ISIS was the precursor of CP/M. Just wanted to add my 2 cents worth... "It ain't necessarily so" ken bass linus!faron!kbb
dennisg@sdcrdcf.UUCP (Dennis Griesser) (11/21/85)
In article <6386@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >Now Peter, this is begging the question. Remember, IBM is out to make money. >When they choose a device, they try to make the best choice they can. >So you have to say that either IBM is a twit, which I won't accept for >a company as successful as they are, or that the 8086 was the best >choice AT THE TIME. Sure we have better choices now, but that's irrelevant. A lousy argument. In logic class, they called this the fallacy of "appeal to authority". It can be summarized "X said this, and X is always right, so this must be true." What I do not doubt is that IBM did indeed make the best choice. However my definition of "best" may not match yours or IBM's. The fact is that IBM is out to make a lot of money. In this case, the best choice of a CPU is one that makes them the most money. There are quite a few trade-offs to be considered, including: actual performance, customer perception of the product, and manufacturing price. I have no idea what factors were included in this decision or how they were weighted. But what would have happened if IBM had been offered a somewhat less than state-of-the-art CPU, in quantity, for an absurdly low price? Most of the personal computers in the world might be running CP/M-80! -- [Standard disclaimers apply.]
meissner@rtp47.UUCP (Michael Meissner) (11/23/85)
In article <2796@watcgl.UUCP> jchapman@watcgl.UUCP (john chapman) writes: >. >> Chris Shaw writes >> The classic, ultimate example of this is the 370 series. The 3090 can run >> essentially the same software as the 370/158. The time difference for these >> machines is probably 15 years (don't know for sure). > > It goes further than that (even! :-) ) it would probably run 360 software too > (since the 370 ran 360 stuff) > It goes even further, since all of IBM's mainframes also include emulators for their previous machines (which I believe are the 704 and 1600). Now adays, the IBM 3084 emulating an IBM 704, runs faster than the original machine. Some of IBM's biggest customers run accounting programs written in the early 70's, for which there is no source available (or the source is all assembler).
dfh@scirtp.UUCP (David F. Hinnant) (11/24/85)
> I have two points to make: > > 2) The whole thing about the 8086 is that it is, to some degree, upward > compatible from 8080. So you get 8080 -> 8086 -> 186 -> 286 -> 386, > each better than the last in some way or another. > This is true up to a point. (See below). > Why? Market share. A fundamental lesson learned very early on (50's) by > etc..... > essentially the same software as the 370/158. The time difference for these > machines is probably 15 years (don't know for sure). > > Thus, Joe Insurance Co. hasn't had to change its software because of software > for the last 15 years. CPU upgrades are a joke. At Waterloo recently, > 2 4341's were swapped for 2 4381's in the space of about 5-10 hours. > Nobody noticed, except for speed. > > Chris Shaw watmath!watrose!cdshaw or cdshaw@watmath The point about Joe Insurance Co. is not a particularly valid one. I suspect that most software written 8, 10 or 15 years has long since outlived its usefulness. Example: At (an unnamed division of) ITT, I ran into a receiving system that constantly crashed, and when up was very, very slow. Often I would go down to receiving, checking on what was growing roots there and hadn't been shipped up to us (everything from disks to disk drives. What bozos!) On several occasions I was told the that "the terminal was full". It seems the DBMS could only hold a finite number of entries that was obviously to low. The DBMS? It was written 10 years ago and when contacted, the vendor was amazed to find anyone still using it. The source code? Not even the vendor had it around anymore. In this 'age' of new! and improved! software (SuperCalc --> Lotus 1-2-3 --> ??) I don't think maintaining the bridge between applications on microprocessor driven systems is as important as it once was (any may still be) with mainframes. Applications software simply changes too fast. -- David Hinnant SCI Systems, Inc. ...{decvax, akgua}!mcnc!rti-sel!scirtp!dfh
jabusch@uiucdcsb.CS.UIUC.EDU (11/26/85)
Correction: if you're going to call them fools, Henry, preface that with 'rich'.
josh@polaris.UUCP (Josh Knight) (11/27/85)
In article <261@rtp47.UUCP> meissner@rtp47.UUCP (Michael Meissner) writes: >It goes even further, since all of IBM's mainframes also include emulators for >their previous machines (which I believe are the 704 and 1600). Now adays, >the IBM 3084 emulating an IBM 704, runs faster than the original machine. Some >of IBM's biggest customers run accounting programs written in the early 70's, >for which there is no source available (or the source is all assembler). Well...almost... The last model for which 1401/1440/1460 and 1410/7010 compatibility was available was the 370/158. The last model for which 7070/7074, 7080 and 709/7090/7094 II compatibility was available was the 370/168. Quite a while ago, actually (mid 70's). These features are not available on any of the 303x, 308x or 3090 processors (reference "IBM System/370 Processor Summary: Processors", publication number GA22-7001). I do keep seeing adds for a product (can't remember the vendor, sorry :-) which purports to convert 1401 autocoder (essentially 1401 assembly language) into COBOL. Also, there may be software emulators (simulators?), but I don't know of them. I'm not very knowledgeable about this, but I think one might be able to micro-code the 308x series processors for your critical 1401 applications, call your IBM sales representative for a quote (-: (-: :-) :-). Any opinions (expressed or implied) or errors are mine and not my employer's. -- Josh Knight, IBM T.J. Watson Research josh at YKTVMH on BITNET, josh.yktvmh@ibm-sj on CSnet, ...!philabs!polaris!josh
david@daisy.UUCP (David Schachter) (11/27/85)
In article <552@scirtp.UUCP> dfh@scirtp.UUCP (David F. Hinnant) writes: >In this 'age' of new! and improved! software (SuperCalc --> Lotus 1-2-3 >--> ??) I don't think maintaining the bridge between applications on >microprocessor driven systems is as important as it once was (any may >still be) with mainframes. Applications software simply changes too fast. > >-- > David Hinnant > SCI Systems, Inc. > ...{decvax, akgua}!mcnc!rti-sel!scirtp!dfh Daisy Systems has invested a few hundred person-years in writing and debugging software for CAE applications. Portability to us is very, very important. Our software ran adequately on 8086s and quite nicely on 80286s. The ability to run '286 software on the '386 without change but at twice the clock rate, is a big win for us and for our customers. It is easier to port code to different processors in the same family than between families. At least, judging by experience porting code between members of the '86 family and porting the same code to other processors. By preserving backward compatibility, Intel allows old software to run while new software is written. For Daisy's customers, this means they can preserve their old knowledge (how to use old programs) and learn how to use new '386-only programs at whatever speed they want to learn. Backwards compatibility means not forcing your customers to convert. That's worth a lot. [I AM RESPONSIBLE FOR MY WRITING ABOVE. NO ONE ELSE IS. THIS ARTICLE DOES NOT REPRESENT OFFICIAL DAISY OPINION.]
henry@utzoo.UUCP (Henry Spencer) (11/30/85)
> Correction: if you're going to call them fools, Henry, preface that > with 'rich'. As in "I'll be rich if I can only convince my program to run on this @%&$^%$#!& processor with those @$#@#&^%&! 64KB segments!"? :-) :-) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
mdm@ecn-pc.UUCP (Mike D McEvoy) (12/03/85)
>> Correction: if you're going to call them fools, Henry, preface that >> with 'rich'. >As in "I'll be rich if I can only convince my program to run on this >@%&$^%$#!& processor with those @$#@#&^%&! 64KB segments!"? :-) :-) > Henry Spencer @ U of Toronto Zoology 1) Last I checked, the 386 had segments just a bit larger than 64k. 2) High level languages make this problem transparent to the user. The majority of the free world refuses to use asssembler other than when necessary and rarely does a module exceed 64k.
wdm@ecn-pc.UUCP (Tex) (12/03/85)
In article <433@ecn-pc.UUCP> mdm@ecn-pc.UUCP (Mike D McEvoy) writes: > >>> Correction: if you're going to call them fools, Henry, preface that >>> with 'rich'. >>As in "I'll be rich if I can only convince my program to run on this >>@%&$^%$#!& processor with those @$#@#&^%&! 64KB segments!"? :-) :-) >> Henry Spencer @ U of Toronto Zoology > > >1) Last I checked, the 386 had segments just a bit larger than 64k. True, INTEL finally fixed (badly) one of their major flaws. >2) High level languages make this problem transparent to the user. > The majority of the free world refuses to use asssembler other than > when necessary and rarely does a module exceed 64k. > Spoken by one who has never written code for the 808x. True, individual modules rarely exceed 64k in length, but what about entire programs? What about "modules" which have to call other "modules" that are not in the same segment? How about compiler models? How do they impact execution speed? All these questions appear trivial to those who have never written code for the 808x. They aren't, however.
mdm@ecn-pc.UUCP (Mike D McEvoy) (12/03/85)
In article <434@ecn-pc.UUCP> wdm@ecn-pc.UUCP (Tex) writes: >>>As in "I'll be rich if I can only convince my program to run on this >>>@%&$^%$#!& processor with those @$#@#&^%&! 64KB segments!"? :-) :-) >>> Henry Spencer @ U of Toronto Zoology > >>2) High level languages make this problem transparent to the user. >> The majority of the free world refuses to use asssembler other than >> when necessary and rarely does a module exceed 64k. > > Modules rarely exceed 64k in length, but what about entire programs? > What about "modules" which have to call other "modules" that are > not in the same segment? How about compiler models? How do they > impact execution speed? I don't know of anyone who "likes" the 808X family better than the 680X0. Nor will I dispute that the segmented architecture can degrade (significantly) the performance of the Intel products in many "real world" situations. In the vast majority of situations, the problem is made transparent to the PROGRAMMER using high level languages. That does not imply that it will occur without a penalty such as a more complex compiler or a degrading of performance due to an increase in overhead or that it is often necessary to "code around" the problems that a (64k) segmented architecture causes. Last I heard, TANSTAAFL still ruled the world. Thank heaven that a good compiler can help hide strange hardware from the programmer.
nather@utastro.UUCP (Ed Nather) (12/06/85)
[Discussing 64K segments:] > 2) High level languages make this problem transparent to the user. > You left out the ":-)" operator. The limitations imposed by the 3 C and 4 Fortran compilers I have tried on the 80x8x are far from transparent to the user ... they are crippling. -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.UTEXAS.EDU
johnl@ima.UUCP (12/07/85)
/* Written 1:44 pm Dec 3, 1985 by 5@utzoo@ecn-pc in ima:net.micro */ >>>>As in "I'll be rich if I can only convince my program to run on this >>>>@%&$^%$#!& processor with those @$#@#&^%&! 64KB segments!"? :-) :-) >>>2) High level languages make this problem transparent to the user. >> What about "modules" which have to call other "modules" that are >> not in the same segment? How about compiler models? How do they >> impact execution speed? >Nor will I dispute that the segmented architecture can degrade (significantly) >the performance of the Intel products in many "real world" situations. >In the vast majority of situations, the problem is made transparent to the >PROGRAMMER using high level languages. That does not imply that it will occur >without a penalty such as a more complex compiler or a degrading of performance >due to an increase in overhead or that it is often necessary to "code around" >the problems that a (64k) segmented architecture causes. >Thank heaven that a good compiler can help hide strange hardware from the >programmer. Oh, stop it. It's just not true that existing compilers can hide the 808x's segmentation. I have just spent the last year and a half writing a large program for the 808x with 5 other people. We spent about 1/4 of our time dealing with the addressing nonsense on the Intel chip. The problem is that if you have more than 64K total of data, you have to worry about allocating that data to segments, and about addressing those segments. Compilers are not much help. I really wish that it were true that a good compiler existed that could hide the addressing from us, but it's not. I looked hard, and there is no compiler of any sort that simultaneously hides the addressing problems and generates code adequate for programs that one can sell. There just isn't. Nor is there likely to be one any time soon. Please correct me if I'm wrong, but don't bother if you haven't run at least a 1,000 line program through your compiler. The sooner the 386 gets into the world and lets me ignore segmentation, the better. You'd think that a 386, having thousands of segments each which can be huge, would let you make real use of segmentation, but you'd be wrong because there are no languages around that make using them worth it. John Levine, ima!johnl PS: PL/I "areas" are the closest I've seen to a high-level equivalent of big segments, and they're still awful.
brad@looking.UUCP (Brad Templeton) (12/08/85)
In article <97800013@ima.UUCP> johnl@ima.UUCP writes: > >/* Written 1:44 pm Dec 3, 1985 by 5@utzoo@ecn-pc in ima:net.micro */ >Oh, stop it. It's just not true that existing compilers can hide the >808x's segmentation. I have just spent the last year and a half writing a >large program for the 808x with 5 other people. We spent about 1/4 of our >time dealing with the addressing nonsense on the Intel chip. The problem >is that if you have more than 64K total of data, you have to worry about >allocating that data to segments, and about addressing those segments. >Compilers are not much help. > >I really wish that it were true that a good compiler existed that could >hide the addressing from us, but it's not. I looked hard, and there is no >compiler of any sort that simultaneously hides the addressing problems and >generates code adequate for programs that one can sell. There just isn't. >Nor is there likely to be one any time soon. Please correct me if I'm >wrong, but don't bother if you haven't run at least a 1,000 line program >through your compiler. > >John Levine, ima!johnl > I'll correct you, because you are wrong. Our product (A syntax-directed programming environment for Pascal) is a 30,000 line program. Using both the Mark Williams C compilers and Microsoft C compilers, this program required almost no segment funnies to compile and run in large model. Funny code to deal with segmentation is only required in dealing with the operating system or special hardware, and it isn't all that hard to write. It has to be redone for every computer, anyway. A minor amount of segment dependent code also existed where we had deliberately used it to increase efficiency. You appear (correct *me* if I'm wrong) to be confusing "dealing with segmentation" with "writing good C programs." Clean C programs, the kind that run properly through LINT, will have no trouble running under the 8086 "Large" model if they don't use single objects larger than 64K in size. Since very few programs do that, your anxiety is excessive. Now I will tell you that we did have lots of segment headaches later, but that was only because of a conscious decision to switch to a "hybrid" model using the Microsoft C compiler. We did this because we required the program to run on a 256K IBM-PC. If we had been content to run on a 320K machine, there would have been no troubles. But then, I don't think we could have ever gotten the program to run in that small an amount of memory on a machine with all 32 bit pointers. ----- It seems to me that most people complaining about problems using LARGE model are just not programming properly. I understand this, because I had to run our system through Lint to pull out mistakes before attempting to compile it large. If you use a Vax, 68000 or pdp-11 all day, you almost thing assumptions like sizeof(int) == sizeof(char *) and "0 is a valid pointer argument" are OK. They are *NOT*, and not just for the 8086. So declare your types, and if you really want to put a pointer into an int, use a special typedef version of int that you can make long. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
hes@ecsvax.UUCP (Henry Schaffer) (12/09/85)
> In article <97800013@ima.UUCP> johnl@ima.UUCP writes: > > > >/* Written 1:44 pm Dec 3, 1985 by 5@utzoo@ecn-pc in ima:net.micro */ > >Oh, stop it. It's just not true that existing compilers can hide the > >808x's segmentation. > >... > >John Levine, ima!johnl > > > > I'll correct you, because you are wrong. Our product (A syntax-directed > programming environment for Pascal) is a 30,000 line program. Using both > the Mark Williams C compilers and Microsoft C compilers, this program > required almost no segment funnies to compile and run in large model. > ... > > ... Clean C programs, the kind > that run properly through LINT, will have no trouble running under the > 8086 "Large" model if they don't use single objects larger than 64K in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > size. Since very few programs do that, your anxiety is excessive. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ----- > Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473 I would say that many programs use single objects larger than 64k. (How big a double precision floating point matrix fits in 64k?) Most programs are (or should be) sufficiently modular that 64k code segments are not much of a penalty, but in scientific/statistical/simulation computations it is quite common to have data objects >64k. (On an 8088/8086 allowing the transparent- to-the-user use of data objects>64k appears to have an unavoidable and significant performance degradation.) There may be some language bias here. Traditionally C has not seen heavy use in the number-crunching community and so large data objects may not have been common. The number-crunching community has primarily used FORTRAN, and that's where you might see things like: REAL*8 XPY(2500), XPX(31375) (which is a quote from one of my programs - where we sometimes have to increase the dimensions to handle a larger than usual data set!) --henry schaffer
ray@othervax.UUCP (Raymond D. Dunn) (12/09/85)
>>1) Last I checked, the 386 had segments just a bit larger than 64k. ^^^^^^^^^^^^^^^^^ > True, INTEL finally fixed (badly) one of their major flaws. ^^^^^^^ Hey folks, there's enough to argue about without getting *facts* wrong! Sure there are things wrong with the 386, but this is not one of them. As has been said on this group before, in protected mode, the maximum segment size on the 386 is the *same* as the maximum physical memory size: 2^32, or 4 Gigabytes. This means that software can, if required, set all segments registers to address all of memory, and thus run 100% as if segmentation did not exist. It also means that, in addition to the features provided by the MMU, software can *IF REQUIRED*, use the segmentation capabilities for its own requirements with *NO DISADVANTAGES*. This includes stack boundary checking, fast swapping/boundary checking of data contexts etc. These are facilities which are available *within each task*. They are not just restricted to the protection etc provided by an MMU under the control of the operating system to protect one task from another. Lets get it clear: The 386 segmentation registers give *additional* functionality over say, the 680x0. The 386 segmentation registers do *not* decrease functionality or ease of use, as they did on the 8086. Ray Dunn. ..philabs!micomvax!othervax!ray
nather@utastro.UUCP (Ed Nather) (12/10/85)
> In article <97800013@ima.UUCP> johnl@ima.UUCP writes: > > > >I really wish that it were true that a good compiler existed that could In article <464@looking.UUCP>, brad@looking.UUCP (Brad Templeton) writes: > I'll correct you, because you are wrong. Our product [...] > required almost no segment funnies to compile and run in large model. ^^^^^^ ^^ > Funny code to deal with segmentation is only required in dealing with > the operating system or special hardware, and it isn't all that hard to write. > "Transparent ..." (your phrase, Brad) does NOT mean "almost no ...", it means NONE. Not a few. Not easy to do. NONE. -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.UTEXAS.EDU
kenyon@nmtvax.UUCP (12/10/85)
In article <> david@daisy.UUCP (David Schachter) writes: >By preserving backward compatibility, Intel allows old software to run >while new software is written. For Daisy's customers, this means they But why write new software when the old works so well? By this reason we should just port everything to CP/M and work on designing *FAST* Z80s. There have been some rumors about a 75 Meg version of the 8080 coming out. If this is true, we won't have to worry about backward compatibility. And an address will be an address like God intended... :-) Why should I disclaim this? I didn't write it. -- Robert Kenyon p / ...ucbvax!unmvax!nmtvax!kenyon / kenyon@nmt / g Your father was a mother and your hamster smells of elderberries!
johnl@ima.UUCP (12/11/85)
/* Written 2:16 pm Dec 8, 1985 by brad@looking in ima:net.micro */ > In article <97800013@ima.UUCP> johnl@ima.UUCP writes: > >Oh, stop it. It's just not true that existing compilers can hide the > >808x's segmentation. I have just spent the last year and a half writing a > I'll correct you, because you are wrong. ... > > You appear (correct *me* if I'm wrong) to be confusing "dealing with > segmentation" with "writing good C programs." > > Now I will tell you that we did have lots of segment headaches later, > but that was only because of a conscious decision to switch to a > "hybrid" model using the Microsoft C compiler. We did this because we > required the program to run on a 256K IBM-PC. If we had been content > to run on a 320K machine, there would have been no troubles. No, I'm right, but I think we actually agree. Our program is a lot bigger than yours -- it's over 400K of code, mostly medium model but about 10% large model. The problems I'm concerned about are not debugging problems, but algorithmic problems. You have to use a hybrid model to make the program fit (and we overlay that) and you have to write lots of extra code to deal with mixed models. If your objects are bigger than 64K, then you have to decide whether to use huge model code which is huge and slow, or large model code which needs fiddling to deal with large objects. Then we had to write even more code to deal with the Lotus/Intel bank switching scheme which, after all, is only needed because of the addressing complications. There is simply a lot of code in our program that is there solely because of the segmented architecture. I suspect that if we redid it for a 386, the total size would be smaller because even though some of the instructions would be bigger, the ones that do the segment munging wouldn't be there at all. Sure, if your program fits into your computer compiled huge model and runs fast enough for you, segmentation is no problem. For the rest of us, it is a royal pain. John Levine, ima!johnl
henry@utzoo.UUCP (Henry Spencer) (12/11/85)
> >> Correction: if you're going to call them fools, Henry, preface that > >> with 'rich'. > >As in "I'll be rich if I can only convince my program to run on this > >@%&$^%$#!& processor with those @$#@#&^%&! 64KB segments!"? :-) :-) > > 1) Last I checked, the 386 had segments just a bit larger than 64k. Let me know when you see 386 machines out in the field in huge numbers, i.e. suitable for getting rich from. The 386 is barely out of the vaporware stage right now. > 2) High level languages make this problem transparent to the user. Provided you've got a good compiler -- they don't grow on trees -- and either none of your data objects is larger than 64KB, or else you don't care if the code runs at the speed of a drifting continent. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
tim@ism780c.UUCP (Tim Smith) (12/11/85)
In article <433@ecn-pc.UUCP> mdm@ecn-pc.UUCP (Mike D McEvoy) writes: >2) High level languages make this problem transparent to the user. > The majority of the free world refuses to use asssembler other than > when necessary and rarely does a module exceed 64k. How about data? Data can easily exceed 64k. And high level languages do not make the segmentation transparent to the user. The only deficiency of the 80?86 that a high level language can hide is the small number of registers. The 80386 still has too few registers, but at least the registers can be pretty much used for whatever the programmer wants, unlike the 80[<3]6. I wish Motorola would put an MMU on the 68020. The real nice thing about the 386 is that it has a real MMU, and there is almost no way that a hardware designed can build a 386 system that I can't run UNIX on. With the 68020, the hardware guys can quite easily screw up memory management. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim ^ ^-- Not ISM780C, ignore the header!
brad@looking.UUCP (Brad Templeton) (12/11/85)
In article <879@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes: > > I would say that many programs use single objects larger than 64k. (How big >a double precision floating point matrix fits in 64k?) Most programs are >(or should be) sufficiently modular that 64k code segments are not much of a >penalty, but in scientific/statistical/simulation computations it is quite >common to have data objects >64k. (On an 8088/8086 allowing the transparent- >to-the-user use of data objects>64k appears to have an unavoidable and >significant performance degradation.) > There may be some language bias here. Traditionally C has not seen heavy >use in the number-crunching community and so large data objects may not have >been common. The number-crunching community has primarily used FORTRAN, and >that's where you might see things like: >REAL*8 XPY(2500), XPX(31375) >(which is a quote from one of my programs - where we sometimes have to >increase the dimensions to handle a larger than usual data set!) > >--henry schaffer Yes, numerical applications do generate such arrays. Although I suspect you would be hard presed to find single *vectors* longer than 64K, so I think you might be able to get around such troubles if you wanted a small amount of effort. But all this aside, is the 8086 the processor to run these heavy floating point applications? Certainly not without the 8087, and if you're that keen on speed but insist on 8086 you should have gone to 286, where it is actually possible to have segment 2 64K beyond segment 1, allowing full sized objects with little work by the compiler. I don't know if anybody has done this, though. I don't think most of the bitching is from numerical analysts, somehow. Besides, several compilers now offer arrays larger than 64K, and the Microsoft C compiler even allows individual objects to be huge in a program that is not otherwise bogged down with the complex pointer arithmetic this involves. -- Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473
tom@stc.UUCP (12/11/85)
>In article <97800013@ima.UUCP> johnl@ima.UUCP writes: > >>/* Written 1:44 pm Dec 3, 1985 by 5@utzoo@ecn-pc in ima:net.micro */ >Oh, stop it. It's just not true that existing compilers can hide the >808x's segmentation. I have just spent the last year and a half writing a >large program for the 808x with 5 other people. We spent about 1/4 of our >time dealing with the addressing nonsense on the Intel chip. The problem >is that if you have more than 64K total of data, you have to worry about >allocating that data to segments, and about addressing those segments. >Compilers are not much help. > >I really wish that it were true that a good compiler existed that could >hide the addressing from us, but it's not. I looked hard, and there is no >compiler of any sort that simultaneously hides the addressing problems and >generates code adequate for programs that one can sell. There just isn't. >Nor is there likely to be one any time soon. Please correct me if I'm >wrong, but don't bother if you haven't run at least a 1,000 line program >through your compiler. > >John Levine, ima!johnl > Pascal 86 version 3.1 handles more then 64k data invisibly. -- (Roots Rockers)
wdm@ecn-pc.UUCP (Tex) (12/11/85)
In article <154@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >> In article <97800013@ima.UUCP> johnl@ima.UUCP writes: >> >I really wish that it were true that a good compiler existed that could >In article <464@looking.UUCP>, brad@looking.UUCP (Brad Templeton) writes: >> I'll correct you, because you are wrong. Our product [...] >> required almost no segment funnies to compile and run in large model. > ^^^^^^ ^^ ^^^^^ >> Funny code to deal with segmentation is only required in dealing with >> the operating system or special hardware, and it isn't all that hard to write >"Transparent ..." (your phrase, Brad) does NOT mean "almost no ...", >it means NONE. Not a few. Not easy to do. NONE. >-- >Ed Nather I had to throw in one more thing - LARGE model also costs you around 10-30% in execution speed and is ALOT larger. Of course I guess you could drop in one of the NEC chips and gain it back. Doesn't the NEC chip gain alot of speed due to the fact that it has an adder in the BIU which is necessary due to the segementation scheme? If I am wrong about the NEC chip, sorry. I know I'm not wrong about the LARGE model, though. Ciao.
Ahlstrom@hi-multics.arpa (Mark L. Ahlstrom) (12/11/85)
I understand the problem of having a single object larger than 64K in large model, but what can you do about the problem of having lots of initialized structures and string constants that add up to more than 64K? I am using Lattice ver2.15, and from what I can figure out, the compiler will only allow one data segment for these structures. Thus, you can't have more than 64K TOTAL... not just the problem of a single structure larger than 64K. Am I missing somethings?? --Mark (Mark Ahlstrom at HI-Multics)
phil@amdcad.UUCP (Phil Ngai) (12/12/85)
In article <738@othervax.UUCP> ray@othervax.UUCP (Raymond D. Dunn) writes: >The 386 segmentation registers do *not* decrease functionality or >ease of use, as they did on the 8086. You seem to have forgotten the 8086's parent. When compared to the 8080, segmentation did not decrease functionality or ease of use either. If you wanted to only address 64K as you could on the 8080, that was trivial. If you wanted 64K of data and 64K of code, that is easy too. There was no decrease of functionality in the Intel family. The 8086 is NOT a 32-bit microprocessor. Stop complaining that it doesn't work well as one. Of course it doesn't, it isn't one. If you guys keep comparing the 8086 to the 68000, a chip which came out a few years later, then I'll compare the 6809 to the 80386. Actually, I agreed with most of what Ray said, such as the following: >The 386 segmentation registers give *additional* functionality over >say, the 680x0. -- Even lefties have rights! Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
ray@othervax.UUCP (Raymond D. Dunn) (12/13/85)
In article <7353@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) responds to my earlier posting: >> The 386 segmentation registers do *not* decrease functionality or >> ease of use, as they did on the 8086. > You seem to have forgotten the 8086's parent. When compared to the > 8080, segmentation did not decrease functionality or ease of use > either. If you wanted to only address 64K as you could on the 8080, > The 8086 is NOT a 32-bit microprocessor. Stop complaining that it > doesn't work well as one. Of course it doesn't, it isn't one. > If you guys keep comparing the 8086 to the 68000, a chip which came > out a few years later, then I'll compare the 6809 to the 80386. Phil, you misinterpreted my statement (i.e. I stated it badly). What I was *trying* to say was: "The 386 segmentation registers do *not* decrease functionality or ease of use compared to other equivalent processors which do not have these registers, as they did on the 8086 WHEN LIKEWISE COMPARED". In other words, we agree, and I'm not one of the "you guys" alluded to! I *DO* belive it is valid to compare the 8086 with the 68000 however, if one is comparing the relative merits of two current machines, or the choice of a processor for a future development. Ray Dunn. ..philabs!micomvax!othervax!ray
henry@utzoo.UUCP (Henry Spencer) (12/13/85)
> The 386 segmentation registers give *additional* functionality over > say, the 680x0. Useless additional functionality. Tailfins. > The 386 segmentation registers do *not* decrease functionality or > ease of use, as they did on the 8086. True, since virtually everyone will run "small model" on the 386, i.e. ignoring the segmentation almost completely.
henry@utzoo.UUCP (Henry Spencer) (12/13/85)
> If you guys keep comparing the 8086 to the 68000, a chip which came > out a few years later, then I'll [make an equally silly comparison] Why shouldn't we compare them? Intel advertising does it all the time. In grossly misleading ways, too.
tim@ism780c.UUCP (Tim Smith) (12/14/85)
In article <466@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes: > >But all this aside, is the 8086 the processor to run these heavy floating >point applications? Certainly not without the 8087, and if you're that >keen on speed but insist on 8086 you should have gone to 286, where it is >actually possible to have segment 2 64K beyond segment 1, allowing full >sized objects with little work by the compiler. I don't know if anybody >has done this, though. > It could have been done with no work from the compiler if Intel had put the bits in a reasonable place. A full pointer has a selector and an offset. Here is what they look like: Selector: -------------------------------------------------------- | Segment Number ( 13 bits ) | Other Stuff ( 3 bits ) | -------------------------------------------------------- Offset: -------------------------------------------------------- | Offset in Segment ( 16 bits ) | -------------------------------------------------------- If they had swapped the Segment number and the Other Stuff, then one could stick 64k segments one after the other, and do reasonable stuff with pointers, and everyone would live happily ever after. Could someone from Intel please explain why it was done this way instead? The only guess I have heard is that since the Segment Number is an index into a table of eight byte things, they saved having to do a shift by three. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
kds@intelca.UUCP (Ken Shoemaker) (12/14/85)
> > The 80386 still has too few registers, but at least the registers can be > pretty much used for whatever the programmer wants, unlike the 80[<3]6. > oh, don't tell this to Henry Spencer...the 32032 only has 8 general purpose registers. I guess lots of registers just isn't elegant. (all this said, tongue implanted firmly in cheek). -- yes, some uncomplicated peoples still believe this myth... Ken Shoemaker, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds ---the above views are personal.
phil@amdcad.UUCP (Phil Ngai) (12/15/85)
In article <6228@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> If you guys keep comparing the 8086 to the 68000, a chip which came >> out a few years later, then I'll [make an equally silly comparison] > >Why shouldn't we compare them? Intel advertising does it all the time. >In grossly misleading ways, too. I would have to say that I am often ashamed by some of the claims I have seen made for the 8086 family. However I hope we don't have to sink to the level of the liberal arts educated marketing slime who push 8086s. Am I the only one who sees neither the 8086 or the 80286 are 32-bit microprocessors? -- Even lefties have rights! Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
rde@ukc.UUCP (R.D.Eager) (12/16/85)
> ...the 80386 still has too few registers....
Oh yeah? What's so great about lots of registers? You're better off with
a nice simple design (no bits wasted in each instruction to specify
which register) and a good fast cache. A cache is after all a dynamic
equivalent to the attempts (often bad ones) at register optimisation by
compilers.
Let's keep to machines with ONE general purpose register, with a few
extra ones for specific purposes. All these gripes about 80*6 registers
are completely out to lunch. The 8086 has:
AX - a general purpose, cheap to use register
DX - an extension to AX
CX - a counter
BX - an index register
SP - a stack front register
BP - a stack frame pointer
SI,DI- base registers for off stack data
Let's stop moaning about the lack of general purpose registers...who
needs them? Keep the compiler writer's job easy...
I am not trying to enter a segmentation discussion; that's a separate
issue!
--
Bob Eager
rde@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589ray@othervax.UUCP (Raymond D. Dunn) (12/16/85)
In article <6227@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) responds to my earlier article (without acknowledgement): >> The 386 segmentation registers give *additional* functionality over >> say, the 680x0. > >Useless additional functionality. Tailfins. > >> The 386 segmentation registers do *not* decrease functionality or >> ease of use, as they did on the 8086. > >True, since virtually everyone will run "small model" on the 386, i.e. >ignoring the segmentation almost completely. In the past I have considered Henry's postings relatively rational and intelligent. Why is he now repeatedly firing off cheap shots at the 386 which ignore reality? There's plenty of valid arguments to be used against the 386 if you so want, as well as some very good ones. On the 386, "small model" (which of course does not exist per se) is 4 Gigabytes. If you re-read his posting, you see that he is not stating any factual errors, only presenting them in a way which is irrationally derogatory to the 386. OK, but lets move that discussion to net.politics, and use this news category to act like the professionals we are supposed to be. In that way it may be possible to retain our plausibility. The posting he used as the basis for his statements was one attempting to debunk the misconception that segmentation on the 386 gives the same disadvantages as on earlier x86 processors. He says that the segmentation registers give nothing and wont be used by anyone. Fine, I'm willing to accept that as the basis of a discussion. So now instead of using those features as an invalid argument *against* the 386, lets ignore them and look at the rest of the chip (and read the data sheets, so that we can discuss *facts*). Ray Dunn. ..philabs!micomvax!othervax!ray
ray@othervax.UUCP (Raymond D. Dunn) (12/16/85)
In article <6228@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ..[comparing 8086 to 68000]... > >Why shouldn't we compare them? Intel advertising does it all the time. >In grossly misleading ways, too. Lets practice what we preach Henry! Ray Dunn. ..philabs!micomvax!othervax!ray
henry@utzoo.UUCP (Henry Spencer) (12/17/85)
> > The 80386 still has too few registers, but at least the registers can be > > pretty much used for whatever the programmer wants, unlike the 80[<3]6. > > oh, don't tell this to Henry Spencer...the 32032 only has 8 general > purpose registers. I guess lots of registers just isn't elegant. > (all this said, tongue implanted firmly in cheek). It's noteworthy that Bliss-11, at the time the most heavily optimizing compiler in the known universe, custom-built to exploit the pdp11 to its limit, and, in particular, making a huge effort to use registers as effectively as possible, did not manage to use more than 3 or 4 registers effectively on most programs. I'm not aware of any more recent work on this sort of thing (*sigh*, most likely it's sitting in my To Be Read pile waiting for me to notice it...), but this augurs ill for the usefulness of large register sets. Especially since they have to be saved and restored on function calls and context switches. Actually, I like lots of registers. But when I say "lots", I mean LOTS. As in RISC machine with overlapping windows, with multiple banks so that I can do process switches without save/restore. If the register count doesn't have a "K" on the end, forget it. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
farren@well.UUCP (Mike Farren) (12/17/85)
In article <154@ism780c.UUCP>, tim@ism780c.UUCP (Tim Smith) writes: > It could have been done with no work from the compiler if Intel had > put the bits in a reasonable place. A full pointer has a selector and > an offset. Here is what they look like: > > Selector: > -------------------------------------------------------- > | Segment Number ( 13 bits ) | Other Stuff ( 3 bits ) | > -------------------------------------------------------- > > Offset: > -------------------------------------------------------- > | Offset in Segment ( 16 bits ) | > -------------------------------------------------------- > Huh? Wha? Am I awake yet? That is NOT the way the segments work; the "Other Stuff" is not a pointer into any kind of table, in fact, it doesn't exist at all. A full pointer on the 8086 is two words. The first word is nothing more than a pointer to a 16-byte boundary which is the beginning of the 64K segment. The second word is the offset within the segment, and is simply added to the (left-shifted 4 bits) first word to obtain a 20-bit real address. -- Mike Farren uucp: {dual, hplabs}!well!farren Fido: Sci-Fido, Fidonode 125/84, (415)655-0667 USnail: 390 Alcatraz Ave., Oakland, CA 94618
kds@intelca.UUCP (Ken Shoemaker) (12/18/85)
> Let's stop moaning about the lack of general purpose registers...who > needs them? Keep the compiler writer's job easy... > -- > Bob Eager uh oh, I guess we blew it by making the 386 registers more general... -- remember, if you do it yourself, sooner or later you'll need a bigger hammer Ken Shoemaker, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds ---the above views are personal.
wendyt@isieng.UUCP (Wendy Thrash) (12/18/85)
In <498@ukc.UUCP>, rde@ukc.UUCP (R.D.Eager) writes > A cache is after all a dynamic equivalent to the attempts (often bad ones) > at register optimisation by compilers. > Let's stop moaning about the lack of general purpose registers...who > needs them? Keep the compiler writer's job easy... Come on, R.D., make my day -- give me lots of g.p. registers; I can handle it. We compiler writers don't want easy jobs, we want job security. :-) The equivalence between a cache and lots of g.p. registers (well-used) seems to me about the same as the equivalence between Diana Rigg and an inflatable doll; it works well in theory, but loses something in the implementation. :-p (No, I don't necessarily mean to imply that Diana Rigg is well-used.)
asgard@well.UUCP (J. R. Stoner) (12/18/85)
In article <351@well.UUCP> farren@well.UUCP (Mike Farren) writes: >In article <154@ism780c.UUCP>, tim@ism780c.UUCP (Tim Smith) writes: >> It could have been done with no work from the compiler if Intel had >> put the bits in a reasonable place. A full pointer has a selector and >> an offset. Here is what they look like: >> >> ( BONK BONK! :-) >> >> > > Huh? Wha? Am I awake yet? That is NOT the way the segments work; >the "Other Stuff" is not a pointer into any kind of table, in fact, it doesn't >exist at all. A full pointer on the 8086 is two words. The first word is >nothing more than a pointer to a 16-byte boundary which is the beginning of >the 64K segment. The second word is the offset within the segment, and is >simply added to the (left-shifted 4 bits) first word to obtain a 20-bit real >address. > >-- > Mike Farren > uucp: {dual, hplabs}!well!farren > Fido: Sci-Fido, Fidonode 125/84, (415)655-0667 > USnail: 390 Alcatraz Ave., Oakland, CA 94618 > Not at all. The information previously posted was in reference to the user documentation for the iAPX 286 and not the brain damaged 808x (the black book). -- From the mania of: J. R. (May the farce be with you) Stoner, Esq.
tim@ism780c.UUCP (Tim Smith) (12/18/85)
In article <351@well.UUCP> farren@well.UUCP (Mike Farren) writes: > Huh? Wha? Am I awake yet? That is NOT the way the segments work; > I was talking about the 80286 in protected mode. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
tim@ism780c.UUCP (Tim Smith) (12/18/85)
In article <498@ukc.UUCP> rde@ukc.UUCP (R.D.Eager) writes: > >> ...the 80386 still has too few registers.... > >Oh yeah? What's so great about lots of registers? You're better off with >a nice simple design (no bits wasted in each instruction to specify >which register) and a good fast cache. A cache is after all a dynamic >equivalent to the attempts (often bad ones) at register optimisation by >compilers. > Well, the 80?86 doesn't seem to have a cache. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
farren@well.UUCP (Mike Farren) (12/19/85)
In article <351@well.UUCP> I wrote: >In article <154@ism780c.UUCP>, tim@ism780c.UUCP (Tim Smith) writes: >> It could have been done with no work from the compiler if Intel had >> put the bits in a reasonable place. A full pointer has a selector and >> an offset. Here is what they look like: >> > > Huh? Wha? Am I awake yet? Well, the answer is, of course, no. If I had been paying more attention (or had bothered to look at the previous articles), I would have realized that the subject wasn't 8086 segments, but 80286 protected mode, as many have been kind enough to point out. My apologies to all - I'll try and see that it doesn't happen again. -- Mike Farren uucp: {dual, hplabs}!well!farren Fido: Sci-Fido, Fidonode 125/84, (415)655-0667 USnail: 390 Alcatraz Ave., Oakland, CA 94618
campbell@sauron.UUCP (Mark Campbell) (12/19/85)
> If you guys keep comparing the 8086 to the 68000, a chip which came > out a few years later, then I'll [make an equally silly comparison] Yes, these Motorola-ites take the cake for sheer gall. Imagine, having the audacity to compare these two parts. Thank goodness that Intel and their legions wouldn't do anything equally as foolish, such as comparing the 80386 to the 68020. (:-) -- Mark Campbell Phone: (803)-791-6697 E-Mail: !ncsu!ncrcae!sauron!campbell
campbell@sauron.UUCP (Mark Campbell) (12/19/85)
In article <498@ukc.UUCP> rde@ukc.UUCP (R.D.Eager) writes: > >> ...the 80386 still has too few registers.... > >Oh yeah? What's so great about lots of registers? You're better off with >a nice simple design (no bits wasted in each instruction to specify >which register) and a good fast cache. A cache is after all a dynamic >equivalent to the attempts (often bad ones) at register optimisation by >compilers. [...] A cache IS NOT a dynamic (or any other type) equivalent to "attempts at register optimization". Named versus unnamed memory space arguments not withstanding, caches are in most cases slower (by at least a memory cycle) than register accesses. >Let's keep to machines with ONE general purpose register, with a few >extra ones for specific purposes. [...] You don't want an 80*86, you want a stack-based machine. It's rather difficult locating these, as most have had rather severe problems commercially. >Let's stop moaning about the lack of general purpose registers...who >needs them? Keep the compiler writer's job easy... [...] And keep the applications slow... -- Mark Campbell Phone: (803)-791-6697 E-Mail: !ncsu!ncrcae!sauron!campbell
johnl@ima.UUCP (12/19/85)
/* Written 7:03 pm Dec 16, 1985 by henry@utzoo in ima:net.micro */ > > The 80386 still has too few registers > It's noteworthy that Bliss-11, at the time the most heavily optimizing > compiler in the known universe, custom-built to exploit the pdp11 to its > limit, and, in particular, making a huge effort to use registers as > effectively as possible, did not manage to use more than 3 or 4 registers > effectively on most programs. I'm not aware of any more recent work on > this sort of thing ... The IBM 801 project had great success keeping their registers full. Indeed, their machine had 32 symmetrical registers, and the compiler used Cocke's graph coloring scheme for register assignment. The registers were all the same, though, and it's not clear to me how well their work would apply to the 80x86 architecture where the registers are not only different, but overlay (ah, ax, and eax, for example.) A fascinating challenge, and no doubt a problem that will be solved just as Intel announces a RISC chip with 128 registers to meet the competition from Motorola, National, INMOS, NCR, Fairchild, NEC, Fujitsu, Siemens, IBM, and AT&T. ( :-) sort of) John Levine, ima!johnl PS: I miss the PDP-8. Now THAT was symmetrical.
david@sun.uucp (David DiGiacomo) (12/20/85)
In article <6233@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >It's noteworthy that Bliss-11 ... did not manage to use more than 3 or 4 >registers effectively on most programs. I don't think static analysis is appropriate here. An optimized rasterop/bitblt routine can make good use of 20-30 registers. On a typical workstation, those registers would be worthwhile even if no other code used them. (Those with bitblt hardware could try optimizing namei().) -- David DiGiacomo {decvax, dual, ihnp4, ucbvax}!sun!david Sun Microsystems, Mt. View, CA (415) 960-7495
oleg@birtch.UUCP (Oleg Kiselev) (12/20/85)
In article <735@stc-b.stc.UUCP> tom@stc.UUCP (Tom Sanders) writes: >Pascal 86 version 3.1 handles more then 64k data invisibly. "Invisibly" for who? Programmer? Or the user? If your program is busy all the time trying to figure out which segment its next memory access is in and keeps setting segments on every memory read/write, it's hardly "invisible"! Then it's not THAT transparent when you look at the time factor,eh? It has been said that large model programs run as slowly on PC/AT as on PC/XT. Small models run a lot faster on the AT. So, what kind of invisibility is that? Besides, I have seen all too many C compilers that screw up the structure addressing and pointer referencing in large model programs. What assurance do you have that your Pascal compiler will not do ugly things when you start using dynamic structures? -- Disclamer: My employers go to church every Sunday, listen to Country music, and donate money to GOP. I am just a deviant. +-------------------------------+ Don't bother, I'll find the door! | "VIOLATORS WILL BE TOAD!" | Oleg Kiselev. | Dungeon Police |...!{trwrb|scgvaxd}!felix!birtch!oleg --------------------------------+...!{ihnp4|randvax}!ucla-cs!uclapic!oac6!oleg
oleg@birtch.UUCP (Oleg Kiselev) (12/20/85)
In article <735@stc-b.stc.UUCP> tom@stc.UUCP (Tom Sanders) writes: >Pascal 86 version 3.1 handles more then 64k data invisibly. "Invisibly" for who? Programmer? Or the user? If your program is busy all the time trying to figure out which segment its next memory access is in and keeps setting segments on every memory read/write, it's hardly "invisible"! Then it's not THAT transparent when you look at the time factor,eh? It has been said that large model programs run as slowly on PC/AT as on PC/XT. Small models run a lot faster on the AT. So, what kind of invisibility is that? Besides, I have seen all too many C compilers that screw up the structure addressing and pointer referencing in large model programs. What assurance do you have that your Pascal compiler will not do ugly things when you start using dynamic structures? -- Disclamer: My employers go to church every Sunday, listen to Country music, and donate money to GOP. I am just a deviant. +-------------------------------+ Don't bother, I'll find the door! | "VIOLATORS WILL BE TOAD!" | Oleg Kiselev. | Dungeon Police |...!{trwrb|scgvaxd}!felix!birtch!oleg --------------------------------+...!{ihnp4|randvax}!ucla-cs!uclapic!oac6!oleg
henry@utzoo.UUCP (Henry Spencer) (12/21/85)
> On the 386, "small model" (which of course does not exist per se) is > 4 Gigabytes. Quite true, but irrelevant to the point I was making: that the 386's segments are largely useless, and do not constitute a useful feature. The *reason* they are useless is indeed that "small model" on the 386 is big enough for most needs. This is a major improvement on the situation for the earlier *86's, where the segments were just as brain-damaged but could not be avoided because "small model" was too small. > He says that the segmentation registers give nothing and wont be used > by anyone. > > Fine, I'm willing to accept that as the basis of a discussion. So > now instead of using those features as an invalid argument *against* > the 386, lets ignore them and look at the rest of the chip (and read > the data sheets, so that we can discuss *facts*). I wasn't using them as an argument *against* the 386, I was attempting to refute an article of yours which said quite explicitly (a) the segments are a neat feature, and (b) they provide added [implied to be useful] functionality over the MMUs on things like the 68020. Which is wrong, as you have just admitted. Now that the size of the linear addresses is large enough, the ability to segment your address space is essentially useless, and can properly be ignored except in unusual cases. About time. The only way in which the segments are an argument *against* the 386 is that they take up silicon which could have been better used for other things. I do not see this as a serious defect; most of the other CPUs around have at least one equally-useless "feature". (The MOVEP instruction was of some interest on the 68000 but is as useful as feet on a fish for the 68020; the 32032 string instructions run slower than tight loops that do the same thing; the VAX is loaded with useless gingerbread; even the fairly-clean PDP11 has the brain-dead MARK instruction.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
larry@geowhiz.UUCP (Larry McVoy) (12/22/85)
>The IBM 801 project had great success keeping their registers full. Indeed, >John Levine, ima!johnl I've heard rumors that IBM is coming out with a RISC machine. I've also heard that this is their Unix workstation. I've also heard that it's based on the 801. (Boy, I've heard a lot, huh?) Anyway, I just heard, which should be read that it's scuttlebutt, not gospel.... Disclaimers aside, what can you all tell me (and the net) about the 801? What happened to it? Did it make to production? Just curious, -- Larry McVoy ----------- Arpa: mcvoy@rsch.wisc.edu Uucp: {seismo, ihnp4}!uwvax!geowhiz!geophiz!larry "If you are undertaking anything substantial, C is the only reasonable choice of programming language" - Brian W. Kerninghan
feustel@ihlpl.UUCP (Feustel) (12/23/85)
> > On the 386, "small model" (which of course does not exist per se) is > > 4 Gigabytes. > > Quite true, but irrelevant to the point I was making: that the 386's > segments are largely useless, and do not constitute a useful feature. 386 segments provide a useful way to access data files as a byte-addressable array instead of as a series of records which must be seeked, getted and putted.
peter@baylor.UUCP (Peter da Silva) (01/01/86)
> > > On the 386, "small model" (which of course does not exist per se) is > > > 4 Gigabytes. > > > > Quite true, but irrelevant to the point I was making: that the 386's > > segments are largely useless, and do not constitute a useful feature. > > 386 segments provide a useful way to access data files as a byte-addressable > array instead of as a series of records which must be seeked, getted and putted. Would you care to explain what memory addressing has to do with accessing files. Perhaps you are referring to a possible mapping of the file directly into the process' address space... something which is possible in any hardware architecture that supports VM (whether or not the software supports it, of course). This is, of course, merely a way of putting the seeking, reading, and writing off for a little while. It may actually be useful, though it sounds a little inefficient. In any case it's hardly a capability restricted to segmented architectures. In fact it has nothing to do with segmenting... it's an attribute of VM. -- -- Peter da Silva -- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076
henry@utzoo.UUCP (Henry Spencer) (01/03/86)
> > ... irrelevant to the point I was making: that the 386's > > segments are largely useless, and do not constitute a useful feature. > > 386 segments provide a useful way to access data files as a byte-addressable > array instead of as a series of records which must be seeked, getted and putted. You can do that perfectly well with a paging machine, given a decent MMU design; you don't need the silly segments. That's pretty much how shared- text binaries work on 4BSD, and (as I recall) 4.2 was originally planned to have more general file-into-address-space mapping primitives as well. On a paged machine. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
kds@intelca.UUCP (Ken Shoemaker) (01/06/86)
> You can do that perfectly well with a paging machine, given a decent MMU > design; you don't need the silly segments. That's pretty much how shared- > Henry Spencer @ U of Toronto Zoology or as, you can do most anything with most anything, I mean, even the VAX doesn't have referenced bits in their page tables, yes? Hardware that is there can make some operations easier and faster, and I think you'd have to put segments in this area. -- remember, if you do it yourself, sooner or later you'll need a bigger hammer Ken Shoemaker, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds ---the above views are personal.
glen@intelca.UUCP (Glen Shires) (01/07/86)
> > > ... irrelevant to the point I was making: that the 386's > > > segments are largely useless, and do not constitute a useful feature. > > > > 386 segments provide a useful way to access data files as a byte-addressable > > array instead of as a series of records which must be seeked, getted and putted. > > You can do that perfectly well with a paging machine, given a decent MMU > design; you don't need the silly segments. That's pretty much how shared- > text binaries work on 4BSD, and (as I recall) 4.2 was originally planned > to have more general file-into-address-space mapping primitives as well. > On a paged machine. > -- I agree completely: You just write code that deals with pages, keeping track of which pieces of code are located in which sets of pages, and their attributes (read/write/present/dirty/etc). Essentially maintaining a data structure that maps logical code chunks into the hardware pages and keeping track what's where. Gee whiz...That's exactly what segmentation on top of paging is. The only difference is that you prefer to do it in software, while the 386 lets you to do it in either hardware or software. -- ^ ^ Glen Shires, Intel, Santa Clara, Ca. O O Usenet: {ucbvax!amd,pur-ee,hplabs}!intelca!glen > ARPA: "amd!intelca!glen"@BERKELEY \-/ --- stay mellow