Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!apple!mips!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.sys.apple2 Subject: Re: My next personal computer will be a PC Message-ID: <12797@smoke.BRL.MIL> Date: 7 May 90 18:12:45 GMT References: <2968@sactoh0.UUCP> <1990May4.055855.23151@athena.mit.edu> <12658@wpi.wpi.edu> <12787@smoke.BRL.MIL> <12699@wpi.wpi.edu> Organization: U.S. Army Ballistic Research Laboratory Lines: 60 In article <12699@wpi.wpi.edu> ggray@wpi.wpi.edu (Gary P Gray) writes: >In article <12787@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>In article <12658@wpi.wpi.edu> ggray@wpi.wpi.edu (Gary P Gray) writes: >>>power of a 25Mhz 32 bit processor means the difference between waiting a few >>>seconds or a few minutes and waiting hours. >>Maybe you should learn how to do arithmetic before making purchasing >>decisions. >No, let me guess, you're one of those people who think a 1Mhz 6502 can beat >the pants off of a 25Mhz 386, right? No, but I do know how to multiply and divide. The ratio between seconds and minutes is 60, so immediately we wonder why you have them in the same timing category, whereas hours (another factor of 60) are in a different one. Where are all the factors of 60 coming from, anyway? Even if we were talking about 1MHz 6502s, which we weren't (current Apple II technology in wide use is 7MHz 65816), taking into account I/O bottlenecks etc. you wouldn't see a relative factor of 60. Compared to the 7MHz 65816 you see very little difference in effective computational power, no more than a factor of 2, depending on the application. Using a fast disk (<= 28ms average access, >= 1Mb/sec transfer rate) and DMA SCSI interface on the IIGS, I doubt that the 386 has any particular I/O advantage, either. The one thing the 386 might have a major hardware advantage in is memory management, allowing a reasonable implementation of UNIX on that platform. The software advantage lies simply in the relative amount of development being done for the PC line, not in anything inherent in its architecture. >I'd heard that the //gs C compilers didn't have all of the bugs worked >out of them I hadn't heard that the PC C compilers had all the bugs worked out of them, either! It is true that the initial releases of both APW C and ORCA/C had problems that often got in the way of application development, but despite the problems there are commercial products developed under these systems. The forthcoming ORCA/C Release 1.1 should be bug-free enough for most applications. Anyone licensed for Release 1.0 can become a 1.1 Beta tester simply by asking (see the ByteWorks product support board on America Online for details). >Are any //gs C compilers ANSI? ORCA/C will be nearly standard conforming as of release 1.1, now in the late stages of Beta testing. The few significant deviations are due to trying to remain compatible with similar deviations in Macintosh environments. The developer of ORCA/C has solicited input from Beta testers in an attempt to determine how important this really is. >I know there is supposed to be a LISP implementation that runs on >classic //'s (now that's something I would like to see :) but what >about prolog? I know of a Modula-2 implementation, Forth, and a few others, but no Prolog. It's not impossible to implement on the 16-bit Apple II line, but there probably isn't much market for Prolog for either home or pre-college educational use, which are the main Apple II markets. >Are C compilers in an integerated enviornment? ORCA/C is; APW C is typically used in a more traditional manner (although one can use it with the ORCA Desktop environment, it doesn't support ORCA's source-level debugger whereas ORCA/C does).