Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!eecea!terry From: terry@eecea.eece.ksu.edu (Terry Hull) Newsgroups: comp.sys.ibm.pc Subject: Re: Why unix doesn't catch on Message-ID: <635@eecea.eece.ksu.edu> Date: 28 Apr 89 22:12:53 GMT References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP> <2496@bucsb.UUCP> <274@tree.UUCP> Reply-To: terry@eecea.eece.ksu.edu (Terry Hull) Organization: Kansas State University, Manhattan Lines: 74 In article <274@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: > >Well, I'm back! Sorry I missed the interim discussion. > >I read just the other day in _Computer_Systems_News_ that Microsoft's OS/2 >for the 386 is being delayed because of the difficulty of converting >100,000+ lines of 286 assembly to 386 assembly. This is *Microsoft*, >people: You know--the company which markets perhaps the best optimized >C compiler in the world. Hold on here. The GNU C compiler is certainly more highly optimizing than the Microsoft C compiler. [stuff deleted] >And the efficiency of UNIX on the 386 is >almost certainly going to look rather sickly when compared to a mature >version of 386 OS/2. Maybe so, but who can wait that long? If we wait for a mature OS/2 written in '386 assembly language, UNIX will be running on '486s and still providing more functionality than OS/2 on that "tired, old, broken-down '386." How long is it going to take to get a "mature" OS/2 for the '386? How long does it take to get all the bugs out of 100,000 lines of assembly code? How 'bout getting OS/2 to run on one of the new inexpensive RICS machines? Do we write 250,000 lines of assembly to accomplish that task? [stuff deleted] >Sure, you can always say: "Throw more hardware at the problem! If you can't >do it on a 286 use a 386. At the current time, I think MIPS are cheaper than programmer hours. If that were not true, would not all of our applictions would be written in assembly language? If programmer time was cheaper and MIPS were more expensive, languages like lisp would never be used. They take less programmer time and more MIPS than an equivalent program in C. How about 4th generation database languages? They are certainly not as efficient as assembly language, yet are being widely used. Anybody want to take a shot at writing GNU Emacs in 8088 assembly so that it will be smaller and faster? Not me. I buy the hardware to support the real thing. You must choose what path that you wish to take. If you want to wait for assembly language programmers to code OSs and applications in assembly language so that you can buy less memory and disk space, that is fine. I would rather buy the disk space for things like GNU Emacs, TeX, troff, and news that will enable me to use the currently available (note: portable) implementations. When a "mature OS/2" is available for the '386, I will be happily banging away on my '486 or SPARC or MC88000, and I will still be getting more work done than the guy who waited for OS/2. After all, isn't the purpose of computing getting more done in less time? >Unfortunately, better >hardware costs (almost exponentially) more money and so there is *always* going >to be a desire for the BEST software to push the limits of the hardware--and >that just can't be done in a "portable" manner. Unfortunately, when there are no longer enough programmer hours available in the world to implement this "BEST" software in assembly language, the definition of "BEST" will no longer be fastest and smallest. If the computer that you are writing this software for is no longer produced by the time you finish the project, can this software possibly be called "BEST?" What ever happened to the "timely" part of "BEST"? >But I'll repeat: Portability IS the >enemy of excellence. To quote another USENETTER, "Bull." -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: tah386!terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!tah386!terry