Architectural Requirements for Unix (was: upgrades)
Henry Spencer
>When I asked about the difficulty of running Unix on the 376, which only
>has segmentation, not paging, but is in other ways similar to the 386,
>I meant running full-blown demand-paged virtual memory...
Who needs paging? Keep your programs down to a sane size and segmentation
will amply suffice, especially on a single-user machine. Of course, very
few of today's Unix programmers know how to make programs small and fast,
so this won't work too well in practice.
>...you would have to use segmentation to emulate the paging unit.
>I figure this would be easy. You just set up each segment for one of the
>pages in your working set...
This is going to hurt performance quite a bit, because you'll have to
juggle segment registers on every memory reference (unless your program
has only a few pages!), and that's painfully slow on the bigger x86
CPUs, as I recall.
--
Life is too short to spend | Henry Spencer at U of Toronto Zoology
debugging Intel parts. -Van J.| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Rick Richardson
>Who needs paging? Keep your programs down to a sane size and segmentation
>will amply suffice, especially on a single-user machine. Of course, very
>few of today's Unix programmers know how to make programs small and fast,
>so this won't work too well in practice.
Even those of us that do know how to make programs small and fast
are hog-tied by the demands of the marketplace these days. I speak,
of course, of X windows. Face it Henry, we can still make programs
fast, but small is a thing of the past. Much to the delight of RAM
manufacturers, I'm sure.
-Rick
--
Rick Richardson - PC Research, Inc., uunet!pcrat!rick, (201) 389-8963
Martin Fouts
From: he...@utzoo.uucp (Henry Spencer)
In article <30...@cup.portal.com> m...@cup.portal.com (Mark Robert Thorson) writes:
>When I asked about the difficulty of running Unix on the 376, which only
>has segmentation, not paging, but is in other ways similar to the 386,
>I meant running full-blown demand-paged virtual memory...
Who needs paging? Keep your programs down to a sane size and segmentation
will amply suffice, especially on a single-user machine. Of course, very
few of today's Unix programmers know how to make programs small and fast,
so this won't work too well in practice.
There are at least four wrong assumptions which the naieve might read
into this paragraph:
1) Segmented memory machines have smaller memory/process than virtual
memory machines. This is not always true. The Cray 2, for example
is a segmented memory machine and I've run 0.99 gigabyte
processes on it. (Others have since run larger...)
2) Virtual memory implies larger processes. Not true. Trading memory
against performance in a virtual memory system may mean larger
process images. However, if they have good locality of reference,
it might mean smaller memory resident set sizes.
3) Smaller is "better". If I have to solve a 1000^3 grid, I have to
solve it. I've done it with segmented memory in the small (Y/MP)
and segmented memory in the large (Cray 2) and virtual memory
(ETA/10.) For my purposes, the Cray 2 was best. Your milage would
vary.
4) The main reason for using virtual memory is to allow a small
physical memory to support a large process image size. This is the
worst reason for using virtual memory. The main reason for using
virtual memory is to make programs easier to write.
The advantages of text/data sharing, small resident sizes, and
implicit memory management are enough to justify the cost of tlbs,
mmus and slower memory accesses in a lot of cases.
I need paging. I need it to keep the total amount of memory I am
using small and make my programs more efficient by:
1) Using implicit sharing of text segments
2) Using copy on write sharing of forked images
3) Using explicit sharing of library code
4) Using explicit sharing of multithreaded applications
5) Using good locality of reference to minimize resident sets
6) Using copy on read to implement lazy evaluation
7) Using remapping to implement data transfer where possible
I do it with paging rather than segments because there ain't never
enough segments on a segmented system, and many segmented systems
don't have the architectural support to ease implementations of some
of the featues.
I *never* use virtual memory to make a small memory look large,
because I can't afford the performance hit from the paging activity,
and feel sorry for those who must take it.
So, the answer (in part) to the question "Who needs it?" is I do.
--
Martin Fouts
UUCP: ...!pyramid!garth!fouts ARPA: apd!fo...@ingr.com
PHONE: (415) 852-2310 FAX: (415) 856-9224
MAIL: 2400 Geng Road, Palo Alto, CA, 94303
If you can find an opinion in my posting, please let me know.
I don't have opinions, only misconceptions.
Peter da Silva
> 3) Smaller is "better". If I have to solve a 1000^3 grid, I have to
> solve it. I've done it with segmented memory in the small (Y/MP)
> and segmented memory in the large (Cray 2) and virtual memory
> (ETA/10.) For my purposes, the Cray 2 was best. Your milage would
> vary.
In turn, you're making a false assumption: that there's something inherent
in these very large programs (VLPs) that people are complaining about
that requires them to be large. Nobody is denying that some problems
require big iron. Text processing, text editing, window systems, and so
on... the majority of VLPs that come under fire... have no inherent reason
to be very large. Even machines as small as a 128K Mac can run excellent
windowing systems, and editors and text processors are even smaller.
> I need paging. I need it to keep the total amount of memory I am
> using small and make my programs more efficient by:
> 1) Using implicit sharing of text segments
This does not require paging. Look at good old PDP-11 UNIX.
> 2) Using copy on write sharing of forked images
This requires paging. Fork() is a poor match for a non-demand-paged
architecture. My reaction is that we don't need fork().
> 3) Using explicit sharing of library code
This does not require paging. Look at good old PDP-11 RSX.
> 4) Using explicit sharing of multithreaded applications
This does not require paging. Look at the Transputer.
> 5) Using good locality of reference to minimize resident sets
This is the big win for paging systems. You don't need to pull any more
reasons out of the hat. However, when you have a small program anyway
this becomes much less important.
The question shouldn't be "is paging good" or "is paging bad" or "who
needs it". The question is "do you need it".
Also, paging and bloated programs are not synonymous. People can write
bloated program with overlays: look at the OS/360 kernel as described in
the Mythical Man-Month. The problem isn't paging. The problem is people
who think that because memory is cheap they can act like it's free.
--
`-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.ferranti.com>
'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
@FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
Wm E Davidsen Jr
| I need paging. I need it to keep the total amount of memory I am
| using small and make my programs more efficient by:
|
| 1) Using implicit sharing of text segments
This can be done with segments, too. As long as the code is pure it
can be shared.
| 2) Using copy on write sharing of forked images
This can be done with segments, too, at least for the segment as a
whole. It's marked read only, then the fault is used to force the copy.
| 3) Using explicit sharing of library code
This could be done with segments, although I don't know of any machine
which does it. I looked at doing it on a 286, with all the library
routines called with far calls to a library segment. I am sure it can be
done, but I don't have an example of doing it.
| 6) Using copy on read to implement lazy evaluation
I believe you can do that with segments, too. You certainly can have
separate read and write bits for a segment and turn off both read and
write, then copy on fault.
| 7) Using remapping to implement data transfer where possible
??? I think you can do this, but I am not totally sure what you have
in mind. Obviously shared memory works in segmented systems, and the
data does not need to be at the same segment number in each process.
|
| I do it with paging rather than segments because there ain't never
| enough segments on a segmented system, and many segmented systems
| don't have the architectural support to ease implementations of some
| of the featues.
Most of the segmented CPUs, Intel for sure, have 32k or 64k segments.
That certainly covers a lot of ground.
|
| I *never* use virtual memory to make a small memory look large,
| because I can't afford the performance hit from the paging activity,
| and feel sorry for those who must take it.
Even running a job which *can* fit in physical memory, I often see
that the working set is smaller than max. Often there is some startup or
wrapup code which doesn't stay in memory, some strings, like error
message, etc.
In many cases, where the order of data access is not easily
determined, virtual memory will be faster than using i/o to bring the
data in from a file. There will *always* be a program which uses a data
set larger than physical memory, and applications which could
legitimately use more address space than they have.
In spite of that, I believe that 95% of all programs on all computers
(by number rather than CPU cycles) will run in 4MB of address space.
And probably 95% in 16MB. There are not a lot of applications which
need the huge memory, and that means a small market, few vendors, high
prices, etc. Adam Smith walks here, too.
--
bill davidsen (davi...@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"Stupidity, like virtue, is its own reward" -me
Mark Robert Thorson
candidates for "world's cheapest virtual memory demand paged Unix engine".
Correct prices are (in 1000-unit quantity):
Intel 376 (not really a candidate) $43 @ 16 MHz
Intel 386SX $66.50 @ 16 MHz
$125 @ 25 MHz
Someone suggested the Acorn RISC machine would be a possibility.
VLSI Tech. VL86C010 $31.25 @ 12 MHz
VL86C020 $92.80 @ 25 MHz
Note that an external MMU is required (I don't have pricing for that).
Motorola is about to release the 68020 in a new package with much reduced
pricing. I don't know if the information has been formally announced yet,
so I can't tell you what it is, but I would say that this chip will be
certainly be the winner as far as low-end Unix machines are concerned.
If you don't care to run MS-DOS, it's price-performance product will be
significantly better than the 386SX.
Doug McDonald
>candidates for "world's cheapest virtual memory demand paged Unix engine".
>
>Correct prices are (in 1000-unit quantity):
>
>Intel 376 (not really a candidate) $43 @ 16 MHz
>Intel 386SX $66.50 @ 16 MHz
> $125 @ 25 MHz
>
the floating point chip.
Doug McDonald
Charles Simmons
Davidsen Jr) writes:
> | 3) Using explicit sharing of library code
>
> which does it. I looked at doing it on a 286, with all the library
> routines called with far calls to a library segment. I am sure it can be
> done, but I don't have an example of doing it.
>
Ah! I can't pass this one up. Turns out that one of your favorite
machines, the GE 6something (well, one of its descendents), does this
sort of thing. The Dartmouth College Time Sharing system started
putting shared libraries in segments in around 1985 or so. Worked
great.
-- Chuck
Alan T. Krantz
I'm not sure what you mean by explicit sharing of library code - but tops-10
did this sort of things with segments. Every program had two segments - a
"high" segment for code (usually writeing was disabled) and a low segment for
data. What the fortran compiler did was put the user's code in the low segment
and then when the program ran it specified the name of the "shared" hi segment
which contained the fortran library (a user could force the linker to generate
his own copy of the fortran library. Of course - one day our machine had a
parity error - just so happen it was in the middle of the shared segment - so
all the fortran programs died...
One neat part of using the shared segments was that the run library could be
updated without rebuilding the user's programs ...
Oh - I wish someone would donate a PDP-10 to me - and a house with a powerplant
to run it ...
------------------------------------------------------------------
| Mail: 1830 22nd street Email: a...@boulder.colorado.edu|
| Apt 16 Vmail: Home: (303) 939-8256 |
| Boulder, Co 80302 Office: (303) 492-8115 |
------------------------------------------------------------------
Randell Jesup
>candidates for "world's cheapest virtual memory demand paged Unix engine".
>
>Correct prices are (in 1000-unit quantity):
>Note that an external MMU is required (I don't have pricing for that).
>
>Motorola is about to release the 68020 in a new package with much reduced
>pricing. I don't know if the information has been formally announced yet,
>so I can't tell you what it is, but I would say that this chip will be
>certainly be the winner as far as low-end Unix machines are concerned.
>If you don't care to run MS-DOS, it's price-performance product will be
>significantly better than the 386SX.
Check out '030 prices. They're now available in a solderable
plastic chip carrier (winged leads) in 16 and 25 Mhz (at least), and they
of course have the MMU built in. Commodore is using them in our new A3000.
I don't know the price, but you could ask Motorola (I'm a software person).
They're supposed to be pretty cheap. The '030 is considerably faster than
the '020, due to integrated MMU and data cache, and some improvements to
internal execution speeds for some instructions.
Last I checked they're cheaper than an '020 and '851 pair.
--
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, je...@cbmvax.cbm.commodore.com BIX: rjesup
Common phrase heard at Amiga Devcon '89: "It's in there!"
Martin Fouts
In article <22...@crdos1.crd.ge.COM> davi...@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
[Anything you can do with virtual pages I can do with segments.]
True. But the granularity is a killer, and you frequently run out of
segment descriptors a lot more quickly than you run out of page table
entries. (I've used literally dozens of shared libraries.)
In spite of that, I believe that 95% of all programs on all computers
(by number rather than CPU cycles) will run in 4MB of address space.
And probably 95% in 16MB. There are not a lot of applications which
need the huge memory, and that means a small market, few vendors, high
prices, etc. Adam Smith walks here, too.
maybe true. I certainly have written a lot of small programs. But
its the big ones that are interesting (;-)
Martin Fouts
In article <3...@garth.UUCP> fo...@bozeman.ingr.com (Martin Fouts) writes:
> 3) Smaller is "better". If I have to solve a 1000^3 grid, I have to
> solve it. I've done it with segmented memory in the small (Y/MP)
> and segmented memory in the large (Cray 2) and virtual memory
> (ETA/10.) For my purposes, the Cray 2 was best. Your milage would
> vary.
In turn, you're making a false assumption: that there's something inherent
in these very large programs (VLPs) that people are complaining about
that requires them to be large. Nobody is denying that some problems
require big iron. Text processing, text editing, window systems, and so
on... the majority of VLPs that come under fire... have no inherent reason
to be very large. Even machines as small as a 128K Mac can run excellent
windowing systems, and editors and text processors are even smaller.
Say What!? There are *no* assumptions in my comments, which were based
on measurements. I said for a particular problem (and hinted at its
nature) that a particular machine was *measured* to perform better. I
then qualified the statement by noting that it wouldn't hold in all
cases: "Your milage would vary."
> I need paging. I need it to keep the total amount of memory I am
> using small and make my programs more efficient by:
> 1) Using implicit sharing of text segments
This does not require paging. Look at good old PDP-11 UNIX.
Doesn't require, but can use.
> 2) Using copy on write sharing of forked images
This requires paging. Fork() is a poor match for a non-demand-paged
architecture. My reaction is that we don't need fork().
> 3) Using explicit sharing of library code
This does not require paging. Look at good old PDP-11 RSX.
Doesn't require, but can be much easier to do. It is often harder to
manage the usually smaller number of segments than the usually larger
number of pages
> 4) Using explicit sharing of multithreaded applications
This does not require paging. Look at the Transputer.
Look at the Cray 2. But it's easier to do if you have them.
> 5) Using good locality of reference to minimize resident sets
This is the big win for paging systems. You don't need to pull any more
reasons out of the hat. However, when you have a small program anyway
this becomes much less important.
Ture.
The question shouldn't be "is paging good" or "is paging bad" or "who
needs it". The question is "do you need it".
I wasn't dealing with good/bad. I was asked "who needs it?" and I
answered me. I'm not sure that the difference between "who needs it"
and "do you need it" is worth using two statements for.
Also, paging and bloated programs are not synonymous. People can write
bloated program with overlays: look at the OS/360 kernel as described in
the Mythical Man-Month. The problem isn't paging. The problem is people
who think that because memory is cheap they can act like it's free.
That is what I was trying to say. I won't be subtle this time:
1) Paging can be abused
2) Paging can be used for many things.
3) Some of these things can be done other ways.
4) Taken as a whole, they make paging worth the effort.
Marty
Peter da Silva
> In article <D:T30:5...@xds13.ferranti.com> pe...@ficc.ferranti.com (Peter da Silva) writes:
> Say What!? There are *no* assumptions in my comments, which were based
> on measurements.
I didn't intend to imply that you were making assumptions about the
software. My point is that people are not complaining about software that
has to be big... they're complaining about bloated software that really has
no reason to be using that sort of resources. Emacs. GNU CC. X. Nobody's
saying paging is a bad thing.
Ronald G Minnich
>machines, the GE 6something (well, one of its descendents), does this
>sort of thing. The Dartmouth College Time Sharing system started
>putting shared libraries in segments in around 1985 or so. Worked
>great.
as a library, then it is a large text segment that has entry points, and
thus falls into this class too.
But what about a big chunk of code like libc or libX11?
On the DG MV/10000 libc was in Ring 3 (if memory serves ... this was
7 years ago). User processes lived in Ring 7. This was in hardware.
And of course B. has had library segments for going on 30 years now.
The question I keep wondering: EMT or whatever your favorite trap instruction
is provides a way, supported in hardware, of calling a library (/vmunix)
with a parameter (for sysent) which allows you to call a function without
knowing its address. Hardware support for dynamic binding, sort of. In
most Unix implementations I have seen /vmunix is the only place this is used,
with the aforementioned DG machine being an interesting exception.
Stdio and all that good stuff is called with straight standard jsr
instructions. My question is now that Unix is finally catching up with
dynamic binding in some implementations do we want architectural support so that
e.g. calls to libc.a have the same mechanism as the kernel calls (probably
not it is pretty expensive) or a *similar* mechanism that is supported in
hardware (e.g. mv10000 call gates, 386 call gates, and so on).
To put it another way do any of you out there see any change in architecture
to support dynamic libraries or dynamic binding or do we stick with traps
and munging all this stuff in software? In the current systems I have
seen (e.g. SunOS) i tend to worry a little about undetected (and undetectable)
jumps into the middle of a function in libc. How do we know this is not
happening now? As far as I can tell, we don't. What happens when we find out
that maybe it is?
ron
--
Grad student, ca 1976: Gosh, the v6 kernel is < 64K! Compare it to that
OS/MVS hog at 400K!
Grad student, ca 1986: Look at all the good stuff in Gnu Emacs for only 600K!
Richard Tobin
> bloated software that really has no reason to be using that sort
> of resources. Emacs. GNU CC. X.
While all these programs are fairly large, gcc (as I have mentioned
before) is rather better than most of the competition. Compiling a
single large function (a virtual machine interpreter) gcc (sparc) grew
to a size of 2 Mbytes. Sun's (sparc) C compiler compiling the same
code grew to a size of 44 Mbytes. Mips's C compiler used at least 6
Mbytes, maybe more.
-- Richard
--
Richard Tobin, JANET: R.T...@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.a...@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
Guy Harris
>little about undetected (and undetectable) jumps into the middle of
>a function in libc.
Well:
1) if you jump into the middle of a function in "libc", it's
either because a) the linker is malfunctioning, b) you
overwrote code (unlikely given that it's generally
write-protected) or smashed a function pointer, or c) because
you were *trying* to. In all those cases, the same thing can
happen with static linking, so it's not unique to dynamic
linking....
2) They're not *completely* undetectable; jumping into the
middle of a function means you don't run the function prolog,
don't copy the right stuff into registers, etc. so there's
what I suspect is a good chance that the misbehaving program
won't misbehave silently....
>How do we know this is not happening now? As far as I can tell, we
>don't. What happens when we find out that maybe it is?
Fix the linker, or fix the program not to overwrite code or smash
function pointers....
This is somewhat along the lines of doing other checks at run-time (or
even compile-time, for some checks), e.g. array-bounds checking. If you
do the latter (especially if the compiler can figure out when it's
needed and when it's not), you may be less likely to overwrite code or
smash function pointers - or do *other* nasty things, so putting the
"architectural" support (whether in the instruction set or the compiler)
there may buy you more.
Ronald G Minnich
> 1) if you jump into the middle of a function in "libc", it's
> either because a) the linker is malfunctioning, b) you
> overwrote code (unlikely given that it's generally
> write-protected) or smashed a function pointer, or c) because
> you were *trying* to. In all those cases, the same thing can
> happen with static linking, so it's not unique to dynamic linking....
always works because there is "hardware support" for it.
"" are there because it isn't really that great, but it does work.
That is not the case for SunOS style software supported dynamic
linking. If for some reason ld.so should get hashed by something
then I can no longer run anything. Period. So the "dynamic linking"
to the kernel is more robust (I think) because of
hardware support, such as it is. Do we not care about having
the same degree of robustness for libraries?
Of course it is not unique to dynamic linking; it is just that
nowadays on sunos i run ld everytime I run a program, and am thus
significantly more exposed to problems should there be a problem
with ld.so. Oh, heck, I will say it: like a virus in ld.so.
With the way things work now on SunOS you can instantly infect
every program on the system by changing one little file.
> 2) They're not *completely* undetectable; jumping into the
> middle of a function means you don't run the function prolog,
> don't copy the right stuff into registers, etc. so there's
> what I suspect is a good chance that the misbehaving program
> won't misbehave silently....
never have worked"- except it did, for years. We really saw this
when we made the big move from -11 to VAX in 1980.
I can easily find linker screwups in a statically linked object
with adb. Not so with dynamic linking. Not that this has ever
happened (well, actually, it did to me once long ago), but there
is a distinct difference in how easy it is to detect.
My original question stands. This list generally discusses
getting lotsa flops, but I don't see much discussion of
whether there should be a second look at such things as architectural
support for such things as dynamic linking. Does that mean
there should not be?
Guy Harris
>libraries?
I wouldn't, unless I saw dynamic linking fail a lot - sufficiently that
the extra cost was worth it. (Bearing in mind, of course, that since
lotsa existing architectures don't have it, there's limits to how much
it can help....)
The reason why you *need* hardware support for dynamic linking to the
kernel is that a call to the kernel crosses a protection domain
boundary, so jumping into the middle of code opens a security hole. If
jumping into the middle of a library routine executed in the same
protection domain opens a security hole, we're all in trouble....
> Of course it is not unique to dynamic linking; it is just that
>nowadays on sunos i run ld everytime I run a program, and am thus
>significantly more exposed to problems should there be a problem
>with ld.so. Oh, heck, I will say it: like a virus in ld.so.
>With the way things work now on SunOS you can instantly infect
>every program on the system by changing one little file.
Well, take a look at "Experience with Viruses on UNIX Systems" in the
Spring 1989 *Computing Systems*; even if you *don't* have dynamic
linking you can still infect lotsa programs if you let people write to
critical system files - such as, but not limited to, "ld.so".
Besides, the first thing *I'd* change in "ld.so" had I write access to
"ld.so" on some system I wanted to crack wouldn't be the way it sets up
jumps to library routines; I'd NOP out the check for set-UIDness before
deciding to allow the user to override the search path for dynamic
libraries by setting LD_LIBRARY_PATH....
In short, I've not seen any evidence that "architectural support for
dynamic linking" would be anything other than a solution looking for a
problem. Yes, you can cause all sorts of nasty problems by writing to
"ld.so", but the same could be said of a lot of *other* programs or
files.
It may be that it would be *part* of a change to increase the security
or reliability of a computer system, but I doubt it's anywhere near
*sufficient* to get you that.
Ronald G Minnich
>kernel is that a call to the kernel crosses a protection domain
>boundary, so jumping into the middle of code opens a security hole. If
>jumping into the middle of a library routine executed in the same
>protection domain opens a security hole, we're all in trouble....
It sounds like the issues of dynamic binding have all been resolved.
There are only ever going to be two modes, for binding to the
super mode we use hardware, for binding to the same mode we use software
to munge our code. We will never again have more than two modes,
I guess, so the answer to my question about
putting libc.a into an execute-only segment with some
amount of hardware support for calls (a la Multics)
to it is "no". The cost is too high for any potential gain now or
in the future. Case closed. Thanks for the replies, folks.
Mark Robert Thorson
Motorola 68K-family chips. The info has now been published, so I feel
free to post it here:
68020 -- $47
68030 -- $95
68881 -- $38
68882 -- $44
All prices are in 1000-unit quantity at 16 MHz. These prices only apply
to the new packaging options, ceramic quad flat-packs for the CPU's and
PLCC's for the FPU's.
After my earlier posting, I got e-mail from someone who claimed to have
bought a 68030 for $45 (single-unit qty, I presume). I wouldn't be too
surprised if that chip came from a large batch of defective chips. These
chips can be identified by an assembly code of Q90xx, where xx is between
03 and 10. The assembly code is printed on the third line of the package
marking. The defect has to do with the sealing of the package -- the chips
might work fine forever, or they might show age-related failures prematurely.
Moto rola says they'll replace the defective chips, though I don't know if
that deal applies to folks who bought a single unit at a hobby shop for
a discount price.
I had earlier said it looked like the 68020 would be the world's cheapest
Unix engine. I was forgetting that it was the 68030 which has the on-chip
MMU. At $95, it's more expensive than the 386SX ($64 in 1000's at 16 MHz).
But when you factor in the price of the FPU, Motorola probably beats Intel.
Motorola should also be faster, because the 386SX has a 16-bit external bus.
BTW, there's a 12 MHz version of the 386SX for $55.50 in thousands.
Somebody said the Acorn RISC machine might be a contender. As I pointed out
in the earlier posting, it requires a separate MMU. I don't have the pricing
on that chip, but I would be surprised if the chip set beats the 386SX on
price or performance.
Somebody else recommended I look at LSI Logic's new SparKIT. The complete
chip set costs $1327 in 1000's at 25 MHz. That includes DMA controller,
DRAM controller, and some other stuff, so it isn't directly comparable
to the 68030 or 386SX pricing. But when you consider that there's a bunch
of companies making chip sets for 386SX-based AT-compatible motherboards,
I'm sure it'd be possible to build a 386SX system for a whole lot cheaper
than a SPARC system. The ZyMos chip set looks particulary good.
To make a system, you need only the 386SX, 387SX, BIOS ROM, P90 peripheral
chip, P91 DRAM controller, DRAM, P92 AT Bus Buffer, and 8042 keyboard controller.
If you only have one bank of DRAM (that could be 8 Mbytes, using the 4 Mbit
chips), you don't need any glue logic.
I haven't got pricing for National's 32532, but the embedded controller
version costs $99 in 1K-qty at 20 MHz, so I'm sure the 532 isn't any
cheaper than that. The embedded controller version (32GX32) is just like
the 532, except it lacks the MMU (or maybe they poured epoxy into its
enable bit :-). Anyhow, the computer graveyard is littered with the bones
of people who designed in a National proprietary CPU, so when you factor that
in, the 68030 looks like a much better deal.
Wm E Davidsen Jr
Honestly chip cost is a small part of the system cost. I have been
getting pricing on parts to make a super cheap home unix system (total
<$3k), and after looking at all the systems I could buy, it looks as if
the 386 based systems are the cheapest.
A few of us are trying to build a system for <$3k with unix and X
capability, color, and enough disk to be useful. We're going to sell for
$100 over cost, and hope someone else will undercut our price before we
get bored building systems. The list of vendors will be available to
anyone who wants to build their own, but some prices depend on three or
ten quantity.
Mark Robert Thorson
100 500 pcs
532 20mhz $505 $485
532 25mhz 575 555
381 20 mhz 86 83 fpu
381 25 mhz 168 160 fpu
Gasp! I wouldn't have guessed they cost so much. I guess no one can
accuse National of underpricing their chips.
Guy Harris
>There are only ever going to be two modes, for binding to the
>super mode we use hardware, for binding to the same mode we use software
>to munge our code. We will never again have more than two modes,
>I guess,
Depends on what you mean by "modes".
I don't know that I'd say future systems will *never* support multiple
protection domains. However, those systems may, just like the Multics
system, have only "user" and "supervisor" mode, and may make use of the
added protection domains to run 99 44/100% of even the lowest levels of
the OS in "user" mode, just as Multics did.
I don't know how much hardware support there would be for this. Multics
on the GE645 didn't have much hardware support; the gate segment was
flagged as non-executable, so a cross-ring procedure call caused a trap.
The gatekeeper software did the requisite permission checking, etc.;
this is not entirely unlike what's done with "supervisor call"
instructions.
The 6180 added hardware to do this, which I think made cross-ring calls
run much faster; there might be other solutions, though. Mach might
fall under this heading, for example with the various user-mode server
processes being the protection domains, and passing a message from a
user program to a server being the equivalent of a cross-domain
procedure call.
>so the answer to my question about putting libc.a into an execute-only
>segment with some amount of hardware support for calls (a la Multics)
>to it is "no".
The only real support Multics offered for inter-domain dynamic linking,
as I remember, was that it had a pointer type that caused a trap when
you dereferenced it. Only calls that crossed rings went through a gate
segment; calls that didn't cross rings went directly to the first
instruction of the procedure being called, albeit through an indirect
pointer, so if there was e.g. a bug in the Multics linker that caused it
to incorrectly resolve links and caused you to jump into the middle of a
procedure, it wouldn't be detected....
Multics could have such a pointer type without too much pain because
1) full-blown pointers on the Multics hardware were 72 bits long, so the
pointer type field that supported Fault Tag 2 sort of came for free;
2) as I remember, the instructions to load a pointer into a base
register (or base pair, on the 645) trapped if you tried to load a
FT2 pointer, so you didn't have to worry about FT2 pointers being in
base registers or in memory outside the combined linkage segment.
The dynamic linker in SunOS 4.x/S5R4 doesn't have those luxuries.
Instead, the way it does dynamic linking to procedures is that the
procedure call instruction jumps to an entry in the procedure linkage
table, rather than to the routine itself. The PLT entry jumps to the
dynamic linker, which finds the routine and then updates the PLT entry
to point to the routine itself.
It doesn't do linkage to data quite as dynamically; references to global
data are relocated by the run-time loader at program startup time,
rather than at the time of the first reference.
Again, the more important hardware support was for intra-domain
procedure calls.
Guy Harris
>procedure calls.
"*Inter*-domain procedure calls", dummy. :-)
Paolo Pennisi
> A while back, I referred to pending announcements of prices cuts on
> Motorola 68K-family chips. The info has now been published, so I feel
> free to post it here:
>
> 68020 -- $47
> 68030 -- $95
> 68881 -- $38
> 68882 -- $44
>
> All prices are in 1000-unit quantity at 16 MHz. These prices only apply
> to the new packaging options, ceramic quad flat-packs for the CPU's and
> PLCC's for the FPU's.
> I had earlier said it looked like the 68020 would be the world's cheapest
> Unix engine. I was forgetting that it was the 68030 which has the on-chip
> MMU. At $95, it's more expensive than the 386SX ($64 in 1000's at 16 MHz).
> But when you factor in the price of the FPU, Motorola probably beats Intel.
> Motorola should also be faster, because the 386SX has a 16-bit external bus.
> BTW, there's a 12 MHz version of the 386SX for $55.50 in thousands.
Are we talking Unix engine or DOS ?
How can you compare an handicapped version of a chip whose father and
grandfather are crippled 16 bit segmented processor, a chip which spends
a lot of its silicon to implement compatibility with those dark ages
cpu to a real 32bit, semi Harvard, data and instruction cache processor,
with a real 32 bit data bus a a real 32bit address bus, support for multipro
cessing and more.
Sure, if we want to build the smaller and cheapest Unix engine we could also
use a Z8001 or a 80286 or whatever... maybe some crippled version III could
run also on a Z80.
The 68030 is definetly superior, more bangs per buck, even not including
the FPU. The 68882 is surely better than a 387DX, not to mention the 387SX.
And it costs definetly less!
Paolo.
PS
I don't want to start another religion war... but the comparison with
the 386SX is too much.
--
(ARPA) si...@bench.sublink.ORG Paolo Pennisi
(BANG) ...!deejay!bench!silos via Solari 19
(MISC) ppennisi on BIX & PTPOSTEL 20144 Milano ITALIA
----< S U B L I N K N E T W O R K : a new way to *NIX communications >-----
Chip Salzenberg
>How can you compare an handicapped version of a chip whose father and
>32bit, semi Harvard, data and instruction cache processor, with a real
>32 bit data bus a a real 32bit address bus, support for multiprocessing
>and more.
Because usable Unix is available for them both.
Any more questions?
--
Chip Salzenberg at ComDev/TCT <ch...@tct.uucp>, <uunet!ateng!tct!chip>
Wm E Davidsen Jr
| Are we talking Unix engine or DOS ?
| How can you compare an handicapped version of a chip whose father and
| grandfather are crippled 16 bit segmented processor, a chip which spends
| a lot of its silicon to implement compatibility with those dark ages
| cpu to a real 32bit, semi Harvard, data and instruction cache processor,
| with a real 32 bit data bus a a real 32bit address bus, support for multipro
| cessing and more.
You're stuck in an infinite loop here. You can't compare the 68k with
a Cray, either. The objective is to build a UNIX engine capable of doing
useful work and running a 32 bit version of a modern O/S. The price
point is that the color system with X will be competitive in price with
a color X terminal.
Since the only low prices UNIX around is V.3.2 (and maybe V.4 soon)
for the 386, that is the choice. Since the cost of the DX chip is
artificially high (I would bet the manufacturing and development cost is
within 10% of the SX) the SX is the only practical choice.
| Sure, if we want to build the smaller and cheapest Unix engine we could also
| use a Z8001 or a 80286 or whatever... maybe some crippled version III could
| run also on a Z80.
Read the original article and the above. You're changing the
objective. Those processors would cost a lot more because there is no
mass production of systems and vendor competition to keep the price
down.
| The 68030 is definetly superior, more bangs per buck, even not including
| the FPU. The 68882 is surely better than a 387DX, not to mention the 387SX.
| And it costs definetly less!
If you can deliver a system complete with color display and software
for $3000 I will agree. Until then I think you're dreaming. This is not
a perfect workstation, it's a color X terminal which is also a free
standing UNIX system. Wish I could include the development set for $3k,
but it doesn't look good.
If anyone wants to help
When I find vendors for all this stuff I intend to sell for cost
(counting $100 as cost to assemble, burnin, and install UNIX). I will
make the list of vendors available to anyone, in hopes that
"competition" will drive the price down and put me out of business.
Since I'm doing this to make a point, rather than make money, I'd be
glad to have someone else make the pittance. If you or your club or
organization want to build some of these drop me a line and I'll send
the vendor list when I get the final configuration.
If you know if a good system which will run UNIX, or a good
motherboard, or VGA display, hard disk, whatever, let me know! I want
current production rather than remnants, so other people and clubs can
build these systems. Please tell me about stuff which you have actually
used, rather than ads. I have a pile of once used motherboards, disk
controllers, and VGA cards, all of which are great for DOS and don't sun
UNIX.
If you can get a UNIX with NFS and X for less than Open DeskTop ($995)
let me know. ESIX + NFS is slightly higher than that by the prices I got
from Everex and ISC.
Woodrow Yeung
> Since the only low prices UNIX around is V.3.2 (and maybe V.4 soon)
>for the 386, that is the choice. Since the cost of the DX chip is
>artificially high (I would bet the manufacturing and development cost is
>within 10% of the SX) the SX is the only practical choice.
I sure hope the SX is only 10% more expensive to make. It would be pretty
silly for Intel to put any more engineering effort in making the 386SX than
to disable some 16 line on the 386. Thus, the 386SX chip is a more expensive
chip, Cost = 386 + lobotomy.
Now if aluminum were as cheap as silicon, we'd be seeing 5.0L 4 cylinder
Porsches that look identical to the 928's V8; the only difference would be 4
faulty fuel injectors that can't be fixed.
Nah, that would be too obvious of a case of price discrimination. Hey any
law students reading this? You should call up AMD, Harris or even NEC and
launch an illegal price competition suit. Oh! I forgot, only Motorola gets
nailed by lawsuits. ;-)
yeung@reed
ye...@eecs.cs.pdx.edu
yeung!@lclark
Sean Fagan
>|we could also use a [...] 80286
>Those processors would cost a lot more because there is no
>mass production of systems and vendor competition to keep the price
>down.
Huh? The '286 is produced by *several* people. Not just machines, but the
*processor* (AMD, Harrisson, Intel). This is why Intel wants people to go
to the 386SX so much. (Last I heard, AMD was in some arbitration with Intel
about the rights to produce the '386 [this was after the court decision];
hopefully, they will be able to do so.)
Wm E Davidsen Jr
| I sure hope the SX is only 10% more expensive to make. It would be pretty
| silly for Intel to put any more engineering effort in making the 386SX than
| to disable some 16 line on the 386. Thus, the 386SX chip is a more expensive
| chip, Cost = 386 + lobotomy.
Since the logic is in the DX bus interface unit to build 32 bit
fetches from 8 and 16 bit datapaths, I think all that's needed (more of
less) is to set the 16 bit datapath line active. That much is true.
However, note that most other chip manufacturers have not put logic in
the BIU to work with narrow data paths or offset addresses. If you try
to fetch 32 bits starting at a location not a multiple of four on a
SPARC you get a bus error.
This is a matter of design philosophy: should the chip do what I say,
even if it isn't fast, or should the chip leave out logic to allow me to
do what I want, so that there will not be slow instructions.
Note that the 68k chip in a Sun3 also allows offset addressing, while
several mainframe systems don't. This is not a CISC vs RISC issue, since
some CISC systems restrict addressing. Since it's easier to not handle
anything except bus access in a single read, I don't see where a chip
which allows more complex bus access modes is inferior.
Paolo Pennisi
this news, but... what about: segments, 64k segment limits, near & far
pointer, large model compiles, 16bit integers, stacks overflow, hours
spent on PD software to catch a bug, which with a normal 32bit processor
would'nt hard more than a warning... (pointers (far:32bit) to int (16but).
Yes, it is usable, to receive and send e-mail, to read and post news (if
u get the bug i mentioned or u have the patched version).
Yes, with a 386SX, all these problems are gone... but SX at clones are
slower than 286 to run DOS, OS/2... let's think of Unix...
I can hardly stand a comparison with a 386DX... the SX is far away,
the 286 doesn't exist (wot... my computer is vanishing....acc!).
Let's have a look of the prices again... 68030-16Mhz, sold in quantity (1k)
for 95$, 68882-16Mhz for just 44$. These are clone prices...
Let's start to think why Intel keeps it prices for inferior silicon so high?
Well, I gone away from the main path, it is my flame fever... I'm sorry.
No more questions!
Paolo.
Bill Beebe
In the last quarter for which such statistics are available (I believe Q1
90), some 10 million 80286 devices were shipped by AMD, Harris, and Intel,
with the largest share by AMD. Reasons for the continuing upsurge in
shipments are the lower price for 16-, 20-, and 25Mhz 80286 versus the
equivalent 80386SX. Intel wants about $65 for the SX in 1000s at 16Mhz,
while the going price for the 80286 in 1000s is between $20 and $30. These
80286 chips at 16Mhz are true CMOS (Intel can't make anything faster than
12Mhz NMOS). Another equally compelling reason for the use of the 80286
is the current allocation of the 386 family, including the SX. Oh yes, Intel
shipped only 1 million 80386SX chips in the same period, and because of
very high demand, the spot-market (broker) price for the 80386SX is about
$200.
The difference in units shipped does not bother Intel, since they claim they
made about as much profit shipping the 1 million SX chips as everyone else made
shipping the 10 million 80286s.
Mark Robert Thorson
> I sure hope the SX is only 10% more expensive to make. It would be pretty
> silly for Intel to put any more engineering effort in making the 386SX than
> to disable some 16 line on the 386. Thus, the 386SX chip is a more expensive
> chip, Cost = 386 + lobotomy.
Not quite. The SX comes in a plastic flat-pack. The other MS-DOS CPU's
come in ceramic, so the SX should be significantly cheaper, percentage-wise,
to manufacture.
Of course, cost-of-production has nothing to do with the sale price, other
than to place a lower bound on it.