Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!amdcad!lll-crg!caip!daemon From: mwm%ucbopal@BERKELEY.EDU@caip.RUTGERS.EDU Newsgroups: net.micro.amiga Subject: Re: Amiga OS Message-ID: <1133@caip.RUTGERS.EDU> Date: Thu, 30-Jan-86 23:30:24 EST Article-I.D.: caip.1133 Posted: Thu Jan 30 23:30:24 1986 Date-Received: Sat, 1-Feb-86 07:25:27 EST Sender: daemon@caip.RUTGERS.EDU Organization: Rutgers Univ., New Brunswick, N.J. Lines: 95 From: Mike (I'll be mellow when I'm dead) Meyer Matt Dillon once again savages AmigaDOS for not being Unix, among other things. To wit: (C) SSLOW linker... no random libraries AT ALL The fix is easy - use a different compiler, with a faster linker. No need to fool with the OS at all (not really an OS complaint). (A) Slow loader... so slow that having lc1 in the ram disk doesn't significantly reduce load time. I haven't noticed any serious problems loading files compared to say, a VAX running Unix. A little bit slower, but it's got floppies instead of a hard disk, and it's got to relocate stuff on the fly (no MMU - the Amigas one major failing). There was a discussion a while back on OS9, where it was boasted the TEXT portion of an executable (i.e. the code), was sharable when several of the same program was running. The only way I can see this happenning is: (A) An MMU or MAP hardware (B) Some register, say A5, containing the 'base' of static data and all static references made by adding this base to the offset and doing an indirection. And the correct answer (for OS/9) is: (C) All programs are required to be relocatable (level I and II, anyway). And what you get is actually better than Unix-like shared text. OS/9 has the ability to share the code for a library between several *different* programs running simulatenously. Multics had this, and it's one of the things that people are *still* trying to put into most Eunices. Of course, AmigaDOS has this same spiffy feature (so do most modern OS's, though), and it uses: (D) Load-time relocation. Slows down the load a little, but if done right (like, put the I/O library in one of the shared libraries), you should get back more in saved I/O after the first load than you spend relocating things. Oh, BTW, all getting Unix-like shared text requires is to have three seperate segments: text, data and stack. The only addressing mode you lose in getting shared text is pc relative. Each process gets it's own stack. I also noticed that lattice doesn't seem to do simple optimizations like OR's to memory (i.e. it moves to d0, then Or's, then moves back).. or am I wrong? I've been told that Lattice C is a recursive descent compiler. Anybody silly enough to write a recursive descent compiler for something like the Amiga (or most anything else....) is silly enough to miss OR's to memory. If this rumor is wrong, *please* let me know. oh yah... George Robbins from CBM made a comment that UNIX's require about 1Meg of memory and at least 20-40 Meg HD's. I agree (though I prefer at least 2 Meg and 100Meg HD). Consider that in a very short time, say a year or two, 100 Meg HD's and 8 Meg Ram will be available at the same cost as 20Meg HD + 640K ram is today. True, but a PIG is still a PIG. I'd rather use all those juicy resources making my life easier than providing for a piggy OS. Mat's proposed solution to some of the OS (?) problems: Hide the OS. Hide the OS? Make yourself a library with such things In other words, build a better C<->AmigaDOS interface. One of the most important things to do would be get the library allocation back into load-time, where you don't have to write funny code to deal with it. Access to the global vector would be nice (shrinking code a *lot*), also. But any attempts to squeeze a langauge onto an OS designed with another language at it's heart is going to require either a lot of work, or wind up being ugly (witness LISP, Pascal and FORTRAN on Unix). Final comment. I finally got my AmigaDOS manuals, and got a look at what's going on inside that file system. My hat's off to whoever designed it. It's simpler than the Unix file system, much more robust, and except for some special cases, should be faster (the important special case is globs). The most imporant thing to notice is ~1/2 the disk access to turn a pathname into a file*. It's just to bad that globs are so heavily used by the workbench. inode translation. Since this got back about 20% of the CPU, you can decide for yourself how important the AmigaDOS 50% decrease in disk accesses is going to be.