Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site dual.UUCP Path: utzoo!linus!decvax!harpo!ihnp4!zehntel!dual!fair From: fair@dual.UUCP (Erik E. Fair) Newsgroups: net.arch,net.micro.68k,net.micro.16k Subject: Re: 16k vs 68k vs 432 Message-ID: <220@dual.UUCP> Date: Fri, 6-Jan-84 07:00:12 EST Article-I.D.: dual.220 Posted: Fri Jan 6 07:00:12 1984 Date-Received: Sun, 8-Jan-84 01:12:46 EST References: <524@nsc.UUCP> Organization: Dual Systems, Berkeley, CA Lines: 68 OK, I will respond to the points one at a time. >>From amd70!fortune!nsc!chongo (Landon Noll) >> >>having used both NS16032 based systems, and DUAL's 68000 based system >>i make the following observation: >> >>1) floating point on the DUAL is very slow. test show that it is between >> 1 to 2 magnitudes slower than National's FPU. (ill be vage since i >> dont have the figures right in front of me) I'm not surprised. There is also a problem with accuracy, since UniSoft chose to leave the DEC standard floating point implementation as is. Fortunately, we also have an IEEE floating point standard C compiler (and you thought that the DEC standard was slow?), and we support the SKY Fast Floating Point board (which makes things faster than the DEC standard, and still IEEE standard too). Clearly, though we can't (nor can any other 68k without an onboard FPU) beat a 16032 with a 16082 FPU right next to it. >>2) due to the lack of extended multiplication on the 68000, the >> multiplication of two long ints needs to be performed via subroutine. >> (so a fellow DUAL used showed me) National's CPU can multiply two 32 bit >> values and get a 64 bit result. Guilty as charged. Thank you, Motorola. >>3) due to the poor memory management hardware, programs only divided >> and swaped on two sections: data and text. you are limited in size >> by the amount of physical memory. (most programs are not allowed >> to poke at the mmu) National's MMU uses 512 byte pages and can >> support a demand paged area of up to 16 Meg, regardless of physical >> memory. [well we assume you do have some! :~) ] OK, this is apples and oranges time. DUAL uses the 68451 MMU with the 68000 processor. That combination can't do Virtual Memory. However, the 68010 with the 68451 CAN. However, I won't argue that the 68451 doesn't leave \much/ to be desired as an MMU in a virtual system. Most of the 68k boxes out there (at least most of the UniSoft ports) are still `swap' based systems, where any given process is limited to the size of physical memory minus the space that the kernel takes up. In the DUAL, though, you can drop 3.25Mbytes on the bus, and that is usually sufficient for most applications. Even a program as large as the Franz Lisp interpreter fits in that quite comfortably. >> >>now dont get me wrong, the DUAL is a GOOD SYSTEM for the price. but if they >>could just get away from the MC68000 based systems and over to ... >> >>chongo /\DD/\ The NS16000 series is a very nice chip set. We would have to about double in size as a company, and start dealing with Yet Another Unix Porting House which is not my idea of fun (although the two who are of any note have both done 4.1BSD, and that, in my book, is a definite plus). One minor note on the NS 16081 MMU, is that apparently it has 512 byte pages ingrained into its structure, and so those of you who want larger page sizes than that are in for an interesting time. Or so our CPU board designer says. sitting on the software side of the fence, waiting for my microVAX, with 4.2BSD, Erik E. Fair {ucbvax,amd70,zehntel,unisoft,onyx,its}!dual!fair Dual Systems Corporation, Berkeley, California P.S. If I got the 16081 and 16082 confused, sorry. Hardware hack, I ain't.