daleske@cbdkc1.UUCP (08/22/86)
[Note that the following discussion is directed toward the 6809 implementation of OS-9. The 68000 version of OS-9 Level I does not have the 64k limitation. -JDD] > There seem to be some people out there who know something about OS9 Level II. > Perhaps (pretty please) you might share some info with the rest of us lowly > Level I users. Specifically, I would like to know how Level II accomplishes > the extended address space. Are programs limited to 64K? Is data limited > to 64K? Any info would be most appreciated. > > Terry Ingoldsby > OS-9 Level II cannot extend a programs logical address space beyond the 64k limit. The 6809 has only 16-bits of address lines thereby limiting its addressability to 65536 bytes. If a 6809 CPU is paired with some bank switching hardware and address traslators, OS-9 can use this hardware to: 1) Use more than 64k of total physical memory in the system, and 2) allow a process access to a full 64k of memory. One of the major drawbacks of a Level One system (without bank switch hardware) is that everything (system, drivers, system data and user program and data) are stored in 64K of memory and all sharing the same address space. The kernel, I/O space and the things the kernel must keep track of amount to about 15-20K of memory. Out of a 64k system, this leaves less than 40K for the user program. A tight squeeze in the days of C! :-) With OS-9 Level II, if a system has say 256k of memory, OS-9's 20k will live in its own address space, effectively freeing this memory for the user's address space. Depending on the particular hardware, a process can address the FULL 64k of memory. The remaining memory is available to load other programs or run other processes. A program can use more than 64k of memory by issuing system calls to OS-9 to map various segments of the program into and out of the process' address space. The concept of modularity is religiously employed by OS-9 itself. If the user program is segmented into may small modules each with a black- box type of approach (sound familiar?), a program much larger than 64k can be run with such a module linking scheme. In effect, OS-9 is treating each process, with its associated program module a sort of a subroutine that executes in its own address space up to the limit of 64k. Level II systems are also much more resistant to program crashes. Since the kernel is in a different address space, it's not so easy to wipe it out (the number 1 cause of system crashes). If the 6809 itself crashes from an illegal opcode (commonly cause by the user program trashing its own or the system's stack) , not much can be done to restart it without (again) special hardware. All this is not without penalty however. Level II systems usually not as fast as Level II system unless the hardware has special facilities for moving data between address spaces. Since the 6809 can address only 64k at once, bank switching must be used to trasfer the data. This of course is a little slower than a direct copy operation. Also, if the system runs out of physical memory, no more memory requests will be granted because OS-9 does not do process swapping or paging. Unessential memory in use must be freed to continue. If a process exceeds its 64k addressing limit, it can cause OS-9 to map out a block of memory in its address space to map in the desired block in its place. In summary, OS-9 provides a very sophisticated programming environment (much the same as UNIX) in quite a smaller implementation. Programs written for Level One system (without MMU) should run on Level Two systems provided the OS-9 programming rules have been followed, thereby providing a large degree of transportability. OS-9 Level II's memory mapping and task/bank switching are completely transparent to the user programs and need not be considered until, of course, you run into a memory limitation. OS-9's modular concept allows a programmer to very efficiently use available memory without resorting to time consuming swapping or paging operations. I hope this info has been helpful. ---------------- Kim Kempf, Microware Systems Corporation {{cornell,decvax,ihnp4,sdcsvax,tektronix}!uw-beaver}\ {allegra,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} >!fluke!mcrware!kim {ssc-vax,hplsla,wavetek,physio,cae780,tikal,telematic}/