Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mddc.UUCP
Path: utzoo!linus!security!genrad!mit-eddie!mit-vax!eagle!mhuxl!
ihnp4!cbosgd!qusavx!mddc!chris
From: ch...@mddc.UUCP (Chris Maloney)
Newsgroups: net.arch,net.micro.68k,net.micro.16k
Subject: 16k vs 68k vs 432
Message-ID: <294@mddc.UUCP>
Date: Wed, 21-Dec-83 21:10:49 EST
Article-I.D.: mddc.294
Posted: Wed Dec 21 21:10:49 1983
Date-Received: Sat, 24-Dec-83 00:40:30 EST
Organization: MDDC, Cincinnati, Ohio
Lines: 14
Though we have all seen parts of this discussion before and
could live without some of the repeations of the same ideas,
I would like to see some discussion of the issues. I am not
really qualified to comment but would like to relate some ideas
of a friend of mine. He is a devoted Motorola fan and claims
they buy far have the best support chips (Memory Management,
Communications, ...). He also feels the Motorola will in the
future and has in the past offer much better support than
NS or Intel. His says about Intel, he wouldn't like to compete
with Big Blue useing chips from the company they control.
He will admit that the 16k has a better instruction set than
the 68k.
Let's here it (but only once).
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch,net.micro.68k,net.micro.16k
Subject: Re: 16k vs 68k vs 432
Message-ID: <3427@utzoo.UUCP>
Date: Wed, 28-Dec-83 18:38:00 EST
Article-I.D.: utzoo.3427
Posted: Wed Dec 28 18:38:00 1983
Date-Received: Wed, 28-Dec-83 18:38:00 EST
References: <294@mddc.UUCP>
Organization: U of Toronto Zoology
Lines: 23
Anyone who thinks Motorola's memory-management chip is superior to
the National one for the 16k has been totally brainwashed. The
Motorola chip is next to useless, while the 16032 does a full demand
paging environment and does it *right*. (Or at least, a lot closer
to right than many other versions, e.g. the one on the VAX.)
Note also that the 16032 has a rather fast floating-point chip already
operational, whereas Motorola is still just mumbling about one. I am
told that a number of people are using the 16032 FPU on 68000 systems,
despite howling and gnashing of teeth from Motorola.
I tend to agree about some of the other Motorola peripheral chips,
with the 68121 a particular win. But these chips don't have any real
competition from National yet; it will be interesting to see just
what appears. National did an awful lot of things right on the 16032
and its support chips. If they can continue this practice and
overcome their slow start, they have a big winner on their hands.
(No, I don't work for National. But the closer I look at the 16032,
the more impressed I am.)
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
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: cho...@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 <the other system that i use is a DUAL> /\DD/\
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: f...@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 <the other system that i use is a DUAL> /\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.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch,net.micro.68k,net.micro.16k
Subject: Re: 16k vs 68k vs 432
Message-ID: <3451@utzoo.UUCP>
Date: Mon, 9-Jan-84 19:14:01 EST
Article-I.D.: utzoo.3451
Posted: Mon Jan 9 19:14:01 1984
Date-Received: Mon, 9-Jan-84 19:14:01 EST
References: <524@nsc.UUCP>, <220@dual.UUCP>
Organization: U of Toronto Zoology
Lines: 15
Erik Fair observes:
.......One minor note on the NS [16032] 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....
It's quite true that the MMU has 512-byte pages ingrained into it. So?
The VAX does too. If you want bigger pages, you simply do everything N
512-byte pages at a time instead of one 512-byte page at a time. As an
example, National's 4.xBSD port does everything 2 pages at a time to
give the effect of 1024-byte pages. Almost any paging hardware has to
make a firm decision about page size and stick to it.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP
Path: utzoo!linus!decvax!genrad!grkermit!masscomp!kobold!tjt
From: t...@kobold.UUCP
Newsgroups: net.arch,net.micro.68k,net.micro.16k
Subject: Re: 16k vs 68k vs 432
Message-ID: <247@kobold.UUCP>
Date: Tue, 10-Jan-84 13:23:53 EST
Article-I.D.: kobold.247
Posted: Tue Jan 10 13:23:53 1984
Date-Received: Wed, 11-Jan-84 08:31:26 EST
References: <524@nsc.UUCP>, <220@dual.UUCP> <3451@utzoo.UUCP>
Organization: Masscomp, Westford, MA
Lines: 26
The problem with compensating for a small page size by pretending the
page size with bigger (as is done in 4BSD for the VAX and National's
4.xBSD port) is that page tables take up N times as much space, and the
inner loops for setting up page tables run N times slower.
On the other hand, a large page size causes you to lose more storage to
fragmentation.
Actually, I had heard that the real reason the VAX used 512-byte pages
was because the unibus disks used 512-byte blocks. Actually, the
physical disk block sizes are less important than the logical file
system block size.
Anyway, does anyone know if it is possible to use the NS 16032 MMU with
some additional logic to look at function codes and fool it into using
a larger page size directly? i.e. the MMU would normally ignore the
bottom 9 bits of the address and only look at the page number. You can
feed whatever bits you want in as the page number. Similarly, you can
take the translated page number to high order bits. By definition, the
low order bits (page offset) of the address aren't changed by the MMU.
However, if the MMU does not find the right page table entry in its
on-chip cache, it will fetch it from memory, in which case the memory
system needs to use exactly the address generated by the MMU.
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 692-6200
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch,net.micro.68k,net.micro.16k
Subject: Re: 16k vs 68k vs 432
Message-ID: <3463@utzoo.UUCP>
Date: Wed, 11-Jan-84 14:37:55 EST
Article-I.D.: utzoo.3463
Posted: Wed Jan 11 14:37:55 1984
Date-Received: Wed, 11-Jan-84 14:37:55 EST
References: <524@nsc.UUCP>, <220@dual.UUCP> <3451@utzoo.UUCP>, <247@kobold.UUCP>
Organization: U of Toronto Zoology
Lines: 26
Tom Teixeira asks:
Anyway, does anyone know if it is possible to use the NS 16032 MMU with
some additional logic to look at function codes and fool it into using
a larger page size directly? i.e. the MMU would normally ignore the
bottom 9 bits of the address and only look at the page number. You can
feed whatever bits you want in as the page number. Similarly, you can
take the translated page number to high order bits. By definition, the
low order bits (page offset) of the address aren't changed by the MMU.
However, if the MMU does not find the right page table entry in its
on-chip cache, it will fetch it from memory, in which case the memory
system needs to use exactly the address generated by the MMU.
Given that the 16032 MMU is *not* just a combinatorial logic block, but
a complex state machine which sits on the cpu bus, manipulates it in
non-trivial ways, and does its own memory accesses using that same bus,
and given that the same set of wires carries virtual addresses from the
cpu, physical addresses from the MMU, and data to and from both, pulling
devious tricks involving reshuffling the bits strikes me as asking for
trouble. I would recommend against it. It's true that simply using N
"real" pages as a single "logical" page involves extra overhead in space
and time, but if these overheads are significant then I would suspect the
software of doing something stupid.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry