blarson%castor.usc.edu@USC-OBERON.ARPA.UUCP (02/08/87)
Path: castor.usc.edu!blarson From: blarson@castor.usc.edu (Bob Larson) Newsgroups: mod.computers.68k Subject: Re: Minix to the 68k? Message-ID: <644@castor.usc.edu> Date: 8 Feb 87 08:11:15 GMT References: <8702070057.AA17890@amdcad.AMD.COM> Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson) Organization: USC AIS, Los Angeles Lines: 23 In article <8702070057.AA17890@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes: >Given that I'm a little shy on information about #3, I'd like to ask the >Amiga gurus here how the Amiga manages to do multitasking. (for that matter, >how does OS9 mangage it?) All Os9 code (except for some system dependent stuff like the boot code) is position indepentent and sharable. When a program is started, if it is not already in memory, (due to special request or another user using it) it is loaded into avalable memory. Data areas are allocated seperatly. Once memory has been allocated, it is not released until it is no longer in use. (Relocation does not occur durring execution.) This allows return addresses, etc. to be pushed on the stack in the normal manner. Yes, this scheme does have the clasical "fragmentation" problem, and does limit your processes to physical memory, but a few extra kilobytes of memory is probably cheaper than a MMU. (This refers only to level I os9. Level II, such as will soon be released for the coco 3, does use an MMU.) -- Bob Larson Arpa: Blarson@Usc-Eclb.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
bet@dukeac.UUCP.UUCP (02/11/87)
Path: dukeac!bet
From: bet@dukeac.UUCP (Bennett Todd)
Newsgroups: mod.computers.68k
Subject: Re: Minix/68k
Message-ID: <359@dukeac.UUCP>
Date: 11 Feb 87 17:04:59 GMT
References: <8702081739.AA11278@gorgo.att.com>
Reply-To: bet@dukeac.UUCP (Bennett Todd)
Organization: Duke User Services, Durham, NC
Lines: 18
OS/9's multitasking model won't help either UNIX or Minix run well on a plain
68000 without MMU; someone mentioned earlier that it doesn't relocate a
process after the process has begun executing (I don't know OS/9; if that was
incorrect then discount this whole note). UNIX (and Minix) found their notion
of multitasking on the fork() system call, which makes two (almost) identical
processes out of the one which invokes it. The two then continue executing
independently. This requires, at a minimum, the ability to duplicate memory
allocated to data, and allow two separate images to proceed executing. Unless
tasks are going to swap on every context switch, the data area has to be
relocatable (including pointers to data and subroutine return addresses on the
stack).
-Bennett
--
Bennett Todd, Duke User Services, Durham, NC 27706-7756; +1 919 684 3695
UUCP: ...{philabs,akgua,decvax,ihnp4}!mcnc!ecsvax!dukeac!bet
BITNET: DBTODD@TUCCbill@caip.rutgers.edu@tifsie.UUCP (02/13/87)
Path: tifsie!bill
From: bill@tifsie.UUCP (Bill Stoltz)
Newsgroups: mod.computers.68k
Subject: OS9 Questions (was Re: Minix/68k)
Summary: questions about OS9
Message-ID: <311@tifsie.UUCP>
Date: 13 Feb 87 05:58:02 GMT
Article-I.D.: tifsie.311
Posted: Thu Feb 12 23:58:02 1987
References: <8702081739.AA11278@gorgo.att.com>
Organization: TI Process Automation Center, Dallas
Lines: 29
Steve Blasingame gave a lot of information about OS9, but he left
me with a few unanswered questions.
If every process is position independent then is every process limited
to 64K bytes? In order to be position independent you have to use
PC relative code. PC relative, from what I have been able to find,
is +-32K bytes. Obviously, programs can be greater than 64k but all
references must be within 32k. How does OS9 handle this?
What does OS9 use to try to protect other processes or kernel memory
from the currently running process, without the use of an MMU?
Where can I get more information on OS9? (General Overview and
some internal workings like we have discussed here)?
-----------------
Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243
UUCP: {uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice: (214) 995-2786jejones@mcrware.UUCP.UUCP (02/13/87)
The earlier mention was right; a OS-9 process's data memory does not get
moved. (Of course, 99.9+% of programs under Unix that use fork() read
if (fork() == /* whatever says I'm the child */)
exec[a-z]*("what I really wanted to run", ...);
so I don't think that OS-9's at any great loss for not having Unix's
fork().)
James Jonesblarson%castor.usc.edu@usc-oberon.arpa.UUCP (02/15/87)
Path: castor.usc.edu!blarson From: blarson@castor.usc.edu (Bob Larson) Newsgroups: mod.computers.68k Subject: Re: OS9 Questions (was Re: Minix/68k) Message-ID: <714@castor.usc.edu> Date: 14 Feb 87 21:56:18 GMT References: <8702130559.AA20439@tilde> <8702081739.AA11278@gorgo.att.com> Organization: USC AIS, Los Angeles Lines: 50 Sender: Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson) Followup-To: Distribution: Organization: USC AIS, Los Angeles Keywords: In article <8702130559.AA20439@tilde> bill@caip.rutgers.edu@tifsie.UUCP (Bill Stoltz) writes: Os9/68k: >If every process is position independent then is every process limited >to 64K bytes? In order to be position independent you have to use >PC relative code. PC relative, from what I have been able to find, >is +-32K bytes. Obviously, programs can be greater than 64k but all >references must be within 32k. How does OS9 handle this? Local program references are limited to the PC-relitive limits. External references are fixed by the linker to inderection through initalized data. (The run-time initialization code calculates the actual address.) Warning: the linker that came with the 2.0 C compiler had a bug in how it handled pointers to functions more than 32kbytes away. >What does OS9 use to try to protect other processes or kernel memory >from the currently running process, without the use of an MMU? Without hardware assistance, there is not much it can do. The fact that all of os9 is relocatable and may be in different places based on machine, os version, etc. does help keep the tinkerers at bay. >Where can I get more information on OS9? (General Overview and >some internal workings like we have discussed here)? Os9/6809 is covered pretty well in "the complete rainbow guide to os9". (Available at radio shack.) The 68k version is similar, but improved. 68 micro journal is the only non-coco commercial magazine that gives regular coverage to os9. The Os9 users group occasionaly gets around to putting out another issue of their "monthly" magazine MOTD. (I don't have their new address.) Mod.os.os9 has some interesting stuff once in a while. Compuserve has a pretty active, but non-technical, os9 section. Bix and Delphi also have os9 sections. (The delphi one is shoved under their coco section.) I'm sure microware would be willing to sell you a set of manuals. -- Bob Larson Arpa: Blarson@Usc-Eclb.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
bsteve@ucbvax.Berkeley.EDU@gorgo.UUCP (02/16/87)
This was a problem in the implementation of OS9 for the 68k. The fix involved
a smart code generator for the C compiler. The limitation is that a single
function may not be larger than 64k (at least in the initial implementation).
Anyone that would write a function that large is in trouble anyway (in my
opinion). The make it clearer, local variables are stored on the stack and
this segment is also limited by the architecture on a per-function basis.
Global/external and static variables are stored in a preallocated static data
segment.
Hope this helps,
Steve Blasingame (Oklahoma City)
ihnp4!occrsh!gorgo!bsteve
bsteve@eris.berkeley.edubsteve@ucbvax.Berkeley.EDU@gorgo.UUCP (02/16/87)
>The earlier mention was right; a OS-9 process's data memory does not get >moved. (Of course, 99.9+% of programs under Unix that use fork() read > if (fork() == /* whatever says I'm the child */) > exec[a-z]*("what I really wanted to run", ...); >so I don't think that OS-9's at any great loss for not having Unix's >fork().) I partly agree, but I would like to have both the OS9 fork() construct with exec() built-in as well as the unix fork(). Given the more recent implementations of UNIX that use virtual memory and copy-on-write, to allocate data segments the overhead of the UNIX fork() is much reduced. This does not preclude the *large* additional overhead of the additional system call to exec(). The reasoning for having the OS9 fork() is very straightforward. It is much simpler to use and is what you need much of the time. The need for the UNIX fork()/exec() construct comes into play when one wishes to perform changes in the process environment (a.k.a signals or io-controls) before actually loading the child process. A good example of this has to do with the creation of children that one doesn't wait() on. You may wish to direct particular signals to a particular process. Consider the following example: /* fork a child process to invoke notes on the * notesfile msg.username for the selected user */ if (!(pid=fork())) { signal(SIGCLD, SIG_DFL); execle("/usr/bin/notes","",answer,0,environ); } else { /* turn off signals in the parent process */ isave= (int) signal(SIGINT, SIG_IGN); hsave= (int) signal(SIGHUP, SIG_IGN); /* wait for child process to complete */ (void) signal(SIGCLD, SIG_DFL); while ((retval=wait(&status)) != pid) ; (void) signal(SIGCLD, SIG_IGN); /* turn back on (void) signals in the parent process */ (void) signal(SIGINT, isave); (void) signal(SIGHUP, hsave); } Here we want the child process to always recieve interrupts and hangups, but wish to disable them in the parent. Given the OS9 fork() this would not be possible. Also in this example we use SIGCLD because we have some asynchronously running children that are concurrent to this child. Steve Blasingame (Oklahoma City) ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu
m5d@bobkat.UUCP.UUCP (02/17/87)
In article <8702131404.AA03521@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes: >The earlier mention was right; a OS-9 process's data memory does not get >moved. (Of course, 99.9+% of programs under Unix that use fork() read > > if (fork() == /* whatever says I'm the child */) > exec[a-z]*("what I really wanted to run", ...); > >so I don't think that OS-9's at any great loss for not having Unix's >fork().) > > James Jones I'll agree that most calls to fork() are followed soon after by an execve(), but not immediately. Files might be closed or opened, priorities changed, and various other things might happen before the new program is loaded. And this still doesn't address the small minority of programs that DON'T execve() after a fork(). For example, the shell -- when it runs a loop in a subshell, it of course doesn't re-load itself. It just calls fork() and the child runs the loop (after redirecting any files). I think that lack of a real Unix fork() is THE great loss of OS9. (Along with lesser things like one-ended pipes, no signal queue, no in-core inode table for text sharing, ...) For a CoCo, OS9 is a big step up. For a 68000 system, however, I want real software. -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474
cmcmanis@seismo.CSS.GOV@sun.UUCP (02/18/87)
Path: sun!cmcmanis
From: cmcmanis@sun.uucp (Chuck McManis)
Newsgroups: mod.computers.68k,comp.sys.amiga
Subject: Fork() under AmigaDOS and others
Keywords: fork(), shared memorry
Message-ID: <13545@sun.uucp>
Date: 18 Feb 87 18:30:00 GMT
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 25
With all the discussion about fork() and why you can or cannot do it
without an MMU, I thought of a solution that I haven't seen proposed
yet.
On the Amiga executables are stored in a runtime loadable format, and
there is a system call LoadSeg() that will load the executable into
memory and fix up all the variable references. So why can't fork()
simply read in a new copy of the executable from disk, peek at the
address of it's data hunks, and copy the variables from the current
process to the new process, duplicate the stack, and then kick it off
with CreateProc() to make it run. You would then have two copies of
the code running simultaneously and not have to worry about 'swapping'
back and forth.
I have not figured out if one would have to muck with such things as
duplicating the current memory allocated by the parent process, and
if so fix up such things as linked lists of data structures.
Comments anyone? Anyone know how Lattice 3.10 does fork() ?
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.bandy@amdcad.UUCP.UUCP (02/19/87)
>From: cmcmanis@sun.uucp (Chuck McManis) >With all the discussion about fork() and why you can or cannot do it >without an MMU, I thought of a solution that I haven't seen proposed >yet. > > [why not just get a clean copy of the unrelocated executable off of > disk,ala amiga's dos, and copy the data space and stack?] >I have not figured out if one would have to muck with such things as >duplicating the current memory allocated by the parent process, Yes, you would. >and >if so fix up such things as linked lists of data structures. It would be difficult. For the compiler to put enough (uh) "bugs" in to allow the operating system to know what to fool with during a fork would be a *large* performance hit. As to duplicating the stack, what happens when you have char *s; auto ca[666]; s = &ca; in your scheme? Whoops! Pointing at the wrong area of memory! In fact, I wrote a little article today about how Tanenbaum's friend who is doing the ST port is working it - and since you probably don't read comp.sys.atari.st, I'll duplicate it here: From: bandy@amdcad.UUCP (Andy Beals) Newsgroups: comp.sys.atari.st Subject: Multitasking discussion Well, as you may know, Andy Tanenbaum has mentioned a number of times that a friend of his is working on a port of minix to the ST. Well, I was curious as to which method was being used (planned on being used? I don't know how far along that port is), so I dropped a note off to him and found out that when processes are loaded, they are relocated on the fly -- apparently the same method that the Amiga folks use. When a process forks, the child is "swapped" to somewhere in memory (wherever there is enough room). When the scheduler starts the child, it swaps out the parent (to somewhere else in memory), swaps the child to where the parent [was] and starts running the child -- this way all the text and data references are okay. In most cases, the child will exec so the new process being loaded in can go anywhere and the parent process can go back to where it belongs. This all should happen within one scheduler tick, so you won't have to do more than four copies of the parent's process image if you're careful // however, if you're really careful, you could get away with two copies (for the fork/exec case) -- copy the parent, run the child (where the parent was), when the child execs, copy the parent back to where it belongs You might be able to get away with not copying the parent back *just shuffle the pointers), but with no read-only pages (no mmu), you have no guarantees that the child hasn't scribbled all over the data or text pages). Yes, I know, this sounds gross, but it isn't too bad -- after all, if you do want your machine to go faster, you can wait until one of the home-computer manufacturers comes out with a cheap machine with an MMU and then run Minix on it. -- Andrew Scott Beals, {lll-crg,decwrl,allegra}!amdcad!bandy +1 408 749 3683
mhorne@tekfdi.FDI.TEK.COM.UUCP (02/20/87)
Path: tekfdi!mhorne From: mhorne@tekfdi.TEK.COM (Mike Horne) Newsgroups: mod.computers.68k Subject: Re: 68000 O/S's, MMUs, et. al. Message-ID: <787@tekfdi.TEK.COM> Date: 19 Feb 87 22:01:25 GMT References: <8702181533.AA27804@ucbvax.Berkeley.EDU> Reply-To: mhorne@tekfdi.UUCP (Mike Horne) Organization: Tektronix, Inc., Beaverton, OR. Lines: 52 In a recent article, HELLER@cs.umass.edu writes: >...multi-user systems it is needed. It is doubtful >that MMUs will ever be common on *little* home/office systems (i.e. ST's, >Amiga's, Mac's etc.) - most of these system will be running well behaved Guess again. In the history of '*little* home/office systems', manufacturers have always put the most up-to-date hardware in their machines at the time of development. Since most new CPUs have built in MMUs, new computers will obviously have OSs that take advantage of this. Atari, Apple, etc., aren't going to put Z80s in their new machines with no MMU just because someone out there can write a 'well behaved' program! It's called 'computer evolution'. >I really doubt that UNIX/MINIX will ever be the O/S of choice amongst home >and office users: UNIX is just too "weird" (why is the directory command >"ls"? why is the type command "cat"? what is an inode? - only UNIX hackers >really understand UNIX). Obviously you haven't given it much thought. Gee, could "cat" possibly stand for "concatenate?" Naaa... Pick up a book once in a while. Gosh, I wonder why UNIX is showing up so often as THE operating system in any new, state-of-the-art computer? Even MS-DOS (yucko!) has some look/feel of UNIX. >Secondly, I have found that I have had little or no trouble with runaway >pointers totally trashing the system, at worst it just trashes the current >"process". Re-booting just that process is suffientent. I guess I tend to >write good code. Also, I have little need to run jobs in the background >much. I guess I am just a synchronious user. I suspect that if I had UNIX on >my system it would just cause an *increase* in the system overhead, because >I would not use enough of it to justify most of what it would supply me >with. I just don't have much need of forks and pipes (or even virtual memory >- I will be going to a 4-meg system soon, which will provide me with more than Gee, I'd never want a Jaguar XJS. What would I do with all that power? Boy, it just doesn't make sense. I'd much rather drive my Edsel. Just the right amount of power I need... I find it hard to believe that you are not just joking! You obviously like the flavor of your foot, but I guess we all are entitled to an opinion. I, too, had a small system, but I learned that a UNIX type system, with memory managment, Vmem, process forking, etc., unleashes power one couldn't dream of before. I suggest you send your messages about things you obviously have no knowledge about to /dev/null. That is, type 'cat > /dev/null'... Mike ------------------------------------------------------------------------ Michael Horne - KA7AXD FDI group, Tektronix, Incorporated INTERNET: mhorne@tekfdi.fdi.tek.com UUCP: {decvax,hplabs,hp-cd,reed,uw-beaver}!tektronix!tekfdi!mhorne
gary@percival.UUCP.UUCP (02/20/87)
Path: percival!gary
From: gary@percival.UUCP (Gary Wells)
Newsgroups: mod.computers.68k
Subject: Re: 68000 O/S's, MMUs, et. al.
Message-ID: <447@percival.UUCP>
Date: 20 Feb 87 19:36:41 GMT
References: <8702181533.AA27804@ucbvax.Berkeley.EDU> <8702190305.AA02511@eneevax.umd.edu>
Reply-To: gary@percival.UUCP (Gary Wells)
Organization: Percy's UNIX, Portland, OR.
Lines: 19
>The UNIX command interpreter is pwoerful and relatively consistant<
Well, you're half right. The only thing consistant about UNIX commands,
especially the options, is that they ALL work differently. Check the
BUGS entry on every man page : "The (insert any letter) option does not
work the same as the (insert related command) (insert some other letter)
option."
True, you can get used to them. True, I like it. True, it's powerful.
It is NOT easy to learn, nor intutitive. (But neither is life).
We really ought not to rain critisism on the messanager for speaking the
truth.
.
--
--------------------------------------------------------------------------------
Wudda yeah mean, I'm gonna get in trouble? I AM in trouble!
________________________________________________________________________________blarson%castor.usc.edu@USC-OBERON.ARPA.UUCP (02/21/87)
Path: castor.usc.edu!blarson From: blarson@castor.usc.edu (Bob Larson) Newsgroups: mod.computers.68k Subject: Re: Submission for mod-computers-68k (really Nuxi fork()) Message-ID: <813@castor.usc.edu> Date: 21 Feb 87 02:24:43 GMT References: <8702131404.AA03521@mcrware.UUCP> <8702171750.AA05745@bobkat> Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson) Organization: USC AIS, Los Angeles Lines: 38 In article <8702171750.AA05745@bobkat> bobkat!m5d (Mike McNally (dlsh)) writes: >I'll agree that most calls to fork() are followed soon after by an >execve(), but not immediately. Files might be closed or opened, >priorities changed, and various other things might happen before the >new program is loaded. Os9 does let you do most of this. The os9fork call includes priority as an argument, and files may be handled by use of dup(), open(), close(), etc. and the ability to specify how many file descriptors to pass. >And this still doesn't address the small minority of programs that >DON'T execve() after a fork(). For example, the shell -- when it runs >a loop in a subshell, it of course doesn't re-load itself. It just >calls fork() and the child runs the loop (after redirecting any >files). The example is one that would work well as a separate process, sharing the program (as os9 always does) but with separate data. I have yet to see a program that can't be recoded to use os9 fork rather than unix fork. (Addmitadly, it isn't always trivial.) >I think that lack of a real Unix fork() is THE great loss of OS9. >(Along with lesser things like one-ended pipes, no signal queue, no >in-core inode table for text sharing, ...) For a CoCo, OS9 is a big >step up. For a 68000 system, however, I want real software. What pipe feature is missing? If by "text sharing" you mean multiple users use a single copy of a program in memory, os9 ALWAYS does that. The things I want in os9 are the various utilities, disk cashing (which some version have), and virtual memory. -- Bob Larson Arpa: Blarson@Usc-Eclb.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson
usenet@JADE.BERKELEY.EDU.UUCP (02/21/87)
Path: jade!violet.berkeley.edu!mwm From: mwm@violet.berkeley.edu (Mike Meyer) Newsgroups: mod.computers.68k Subject: test, mod.computers.68k Message-ID: <2581@jade.BERKELEY.EDU> Date: 21 Feb 87 20:24:34 GMT Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@violet.berkeley.edu(Mike Meyer) Distribution: ucb Organization: University of California, Berkeley Lines: 5 Another test. Ignore this one, too. <mike
mhorne@tekfdi.FDI.TEK.COM.UUCP (02/25/87)
Path: tekfdi!mhorne From: mhorne@tekfdi.TEK.COM (Mike Horne) Newsgroups: mod.computers.68k Subject: Rehash: MMUs and the fate of computers to come Message-ID: <795@tekfdi.TEK.COM> Date: 24 Feb 87 22:16:50 GMT Reply-To: mhorne@tekfdi.fdi.tek.com Organization: Tektronix, Inc., Beaverton, OR. Lines: 72 In an earlier article, mwm writes... > Gee, the biggest, fastest Unix box I can get to (both legitimately and > otherwise) doesn't have VM. Their attitude is "Real memory for real > performance." Maybe the hardware designers know something you don't? > If not, "how come you ain't rich?" :-) Make that "Real memory for real bucks." Also note that hardware designers work on projects that last 2 or 3 years. Give Atari, Apple, Commodore, SUN, Apollo, etc. etc. a call on the phone and ask them if their new machines to be released in the next year or two are using VM. If they aren't, check the business obituaries daily. But, I think you will find that they are. Atari is. Apple is. SUN and Apollo have been for years. And the list goes on... > There's a place for everything. Given a 68K based system, I'd rather > not have virtual memory - just give me 16Meg of real, and forget the > virtual. An MMU would still be nice, though. But if I can save 10% of > the cost of producing a box, and I'm planning on selling it in a > market that doesn't need an MMU, then I'd be stupid to put one in. Think about what you just said. "Save 10%." Now, what if we had just put in 2 MB of DRAM and a swapper with an 16MB swap space. Now, think about how much that additional 14 MB of DRAM is going to cost if you have a 16 MB system. Try (using 1Mb DRAM chips) 20 bucks per chip times 8 chips times 14 sets. That's 2240 buckaroos, bud. Oh, and don't forget the price of the support chips. I think I can find a pretty good MMU for that price, plus maybe a 200 MB hard drive (OEMs can get a 200 MB hard drive for < $1500, quantity 100 or so) too. Simple math. Of course, the price of RAM will drop. But so will MMUs and HDs. So, what does this get me? Well, it doesn't get me 16 MB of real memory, but it does get me a nice HD and true multi-tasking capability for the same price. In addtion, as far as my programs are concerned, I truly have a 16 MB address space. What will the customers want for storage? Floppies or an HD? I think we all know the answer to that one. > For instance, that's why the Amiga doesn't have an MMU; they looked at > it, and were looing at $125 for the CPU board. Even at $10 for the Again, the Amiga is 'old' in comparison to todays technology available to the designer. True, when they designed it, an MMU may have been expensive, but companies don't turn out new computers every couple of months! It is a very long and difficult process (try years). Nevertheless, todays design engineers can take advantage of much cheaper and much more powerful chips than when the amiga (or ST, or Mac) was designed. And they are. > As for Unix proper - it's got serious problems. The worst is that the > system calls have long since gotten past the point of having been > designed, and have "grown" to be what they are. Starting over from > scratch, and building a system that emulates Unix on top of a > reasonable OS (which is what Minix is) is a _good_ thing. Period. The > trick is to then get all those Unix utilities (hopefully, after > rewriting them to regularize the argument parsing & delete cruft > that's been added to solve problems you solved in a better way) > running on your system. That's harder, 'cause you have to talk AT&T > out of the sources, or rewrite all of them. I tend to agree that UNIX is not as easy to learn as some other OSs. Yet, it is very powerful. One cannot overlook the power of an OS/language just because it may be difficult for some people to learn. It's the same old "Why should I learn it if I can't understand it in 5 minutes" attitude that raises all of these "I hate XXXX OS/language/computer" comments. Still, I agree that there is room for improvement. There always is. Mike ------------------------------------------------------------------------ Michael Horne - KA7AXD FDI group, Tektronix, Incorporated INTERNET: mhorne@tekfdi.fdi.tek.com CSNET: mhorne@tekfdi.fdi.tek.csnet@csnet-relay.csnet UUCP: {ucbvax,decvax,hplabs,uw-beaver}!tektronix!tekfdi!mhorne
mhorne@tekfdi.FDI.TEK.COM.UUCP (02/26/87)
Path: tekfdi!mhorne From: mhorne@tekfdi.TEK.COM (Mike Horne) Newsgroups: mod.computers.68k Subject: Re: Multitasking et al... Message-ID: <798@tekfdi.TEK.COM> Date: 26 Feb 87 01:49:38 GMT References: <8702242259.AA28381@violet.berkeley.edu> Distribution: world Organization: Tektronix, Inc., Beaverton, OR. Lines: 26 In a recent article about a recent article about a... >>> Well, how many machines at *all* have the 010? > >Workstations. The real win with the '010 was being able to do VM. >There wasn't enough performance gain (outside of special applications) >over the '000 to make it worthwhile, unless you wanted to do VM. > > <mike Yes, several Workstations use them. For example, the SUN II line used them, and they were/are very fast and good, hearty machines. Not as fast as the 68020 machines out there, but faster than the 68000, not to mention the nice virtual address space. My own computer has a 68010 with 8MB of VM running UniFLEX, and I must say that it really is nice for getting things done *NOW*. The 010 is a good CPU, but of course, I would rather have an 020 based machine... Mike ------------------------------------------------------------------------ Michael Horne - KA7AXD FDI group, Tektronix, Incorporated INTERNET: mhorne@tekfdi.fdi.tek.com CSNET: mhorne@tekfdi.fdi.tek.csnet@csnet-relay.csnet UUCP: {ucbvax,decvax,hplabs,uw-beaver}!tektronix!tekfdi!mhorne
mhorne@tekfdi.FDI.TEK.COM.UUCP (02/26/87)
Path: tekfdi!mhorne From: mhorne@tekfdi.TEK.COM (Mike Horne) Newsgroups: mod.computers.68k Subject: Re: Memory? Message-ID: <799@tekfdi.TEK.COM> Date: 26 Feb 87 02:33:53 GMT Reply-To: mhorne@tekfdi.UUCP (Mike Horne) Distribution: world Organization: Tektronix, Inc., Beaverton, OR. Lines: 86 Yup, another followup.... "In a recent article, mwm writes..." >> Think about what you just said. "Save 10%." Now, what if we had just put >> in 2 MB of DRAM and a swapper with an 16MB swap space. Now, think about >> how much that additional 14 MB of DRAM is going to cost if you have a 16 MB >> system. Try (using 1Mb DRAM chips) 20 bucks per chip times 8 chips times >> 14 sets. That's 2240 buckaroos, bud. Oh, and don't forget the price of >> the support chips. I think I can find a pretty good MMU for that price, >> plus maybe a 200 MB hard drive (OEMs can get a 200 MB hard drive for < $1500 >> quantity 100 or so) too. Simple math. Of course, the price of RAM will >> drop. But so will MMUs and HDs. > >Simple math, but I don't like the numbers you started with. I was >offered 2Meg for $150 today. Multiply by eight, you and get that 16Meg >costs all of $1K. Support system is about $500. For that, I can get >maybe a 60 Meg HD + disk subsystem. But I'd rather have the memory. > Aaaahhhhh... You're working with 256Kb DRAMs, though! Yes, they are cheaper, but it takes 4 times as many chips! Lemmeesee... 8 chips = 256K 4 x 8 = 32 chips per MB. 32 x 16 = 512 chips per 16MB Hmmm.... I guess I could pack 512 chips into my new computer design. But wait, what about board space? What about power supply requirements? Do you know what 512 chips looks like, side by side? Yes, you could get SMD (surface mount device) parts, but no company in its right mind would tackle a design like that. Oh, and are you going to prototype one of these up using wirewrap? Good hairy luck! The reality is that companies do *NOT* use old technology if new technology can do it in 1/4th the board space (or 1/3, or 1/2), even if it costs more. For example, one can find 1K X 4 SRAM chips for a dime a piece, but just because they are cheap doesn't mean they are a good idea to use in a design (at least, not any more!). Eventually the 1 MB DRAM chips will be cheap enough to meet the quoted prices that you had above. But it will be at least a year or two (following past experience). Of course, the 4 and 16 MB DRAM chips will be out then. NEC and other Japanese companies have already shown that they can produce the 4 MB DRAM chips, and they are already working on the 16 MB chips. >Low-end home computers (those which have 68K's being the _topic_ of >this newsgroup). Note: Anything having to do with the design of a computer system around a 680X0 is relevent to this newsgroup (MMUs, DRAM, etc.). >Yah, but I bet you don't see the "new" technology before 1988 ("new" >== 68030 and whatever intel has in the pipe). Not in consumer-priced >machines, anyway. By which time the next newest chip will also have >neat features you want. Sorry, but I want a system now, not year after >next. Well, then you get a 68000 with 1MB of DRAM, no VM, a 700 dollar 20MB HD, etc. If this suits you, fine. BUT, if you want more ram, VM, more power, etc., it is being developed NOW. You gotta wait. I'm totally happy with my 68010, 2MB DRAM, VM, etc. for now. But you would never get me to go back to something without an MMU. Put it this way: Once you have tasted the soup, you don't want the dry toast. >Sure, if you offered to give me a system with an MMU, I'd probably >take it over one without. But until the price drops to something >reasonable (say, a system with an MMU for < $1K), I'll keep what I've >got. With enough memory, it's a more pleasant environment than my Sun, >and at 1/3rd the cost. I agree. Use what you have. But realized that the next generation of machines will have VM. The next generation is just around the corner. >there way back into Unix. So which do you expect to be the better OS? Well, I feel that UNIX is, right now. But as people keep learning from existing software and past experience, other OSs will eventually replace UNIX. I think we agree on the same thing here, just different time frames. Mike (P.S. Speaking of new chips, watch for Motorola's 78000: 25 MIPs) ------------------------------------------------------------------------ Michael Horne - KA7AXD FDI group, Tektronix, Incorporated INTERNET: mhorne@tekfdi.fdi.tek.com CSNET: mhorne@tekfdi.fdi.tek.csnet@csnet-relay.csnet UUCP: {ucbvax,decvax,hplabs,uw-beaver}!tektronix!tekfdi!mhorne
drforsey@watcgl.waterloo.edu.UUCP (02/26/87)
Path: watcgl!drforsey From: drforsey@watcgl.UUCP (Dave Forsey) Newsgroups: mod.computers.68k Subject: Re: Submission for mod-computers-68k Message-ID: <662@watcgl.UUCP> Date: 26 Feb 87 20:18:47 GMT References: <8702242216.AA09273@tekfdi.FDI.TEK.COM> Reply-To: drforsey@watcgl.UUCP (Dave Forsey) Distribution: world Organization: U. of Waterloo, Ontario Lines: 15 >> For instance, that's why the Amiga doesn't have an MMU; they looked at >> it, and were looing at $125 for the CPU board. Even at $10 for the > >True, when they designed it, an MMU may have been expensive, >but companies don't turn out new computers every couple of months! It is >a very long and difficult process (try years). There is perhaps a deeper reason for the amiga not using a MMU. The operating system is based on message passing, those messages are passed by reference rather than copying. It assumes and is dependent on an single address space. Unless the OS changes in a major way you'll not get VM on an Amiga. Dave Forsey Computer Graphics Laboratory University of Waterloo.
mhorne@tekfdi.FDI.TEK.COM.UUCP (02/27/87)
Path: tekfdi!mhorne From: mhorne@tekfdi.TEK.COM (Mike Horne) Newsgroups: mod.computers.68k Subject: Re: Re: Re: ... Message-ID: <801@tekfdi.TEK.COM> Date: 27 Feb 87 04:58:08 GMT Reply-To: mhorne@tekfdi.UUCP (Mike Horne) Organization: Tektronix, Inc., Beaverton, OR. Lines: 58 In an incredibly recent article by mwm... >> >Low-end home computers (those which have 68K's being the _topic_ of >> >this newsgroup). >> Note: Anything having to do with the design of a computer system around >> a 680X0 is relevent to this newsgroup (MMUs, DRAM, etc.). > Ahem. From the list of lists: > INFO-68K@UCBVAX > Mailing list for users of OS's capable of running on small 68000 systems, > primarly CP/M-68K. Related systems (OS/9-68K, etc.) and topics welcome. ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ Well, Mike, tell me what "Related systems and topics" is/are? Since not specifically defined, it is left open for interpretation. By the way, I would consider the hardware (memory, etc.) to be a "related topic", or are you able to run your "small 68000 system" without these? If so, you've got something there... > I'd rather have what I've got: 68010, 2.5MB dram (yes, it's on 256Kb > chips. It's going to go to 4.5 in the next month or so. I mean, for > $150, who can resist?), no VM. Since I'm planning on playing with > LISP, VM would be a major performance hit. Going to 8.5Meg (or maybe > more) of real is a _lot_ more attractive than adding an MMU. Before you got to 4.5 or 8.5, you better check your power supply specs. That many chips can/will draw a lot of juice. Just a suggestion. > Uh, sorry, but I make my living hacking on systems with MMUs. And VM. > On those systems, I miss shared memory, shared libraries, streams, > real IPC, lightweight processes (tasks, if you want to be accurate), > dynamically mountable device drivers, etc., etc., etc. Hmmm... Well, this may be where we disagree. I prefer to have my own copy of everything. That way no one can get into trouble. With an 8MB address space, I can't go wrong. And still every process has access to all of the system resources. I can still fork(), and I can still make my binaries share resources. The so-called 'advantages' of shared this-n-that are really known as limitations due to the hardware. Machines are growing, and the 'small system' ideas of today are going to look really 'small' (gee, remember those nice little 8080 base machines? Boy, those were really powerful! Wanna go back to them? They had shared memory!). I'd say the next generation of 'small systems' are going to be based around the 68020, 320XX, and 80386 CPUs. And they will have memory managment. It's a fact of life. Mike (P.S. This is my last one. How about one more rebuttal on your part?) ------------------------------------------------------------------------ Michael Horne - KA7AXD FDI group, Tektronix, Incorporated INTERNET: mhorne@tekfdi.fdi.tek.com CSNET: mhorne@tekfdi.fdi.tek.csnet@csnet-relay.csnet UUCP: {ucbvax,decvax,hplabs,uw-beaver}!tektronix!tekfdi!mhorne
stever@videovax.TEK.COM.UUCP (03/03/87)
Path: videovax!stever From: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Newsgroups: mod.computers.68k Subject: Re: Multitasking at el... Summary: 68020 has a significant cost penalty. . . Message-ID: <4257@videovax.Tek.COM> Date: 3 Mar 87 16:38:06 GMT References: <8702211138.AA05883@ucbvax.Berkeley.EDU> <8702231846.AA05718@amdcad.AMD.COM> Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Distribution: world Organization: Tektronix Television Systems, Beaverton, Oregon Lines: 27 In article <8702231846.AA05718@amdcad.AMD.COM>, Andy Beals (bandy@amdcad.UUCP) writes: > . . . The *next* st to come out will probably > have an 020. The next amiga probably will also. There is a significant cost penalty to the 68020, due to its pin grid array (PGA) package. The 68000 and 68010 are packaged in 64-pin DIPs, which are cheap -- the price of the part will undoubtedly drop to the $3 to $5 neighborhood for large quantities. The 68020, on the other hand, will remain pricey ($50 to $75 minimum even in large quantities) until the part can be packaged in plastic. Right now, 68020 add-ons to the Amiga sell for $800 to $1,400 (admittedly, they have other things as well). Much of that can be laid to low volumes (the 68020 is about $150 in moderate quantities, and the development cost of the circuit boards must be amortized over a small production quantity). However, it is unlikely that a $100 processor will appear in a < $1,500 home computer -- that leaves too little for such essentials as a power supply, a keyboard, manufacturer's profit and dealer markup! When the plastic 68020 comes out, it will be a different story. . . Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
jesup@seismo.CSS.GOV@steinmetz.UUCP (03/05/87)
Path: steinmetz!jesup From: jesup@steinmetz.steinmetz.UUCP (Randell Jesup) Newsgroups: mod.computers.68k Subject: Re: Submission for mod-computers-68k Message-ID: <1262@steinmetz.steinmetz.UUCP> Date: 4 Mar 87 22:13:00 GMT References: <8702262018.AA16981@watcgl.uucp> Reply-To: jesup@kbsvax.steinmetz.UUCP (Randell Jesup) Distribution: world Organization: General Electric CRD, Schenectady, NY Lines: 20 In article <8702262018.AA16981@watcgl.uucp> drforsey@watcgl.waterloo.edu (Dave Forsey) writes: >There is perhaps a deeper reason for the amiga not using a MMU. The operating >system is based on message passing, those messages are passed by reference >rather than copying. It assumes and is dependent on an single address space. >Unless the OS changes in a major way you'll not get VM on an Amiga. > >Dave Forsey There is SOME support for seperate address spaces for different processes. When you allocate memory, the type you can get are FAST, CHIP, and PUBLIC. CHIP is accessable by the custom chips, FAST isn't, and PUBLIC is guarenteed to be accessable by other processes. Of course, there probably are a lot of programs that just take any memory at all when allocating messages, etc, but the basic support is there. Randell Jesup jesup@steinmetz.uucp jesup@ge-crd.arpa
cliff@ethos.UUCP.UUCP (03/15/87)
Path: ethos!cliff
From: cliff@ethos.UUCP (Cliff Elam)
Newsgroups: mod.computers.68k
Subject: Valid Scaldsystems
Keywords: ScaldSystem IV, 4.1BSD, HELP
Message-ID: <1159@ethos.UUCP>
Date: 14 Mar 87 21:27:28 GMT
Organization: Humanities Forum at ethos, Durham, NC
Lines: 23
I'm looking for other Valid owners because I just purchased a
Valid ScaldSystem IV and, while I have (I think) all the software,
I havn't a document in site. (sorry) Some of my friends are
in the same boat, and we're would like to hear
from other Valid owners interested in participating in a discussion
we are starting on a local VAXEN. We're looking for
people into h/w and s/w, particularly VALIDS. Anything that seems
to be of general interest will (probably) be posted here too.
A topic we're starting on is replacing those wimpy 20M HD's. Any
experience floating around out there?
If anyone else wants a ScaldSystem IV they should look under the
forsale group - there's still a few for sale. (nuder $800!)
Write or mail, and we'll put you on the mailing list when
plans are (more) finalized.
-Cliff Elam
{mcnc,ihnp4,duke}!ethos!cliff
PO Box 1087, Chapel Hill, NC, 27514
(919) 942-6024 (10am-10pm EST)kavi@aloha1.UUCP (03/30/87)
Path: aloha1!kavi
From: kavi@aloha1.Hawaii.EDU (Kavindra Saxena)
Newsgroups: mod.computers.68k
Subject: Re: Info-68K subscription request
Message-ID: <208@aloha1.Hawaii.EDU>
Date: 30 Mar 87 14:34:31 GMT
References: <8703201250.AA09073@jade.berkeley.edu>
Reply-To: kavi@aloha1.UUCP (Kavindra Saxena)
Distribution: world
Organization: University of Hawaii, Honolulu
Lines: 6
TO: Info-68k Coordinator,
I would like to join the 68K info mailing list.
Thanx in advance.
Kavi(humu!uhmanoa!aloha1!kavi@nosc)