Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amiga!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory (in which Dave say good things about UNIX) Message-ID: <6905@cbmvax.UUCP> Date: 17 May 89 19:39:40 GMT References: <8905170500.AA25917@jade.berkeley.edu> Organization: Commodore Technology, West Chester, PA Lines: 83 in article <8905170500.AA25917@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) says: > Matt Dillon writes in > Message-ID: <8905162209.AA20997@postgres.Berkeley.EDU> >> You are clearly missing the point. Certainly I would much rather >> have a MEMF_PHYSICAL flag instead of a MEMF_VIRTUAL flag, but it would break >> too many programs... more than too many, a *huge* number of programs. > Would you not rather break many programs today, when there are so few potential > A2500 owners and users of virtual memory, than three years from now when every > body will be having MMUs in their Amigas? Ordinarily it's very easy to decide whether a given application can legidimately break in a new OS release -- if the application does something unsupported (we can easily find out on our own if the developer won't own up) that makes it break, it should break. If it follows the rules, it should work. There weren't proper rules for VM available to software authors when all software was written, so the Right Thing To Do in such a case is usually to make sure that as much as possible works under such a system. However, given that VM will always be something that is set up at the user's option, at least as long as we have 68000 machines supported, that changed the rules for compatibility, IMHO. > Preposterous! Virtual memory can be written within a week by somebody who knows > what he is doing. A handler will be available by the end of the summer, I will > bet my iron ring on that. I could probably have something going with about 3 months of "Hazy-time" hacking, given what I know about the MMU and the Amiga system. I have at least one decent answer for each of the raised concerns about VM on the Amiga that have so far surfaced. I currently expect that some things would break, but not lots of things (hint -- I could make the Forbid()/Permit() and Disable()/Enable() calls do anything I like (includes "Informing the VM manager"), even though they are often macros. That's what Virtual Machines are for. Then again, there are far better and knowledgable programmers than I at least thinking about this, so I can't really comment on whether "a week" is outlandish or not. I do know that I currently don't have the time to work on this, though perhaps I will in the next several months. It certainly tops my list of "way-cool things that no-one's yet done". >> (4) it does not ease the way for eventual file mapping which is where UNIX is >> going these days. > Hmmm, you seem to have Unix etched in your head. Again, IMHO. You can never ignore what's being done in UNIX. Period. Even if some parts of UNIX aren't even close to the level of what's done daily in the Amiga OS, there are many lessons to be learned from UNIX. First of all, there are an amazing number of EXCELLENT folks working on solutions to the same kind of problems you'd like to solve for AmigaOS. Many of their clever solutions are applicable to AmigaOS, even if the specific form adpoted under UNIX seems BOGUS. There's also, plain and simple, more brain power at work there, solving real problems. It's not like trying to learn from MS-DOS, where the Big Problem is usually how to trick the OS into doing something cool, the latest method of TSR programming, how to really use that extra 1 meg you just added which is outside of 808x space, etc. UNIX and AmigaOS each have their good and bad points and we're in a good position -- AmigaOS can benefit from advances in UNIX theory; cool stuff we do in AmigaOS isn't yet likely to be noticed by the UNIX PTB. > Unix is slow, Unix is big, Unix is cumbersome. Yeah, compared to AmigaOS, UNIX is slow. One good reason is that it's not real time. A real-time OS make much more sense in a single user situation, methinks. Big, well, there are LOTS of standard UNIX tools which aren't available as AmigaOS standards. You can get most of them on Fish Disks or as part of your C Compiler package, though I still don't have anything as nice as Franz LISP on my Amiga. As far as what you need to run UNIX at all, it's not all that different from what you can run AmigaOS in. Certainly UNIX can run, rather comfortably (though perhaps not to Johann's speed standards) on a 3-meg Amiga with hard drive. It does need an MMU, so A2620s are idea for UNIX. AmigaOS is somewhat less memory hungry, but I find a minimum of 2 megs is needed before I have a real smooth AmigaOS system. I do lots of painful stuff, like compiling Lattice C++; a minimal Amiga system could live in less space than a minimal UNIX, but for approximately the same kind of usage, UNIX and AmigaOS are in the same ballpark, at least. The same cannot be said about OS/2. Apparently, MicroSoft hasn't learned from UNIX. > Valentin -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession