Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!lll-lcc!pyramid!prls!mips!mash From: mash@mips.UUCP Newsgroups: comp.arch Subject: Re: MIPS to offer COBOL Message-ID: <104@winchester.mips.UUCP> Date: Mon, 26-Jan-87 00:09:30 EST Article-I.D.: winchest.104 Posted: Mon Jan 26 00:09:30 1987 Date-Received: Tue, 27-Jan-87 02:03:37 EST References: <14392@amdcad.UUCP> <1275@cbmvax.cbmvax.cbm.UUCP> <984@ur-tut.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 64 Keywords: MIPS COBOL Gee whiz!! It's amazing what happens when you go away for a week; truly berserk outbreaks on the net [in comp.arch, of all places]. For some reason my colleague Larry Weber [who runs the languages effort here, i.e., group who did all that zingy compiler technology] has chosen not to comment on this. However, I'm in a touchy mood [having been required to play airline-guessing games to escape the snow in Washington], hence: 1. The MIPS R2000 wasn't particularly built to run COBOL fast. We didn't even take the small steps that the HP-Spectrum did to help it. I can't think of a single thing that we've sacrificed in favor of good COBOL-ness. REALLY, REALLY, WE'RE INNOCENT OF EXPECTING THAT: 2. Some of our customers/prospects discovered [to our astonishment, in some cases inventing amazing uses of some of our instructions] that the R2000 actually looked like a fine COBOL engine (!!??!!) This mostly comes from fast subroutine calls, some sneaky code-generation, and the effects you get from serious optimizing compiler technology, and the fact [documented by the Spectrum folks] that COBOL environments are mostly systems-type code that don't really spend much time doing decimal operations. 3. I know this may be astonishing out there in UNIX-land, but much of the world out there really uses COBOL, and it's often portable enough to move to new architectures. When a whole bunch of large customers tell you that you need COBOL, you at least listen to them. Sometimes they say things like "we really like your C, FORTRAN, PASCAL, etc, but we really need one architecture to cover both technical and commercial markets, so when will COBOL be available?" [You have noticed thjat DEC supports COBOL?] 4. Consider the current state of microprocessor languauges, as compared to minicomputer/mainframe compilers: a) The micro vendors have [often/sometimes] not invested upfront in high-quality optimizing compilers that use common components, compatible runtimes [where possible], etc. The result is often a large gaggle of different compilers, runtimes, etc, in quality ranging from excellent to awful, which are supplied by combinations of microprocessor vendors, compiler vendors, and systems vendors. b) There are some fine compiler vendors out there; nevertheless, the confusion factor doesn't particularly help systems integrators or end users, who just want to g et a job done with a minimum of fuss. 5. Personally, I don't ever expect to write COBOL code, but I sure think it's important to have a good compiler for it that meshes well with our systems, and I'd much rather have Larry's [fine] compiler group doing it than to have our customers having to build complex 3rd-party deals to get what they need. I'd much rather have 1 good COBOL system that people can count on. Thus, these comments are not particularly in favor of COBOL per se, but simply recognition of reality: any general-purpose computer vendor will need COBOL sooner or later, so it might as well be good. Well, enough specific comments. Let me observe that one of UNIX's strengths has been the following combination: a) Elegant, insightful advances that looked beyond the state of the art. b) Willingness of people to adapt it as needed, even to environments otherwise alien, un-purist, or backward. c) Reduction of the "gulp factor", i.e., people avoid new technologies that make them discard everything they have. They'd much rather move what they have, then convert it to newer technology over time. UNIX has snuck into a lot of environments this way, like when we helped UNIX let people edit COBOL and PL/I code and send it to IBM systems years ago [unpure! but it helped people get their work done, and many of the next round of projects was UNIX-based...] Well, enough..... and shame on you, Steve W: how can you give us a hard time when you guys have put so much effort into doing well by that other nasty old language, FORTRAN? :-) As you say, everyone has their price. :-) -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086