seenu@isieng.UUCP (Seenu Banda) (01/13/89)
I have seen the DEC 3100 announcement today. This workstation sounds very similar to the one made by Integrated Solutions (ISI). Can anyone enlighten me more about the 3100 to understand the differences between the two products? Integrated Solution has been shipping Advantedge 2000 workstation for a few months and announced the product in December 1988. Advantedge 2000 is also based on R2000 operating at 16.67MHz. This UNIX workstation has an on-board SCSI and Ethernet. The major differences in the system are Operating System: DEC uses Ultrix ISI uses RISC/os (UMIPS) or ISI's UNIX "Dual Universe" which can run 4.3BSD and Sys V.3 simultaneously. Similarities: Size: Both look about the same size UNIX: Both have a version of UNIX I/O: Both have SCSI and Ethernet. ISI uses a 80186 compatible NEC V50 for I/O processing. Does anyone know what the 3100 uses? Has anyone come across any performance numbers? Pricing: Comparable I will appreciate any information (or pointers to info.) on the DECstation 3100. Thanks in advance, seenu ..!pyramid!isieng!seenu
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/14/89)
In article <979@isieng.UUCP> seenu@isieng.UUCP (Seenu Banda) writes: >This workstation sounds very similar to >the one made by Integrated Solutions (ISI). >Can anyone enlighten me more about the 3100 >to understand the differences between the >two products? > I am unfamilar with the ISI product, but from the press release info one can see the following (for starters). 1) Byte ordering is reverse of ALL other MIPS based machines. Binaries are NOT compatible. 2) Ultrix is propritary, and differs from the MIPS OS offerings considerably. If you like Ultrix on your VAX, perhaps you will like it on your MIPS box. But if you come from any other unix environment it is quite a change. 3) 3100 has a max memory size of 24Mb RAM, 1Gb disk. I have talked to one user of the 3100, and he was very unhappy that his code (100+K lines of fortran) ran on their VAX, their Sun, their SGI IRIS, and etc., but after considerable effort it is still not running on the 3100. If you decide to buy a MIPS based processor, stick with one that is STANDARD comforming. Why make your life difficult. If you don't like the ISI, after a bit, you can go with someone else (MIPS, Ardent, etc.). If you don't like the 3100 upgrade choices, you're stuck with an OS AND processor change. **** This opinon is clearly mine. Sun would prefer you buy a SPARC based system.:>! *** Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (01/14/89)
<85330@sun.uucp>, by khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering): > 2) Ultrix is propritary, and differs from the MIPS OS offerings > considerably. If you like Ultrix on your VAX, perhaps > you will like it on your MIPS box. But if you come from > any other unix environment it is quite a change. I beg to differ with the gentleman from Sun. I use both Ultrix and SunOS, and while I usually prefer Sun workstations to timeshared VAXen or even VAXstations, I don't find Ultrix and SunOS to be as different from each other as either is from, say, System V or HP-UX, or even a nominally bsd-flavored Apollo Domain/IX (SR9.x -- I haven't used SR10.x). Ultrix is proprietary, but that's a red herring. SunOS is also proprietary. (I was going to follow the first sentence with "So is SunOS", then realized that I didn't mean that SunOS is a red herring, regardless of what Sun's competitors may want the market to believe :)) Mike Khaw -- internet: mkhaw@teknowledge.com uucp: {uunet|sun|ucbvax|decwrl|ames|hplabs}!mkhaw%teknowledge.com hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
vixie@decwrl.dec.com (Paul A Vixie) (01/15/89)
Wow, Sun and DEC fighting in the workstation market. Who'd've ever thought? # 1) Byte ordering is reverse of ALL other MIPS based machines. # Binaries are NOT compatible. Well, waitaminute. There is no ABI for MIPSCO as yet; binaries from an Ardent are not going to run on a MIPSCO M1000. Heck, binaries from a SysV MIPSCO box don't run on a UMIPS 4.3 MIPSCO box. So while this point is valid for binary data files, if by "binaries" you mean binary code files, either a.out or *.o, then this point is etherial since there is nothing to be binary-compatible WITH. # 2) Ultrix is propritary, and differs from the MIPS OS offerings # considerably. If you like Ultrix on your VAX, perhaps # you will like it on your MIPS box. But if you come from # any other unix environment it is quite a change. As Mike Khaw pointed out, Ultrix is no more or less proprietary than SunOS or UMIPS. I'm sure that if somebody actually _wanted_ to license Ultrix for their non-Digital hardware, some arrangement could be made. BTW, I'd like to buy a copy of the SunOS port that was done for the Compaq during the RR development. What's that? You say Sun isn't in the software business and that if I want SunOS I've got to buy some Sun or Sony hardware? Funny thing, that. Ultrix is not that much of a change, really. It's enough like SysV that most SVID code compiles, and it's enough like BSD that most BSD code compiles. And it's enough like SunOS that most SunOS users would feel quite at home. Note that I don't particularly _like_ Ultrix (or SunOS), I'm a BSD purist. But as of 3.0, Ultrix is enough like BSD that I no longer pine and whine for 4.3. (I'm in research, not product; I get to say things like "I don't like Ultrix" and they don't fire me. Neat, huh?) # 3) 3100 has a max memory size of 24Mb RAM, 1Gb disk. This bothered me at first, too. But then I realized: "hey! it's a workstation, not a compute server." Fastest damned workstation _I've_ ever used. It gives the Ardent Titan stiff competition as a color X11 server. Of course, Ardent isn't done optimizing their server yet, so eventually their custom hardware will blow the 3100 away, X11-wise. But the 3100 has just a dumb 8-bit frame buffer, and it _screams_. In fairness to the 24MB/1GB limitation -- there aren't many things I want to do that need more than 24MB of RAM or 1GB of disk, and of those, they are better run on a DECWRL Titan :-). # I have talked to one user of the 3100, and he was very unhappy that # his code (100+K lines of fortran) ran on their VAX, their Sun, their # SGI IRIS, and etc., but after considerable effort it is still not # running on the 3100. This is surprising. Granted, for VAX/Ultrix you can get a VMS-compatible FORTRAN compiler, while I believe the 3100 compiler is from MIPSCO. But I would have thought that the MIPSCO compiler would be as VMS-like as possible, since that's what Ardent and Sun and everybody else is doing with their FORTRAN compiler. But I readily concede this point -- I don't like FORTRAN anyway. # If you decide to buy a MIPS based processor, stick with one that is # STANDARD comforming. Why make your life difficult. If you don't like # the ISI, after a bit, you can go with someone else (MIPS, Ardent, # etc.). If you don't like the 3100 upgrade choices, you're stuck with # an OS AND processor change. This is just silly. Which STANDARDs? As I said above, the a.out and *.o file format is different on almost every MIPS-based machine I know of. If someone wants to compile something on an Ardent and run it on an ISI or SGI to prove me wrong, go for it. If you get a 3100 and don't like it, your options are about the same as if you bought an ISI or SGI or SPARC machine and didn't like it -- you tell your software vendors that you want to switch architechtures or hardware vendors or whatever, they tell you what your options are. Then you tell your hardware vendors what you want to do and watch them fight it out. Am I missing some- thing important? # **** This opinon is clearly mine. Sun would prefer you buy a SPARC # based system.:>! *** What you said. The above (non-quoted) opinions are clearly mine; I have no idea what I'd say if I were speaking officially for DEC. If anyone quotes any of the above, please include this paragraph. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
pavlov@hscfvax.harvard.edu (G.Pavlov) (01/15/89)
In article <85330@sun.uucp>, khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) writes: > ............. If you like Ultrix on your VAX, perhaps > you will like it on your MIPS box. But if you come from > any other unix environment it is quite a change. Sorry, but coming from Ultrix and porting to Sun and (mainly) "generic" MIPS, I haven't seen this "quite a change". Except, at times, with fortran. But we always had problems porting fortran between DEC machines........ > >.... code (100+K lines of fortran) ran on their VAX, their Sun, their > SGI IRIS, and etc., but after considerable effort it is still not > running on the 3100. > greg pavlov, fstrf, amherst, ny
rbradbur@hqpyr1.oracle.UUCP (Robert Bradbury) (01/15/89)
In article <VIXIE.89Jan14123901@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: > >Well, waitaminute. There is no ABI for MIPSCO as yet; binaries from an Ardent >are not going to run on a MIPSCO M1000. Heck, binaries from a SysV MIPSCO box >don't run on a UMIPS 4.3 MIPSCO box. > >So while this point is valid for binary data files, if by "binaries" you mean >binary code files, either a.out or *.o, then this point is etherial since there >is nothing to be binary-compatible WITH. There is no excuse for this. Vendors of large application programs (like the Oracle RDBMS) are getting very tired of vendors of hardware who can't get their act together to standardize on ABI's. We have had to expand our computer room 3 times in the last 3 years to fit in all the machines from various vendors running different flavors of the UNIX operating system. Because UNIX vendors have not standardized the operating system call interfaces for each hardware type, Oracle's UNIX development staff now has more people than any other development department. We have dozens of people who do nothing but take many megabytes of source code, compile it on yet another UNIX box and spend weeks figuring out what that manufacturer did not manage to get right in his port of UNIX. Sequent and Pyramid have demonstrated that you *can* provide a single environment which supports both BSD and SV system calls. The 88000 group is wisely starting out up front by standardizing on an ABI. The reason UNIX has taken so long to succeed in the market place is because there was no application software. The reason that there was no application software is because application vendors cannot afford the machines, development time, support staff, etc. to support 14 different flavors of UNIX for each hardware platform out there. (Quick test: how many vendors are there of UNIX 68000 boxes?) MIPS & DEC are shooting themselves in the foot by not providing a standard ABI's for the large software vendors. We will not port software for a machine unless it is clear that there is sufficient demand out there to justify our investment. By subdividing the MIPSCO marketplace MIPS & DEC are that much less likely to be able to generate sufficient sales for vendors to justify supporting those os/hardware combinations. And of course the lack of application vendor support on those platforms increases the probability that customers will chose to go with other machines (like 88000 based boxes) where there is a standard ABI and software vendors know months or years in advance that they will be able to justify porting their software to that environment. >As Mike Khaw pointed out, Ultrix is no more or less proprietary than SunOS or >UMIPS. As a software vendor we do not care what flavor of UNIX you are running (provided you support the System V IPC primitives). We do not care what you call your version of UNIX nor what fancy extras you add to make your box unique (csh, more, NFS, RFS, X windows, etc.). where we start to get really frustrated is when you release different versions of UNIX for the *SAME BOX* which cannot run the same binary programs. (Are you listening DEC? MIPSCO?) >Ultrix is not that much of a change, really. It's enough like SysV that most >SVID code compiles, and it's enough like BSD that most BSD code compiles. And >it's enough like SunOS that most SunOS users would feel quite at home. Note >that I don't particularly _like_ Ultrix (or SunOS), I'm a BSD purist. But as >of 3.0, Ultrix is enough like BSD that I no longer pine and whine for 4.3. That's funny last time I looked at our code there were a fair number of #ifdef's to work around bugs and/or idiosyncrasies for Ultrix, BSD and the SunOS. (You aren't there yet folks. Ask the software vendors if you want to know for sure! :-)). >(I'm in research, not product; I get to say things like "I don't like Ultrix" >and they don't fire me. Neat, huh?) > Yes, research people would like BSD 4.3. A great environment for research, but not one that can support a high performance RDBMS due to its lack of robust IPC primitives. I'll take a real O.S. that conforms to the SVID any day of the week. >What you said. The above (non-quoted) opinions are clearly mine; I have no >idea what I'd say if I were speaking officially for DEC. If anyone quotes >any of the above, please include this paragraph. >-- >Paul Vixie >Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 >Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013 I'm not in management at Oracle, but I suspect my opinions are close to management's given the amount of money we have to spend to support products for vendors who can't get it organized to standardize binary interfaces. Robert Bradbury Oracle Corporation (206) 782-9474 hplabs!oracle!rbradbur
jg@jumbo.dec.com (Jim Gettys) (01/16/89)
I always get amused by Sun folks pushing binary comptibility, when Sun has sold at least (depending upon how you count) three or four or five architectures (680x0, 80386 and SPARC) and has never maintained even complete compatibility between any two series of machines, even within the same family of processors (Sun 1, Sun 2, Sun 3, Sun 4, Sun 386i), and often even between releases of their OS. Maybe they've finally learned the lesson Digital learned over a decade ago... During the same period, Digital has produced 6 additional implementations of the same VAX architecture, fully binary compatible with each other, to go along with the three which precedes Sun's existance. And with very limited exceptions, there has been binary upward compatibility on both VMS and Ultrix during this entire period. Throwing stones in glass houses is usually a mistake. We certainly carefully considered which byte order the PMAX (DECstation 3100) should be run in; in fact, early prototypes have a jumper (never used) which determines the byte order. Now let us examine what various people have suggested; that we should be selling UMIPS on a big endian MIPS machine. I believe those same people would be castigating us about offering two Unix versions, incompatible with each other, of differing byte orders, maximizing the trouble to port to DEC hardware. (Not to even mention the problems this would cause us internally). No matter what we did, it was not possible to make everyone happy. There are certainly good arguments to the byte order question; both sides have cogent arguments on their sides; just look at the wasted network bandwidth in this and other newsgroups on the topic. And being one of the authors of one of the more portable pieces of software in the world, I am completely familiar with the problems of porting software, having spent significant amounts of my time while a DEC employee making sure it would run on RT/PC's, Suns, and other machines. So we went with the byte order which, though us Unix bigots may not like it, is most compatible with the most machines and software in the world, the Intel based PC's (next to which, the hundreds of thousands of VAXes pale, though internal to Digital it is a real issue; for example we have DECnet at FRS, which probably woundn't have made it if the byte order were the other way). I have already recieved mail from one major third party software vendor who was very happy to hear the machine was the same byte order as the PC, as it was going to aid his port from the PC to the DECstation 3100. But as usual, there are arguments on both sides, as another note from a different vendor in this newsgroup suggests. And the choice certainly aids other ports and compatibility with the VAX; for example, the entire core client X distribution compiles and runs on the DECstation 3100 without any ifdef's in any code (you do have to fool it into thinking it is a VAX, as at the moment there are architecture ifdef's for mips in the imake code which really should be UMIPS ifdefs; fixed we hope in X11R4). The port of X to the PMAX was by far the easiest I know of (having participated in ports to the Sun, RT/PC, and a bit to the Apollo and CCI over the last 3 years, though a CCI running 4.3BSD was about as trivial back in V10 days). And I will be happy when OSFix makes real binary compatibility possible between vendors using the same architecture/byte order; I certainly understand the problem of the 3rd party vendors. But at the moment, this was the way we could give them the most REAL compatibility to help them until this day actually arrives; it certainly doesn't exist today for anyone's version of Unix. So, on the issue which is one of the biggest portability sticking points, Digital is at completely consistant; all of our current machines are the same byte order (PC, VAX, MAX). Ultrix on the DECstation 3100 looks essentially identical to that on the VAX, and an amazing amount of code recompiles and runs without change. Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory Cambridge Massachusetts, 02139 <the usual disclaimers go here>
mash@mips.COM (John Mashey) (01/16/89)
In article <558@oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes: >In article <VIXIE.89Jan14123901@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: >>Well, waitaminute. There is no ABI for MIPSCO as yet; binaries from an Ardent >>are not going to run on a MIPSCO M1000. Heck, binaries from a SysV MIPSCO box >>don't run on a UMIPS 4.3 MIPSCO box. >Sequent and Pyramid have demonstrated that you *can* provide a single >environment which supports both BSD and SV system calls. The 88000 >group is wisely starting out up front by standardizing on an ABI. >The reason UNIX has taken so long to succeed in the market place >is because there was no application software. The reason that there >was no application software is because application vendors cannot >afford the machines, development time, support staff, etc. to support >14 different flavors of UNIX for each hardware platform out there. >(Quick test: how many vendors are there of UNIX 68000 boxes?) >MIPS & DEC are shooting themselves in the foot by not providing a standard >ABI's for the large software vendors. We will not port software for a >machine unless it is clear that there is sufficient demand out there to >justify our investment. By subdividing the MIPSCO marketplace MIPS & DEC >are that much less likely to be able to generate sufficient sales for vendors >to justify supporting those os/hardware combinations. And of course the lack >of application vendor support on those platforms increases the probability that >customers will chose to go with other machines (like 88000 based boxes) where >there is a standard ABI and software vendors know months or years in advance >that they will be able to justify porting their software to that environment. To inject some reality into this discussion, I observe the following: 1) All MIPS-built machines are big-endian, as are essentially all Rxxxx-based systems. The first MIPS-built systems shipped in 1986. 2) All of the newer MIPS machines are System-V-based (with a whole lot of BSD features, and shortly to have enough to make even BSD-fans (of which we have plenty of at MIPS) happy. The reason for the merge, of course, was EXACTLY the issue of application software; although we are still supporting our BSD customers, of course, we'll be encouraging them to convert upon the next release. I.e., this ABI issue has little to do with BSD versus SYS V. 3) MIPSco does not REQUIRE our customers to do anything in particular. However, you will find that quite a few binaries interchange amongst machines [the Ardent ones are different, given the different FP hardware, but they are working on being able to handle the "standard" binaries.] Synthesis Software Solutions, Inc, works pretty hard on this issue, and we work with our customers to allow necessary extensions to co-exist with the enough compatibilty that most reasonable applications have a chance of being binary-compatible. 4) Across most MIPS-based machines, regardless of who builds them, (and definitely including the DECstation 3100) the same compilers, linker, assembler, calling conventions, object formats, etc, are used. As software developers know, fighting compiler problems/differences is often a worse problem than fighting UNIX differences, because people have often learned to parameterize UNIX variant differences, whereas it's nontrivial to work-around compiler problems, especially with good optimizers, whose bugs can be terrifyingly subtle. [Those of you who know may may have noticed the gray hairs I gained around 1986....] 5) It might have been nice to have gotten the VAXstation 3100 to appear with a big-endian, SYSV-based model. DEC had some perfectly reasonable reasons for going the other way, leading to having 2 ABIs for MIPS-based systems. Given that we (and our customers) were already committed in one direction, we weren't going to change. Given a chip that can go both ways, and compiler support that was also that way, do you REALLY think that we (MIPSco), knowing DEC was going little-endian, should have told them "Well, DEC, since you're going to go little-endian, and really weird, going to port Ultrix, we don't want you as a customer, so go away"??? I don't think this is shooting ourselves in the foot; everybody involved had good reasons to do what they did; maybe, in 1985, we'd have gone little-endian instead, if we expected to end up with DEC as a customer; for some bizarre reason, our business plan didn't count on that....:-) 6) EACH of these 2 ABIs is perfectly capable of gaining sufficient numbers to be interesting to 3rd-party vendors: a) Synthesis' numbers have gotten consdirable interest from 3rd-party folks, without counting DEC. b) I have no data on DEC's ability to attract 3rd-party SW to the 3100. I suspect it may be adequate... :-) About 20,000 MIPS chipsets have been shipped thru 1988, not counting whatever our chip partners have started shipping (as MIPSco phases out of that side of the business ). Now, that's NOTHING compared with the number of 68Ks or 386s, but it's ramping fast, and it is VERY significant in the RISC world, especially because most of those chips are in systems not built directly by MIPS, but by a large variety of other companies. (To answer rbradbur@oracle's comments) I'd note that the 88K is going to have to start showing up in real systems, in significant numbers, and pretty soon, or it isn't going to catch even 50% of the MIPS numbers for a long time.... Note that a lot of the ABI idea was derived from the mess that happened with 68Ks, where {compilers, linkers, assemblers, object code format, math libraries, and even FP-hardware} were different, whereas they're the same across multi-endian MIPS-based machines. 7) Given the commonality of software (remember, these 2 ABI's use a great deal of common software), many programs will port quite easily back and forth, because people won't be fighting surprises in the tools. Weirdly enough, it may even be easier to port from other systems. Anecdotal evidence is not evidence; nevertheless, just to pick a random example, I know of one significant package that ran on Sun-3s (and whose vendor, of course, I'm not allowed to name). It got ported to MIPS boxes about a year ago, and hadn't been gotten working on Sun-4s until about 6 months later, despite serious efforts to do so, starting months before the MIPS-port. I do not believe this is necessarily representative, for several reasons; nevertheless, it does show that one must be extremely careful in waving "source-compatibility" and ABI magic wands over everything and claiming that it's done... Summary: I wish there weren't Big & Little-endian, but they were here before I was in this business. I wish DEC had gone Big-Endian, but they had good reasons not to, and I'm pleased to have them as a customer. Even though the ends are different, I have reason to believe software will move especially easily back and forth, and as an old UNIXer, I'm happy about being able to move software around more machines. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
vixie@decwrl.dec.com (Paul A Vixie) (01/16/89)
In <558@oracle.UUCP> rbradbur@hqpyr1.oracle.UUCP (Robert Bradbury) writes:
# There is no excuse for this. Vendors of large application programs [...]
# are getting very tired of vendors of hardware who can't get their act
# together to standardize on ABI's.
I'm sure there are people at MIPSCO just hopping from one foot to the other
wishing there were an ABI for their chip. I can only guess that they thought
everybody would follow the a.out and *.o and syscall assignments that they
used in their UMIPS and SYSV products; however, various teams of gurus who
had these chips and/or machines handed to them with the directive: "port UNIX
to it and make it look as much like our other products as you can and get it
done in time for COMDEX" just did not have ABI's in mind. I'm not happy about
it, but I do understand it.
Even if they had ABI's in mind, could they have agreed? Would they have let
OSF or MIPSCO mediate? Binding arbitration among competitors? I'll believe
it when I see it. I'd love to see it, of course, but I'd be careful about
threatening to hold my breath until it happens.
# Sequent and Pyramid have demonstrated that you *can* provide a single
# environment which supports both BSD and SV system calls. The 88000
# group is wisely starting out up front by standardizing on an ABI.
I applaud the 88000 people. So far the marketing (and an ABI is _marketing_,
folks!) of the 88000 has been fantastic. It may well be the first counter-
example to what I asserted above about competitors being polite to eachother.
But the 88000 is not yet taking the world by storm, while the MIPSCO chip _is_.
Sequent and Pyramid both have great products, but since Pyramid runs a closed
architechture and since Sequent is incompatible with all other NS32000 and
80386 machines, I don't see them as luminaries of the cause of the ABI.
# MIPS & DEC are shooting themselves in the foot by not providing [...] ABI's
Wait, wait. MIPS may be shooting themselves in the foot, I don't know. But
as Gettys pointed out in another article in this forum, DEC's MIPS-based
machine is as compatible as possible with the rest of what DEC sells. If you
have a VAX/Ultrix port of Oracle, chances are you'll have little trouble
making it run on the 3100.
Also, DEC has always provided as much upward binary compatibility as they
could -- many VMS 1.0 binaries (and RSX-11 binaries, for that matter) will
run on the latest VMS, and most Ultrix 1.0 (or BSD 4.2) binaries will run
on the latest Ultrix. I'm interested in hearing from anyone who thinks
that DEC is about to change that policy.
# Yes, research people would like BSD 4.3. A great environment for research,
# but not one that can support a high performance RDBMS due to its lack of
# robust IPC primitives. I'll take a real O.S. that conforms to the SVID
# any day of the week.
(Groan.)
Have a look at the latest CSRG proposal for IPC if you want to see "robust".
The less said about SVID IPC, the better. :-(.
# I'm not in management at Oracle, but I suspect my opinions are close to
# management's given the amount of money we have to spend to support products
# for vendors who can't get it organized to standardize binary interfaces.
#
# Robert Bradbury
# Oracle Corporation
# (206) 782-9474 hplabs!oracle!rbradbur
Standard disclaimer: I don't speak for DEC, I just work here. If any of my
words above are quoted, please include this paragraph.
--
Paul Vixie
Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600
Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013yuval@taux02.UUCP (Gideon Yuval) (01/16/89)
In article <13508@jumbo.dec.com> jg@jumbo.UUCP (Jim Gettys) writes: >.......... .. .... ... ..... .......... .. ... ...... And being one of the >authors of one of the more portable pieces of software in the world, I am >completely familiar with the problems of porting software, having spent >significant amounts of my time while a DEC employee making sure it would >run on RT/PC's, Suns, and other machines. Which piece of software is this? my E-mail query bounced. Thanks -- Gideon Yuval, yuval@taux01.nsc.com, +972-2-690992 (home) ,-52-522255(work) Paper-mail: National Semiconductor, 6 Maskit St., Herzliyah, Israel TWX: 33691, fax: +972-52-558322
w-colinp@microsoft.UUCP (Colin Plumb) (01/16/89)
mash@mips.COM (John Mashey) wrote: > (To answer rbradbur@oracle's comments) I'd note that the 88K is going to > have to start showing up in real systems, in significant numbers, and > pretty soon, or it isn't going to catch even 50% of the MIPS numbers for > a long time.... Now, John, you've already succeeded in ruining the credibility of the 88000; must you rub it in? (For those who haven't noticed, DEC approached Motorola about second- sourcing the MIPS chip. Reports claim that Motorola was getting pretty serious about this, until they decided it showed a lack of confidence in their own RISC processor. Motorola is now making loud "firmly committed" noises.) -- -Colin (uunet!microsof!w-colinp)
mac@mrk.ardent.com (Mike McNamara) (01/17/89)
In article <VIXIE.89Jan14123901@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: |Keith Bierman of Sun writes: |# If you decide to buy a MIPS based processor, stick with one that is |# STANDARD comforming. Why make your life difficult. If you don't like |# the ISI, after a bit, you can go with someone else (MIPS, Ardent, |# etc.). If you don't like the 3100 upgrade choices, you're stuck with |# an OS AND processor change. | |This is just silly. Which STANDARDs? As I said above, the a.out and *.o file |format is different on almost every MIPS-based machine I know of. If someone |wants to compile something on an Ardent and run it on an ISI or SGI to prove |me wrong, go for it. | Ardent Titans and MIPSCO boxes and SGIs will *not* run each others a.outs, although things like /bin/file will recognize foriegn objects as native sons... And it makes sense, The Ardent Titan is up to four Mips R2000 each tightly intergrated with a custom vector processing unit. What do you expect an M120 to do when given an Ardent `dvma' instruction? (double precision A = B*C+D). (Probably bus error...). [I apologize if there appears to be an advertisment up there... ] [These opinons are my own, and all that... ] mac @ ardent.com
mash@mips.COM (John Mashey) (01/17/89)
In article <279@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >mash@mips.COM (John Mashey) wrote: >> (To answer rbradbur@oracle's comments) I'd note that the 88K is going to >> have to start showing up in real systems, in significant numbers, and >> pretty soon, or it isn't going to catch even 50% of the MIPS numbers for >> a long time.... > >Now, John, you've already succeeded in ruining the credibility of the >88000; must you rub it in? Sorry; no intent to do that: somebody else raised the issue.... > >(For those who haven't noticed, DEC approached Motorola about second- >sourcing the MIPS chip. Reports claim that Motorola was getting >pretty serious about this, until they decided it showed a lack of >confidence in their own RISC processor. Motorola is now making loud >"firmly committed" noises.) No comment. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
guy@auspex.UUCP (Guy Harris) (01/17/89)
>You say Sun isn't in the software business and that if I want >SunOS I've got to buy some Sun or Sony hardware? SunOS runs on Sony hardware? That's news to me....
jkrueger@daitc.daitc.mil (Jonathan Krueger) (01/17/89)
In article <558@oracle.UUCP>, rbradbur@hqpyr1 (Robert Bradbury) discusses:
Interfaces that support software portability
Application binary interfaces
These are two separate issues, distinct and different. Clearly one
can be for the former without affecting one's views on the latter.
Thus when Robert says
We have dozens of people who do nothing but take
many megabytes of source code, compile it on yet
another UNIX box and spend weeks figuring out what
that manufacturer did not manage to get right in
his port of UNIX.
he is arguing for the former, and when he says
when we start to get really frustrated is when you
release different versions of UNIX for the *SAME
BOX* which cannot run the same binary programs.
(Are you listening DEC? MIPSCO?)
he is arguing against the latter. No, that's not a typo: he may
think he's arguing for the latter, but the inability of machine
architectures to specify program compatibility across OS releases
turns his point against the latter.
-- Jon
-- khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/17/89)
In article <1798@ardent.UUCP> mac@mrk.ardent.com (Mike McNamara) writes: >| > Ardent Titans and MIPSCO boxes and SGIs will *not* run each >others a.outs, although things like /bin/file will recognize foriegn >objects as native sons... > > And it makes sense, The Ardent Titan is up to four Mips R2000 >each tightly intergrated with a custom vector processing unit. What do >you expect an M120 to do when given an Ardent `dvma' instruction? >(double precision A = B*C+D). (Probably bus error...). > C'mon old buddy, isn't there a way to generate scalar only code ? Shouldn't one expect scalar only code to be portable ? A vector version of gnu-emacs, for example, might be nice...but being able to "plug and play" can be handy. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
henry@utzoo.uucp (Henry Spencer) (01/17/89)
In article <13508@jumbo.dec.com> jg@jumbo.UUCP (Jim Gettys) writes: >Digital has produced 6 additional implementations of the same VAX >architecture, fully binary compatible with each other, to go along with >the three which precedes Sun's existance... Well, "fully" if you discount the mishmash of four or five different floating-point formats, not all of which exist on all VAXen last I heard... -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
vixie@decwrl.dec.com (Paul A Vixie) (01/17/89)
(Moving this thread to comp.arch) [Bierman] # C'mon old buddy, isn't there a way to generate scalar only code ? # Shouldn't one expect scalar only code to be portable ? A vector # version of gnu-emacs, for example, might be nice...but being able to # "plug and play" can be handy. I'm sure Ardent will decide that it's generally "handy" enough (i.e., a marketable feature) that they will work hard to be compatible with other MIPSCO boxes in the future. But as it stands, I believe their a.out format is generalized for a multi- processor, where the compiler doesn't know how many CPUs the target machine will have but the code STILL takes advantage of however many there are on that machine on that day. Hard to do and still fit into a scalar ABI. I've used Ardent Titans; they aren't as fast as a DECWRL Titan for some things, but since they're a super-workstation and we're a non-product, it's not a fair comparison. Great box. Wish they hadn't stolen our name, though :-). -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
vixie@decwrl.dec.com (Paul A Vixie) (01/17/89)
[Spencer] # Well, "fully" if you discount the mishmash of four or five different # floating-point formats, not all of which exist on all VAXen last I heard... There have been rules for subsetting Vaxen since before there were Vaxen. (I know because I just went looking for "trap type 9" and I ran across a prehistoric version of the Vax Arch Ref Man in the DECWRL library). Some implementations leave out some floating point types; others leave out the POLY and EDITPC and sometimes MOVC. These you do in software; if the hardware can do it (either by basic design or because of an accelerator), you don't see the traps and your code runs faster. I'll admit, it's not the way I'd design something today. But in 1970, they had some design ideas that they couldn't implement in hardware "yet", and some other ideas that they knew would be hard to put into a low-end model later on. Looking back at it, it seems like they did okay. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
bwong@sundc.UUCP (Brian Wong) (01/17/89)
In article <278@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: > In article <558@oracle.UUCP>, rbradbur@hqpyr1 (Robert Bradbury) discusses: > Interfaces that support software portability > Application binary interfaces [quote from bradbury deleted] > he is arguing against the latter. No, that's not a typo: he may > think he's arguing for the latter, but the inability of machine > architectures to specify program compatibility across OS releases > turns his point against the latter. Jonathan, Could you please explain this? I don't think I'm the only one who doesn't understand your logic here. I don't mean to be flip. I genuinely don't follow you here. -- Brian Wong Sun Microsystems bwong@sun.com Vienna, Va. 703-883-1243
hascall@atanasoff.cs.iastate.edu (John Hascall) (01/17/89)
In article <1989Jan17.042349.5379@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <13508@jumbo.dec.com> jg@jumbo.UUCP (Jim Gettys) writes: >>Digital has produced 6 additional implementations of the same VAX >>architecture, fully binary compatible with each other, to go along with >>the three which precedes Sun's existance... >Well, "fully" if you discount the mishmash of four or five different >floating-point formats, not all of which exist on all VAXen last I heard... While they may not all exist in hardware on all VAXen, those that don't have the hardware emulate them in software--so they are there (although maybe slower). This is also true for some of the more esoteric/less used instructions. John Hascall ISU Comp Center
darin@nova.laic.uucp (Darin Johnson) (01/18/89)
In article <979@isieng.UUCP>, seenu@isieng.UUCP (Seenu Banda) writes: > > I have seen the DEC 3100 announcement today. We were beta testing some of the workstations (and still are to some extent). It took me some time to realize that DECstations 3100 referred to the MIPS machine we had, rather than some other VAX (the name plate was missing and I missed the announcement). We called it a PMIPS (as opposed to PVAX). I was quite surprised at how well it ran. It runs a bit faster than our Sun 4/260, but sits comfortably on your desk - similar in size to a Sun 3/60 or 3/50. We wanted to benchmark some LISP also, but didn't have one for the 3100. They also include a small disk hidden in the box that can be used to boot the machine, with NFS used for everything else (we haven't used it, we boot it off a VMS machine - gack). I think this is a nice advantage over a workstation that is completely diskless, or having to buy a boot disk that is larger than you need. Also, DEC has apparently ported Ultrix rather faster than I thought they would, and even has most of the "ifdef VAX" type stuff in place. (I read a article earlier implying that DEC had actually tried porting VMS, but gave up quickly) The DECwindows is interesting, but not exactly to my liking (I haven't read the manual enough to know if I can change a lot of it). Their terminal window client has plenty of bells and whistles (too many for me), but won't work on non-DEC workstations without appropriate fonts, etc. This is something we wanted to be able to do, but at least xterm works (I had suspected earlier that DECwindows would be unusable from non-DEC servers - DEC likes to pervert standards just enough to lock people in). It has a nice price from what I hear. Still, if DEC could come out with a cheaper (less memory, slower, etc.) model in the $5000 range, they could grab a lot of business. Since DEC appears to be turning towards DECwindows as its major interface, it makes sense to have an inexpensive X server. (oh well, just dreamin') Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) "You can't fight in here! This is the war room.."
snoopy@sopwith.UUCP (Snoopy) (01/18/89)
In article <558@oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes: | We have had to expand our computer room | 3 times in the last 3 years to fit in all the machines from various vendors | running different flavors of the UNIX operating system. To properly test your code, you'd have to do this anyway, ABI or no. | The 88000 group is wisely starting out up front by standardizing on an ABI. Is it carved in stone somewhere that any box using a m88k must adhere to the ABI? | The reason UNIX has taken so long to succeed in the market place | is because there was no application software. The reason that there | was no application software is because application vendors cannot | afford the machines, development time, support staff, etc. to support | 14 different flavors of UNIX for each hardware platform out there. I seem to remember a quote along the lines of "It is easier to port Unix to a new machine than to port a major application to a new OS." Perhaps you'd prefer that your roomfull of machines all have very different OSes? Perhaps you could look into porting your one favorite flavor of Unix to all the boxes rather than porting your app to all the flavors of Unix? :-) | Yes, research people would like BSD 4.3. A great environment for research, | but not one that can support a high performance RDBMS due to its lack of | robust IPC primitives. I'll take a real O.S. that conforms to the SVID | any day of the week. SVID, a great environment for porting RDBMS, but not one that can support high performance research. You can yell and scream about bringing all the various versions together all you want, but if you want any progress, if you want things to ever improve over where they are at the time the mightly standard is set, then people are going to do research and add features and change things around. Other people are going to hear about this and pick up some of the changes that they like. And from time to time, some of these changes are going to break your application. Sorry, but that's the way it is. As far as the AT&T ABI thing, perhaps you missed it, but a lot of people were/are unhappy with the way AT&T wants things to be. Note the OSF, the mere existance of which is pretty amasing. Are there too many versions of Unix? Maybe. Is ABI the solution? Probably not. Is there a solution? Probably not, at least if you want things like progress and competition. Not everything can be done in libraries. Did DEC do the right thing making their new box little-endian? Sounds like a bugfix to me. A big-endian lover would disagree. A "all machines from this company should be compatible" person would agree. A "all machines based on this cpu chip should be compatible" person would disagree. _____ /_____\ Snoopy /_______\ |___| tektronix!tekecs!sopwith!snoopy |___| sun!nosun!illian!sopwith!snoopy
mac@mrk.ardent.com (Mike McNamara) (01/18/89)
In article <85553@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: |In article <1798@ardent.UUCP> mac@mrk.ardent.com (Mike McNamara) writes: |> Ardent Titans and MIPSCO boxes and SGIs will *not* run each |>others a.outs, although things like /bin/file will recognize foriegn |>objects as native sons... |> |> And it makes sense, The Ardent Titan is up to four Mips R2000 |>each tightly intergrated with a custom vector processing unit. What do |>you expect an M120 to do when given an Ardent `dvma' instruction? |>(double precision A = B*C+D). (Probably bus error...). |> | |C'mon old buddy, isn't there a way to generate scalar only code ? |Shouldn't one expect scalar only code to be portable ? A vector |version of gnu-emacs, for example, might be nice...but being able to |"plug and play" can be handy. | NASTRAN, GATEWAY, FIDAP, et. al. are interested in Floating Point performance. They sell binaries for big bucks. Hence the desire for an ABI, but the price of loss of performance (from ignoring vendor specific fp (and vendor specific multiple processor synchronization) hardware is too high.) As long as the chip vendors do not supply MP synch. instructions, system vendors will have to roll their own, leading to incompatibility. While MIPSco does provide a FP Coprocessor, we rolled our own Vector FP unit, to get the 64 MFLOPs peak. Gnu-emacs needs a fast integer box with good VM. They distribute source for free. Hence no need for ABI for Gnu-emacs. (Although compatible networking code helps a lot!!) | |Keith H. Bierman mac @ ardent.com
jthomp@texsun.Central.Sun.COM (Jim Thompson Sun Dallas SWAN Engineer) (01/18/89)
In article <85553@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: >In article <1798@ardent.UUCP> mac@mrk.ardent.com (Mike McNamara) writes: >>| [discussion of Mips chips in various boxes.] >> >> And it makes sense, The Ardent Titan is up to four Mips R2000 >>each tightly intergrated with a custom vector processing unit. What do >>you expect an M120 to do when given an Ardent `dvma' instruction? >>(double precision A = B*C+D). (Probably bus error...). >> > >C'mon old buddy, isn't there a way to generate scalar only code ? >Shouldn't one expect scalar only code to be portable ? A vector >version of gnu-emacs, for example, might be nice...but being able to >"plug and play" can be handy. Turns out that a vectorized gnu-emacs is a loose. The only place you pick up speed is in bcopy, and then only for strings longer than the vector length. (At least that's what I found at Convex... :-) Overall, the vector version of gnu emacs was slower than the version compiled without vectorization. (And the version compiled with gcc was better than either!) I have typically found that vectors and vector machines are usually left to the pipe stress freaks and other fp grunts. But then, its been a long time since I wanted to write any Fortran. :-) In most cases, the context switch overhead of getting on the vector board(s) isn't worth the speed increase unless you can keep the dern things fed for some large (relatively speaking) amount of time. For general purpose computing, gimme something like what the people at Prisma are trying to do. (fast GaAs, Unix, SPARC.) (Did that sound like an ad? Sorry.. :-) Disclaimer: I work for Sun. I used to work for Convex. I have friends who work for Prisma. I don't own stock in any of the mentioned companies. I don't speak for Sun, Convex, or Prisma. This has been a recording. -- Jim Thompson jthomp@central.sun.com "I woudn't recommend sex, drugs, or insanity Network Engineering for everyone, but they've always worked for me." Sun Microsystems -- Hunter S. Thompson
seenu@isieng.UUCP (Seenu Banda) (01/19/89)
In article <414@laic.UUCP>, darin@nova.laic.uucp (Darin Johnson) writes: > We were beta testing some of the workstations (and still are to some > .. > have one for the 3100. They also include a small disk hidden in the box ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > that can be used to boot the machine, with NFS used for everything else > (we haven't used it, we boot it off a VMS machine - gack). I think this This is really interesting. This is the first time I heard about a hidden disk in the 3100. Does anybody know more about this disk? How small (or big) is it? 10MB? seenu ..!pyramid!isieng!seenu #include <standard.disclaimer>
bga@raspail.UUCP (Bruce Albrecht) (01/19/89)
I've been seeing the acronym ABI a lot recently. What does it stand for?
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/19/89)
In article <85330@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: | If you decide to buy a MIPS based processor, stick with one that is | STANDARD comforming. Why make your life difficult. If you don't like | the ISI, after a bit, you can go with someone else (MIPS, Ardent, | etc.). If you don't like the 3100 upgrade choices, you're stuck with | an OS AND processor change. Those of us who work with a number of vendors would be delighted to have an LSB standard. Those damn PC won't go away, so machines like the VAX give fewer "learning opportunities" than any other byte order machines. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
steve@fnord.umiacs.umd.edu (Steven D. Miller) (01/19/89)
The 'hidden' disk in the DECstation 3100 is a 105MB, 3.5 inch SCSI disk. You can put two of them in the box with the CPU, if I'm not mistaken. If you'd prefer, you can also purchase 332MB disks, but they're in the 5 inch form factor and sit in a sidecar box. -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
slackey@bbn.com (Stan Lackey) (01/19/89)
In article <1153@raspail.UUCP> bga@raspail.UUCP (Bruce Albrecht) writes: >I've been seeing the acronym ABI a lot recently. What does it stand for? British Motor Works! :-)
ekrell@hector.UUCP (Eduardo Krell) (01/19/89)
In article <986@isieng.UUCP> seenu@isieng.UUCP (Seenu Banda) writes: >Does anybody know more about this disk? How small (or >big) is it? 10MB? It's a 3.5 inch half-height, 104 MB (formatted) drive. It's optional, though. The internal option is called RZ23 and is listed at $2400 and the external version is called RZ22 and listed at $2850 (prices according to Digital Review). Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
vixie@decwrl.dec.com (Paul A Vixie) (01/19/89)
[seenu] # This is really interesting. This is the first time I heard about a hidden # disk in the 3100. Does anybody know more about this disk? How small (or # big) is it? 10MB? They call the internal disk an RZ23. I don't know where it is in the product line, or whether it even made it into the product line :-), or how much it costs. They're useful for swap space. About 100MB each, I think, with room for two of them in my prototype (check with your salesman for better details). They're 3.5-inch SCSI drives. Disclaimer: I don't speak for DEC, I just work here. Don't quote me, don't hold me or DEC to any promises I seem to have made, etc, etc, etc. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
hascall@atanasoff.cs.iastate.edu (John Hascall) (01/19/89)
In article <986@isieng.UUCP> seenu@isieng.UUCP (Seenu Banda) writes: >In article <414@laic.UUCP>, darin@nova.laic.uucp (Darin Johnson) writes: >> have one for the 3100. They also include a small disk hidden in the box > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >This is really interesting. This is the first time I heard about a hidden >disk in the 3100. Does anybody know more about this disk? How small (or >big) is it? 10MB? Is there really a hidden disk? Or is this person just talking about the RZ22 and RZ23 which are 3.5" half height SCSI drives (52 and 104 Mbytes respectively) [HHHW half-height half-width? :-) ] which are indeed very small. John Hascall
pavlov@hscfvax.harvard.edu (G.Pavlov) (01/20/89)
In article <558@oracle.UUCP>, rbradbur@hqpyr1.oracle.UUCP (Robert Bradbury) writes: > [ a long diatribe on the lack of absolute standardization among Unix-based hardware vendors ] As a user, I have not found the differences between the systems we have used particularly onerous. Maybe it is the nature of our particular applications, but the majority of our intra-Unix ports have been relatively painless, some- times surprisingly trivial. Nothing compared to the "bad old days" when we tried to move between hardware vendor-specific operating systems. But what has been a royal pain is moving data between different brands of dbms's. Each vendor insists on storing data differently, using proprietary interfaces between front ends and back ends, etc. The DBMS industry has overwhelmingly declared support for the "SQL standard". Too bad that it is so far away from reality. Differences in syntax, exten- sions, and host-language call implementations make this a hollow marketing claim. I appreciate the problems caused by Unix variants. But the Unix industry is way ahead of the dbms industry in offering inter-vendor operability and portability. greg pavlov, fstrf, amherst, ny
keith@imagen.UUCP (Keith Rich) (01/21/89)
In article <12989@steinmetz.ge.com> you write: :In article <85330@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: : :| If you decide to buy a MIPS based processor, stick with one that is :| STANDARD comforming. Why make your life difficult. If you don't like :| the ISI, after a bit, you can go with someone else (MIPS, Ardent, :| etc.). If you don't like the 3100 upgrade choices, you're stuck with :| an OS AND processor change. : : Those of us who work with a number of vendors would be delighted to :have an LSB standard. Those damn PC won't go away, so machines like the :VAX give fewer "learning opportunities" than any other byte order :machines. :-- : bill davidsen (wedu@ge-crd.arpa) : {uunet | philabs}!steinmetz!crdos1!davidsen :"Stupidity, like virtue, is its own reward" -me I get a kick out of the above logic. I suppose that this means that the PC which was released in 1981 was the reason for the LSB standard being adopted for the Vax which was released in 1977. What does this mean in terms of the PDP-11 which was released in 1970? And why didn't the PDP-10 follow this LSB standard? Actually, the PC followed the 8080 which was released circa 1974. In any case, you can thank (or blame) DEC for the LSB "standard". All machines used the MSB standard until DEC "improved" the situation in 1970.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/24/89)
In article <2932@imagen.UUCP> keith@imagen.COM (Keith Rich) writes: | [ I wrote ] | : Those of us who work with a number of vendors would be delighted to | :have an LSB standard. Those damn PC won't go away, so machines like the | :VAX give fewer "learning opportunities" than any other byte order | :machines. [ my sig deleted ] | I get a kick out of the above logic. I suppose that this means that the PC | which was released in 1981 was the reason for the LSB standard being adopted | for the Vax which was released in 1977. What does this mean in terms of the | PDP-11 which was released in 1970? And why didn't the PDP-10 follow this | LSB standard? What brought that on? I not only didn't mean that, I never said it. What I said was that people who work in a multi-vendor environment like LSB in their large machines because some programs have been written for the PC which port well into VAXen and the like. Yes I know you can write programs which will run on anything, but unless you want to write everything yourself, you use what you get. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
darin@nova.laic.uucp (Darin Johnson) (01/24/89)
In article <986@isieng.UUCP> seenu@isieng.UUCP (Seenu Banda) writes: >In article <414@laic.UUCP>, darin@nova.laic.uucp (Darin Johnson) writes: > >> have one for the 3100. They also include a small disk hidden in the box > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> that can be used to boot the machine, with NFS used for everything else > >This is really interesting. This is the first time I heard about a hidden >disk in the 3100. Does anybody know more about this disk? How small (or >big) is it? 10MB? Since I wasn't the primary tester/installer, I don't have that much in the way of detail, but there was a small disk inside the box. This is probably not the same model as the one that will be sold as 'diskless'. But then again, since the disk was probably 3-1/2 or 5-1/4 inch, it probably isn't big enough to support UNIX and users/applications. Most likely, it was intended to eliminate swapping over the network. I'll have to go look in the manuals to see how big it was. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) "You can't fight in here! This is the war room.."
abstine@sun.soe.clarkson.edu (Arthur Stine) (01/24/89)
From article <420@laic.UUCP>, by darin@nova.laic.uucp (Darin Johnson): > In article <986@isieng.UUCP> seenu@isieng.UUCP (Seenu Banda) writes: >>In article <414@laic.UUCP>, darin@nova.laic.uucp (Darin Johnson) writes: >> >>> have one for the 3100. They also include a small disk hidden in the box >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> that can be used to boot the machine, with NFS used for everything else >> >>This is really interesting. This is the first time I heard about a hidden >>disk in the 3100. Does anybody know more about this disk? How small (or >>big) is it? 10MB? > The new 3100's have various SCSI disk options. The small (3.5") internal disk options are: RZ22 52MB paging disk, RZ23 104MB primary storage disk, and the RZ55 332MB (5.25") disk. This is in addition to the RX23 1.44MB floppies, the new RRD40 optical drive, and the TK50Z tape. The RZ22 is intended as a page/swap area only and not for primary storage. As far as performance: Drive RZ22 RD53 RZ23 RD54 RZ55 ------ ----- ---- ---- ---- ---- Capacity 52M 71M 104M 159M 332M Ave. Access 33 38 33 38 24 Xfer rate MB/s 1.25 .625 1.25 .625 1.25 form factor 3.5" 5.25" 3.5" 5.25" 5.25" full/half hgt half full half full full price ++ $4,274 $2,400 $4,590 ++ ++ the RZ22 and RZ55 are only available imbedded in the systems and not as add-on options. RZ55 is a DECstation 3100 has a transfer rate of 4MB/s using Sync SCSI. RZ22 is available on VAXstation-3100 only, RZ23 is available on VAXstation 3100 as a primary storage disk and on the DECstation-3100 as a paging disk. The RZ55 fits into an expansion box on the two 3100 stations at a price of $6500 Now, since both the DECstation 3100 and VAXstation 3100 use standard SCSI, your best bet is to probably get 3rd party fast SCSI drives (fast meaning less than 20ms access times). Not only are they faster, but they are probably cheaper too. Art Stine Sr Network Engineer Clarkson U
lgy@blake.acs.washington.edu (Laurence Yaffe) (01/25/89)
In article <2051@sun.soe.clarkson.edu> abstine@sun.soe.clarkson.edu (Arthur Stine) writes:
-
- Now, since both the DECstation 3100 and VAXstation 3100 use standard SCSI,
- your best bet is to probably get 3rd party fast SCSI drives (fast meaning
- less than 20ms access times). Not only are they faster, but they are probably
- cheaper too.
-
- Art Stine
- Sr Network Engineer
- Clarkson U
Does getting 3rd party SCSI drives also entail getting a device driver
from the 3rd party vendor, or are all SCSI drive alike? (I know next to
nothing about SCSI devices.)
On an unrelated note, does someone know if the keyboard of the DECstation 3100
has a reasonably-placed escape key?
--
Laurence G. Yaffe Internet: lgy@newton.phys.washington.edu
Department of Physics, FM-15 Bitnet: yaffe@phast.bitnet
University of Washington
Seattle WA 98195abstine@sun.soe.clarkson.edu (Arthur Stine) (01/25/89)
From article <617@blake.acs.washington.edu>, by lgy@blake.acs.washington.edu (Laurence Yaffe): > > Does getting 3rd party SCSI drives also entail getting a device driver > from the 3rd party vendor, or are all SCSI drive alike? (I know next to > nothing about SCSI devices.) > > On an unrelated note, does someone know if the keyboard of the DECstation 3100 > has a reasonably-placed escape key? > -- It depends on the third party device. Disks should be just fine, since DEC supplies a device driver for the SCSI drives (although I am unsure of whether they check for their device types explicitly or not. I think their intention though is to make it as flexible as adding 3rd party disks to a Sun). Tape devices and other SCSI things will probably need their own device driver unless the device looks like a TK50Z or the RRD40 optical drive. DEC has said that they will be supporting additional SCSI devices in the future though... whatever that means... As far as the keyboard, I believe from what I have seen that the keyboard is the same as the other VAXstations, the LKxxx type keyboard, which has an escape key in a dumb place. Sorry... art stine sr network engineer clarkson u
avolio@decuac.dec.com (Frederick M. Avolio) (01/25/89)
In article <986@isieng.UUCP> seenu@isieng.UUCP (Seenu Banda) writes: >In article <414@laic.UUCP>, darin@nova.laic.uucp (Darin Johnson) writes: > >> have one for the 3100. They also include a small disk hidden in the box > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> that can be used to boot the machine, with NFS used for everything else > >This is really interesting. This is the first time I heard about a hidden >disk in the 3100. Does anybody know more about this disk? How small (or >big) is it? 10MB? It is 104MB. 2 fit in the system box. Fred
jg@jumbo.dec.com (Jim Gettys) (01/25/89)
In article <2056@sun.soe.clarkson.edu> abstine@sun.soe.clarkson.edu (Arthur Stine) writes: >From article <617@blake.acs.washington.edu>, by lgy@blake.acs.washington.edu (Laurence Yaffe): >> >> Does getting 3rd party SCSI drives also entail getting a device driver >> from the 3rd party vendor, or are all SCSI drive alike? (I know next to >> nothing about SCSI devices.) >> >> On an unrelated note, does someone know if the keyboard of the DECstation 3100 >> has a reasonably-placed escape key? >> -- > >It depends on the third party device. Disks should be just fine, since DEC >supplies a device driver for the SCSI drives (although I am unsure of whether they check for their device types explicitly or not. I think their intention >though is to make it as flexible as adding 3rd party disks to a Sun). Tape >devices and other SCSI things will probably need their own device driver >unless the device looks like a TK50Z or the RRD40 optical drive. DEC has said >that they will be supporting additional SCSI devices in the future though... >whatever that means... Be careful on selecting 3rd party drives; experience has shown that many devices have had bugs in their SCSI implementations. We tried several other drives during testing of the PMAX which appear to work, but know that firmware problems in the drives we qualified for the RZ23 and the RZ55 had to be fixed for reliable operation. (Or are we a statistical fluke? Somehow I doubt we were...) Presumably as SCSI becomes more mature as a standard these kinds of problems will diminish. But this is always true of buying third party devices, so I'm really not saying anything new, other than the history of the drives we use was not without a bit of excitement. > >As far as the keyboard, I believe from what I have seen that the keyboard is >the same as the other VAXstations, the LKxxx type keyboard, which has an >escape key in a dumb place. Sorry... > Using X, you can reprogram the keyboard to an almost rediculous extent, so put the escape key anywhere you like. I know; I designed that part of X, and didn't want to put up with the escape key's (or the lock keys) location. See xmodmap on the X distribution. Jim Gettys
richard@vajra.uucp (Richard Wood) (01/26/89)
In article <617@blake.acs.washington.edu> lgy@blake.acs.washington.edu (Laurence Yaffe) writes: >On an unrelated note, does someone know if the keyboard of the DECstation 3100 >has a reasonably-placed escape key? Unfortunately no, the DEC keyboards were designed for an office environment where the Escape key is meaningless. There are actually three escape keys: Always <esc>: Control-3 and Control-[ Sometimes: F11 (Function key 11) (depending on a settable mode of the terminal) -- ---------------------------------------------------------------------------- Does it need saying that I'm not speaking as an official representative of DEC? =============================================================================== Richard Wood ! U. S. Worksystems, Palo Alto ! Digital Equipment Corporation