Newsgroups: comp.sys.amiga.hardware
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!cica!travis!greg
From: greg@travis.cica.indiana.edu (Gregory TRAVIS)
Subject: Re: Amiga Custom Chips - why hasn't C= made them faster?
Message-ID: <greg.671422948@travis>
Sender: news@cica.indiana.edu (News System)
Nntp-Posting-Host: travis.cica.indiana.edu
Organization: Indiana University
References: <6154.tnews@amiga.actrix.gen.nz>
Date: 12 Apr 91 02:22:28 GMT

twills@amiga.actrix.gen.nz (Tony Wills) writes:

>Quoted from - tagreen@bronze.ucs.indiana.edu (Todd A. Green):
>> In article <1991Apr5.034303.14202@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Scott Cantrell) writes:
>[...]
>> >Virtual memory comes to mind as a far more productive use for the MMU.  Can
>> >you say 100 MB free? [insert drool noise]  Not to mention color X-Windows
>>

Color X-Windows?  Can you just say no?

>> My point is that VM is nice, VM is good, VM is your friend, but it
>> ain't never gonna nohow replace RAM.

Good point - remember virtual memory s a transitory kludge dictated
by economy and the gluttonous products of our universities.

>I certainly agree that the Amiga I/O etc is a little slow for virtual memory
>if you considered swapping tasks (or just code/data 'pages') in and out during
>task switching.

The Amiga's I/O subsystem (if it can be called that) is actually quite
fast.  And there's nothing that says paging I/O has to go through the
I/O system (I assume you mean the filesystem).  Most UNIX boxes don't.

>I envisage using virtual memory principles to allow me to swap out complete
>Amiga programs, ie take the code, data, and current register state, and stuff
>them onto disk thus freeing up memory, but allowing the program to continue at
>a later time from where it left off.
>(Of course if the program isn't self modifying no need to copy it to disk)

This is called swapping and has been around for about forty years.  It has
nothing to do with virtual memory.  How quickly they forget.  *sigh*

>A major problem with this idea is the Amigas lack of resource tracking, ie
>you don't know which bits of memory belong to which task.  But then I
>suppose you can just intercept the memory allocation system calls, and
>keep your own resource table - retrofit resource tracking :-(

This is nearly impossible.  Unfortunately AmigaDos/Exec screwed itself out of
ever having resource tracking.  Remember that a program may allocated memory
and silently pass a pointer to that memory to another program.  How do you
know what other running programs depend on that memory you just swapped out?
Same thing with library resources, fonts, etc. ad nauseum.  Sure they were
SUPPOSED to use MEMF_PUBLIC...

>If you switched out more information (like system task table entries, and
>any other info required by the operating system about executing tasks), you
>could even swap out tasks and switch off the machine ... then resurect them
>later to continue as though nothing had happened!

Why would you want to switch off the machine?  Here's a man who was
obviously born while cheap computers ruled!  Life is short!

>This would be a non trivial operating system hack, it'd be easier just to
>purchase a 100 Megs!! :-)

I think you're on to something here.
--
Gregory R. Travis                Indiana University, Bloomington IN 47405
greg@cica.indiana.edu  		 Center for Innovative Computer Applications
This signature intentionally left blank.
