Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!viusys!uxui!unislc!harem!wes From: wes@harem.clydeunix.com (Barnacle Wes) Newsgroups: comp.unix.sysv286 Subject: Re: Kernel Definition Summary: Segmented (demented?) memory! Message-ID: <312@harem.clydeunix.com> Date: 31 May 91 22:01:22 GMT References: <1423@necis.UUCP> <29696@hydra.gatech.EDU> Organization: Clyde's Harem; Eunuchs Guard Lines: 25 In article , greg@travis.cica.indiana.edu (Gregory TRAVIS) writes: > Swapping out parts of the kernel was never part of the plan. All of the > code for the kernel, even if it was 300K, was locked into core from system > startup to shutdown. All in continguous memory. Only the hardware > segment registers were modified to bring the appropriate pieces of this > code into the 64K "execution window." This scheme should sound familiar to everyone reading this thread in comp.unix.sysv286; it is similar to the way a 286 kernel is managed. My current (V/AT 2.3) kernel has 3 text segments. The 286 doesn't have, or need, the microkernel concept discussed earlier in Greg's post, but the segment loading is very similar in concept. > This overlay scheme was also used at the application level. Big Emacs would > have been impossible without it! And it was almost completely transparent > to the programmer. Ditto for V/AT. Just compile with -Ml to get multiple-segment programs. Wes Peters -- #include The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes