🚀 go-pugleaf

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