Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcc7.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!ucdavis!ucbvax!decvax!ittatc!dcdwest!sdcsvax!sdcc3!sdcc7!ln63fcv From: ln63fcv@sdcc7.UUCP (This is a test) Newsgroups: net.micro.atari Subject: Re: questions : os9,unix,rumors Message-ID: <154@sdcc7.UUCP> Date: Wed, 6-Nov-85 14:37:25 EST Article-I.D.: sdcc7.154 Posted: Wed Nov 6 14:37:25 1985 Date-Received: Sat, 9-Nov-85 07:08:42 EST References: <396@ssc-bee.UUCP> <213@l5.uucp> <1584@hammer.UUCP>, <136@sdcc7.UUCP> <6099@utzoo.UUCP> Organization: U.C. San Diego, Academic Computer Center Lines: 67 In article <6099@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > I must say that I find it quite hard to believe that NatSemi is already coming > > out with the 32332 already, when they haven't even come out with the 32132 > > or the 32232 yet(Yes, these are actual scheduled components). > > Last I heard, the 32232 was no longer a real part, and the 32132 is a minor > upgrade of the 32032. The plans got reshuffled a while ago: make sure you > have the up-to-date word. Yes, the 32332 is coming, and looks interesting. > Non-disclosure prevents me from saying more. (Except that they'd better > get the 32332 out fast without major bugs if they want any market share!) > all right, i admit i was probably wrong since i was relying on old information but i from what i hear, nat semi is still having problems with their components and the only thing of theirs that i would consider using is a 32081 fpu, and this is only till motorola comes out with the 68881 > > This argument is moot anyway for one reason. The 68020 is considerably faster > > because the original 68000 is very bus bound, while the 20 is much less so. > > Let me see. You're saying that because the 68000 had no prefetch queue and > a 16-bit bus, and the 68020 fixes both of those problems, that the 68020 is > better than the National 32-bit chips? Does not compute: the National chips > have had prefetch queues all along, and the 32-bit ones have had a 32-bit > bus all along. The 68020 is a vast improvement on the 68000 in this regard, > but that is utterly irrelevant to comparing it against the 32000s. > that was exactly what i was saying, that the nat semi chips show no great improvement in speed as we up to bigger bus widths, while the 020 is a lot faster than the 000 because of the inclusion of these new features, also, im not sure, but i think the 020 also includes pipelining while the 000 didn't(is this right?) > > ... Also, a memory cycle > > on the NS series and the 68000 is 4 cycles, as opposed to the twenty, which is > > 3 for main memory, and 2 for the 256 byte queue. > > Let me know if you can find a 68020 system that really does a main-memory > fetch in 3 cycles. It's extremely difficult to build low-cost main memory > that can run that fast (although caches can help). Don't forget to add the > delay for memory management. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry about that last comment, the 020 is capable of doing main memory fetch in 3 cycles, and a queue fetch in 2 cycles. the 80286 i have heard can do a main memory fetch even faster, but that doesn't mean it will when implemented. NOW, why should i include a delay for memory management? I mean, why should i have memory management? we're talking a single user system here with maybe a few small background tasks. I dont understand this idea of strapping me with memory management when i do not want to use unix or anything similar to it in complexity. the simpler the os, the faster the system. and i have used att 3b2 unix personal computers and they are slow, even though there are provsions for up to four users in them. i believe this is because of the os(unix) ah, well, i am getting philosophical here, so scott weisman sdcsvax!sdcc7!ln63fcv this is a disclaimer the below statement is true ^ | \/ the above statement is false