Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site nsc.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!menlo70!nsc!chongo From: chongo@nsc.UUCP (Landon Noll) Newsgroups: net.arch,net.micro.68k,net.micro.16k Subject: Re: 16k vs 68k vs 432 Message-ID: <524@nsc.UUCP> Date: Wed, 4-Jan-84 15:44:41 EST Article-I.D.: nsc.524 Posted: Wed Jan 4 15:44:41 1984 Date-Received: Fri, 6-Jan-84 02:33:49 EST References: <3427@utzoo.UUCP>, <208@dual.UUCP> Organization: National Semiconductor, Sunnyvale Lines: 24 having used both NS16032 based systems, and DUAL's 68000 based system i make the following observation: DUAL's systems are nice, but one of the two major limiting factors is the 68000 hardware. to this problem i note: 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) 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. 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! :~) ] 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/\