ericmcg@pnet91.UUCP (Eric Mcgillicuddy) (09/30/90)
I have received no responses to my request for information on how people use the memory manager on the IIgs. I can therefore assume that everyone follows Apple's standards. The reason for asking is that I am in the process of writing a virtual memory management system for GSOS. I have attempted to make it as transparent as possible, but this is not always possible. I may be able to make it compatible with existing programs, but I can not guarantee this. To make things faster and easier all memory requests should be in block sizes of exactly 64k. This minimizes disk fragmentation. Regardless of the size of the block swapped out, the disk space occupied will be rounded up to the nearest multiple of 4k internally. Thus 16 bits will represent 64k making free space searching very fast. Data is usually position independent, however once loaded code is usually not. To get around this I suggest using only short addressing modes and bank aligning all code segments. Do not use long addressing modes anywhere except through a Jump Table to move between code segments, use this form JMP [segmentpointer], where segmentpointer points to the dereferenced and resolved address of the desired code segment etry point. Given the memory manager model This should be the standard method used in existing applications, but since I have received no feed back I can not be certain. ViM will allow you to create the backing file on any GSOS volume, hard disk, RAMdisk, or 3.5" disk. I would reccommend against using a 5 1/4" disk, a useful size would be 1 Meg minimum. This will provide a good use for existing slot RAMcards. The maximum size for virtual memory will be 16Megabytes, giving a total memory available of over 17Megs, 16Meg virtual plus whatever real memory you have. Given that GSOS is a 32 bit operating system up to 4Gigaytes of virtual memory is possible in the future. I require FEEDBACK on this system, and soon. I have the swapout routines working and some of the swap in routines. I am having trouble patching the memory manager and this is delaying beta release. I need idas, suggestions and opinions before I get any farther into the design stage, once I choose a certain form it will not be changed. I need your help as I would like to release this before System7 is available on the Mac's. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
cbdougla@uokmax.ecn.uoknor.edu (Collin Broad Douglas) (10/02/90)
In article <9009291730.aa10320@generic.UUCP> ericmcg@pnet91.UUCP (Eric Mcgillicuddy) writes: >I have received no responses to my request for information on how people use >the memory manager on the IIgs. I can therefore assume that everyone follows >Apple's standards. The reason for asking is that I am in the process of >writing >a virtual memory management system for GSOS. > [munch munch] >I need your help as I would like to release this before System7 is available >on >the Mac's. > > >UUCP: bkj386!pnet91!ericmcg >INET: ericmcg@pnet91.cts.com I'm sorry I can't give you real suggestions but I'm glad that there is some good news now on the net. Collin Douglas cbdougla@uokmax.ecn.uoknor.edu
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/02/90)
Mail me a rough description of your swapping algorithm. I need to know what gets swapped out and when. Virtual memory in software is a royal pain in the rear unless your programs are written to expect it and you could fact some serious compatability problems. Most applications that I have seen are either totally memory resident or they use segments, a semi-voluntary form of virtual memory that is required for large programs... Todd Whitesel toddpw @ tybalt.caltech.edu
jm7e+@andrew.cmu.edu (Jeremy G. Mereness) (10/03/90)
I think this is a neat project, too. I don't have too much to offer, but I will put it to the members of my user's group. I would also suggest the apple // technotes at the Apple // FTP site, 130.43.2.2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |Jeremy Mereness | Support | Ye Olde Disclaimer: | |jm7e+@andrew.cmu.edu (internet) | Free | The above represent my| |a700jm7e@cmccvb (Vax... bitnet) | Software| opinions, alone. | |staff/student@Carnegie Mellon U.| | Ya Gotta Love It. | -----------------------------------------------------------------------
ericmcg@pnet91.UUCP (Eric Mcgillicuddy) (10/04/90)
System 5.0 added the Out of Memory Queue to the system structure. Whenever you ask for a block of memory there is a chance that memory will be compacted and purgable blocks get purged. In lieu of this I propose that the blocks be swapped out until sufficient memory is available. Also because of this, unless you lock the block, a deferenced block may not be where you think it is. CheckHandle will force the swap in of a memory block if not present in real memory. This makes sense since memory pointers are no longer guaranteed, unless one never allocates new handles (or reuses the same ones over and over). Various other memory manager calls will force a swapin (don't have the list in front of me). Vim will be exactly 64k in size and this includes an LRU queue to track the oldest handles (it is fixed in size and limited to about 1000 memory blocks). Another option would be to alter the memory manager data structure to include the LRU, but this is guarantted to break many programs that don't exactly follow Apple's guidelines, and would also give DTS kniptions. There is a possibility that ViM will work with 68000 based Macs, but I think there is a good chance that the Mac's stack could be swapped (this is bad), Bank 0 on the GS is inviolate to ViM (I'll code it in now! :). Even if this is not 'true' virtual memory, it will at least provide automatice overlays for huge programs. (Who'd ever need more than 1 Meg of memory anyway:). additionally, this is only part 1 of a proposed 3 part series. Part 2 is Multi8, interupt driven task switching of 8-bit programs (prodos only at this time, unlike Softswitch). PArt 3 is Vigour, true multitasking of 16-bit programs. I am still not satisfied with what I've done so far, but I hope to release it locally for Beta in the next 2 or 3 weeks. Dpending on how things go, I'll see about getting it on the net by Christmas (Of what year you ask?). Also depending on how things go, I will likely be the owner of a 386 clone or a ROM04 GS, whichever comes first, by Christmas. Not much point in time slicing 2.8MHz is there? :( UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (10/05/90)
Yes, there is point in time-slicing 2.8 MHz - I want ot be able to
multi-task!!! And so do other people. That's why I've taken up Andy
McFaddden's LWP-GS project. I like what it does!! That's reason enough
to do it, and for something like true full multitasking, that's
something to charge for, even at 2.8MHz (which is moderately fast; don't
believe what the MS-DOS folks tell you, believe what you see when you
use the machine. 2.8MHz is faster than a 4.77MHz (that's what they all
used to be) MS-DOS clone. It's not faster than 12MHz, but I'll bet the
7MHz of the TWGS comes pretty close. And don't forget that the GS was
designed to run a GUI, and MS-DOS machines weren't, even if Windows 3.0
does look impressive.
-----------------
Jeffrey Hutzelman
America Online: JeffreyH11
Internet/BITNET:jh4o+@andrew.cmu.edu, jhutz@drycas.club.cc.cmu.edu
>> Apple // Forever!!! <<jb10320@uxa.cso.uiuc.edu (Desdinova) (10/05/90)
In article <9010040400.aa06851@generic.UUCP> ericmcg@pnet91.UUCP (Eric Mcgillicuddy) writes: [design of ViM removed] >Also depending on how things go, I will likely be the owner of a 386 clone or >a ROM04 GS, whichever comes first, by Christmas. Not much point in time >slicing 2.8MHz is there? :( Wrong. Most of the time the GS is spending CPU power doing the following busy wait: EventLoop: Mouse? Nope. Keyboard? Nope. goto eventloop Time slicing and process management would increase the effective throughput of the CPU by not busy-waiting. Any process calling GetNextEvent would be blocked until its input came thru. Note this is a step better than MultiFinder or LeapFrog, which just cycle the busy wait through multiple processes. Time Slicing and process management will make the GS work faster. >UUCP: bkj386!pnet91!ericmcg >INET: ericmcg@pnet91.cts.com -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! | (B O'Cult) Apple II Users Unite! Storm the New Product Announcement and Demand Justice!
ericmcg@pnet91.UUCP (Eric Mcgillicuddy) (10/10/90)
This is a reply to private mail I had received. Unfortunately it was
undeliverable, so I'll post for all to see. And hopefully the person who
contacted me will get it too.
>>>>>>>>>>>>>>>>>>
I only use high level I/O commands so DMA compatibility is not my problem.
This has the additional virtue of allowing any file system to be resident
without having to recompile the program (or do at least make minor changes to
take advantage of the new system, i.e. Mac HFS). Also I don't have to care
about the block size, Prodos/Mac use 512k blocks, CP/M uses 1k blocks and
MSDOS uses 2k-4k clusters, ViM doesn't care as long as the required data is
returned correctly.
The GS has a Memory Management system in the Toolbox that is lacking in DOS
computers, this is what makes ViM possible in software only. An equivalent
utility is not possible without hardware support on DOS systems (or 8=bit
Apple II's for that matter). I would ask that you look at programming your GS,
I think you be amazed at the power available to you, I was.
BTW, I used Orca/C to prototype the system and test the logic, you might wish
to consider this option. I needed more direct control, so I am in process of
hand compiling the code, I make a much better compiler than any machine could
ever hope to achieve. :)
<<<<<<<<<<<<<<<<<
UUCP: bkj386!pnet91!ericmcg
INET: ericmcg@pnet91.cts.com