darrell@sdcsvax.UUCP (03/10/87)
Some people call RAM "fast memory" and disk "slow memory" (and tape
"very slow memory"). With large address spaces and virtual memory, who
needs files? Why not define all storage as extended memory structures
that may be loaded as needed. I realize that this is the de facto
effect of paging systems, disk-caching, sparse addressing,
runtime-loadable modules and workspace-oriented environments...why not
make it de jure?
This model would be inappropriate for some environments, but many small
systems (32 bits && < 4Gbytes storage) would fit just fine.
Non-inflammatory comments please....
--
-------------------------------------------------------------------------------
Bob Bagwill Are we not men?
UUCP: {decvax,seismo,cbosgd}!decuac!bagwill INET: bagwill@decuac.DEC.COMdarrell@sdcsvax.UUCP (03/12/87)
Multics used the idea of "no such thing as 'files' from the very start. Everything was in virtual memory (36-bit addresses, too) Look where it got them. :-(
darrell@sdcsvax.UUCP (03/12/87)
In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes: >Some people call RAM "fast memory" and disk "slow memory" (and tape >"very slow memory"). With large address spaces and virtual memory, who >needs files? Why not define all storage as extended memory structures >that may be loaded as needed. I realize that this is the de facto >effect of paging systems, disk-caching, sparse addressing, >runtime-loadable modules and workspace-oriented environments...why not >make it de jure? I can think of one very important distinction between virtual memory and files. That is, we expect file integrity to be maintained in case of a system crash, but we don't expect this from most virtual memory systems. Adding facilities to a virtual memory to insure such integrity would probably add a great deal of overhead to normal memory accesses. [It seems to me that what you need is the notion of a persistent data object DL] Also, think of how big the page tables for a 2GB virtual memory would be (if the whole 2gb space was used); that would be 2 million pages, if we have a 1k page size. These tables would probably be too big to remain permanently resident, and would have to be paged, resulting in potential multiple page faults on a simple memory access. [The address space would be sparse (consider the IBM RT). Also, it is not unusual for page tables to be paged themselves (VMS). DL] There have actually been systems implemented which do keep all their data in a large virtual memory. A system called LOOM (for Large Object-Oriented Memory) was implemented at Xerox to provide storage for Smalltalk objects, and an object-oriented filing system was built for the Intel iAPX-432. I have references to these, and can dig them up upon request. Cheers..Yoram Yoram Eisenstadter | Arpanet: yoram@cs.columbia.edu Columbia University | Usenet: seismo!columbia!cs!yoram Dept. of Computer Science | Bitnet: yoram%cs.columbia.edu@WISCVM New York, NY 10027 | Phone: (212) 280-8180
darrell@sdcsvax.UUCP (03/12/87)
In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes: > With large address spaces and virtual memory, who >needs files? Why not define all storage as extended memory structures >that may be loaded as needed. That's approximately the approach I'm taking with the OS I'm writing for the 80386, which supports both segmentation and paging. My project is to build a prototype implementation of the proposed MIL-STD-1838a, aka. CAISa (Common APSE (Ada Programmer Support Environment) Interface Set, revision a. This system doesn't really have a "file system;" instead, it has an entity-relationship-attribute data base with strongly-typed components. I'm mapping the components directly to 386 segments in virtual memory, and letting the underlying paging system move them back and forth between RAM and disk. User programs will access data in ways that are half-way between file access and manipulating memory-resident data structures. BTW, the whole thing is being written in Ada. There don't seem to be very many people out there doing anything with the 386's ability to do demand paging. I'd love to share experiences and even code (my stuff is all public domain, and MITRE is good at keeping proprietary data secure). -- Bob
darrell@sdcsvax.UUCP (03/13/87)
In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes: >Some people call RAM "fast memory" and disk "slow memory" (and tape >"very slow memory"). With large address spaces and virtual memory, who >needs files? Why not define all storage as extended memory structures >that may be loaded as needed. ... This is a great idea. In fact, it's such a great idea that it was first implemented in the late 1960s under Multics, which indeed does all of its file I/O by mapping the files into the address space. The IBM System/38 also has a single-level-store architecture, with all memory and file objects having a uniform addressing scheme. Even the RT PC was supposed to do its file I/O through the pager, but we kind of wimped out. It seems to me that considerable performance gains should be obtained this way, because the path from the program to the I/O supervisor via page faults should be faster than that through system calls -- no user arguments to validate. There are some problems with doing I/O this way, most notably that it makes device independence very hard. How do you do I/O to a terminal through page faults? To a network socket? Beats me. For that matter, how do you tell how big a file is to less than the granularity of a page? You add extra system calls which lose much of the elegance that page-fault I/O gains. The other reason that you want files is that they have an existence and a naming structure separate from the programs that manipulate them, which is kind of unavoidable. You as a human would probaby rather call a file /usr/fred/games/source/pinball_bounce.c, while your program would rather have a nice handle like a memory address of 0x18723d70 or a file handle of 5. -- John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Where is Richard Nixon now that we need him? [He's 76 years old, hopefully he a relaxing -DL]
darrell@sdcsvax.UCSD.EDU (Darrell Long) (03/17/87)
yerazuws@lll-crg.ARPA (Crah): > Multics used the idea of "no such thing as 'files' from the very > start. Everything was in virtual memory (36-bit addresses, too) > > Look where it got them. :-( Actually, the hardware limitations are probably what did Multics in. If a Multics-like machine was designed today, instead of in 1966, it would probably be a much better performer. Things like a maximum segment size of 256K (18-bit segments, 2^18 # of segments), a single 36-bit accumulator, very limited memory capacity, etc. meant that performance was very limited. And implementing the MMU (with associative look-up cache), caches, etc. with ancient technology was very expensive. I currently attend a university that has an old Multics unit hanging around, the University of Southwestern Louisiana (although USL-Multics is being replaced by an IBM 3090 -- ick). For those of you who've never seen a Multics system and how it does its "all files are segments and are mappable into the address space" trick, a quick description follows: There was no such thing as a "file" in Multics. Everything was a segment, mappable into virtual memory via a system call. However, traditional "file" operations were also allowed. A segment was 18 bits, and there were 2^18 possible segments (thus the "36 bit addresses", which is as misleading as saying that an 80286 has "32 bit addresses"). Segments were paged, and there was a segment table and a paging table keeping track of all this segmentname-segment# info and virtual-address/real-address mapping. An interesting thing was that all memory was also accessible as a file -- that is, since a segment can be either interpreted as being a file or as being memory... there was a "process directory", which contained all these segments, with randomly-generated filenames (Multics has a tree-structured file/segment system, which is where Unix got its concept from). Another Multics oddity was dynamic binding. This may have also had some negative impact on performance, and really should be considered to be a different topic altogether from having memory and files as being identical. The processor itself (Level-68) was pretty weird. It has a single 36-bit accumulator, 16 18-bit index registers, 16 32-bit in-segment addressing registers, and a whole lot of other similiarly brain-dead stuff that I can't remember (it's been 4 years since I last looked at the architecture manual). All instructions used 18-bit addresses -- that is, the first 18 bits have the instruction and addressing mode, the second 18 bits is an address (it has 36 bit words). So most addressing was indexed off one of those 32-bit segment registers, which is quite a bottleneck if you're wanting to access more segments than the available # of segment registers. But standard languages just used a few segments -- a heap, a static variables area, and the stack segment. The PL/1 compiler was huge, and did some of the funkiest optimization that I ever saw... necessary, since there was a LOT of operating system, almost all of it written in PL/1, and you're trying to get decent performance out of some of the most... bizarre... hardware in existence. Despite the fastest I/O processors I've ever seen, a triple-processor Level-68 Multics system could only handle about 100 users before becoming sluggish. Which is really great for a $5,000,000 system :-). A network of three Pyramid 98x machines do that, for under a million... it is probably that fact, rather than anything inherent about treating files as memory, which accounts for the big flop. An 80386 has most of the architectural features of Multics, much improved (such as 32 bit addresses, 2^32 # of segments), and probably would make a much better basis for implementing such an architecture, than the kluged '60s-era GE hardware (originally intended for GECOS) that Honeywell cobbled together. I doubt that anybody will ever do it, though, with Unix around, and Honeywell more interested in bringing GCOS up to bronze-age standards (bringing it up to modern standards would be nigh impossible...). -- Darrell Long Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093 ARPA: Darrell@Beowulf.UCSD.EDU UUCP: darrell@sdcsvax.uucp Operating Systems submissions to: mod-os@sdcsvax.uucp
darrell@sdcsvax.UUCP (03/17/87)
In article <2859@sdcsvax.UCSD.EDU> johnl@ima.ISC.COM (John R. Levine) writes: >In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes: >>"very slow memory"). With large address spaces and virtual memory, who >>needs files? Why not define all storage as extended memory structures >>that may be loaded as needed. ... : > >This is a great idea. In fact, it's such a great idea that it was first >implemented in the late 1960s under Multics, which indeed does all of its >file I/O by mapping the files into the address space. The IBM System/38 >also has a single-level-store architecture, with all memory and file objects >having a uniform addressing scheme. Even the RT PC was supposed to do its >file I/O through the pager, but we kind of wimped out. It seems to me that >considerable performance gains should be obtained this way, because the path >from the program to the I/O supervisor via page faults should be faster than >that through system calls -- no user arguments to validate. : > >-- >John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400 : Another way to approach this is to leave the files with a separate existence, but to structure the (file description tables or whatever the system calls them) such that the file can be mapped to virtual memory. Then provide the operating system with a call to MAP a file to process memory. Both the old IBM TSS operating system (R.I.P :-( ) and the still current CDC VSOS operating system have this feature. It works very well and is a very efficient way of doing I/O. The FIRST call to open the file goes through a system call, after that file access is to memory (and via the PAGER when necessary). This is a very clean, simple, intelligent way to get very good RANDOM I/O performance. There is one minor problem however. Most operating systems read ahead when doing sequential I/O. Programs which read large amounts of data sequentially ( a lot of programs) will suffer a serious negative impact if this case is not handled properly. One way is to put code in PAGER to read ahead. In order for this to work efficiently, PAGER needs to be able to distinguish regular virtual memory from sequential file memory. This is an additional complication, though it can be (and was, for some versions of TSS) done. An additional (not mutually exclusive) way is to provide an operating system call to ADVISE the PAGER which virtual memory (which may be files or just regular process memory) will be needed in the near future. VSOS has this good feature, and I think it is a good feature to make available on any virtual memory system. Since the advise is a system call, you lose a little bit, though typically less than with non-mapped I/O, since the ADVISE is asynchronous. If this approach is taken, the I/O library needs to keep track of how much data it is using and issue the ADVISES for itself. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
darrell@sdcsvax.UUCP (03/20/87)
In article <2875@sdcsvax.UCSD.EDU> darrell@sdcsvax.UCSD.EDU (Darrell Long) writes: > If a Multics-like machine was designed today, instead of in 1966, it would > probably be a much better performer. > a triple-processor Level-68 Multics system could only handle about 100 users > before becoming sluggish. Which is really great for a $5,000,000 system :-). And that's 1960's dollars, probably about $15M today. Given that you can buy a 16M RAM, 160M disk, Sun-like display 386 machine for about $15K, that's a thousand users equivalent. > An 80386 has most of the architectural features of Multics, much improved > (such as 32 bit addresses, 2^32 # of segments), and probably would make a > much better basis for implementing such an architecture, than the kluged > '60s-era GE hardware (originally intended for GECOS) that Honeywell cobbled > together. Bit of a lapse there in your history, though most of the preceeding technical info is accurate (the machine did support 2**18 word-long segments, but MULTICS arbitrarily limited them to 2**16). As far as I know, Honeywell was not involved in the genesis of MULTICS; it was a joint MIT/GE/Bell Labs project sponsored by ARPA. The 645 was a kludge of the commercial product GE 635. BTW, most of this was going on in the same Tech Square building and at the same time as the seminal days of the MIT AI Lab (of "Hackers" fame) AND the creation of IBM's CP-40, later CP-67/CMS and then the current VM system. An awful lot of our current world started at that very small area in time and space. > I doubt that anybody will ever do it, though, with Unix around, and Honeywell > more interested in bringing GCOS up to bronze-age standards. Wanna' bet? I'm considering calling my system MULTICS/386, which may be possible now that Honeywell has decommitted their MULTICS. I'm also considering the name Elliott, in honor of the late Elliott Organick who wrote a very important book describing MULTICS. And, of course, I'm using the current equivalent of PL/I, Ada. -- Bob Munck
bobp@vsedev.vse.com (Bob Pearson) (03/22/87)
Please excuse the length of the following and the inclusion of ravings of biblical proportions. Also, please excuse me if some of my opinions are not new as I did not have access to "news" when Multics was cancelled and I am new to the net. If I've broken any net etiquette, let me apologize in advance. My comments refer to the HIS (Honeywell Information Systems) Series 60 Level 68 and HIS Series 6000 6180 processors and not the HIS Series 600 645/647 (was General Electric) processors that were discussed in "The Multics System: An Examination of Its Structure" by Elliott Organick (MIT Press 1972). Please reference "The Multics Virtual Memory" (H.I.S. June 1972, AG95 Rev. 0). This is a historical paper on the Multics virtual memory implementation and also describes how rings are implemented in hardware (they were not in the Multics implementation on the HIS 645/647 describe by Organick). As an interesting footnote, Honeywell estimated that the software simulation of rings on the HIS 645/647 took between 10 to 20 percent of total chargeable time, with a hardware implementation of rings it became negligible. yerazuws@lll-crg.ARPA (Crah) writes: >> Multics used the idea of "no such thing as 'files' from the very >> start. Everything was in virtual memory (36-bit addresses, too) >> >> Look where it got them. :-( to which darrell@sdcsvax.UCSD.EDU (Darrell Long) responds: > Actually, the hardware limitations are probably what did Multics in. If a > Multics-like machine was designed today, instead of in 1966, it would probably > be a much better performer. Things like a maximum segment size of 256K (18-bit > segments, 2^18 # of segments), a single 36-bit accumulator, very limited > memory capacity, etc. meant that performance was very limited. And > implementing the MMU (with associative look-up cache), caches, etc. with > ancient technology was very expensive. FLAME (RAVE) ON... I do not agree. The problem with Multics was that is was way ahead of its time and the fact that Honeywell did not know how to market it. The hardware was quite sound given the desire that secondary storage be directly processor addressable. There is a real cost (read high overhead) associated with this capability that has to be weighed against the power it gives you [be very careful here, raving of unimaginable magnitude follows], the best program- ming environment in the world. Compared with IBM's TSO or VM/CMS , DEC's VAX/VMS or TOPS-20 operating systems, or UNIX [your favorite incarnation here] (now you opened a hornet's nest) there is no comparison. It is a crime that so much great work must be lost and the wheel be reinvented again and again. Please do not rave at me with "if Multics was so good, then why wasn't it successful?". I attributed this to the fact that Honeywell didn't know how to market it and never realized what they had. It didn't help that IBM released the IBM 360/67 (CP 67) computer (to compete in the timesharing arena) priced to earn a minuscule 0.009% (read PERCENT) profit. BIG BLUE didn't want to lose any more customers (see DATAMATION, May 1 1986, "Multics Users Face Their Maker" by John W. Verity, pages 103-112). I ascribe the success of UNIX to the fact that it is "portable" across many different architectures (no small feat). Multics needs very specific hardware support to run. Multics was done right (if albeit painfully) and didn't take many easy way outs [design compromises (read kludges)]. It was an extremely elegant design. Maybe its goals were lofty but I for one believe in shooting for the stars. FLAME (RAVE) OFF... > There was no such thing as a "file" in Multics. Everything was a segment, > mappable into virtual memory via a system call. Incorrect. While a process can directly invoke a supervisory routine to make a segment known to a process, the normal method was via a hardware fault (trap). The process of making a segment (procedure or data) known takes a rather lengthly discussion to describe all of the mechanics involved (omitted here). It is not done by a "system call" but a hardware trap. Basically, a reference to a segment <k> (by symbolic name) that does not have a valid segment number assigned [(i.e.) its ITS (Indirect To Segment) word "snapped" in the process combined linkage segment for this ring], would not point to a valid SDW (Segment Descriptor Word) and this would cause a Segment Missing Fault that traps to a specific supervisor module [the SCM (Segment Control Module)] that is mapped into every process address space and has a fixed segment number in the address space. This module is responsible to search the supervisor's database of known and active segments to see if the segment is known by any other process (and hence the supervisor), if it is not, it invokes Directory Control Module procedures to locate the desired segment's directory entry with its location in secondary storage (and access rights, page map, and other file attributes) and brings it into main memory. The final byproduct of all of this is that a SDW is constructed in the descriptor segment, the process access rights are set and the segment descriptor word is made to point to word zero of the page table for this segment and the ITS word is set with k# (an offset to the SDW in the descriptor segment for this process). Now the faulting process can continue executing with a valid k# (the segment is now known). The actually process is unfortunately even more complicated. This process is part of dynamic linking. The address (k#) of the target segment is *NOT* known at reference time. > However, traditional "file" > operations were also allowed. A segment was 18 bits, and there were 2^18 > possible segments (thus the "36 bit addresses", which is as misleading as > saying that an 80286 has "32 bit addresses"). Segments were paged, and there > was a segment table and a paging table keeping track of all this > segmentname-segment# info and virtual-address/real-address mapping. Also, conventional I/O was possible via DIMs (Device Interface Modules), that is another topic definitely. Multics also supported nonpaged segments also, but this is not the issue. > An interesting thing was that all memory was also accessible as a file -- that > is, since a segment can be either interpreted as being a file or as being > memory... there was a "process directory", which contained all these segments, > with randomly-generated filenames (Multics has a tree-structured file/segment > system, which is where Unix got its concept from). Another Multics oddity was > dynamic binding. This may have also had some negative impact on performance, > and really should be considered to be a different topic altogether from having > memory and files as being identical. I am not certain that it is a different topic altogether. Dynamic linking is the single biggest win, in my opinion, with the Multics system. It is indeed built on top of the segmented/paged virtual memory but is part of the justif- ication for all this addressing complexity (as well as the true sharing of pure procedures and read only data). It allows the running of incomplete programs and a debugging environment par excellence. In a traditional system, a link editor resolves all external references to construct a core image using either via real memory addresses, relative to relocation registers or via paged virtual addresses. This is fixed at compile and/or link time. In Multics, global symbol table information is included in an executable module and intra-segment references are resolved on the fly. A change in a procedure involves only a recompilation of the segment in which it is found. VMS or SVR3 shared libraries are not needed as all pure procedure (procedures that do not modify themselves) are shareable. All users reference the same main memory resident pages. As an added bonus, a user can replace a version of a procedure that is part of large subsystem (program) with his own copy by modifying search rules used to find missing segments (before they are made known or *AFTER*), and not have to recompile and link a new "image". I could test this version without my new procedure affecting any other users who are running this subsystem. How's that for flexibility? In Multics, if a segment is pure, its pages are either in main memory or in secondary storage. No special mechanism needs to be invoke, it is the normal operating environment. The combination of a segmented/paged addressing scheme with dynamic linking leads to a very good simulation of an idealized infinite memory. There is a performance penalty associated with this added capability that I for one, think is well worth it. Another unique feature of the Multics system is that changes in access to a segment are immediately enforced. Once a process has access to a segment and the access rights are changed, future references to the segment cause protection violations. What other system does this? > The processor itself (Level-68) was pretty weird. It has a single 36-bit > accumulator, 16 18-bit index registers, 16 32-bit in-segment addressing > registers, and a whole lot of other similarly brain-dead stuff that I can't > remember (it's been 4 years since I last looked at the architecture manual). > All instructions used 18-bit addresses -- that is, the first 18 bits have the > instruction and addressing mode, the second 18 bits is an address (it has 36 > bit words). So most addressing was indexed off one of those 32-bit segment > registers, which is quite a bottleneck if you're wanting to access more > segments than the available # of segment registers. But standard languages > just used a few segments -- a heap, a static variables area, and the stack > segment. The PL/1 compiler was huge, and did some of the funkiest optimization > that I ever saw... necessary, since there was a LOT of operating system, > almost all of it written in PL/1, and you're trying to get decent performance > out of some of the most... bizarre... hardware in existence. > Despite the fastest I/O processors I've ever seen, a triple-processor > Level-68 Multics system could only handle about 100 users before becoming > sluggish. Which is really great for a $5,000,000 system :-). A network of > three Pyramid 98x machines do that, for under a million... it is probably that > fact, rather than anything inherent about treating files as memory, which > accounts for the big flop. An 80386 has most of the architectural features of > Multics, much improved (such as 32 bit addresses, 2^32 # of segments), and > probably would make a much better basis for implementing such an architecture, > than the kluged '60s-era GE hardware (originally intended for GECOS) that > Honeywell cobbled together. I doubt that anybody will ever do it, though, with > Unix around, and Honeywell more interested in bringing GCOS up to bronze-age > standards (bringing it up to modern standards would be nigh impossible...). The restriction of 256K byte segments can be handle via multisegment files and few procedures (ala structured programming) need to be greater that 256K bytes, though data files do. This is not to say that the Level 68 was ideal and could not be much improved but all the great work was done is now dust in the wind (I hope not!!). I believe it is impossible to fairly evaluate Multics hardware by looking at its features and/or capabilities in isolation. Rather, one must look at them as providing a foundation for the support of a truly unique operating system/ developing environment. Multics gave us, rings (domains of execution), dynamic linking, a hierarchical file system that was extremely reliable, control sharing of programs/data via discretionary ACLs (Access Control Lists) and nondiscretionary AIM (Access Isolation Mechanism), demand paging (no thrashing here), unparalleled security, device independent I/O, the concept of files as an extension of memory, IPCs, replaceable execution environments (that a USER could code), a realtime pre- emptive operating system that was highly interactive, the ability to do backups automatically on ACTIVE FILE SYSTEMS, the ability to install changes to the OS without taking the system down, etc, etc... MORE RAVING... One is incredulous that with these features, so far ahead of all its competition of the day (vintage IBM VM/CMS, the TSO of MVS, TOPS-10, TWENEX, VMS, et al), were not enough to save this very elegant operating system. But alas, the Dollar wielded its mighty sword and slayed this sleeping giant. We all know that this is the most important criteria on judging an operating system. If it doesn't make money, it must be a loser. Since Multics could not make it in the real world, it couldn't have been that great of a system. I for one, think Honeywell and the industry in general, didn't know a great thing when they saw it. When I talk to CS students who take OS courses, some say they studied Multics in class and their general impression is that it is a dinosaur, that the operating systems of today are much more advance and elegant. I wonder... I am truly HBD (Honeywell Brain-Damaged), Bob Pearson And now for the BIGGEST RAVE OF ALL TIME... DEFINITION OF UNIX (eunuchs)... Multics without the balls... The opinions expressed here and not the opinions of my employer or of any sane, rational sentient being. btw... I actually like UNIX a lot. ============================================================================= -- -- UUCP: ..!seismo!vsedev!bobp (Bob Pearson) ..!verdix!vrdxhq!vsedev!bobp INET: vsedev.VSE.COM!bobp@seismo.CSS.GOV
darrell@sdcsvax.UUCP (03/23/87)
>> There was no such thing as a "file" in Multics. Everything was a segment, >> mappable into virtual memory via a system call. > >Incorrect. While a process can directly invoke a supervisory routine to make >a segment known to a process, the normal method was via a hardware fault "Normal" in what sense? If you wanted to get at a segment by a name *specified at run time*, which many many commands would, you had to call the system. In fact, the dynamic linker code that responded to those faults would, I believe, find the name of the segment being referenced and call the hardcore supervisor routine to map in in, so ultimately to get a segment into a process' address space *somebody* has to call the system to do it. > The process of making a segment (procedure or data) known takes a rather > lengthly discussion to describe all of the mechanics involved (omitted here). > It is not done by a "system call" but a hardware trap. Not really that lengthy. An instruction that made an external reference would do so through a pointer in the process' "combined linkage section". The pointer in question was initially a Fault Tag 2 pointer. That would cause a trap to the linker. The linker would use that pointer to find the name of the segment in which the location being referenced existed, and use the standard hardcore supervisor call to get a pointer to that segment. (This routine was called "hcs_$initiate_refname", or something like that, if I remember correctly. The name that was used for the segment was called a "reference name". To translate such a name to a segment, the supervisor searched your search path, which was a list of directories, for a file with the given name as a file name. Actually, an entry in the search path could refer to the Known Segment Table, which was a table that recorded all the segments that had already been "initiated" by "hcs_$initiate_refname".) If the reference were not to some offset from the base of the segment as a whole, but to an offset from a particular entry point in that segment (i.e., the segment is an object module), the linker would look for the entry point in the segment's symbol table and modify the pointer to point to that entry. In either case, it would then replace the FT2 pointer with the new pointer. (I forget whether it snapped any other links to that segment or entry point or not.) >Basically, a reference to a segment <k> (by symbolic name) that does not >have a valid segment number assigned [(i.e.) its ITS (Indirect To Segment) >word "snapped" in the process combined linkage segment for this ring], If you're talking about an unsnapped link, when I was using Multics at school, they weren't ITS pointers at all, they were FT2 pointers. (Organick's book also describes it this way.) The trap didn't occur because the segment number was invalid, but because the pointer was one that always caused traps when a reference was made through it. Did they stop using FT2 pointers in a later version of Multics? >Also, conventional I/O was possible via DIMs (Device Interface Modules), >that is another topic definitely. If I remember correctly, you could (if you felt so inclined) call the low-level device driver routines directly. They didn't, however, have device-independent interfaces. The DIMs provided the device-independent interfaces; they generally didn't run in a privileged ring, but called the low-level I/O routines which did. There was also a DIM that referred to segments, so you could do the equivalent of "write" calls to files (which merely meant that the DIM copied data into the segment) or to devices. (Actually, the DIM supported "multi-segment files", which were files that could be larger than a segment. They were implemented as directories containing multiple segments that contained pieces of the data in the file.
darrell@sdcsvax.UUCP (03/23/87)
> yerazuws@lll-crg.ARPA (Crah): > > Multics used the idea of "no such thing as 'files' from the very > > start. Everything was in virtual memory (36-bit addresses, too) > > > > Look where it got them. :-( > > Actually, the hardware limitations are probably what did Multics in. > The processor itself (Level-68) was pretty weird. Not that wierd (GE-645). The point is that there were other operating systems (e.g. DTSS, early UN*X) that would run on the same processor without such overhead. Multics was developed in a research environment where burning up hardware wasn't an issue. [DTSS? I'd like to hear more about that. -DL]
darrell@sdcsvax.UUCP (03/24/87)
[I think that most of us agree that Multics was great. Let's finish up with Multics and move on to what we should put into present-day OS's -DL] Well, actually, I expect you've been reading the Organick book. Originally Multics used 64K (2**16) word segments, but for a long time they've been (an inconvenient) 2**18 - 1K word segments. The missing 1K is interesting. The original processor was architecturally more-or-less a copy of IBM 7094 type machines. (GE-645). The bits needed to do most of the fancy character operations, most of the segmentation and paging support, and the 8-ring protection, are in an add-on box tacked onto the standard (GCOS system type) processor. Whoever designed that box used page number 0 as a special case, so that segments could only be 1-255 (1K) pages long. Most of the standard hardware, bar the tack-on Multics box, could cope with 256K segments. The character-handling instructions and some others can't. Recently work has been done to allow 'large segments' -- that is, things which are more than one segment long but which can be manipulated, at least from highe-level languages, as though they were normal segments. The original development was done by AT&T (Bell Labs), General Electric, and MIT, sponsored by the US DoD. AT&T pulled out fairly early. Then (mid-60s, I think, maybe early 70s) GE sold out to Honeywell. HIS produced several newer versions of GCOS hardware (though mostly the same architecture, just faster/denser parts) with tack-on Multics boxes. The real problem with Multics was that there was never a processor designed to run it. It was always a bodge-box attached to a non-Multics processor. HIS wouldn't develop new hardware because Multics didn't sell well enough. Multics didn't sell well enough because many if not most of the HIS sales staff didn't even know about it. There were incredible political rows about this within HIS, but it appears to me that there were 2 factors involved: (1) HIS marketing regarded Multics primarily as a research project -- an attitude not fought by the developers, particularly; and (2) most of the higher-level executives at a few critical moments had strong past attachments to the GCOS side of the product line, and saw Multics as an internal competitor. Still, it lives on in the form of influences to a number of O/Ss which acknowledge a debt to it -- the first 2 to come to mind are U*ix and Primos.
darrell@sdcsvax.UUCP (03/25/87)
In article <2892@sdcsvax.UCSD.EDU> bobp@vsedev.vse.com (Bob Pearson) writes: > : > >Multics gave us, rings (domains of execution), dynamic linking, a hierarchical >file system that was extremely reliable, control sharing of programs/data via >discretionary ACLs (Access Control Lists) and nondiscretionary AIM (Access >Isolation Mechanism), demand paging (no thrashing here), unparalleled security, >device independent I/O, the concept of files as an extension of memory, IPCs, >replaceable execution environments (that a USER could code), a realtime pre- >emptive operating system that was highly interactive, the ability to do backups >automatically on ACTIVE FILE SYSTEMS, the ability to install changes to the OS >without taking the system down, etc, etc... > >MORE RAVING... >One is incredulous that with these features, so far ahead of all its competition >of the day (vintage IBM VM/CMS, the TSO of MVS, TOPS-10, TWENEX, VMS, et al), >were not enough to save this very elegant operating system. But alas, the >Dollar wielded its mighty sword and slayed this sleeping giant. We all know : > >When I talk to CS students who take OS courses, some say they studied Multics in >class and their general impression is that it is a dinosaur, that the operating >systems of today are much more advance and elegant. I wonder... > > I am truly HBD (Honeywell Brain-Damaged), > > Bob Pearson : Interestingly enough, IBM's TSS operating system had many of the features of MULTICS as listed above (they were copied, of course). TSS had a lot of bugs when it was first released, and gained a (deserved at the time, but not later) reputation for unreliability. In the meantime, the forces of OS/360 (now MVS) recouped within IBM and succeeded in killing off TSS before it ever really had a chance to succeed. In this case, I believe it really was a question of politics, not profit. TSS is also listed as a "dinosaur" in the operating system textbooks, despite the fact that it and MULTICS are still unsurpassed today in any commercial operating system. Amusingly enough, though, the TSS kernel lives on inside UNIX/370, IBM's UNIX done for Bell labs for the IBM 370, and probably inside IX/370 as well. TSS was originally designed for the 32 bit addressing 360/67, though it was given a partial lobotomy to run on the 370/168 (24 bit addressing). I believe that the MVS lobby within IBM will not permit 32 bit addressing to be restored to TSS to support UNIX, or will delay it inordinately, for political reasons. Nor will they permit, I would bet, IX/370 to be ported to the 3090/VF series, again to protect MVS. Ask your local IBM sales rep about it some time; especially ask why if MVS is so good you can't run UNIX on top of it :-) For years people inside and outside IBM have been trying to get IBM to give VM the right stuff to be an operating system in its own right, but the MVS crowd has successfully fought it off. There is still (the last time I looked) no support of 32 bit addressing in CMS, and no decent production batch monitor. I guess I am TBD (TSS Brain-Damaged), but my message to whoever is reading this is, "Never Give In (when internal politics threatens to destroy technically sound marketable products)". Easy to say, but hard to do! Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")
darrell@sdcsvax.UUCP (03/26/87)
In article <2859@sdcsvax.UCSD.EDU> johnl@ima.ISC.COM (John R. Levine) writes: >In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes: >> >> ... Why not define all storage as extended memory structures >>that may be loaded as needed. ... > > ... it makes device independence very hard. ... > >The other reason that you want files is that they have an existence and a >naming structure separate from the programs that manipulate them, which is >kind of unavoidable. You as a human would probably rather call a file >/usr/fred/games/source/pinball_bounce.c, while your program would rather >have a nice handle like a memory address of 0x18723d70 or a file handle of 5. I'd like to continue this defence for the file concept and to turn the question the other way: Why not turn all memory into files? The structured UNIX file tree is a very comfortable means for handling big, non-uniform amounts of data. Much more comfortable than a uniform, binary address space from zero to infinity. Even an address space from zero to 2^16 (as on this PDP-11/70 called Obelix) seems too big and unstructured to me. Why not continue the partitioning of data into files and directories down to the variable/record/statement level? Of course, we would then have to consider interpreting languages with more overhead than todays optimized number-crunchers, but, as computers as such become faster and smaller, we would have to find a way to use their extra power anyhow :-). I think this idea has been used to implement some virtual LISP and SmallTalk machines, but these aren't too common. To the comp.arch people: Who will invent the tree-structured memory chip? -- Name: Lars Aronsson Snail: Rydsvagen 256 A:10, S-582 48 Linkoping, Sweden UUCP: {mcvax,seismo}!enea!liuida!obelix!l-aron ARPA: l-aron@obelix.ida.liu.se
darrell@sdcsvax.UUCP (03/27/87)
>In article <2859@sdcsvax.UCSD.EDU> johnl@ima.ISC.COM (John R. Levine) writes: >>In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes: >>> >>> ... Why not define all storage as extended memory structures >>>that may be loaded as needed. ... >> >> ... it makes device independence very hard. ... >> >>The other reason that you want files is that they have an existence and a >>naming structure separate from the programs that manipulate them, which is >>kind of unavoidable. You as a human would probably rather call a file >>/usr/fred/games/source/pinball_bounce.c, while your program would rather >>have a nice handle like a memory address of 0x18723d70 or a file handle of 5. Actually, there are operating systems that let you do this sort of thing. (Well, maybe it's just a sufficiently close approximation.) The Dartmouth College Time Sharing system provides an "address file" system call which maps a file into your virtual memory space. The program now has a nice handle on the file which is a memory address, the operating system having performed the translation between a user supplied treename (pathname) and a memory address. The program can now access the memory mapped file using a suitable data structure. Device independence is not a problem. Back before DCTS implemented this system call, some people were porting IBM PL1 programs which apparently did similar things. -- Chuck
darrell@sdcsvax.UUCP (03/27/87)
In article <2907@sdcsvax.UCSD.EDU> l-aron@obelix.UUCP (Lars Aronsson) writes: >I'd like to continue this defence for the file concept and to turn >the question the other way: Why not turn all memory into files? > >The structured UNIX file tree is a very comfortable means for handling >big, non-uniform amounts of data. Much more comfortable than a uniform, >binary address space from zero to infinity. Even an address space from >zero to 2^16 (as on this PDP-11/70 called Obelix) seems too big and >unstructured to me. Why not continue the partitioning of data into >files and directories down to the variable/record/statement level? >Of course, we would then have to consider interpreting languages >with more overhead than todays optimized number-crunchers, but, >as computers as such become faster and smaller, we would have to find >a way to use their extra power anyhow :-). > >I think this idea has been used to implement some virtual LISP and >SmallTalk machines, but these aren't too common. > >To the comp.arch people: > Who will invent the tree-structured memory chip? (They have! Ain't you ever heard of a binary tree?! :-) ) I think the problem is that this drives the size of a pointer through the roof. It also makes dereferencing the things a horrible operation. It might, however, be possible to use plain ol' numbered memory with a facility for translating names to addresses... Hm... Could you describe the avantages you see in this memory model? I'm not sure exactly what it's hoping to accomplish. It sounds sorta interesting, but I can't see any great advantages it has over large address spaces. -- -Colin Plumb (watmath!watnot!ccplumb) Silly quote: I'll procrastinate when I get around to it.