davecb@yunexus.UUCP (David Collier-Brown) (06/07/89)
In article <76700071@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: [responding to a discussion involving Intel's idea of segmentation] > >Well, if you're going to point fingers, why don't you blame MIT and >project MAC? They were the one of the ones that took segmentation to >outrageous extremes to begin with. Intel was only copying them. I beg to differ. The only similarity between the segments (aka files) defined by project MAC and the segments used for address-space-extension by intel is in the name. Project MAC is not, was not and never will be responsible for this particular misuse of the terminology. To go to the primary sources... In most modern file systems following CTSS, files (as do segments) carry unique names, have attributes, are created, destroyed, allowed to grow and shrink, have access controls applied to them (i.e., may be shared), and are structured in a directory hierarchy. A file system maintains this structure and offers retrieval services, backup services, and so forth. Only the difference (albeit very significant) that segments are "instantaneously" shareable by virtue of being directly addressable in Multics programs distinguishes the segment from the file. -- from Organick, E. "The Multics System: An Examination of Its Structure", Cambridge, Mass (The MIT Press), 1972. --dave (sources, people, sources! we're computer **scientists**, don't forget) c-b -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 223-8968 | He's so smart he's dumb.
mac@uvacs.cs.Virginia.EDU (Alex Colvin) (06/22/89)
(Sorry if this has already been hacked to death. Something is clogged in our news feed.) > [responding to a discussion involving Intel's idea of segmentation] > The only similarity between the segments (aka files) defined by > project MAC and the segments used for address-space-extension by intel > is in the name. Project MAC is not, was not and never will be > responsible for this particular misuse of the terminology. We're talking segments in the processor address space here, not Multics mapping into the file system. And yes, there is a similarity. GE 645 operands coud select from 8 segment registers, where iNtel can select from 4. GE segments were 1^18 words long, iNtel 2^16 bytes. Therein lies the rub. In the 60s, 1/4 MW was a lot, enough for almost any program. In the 80s, 1/16 MB is not a lot, too small for many programs. Even so, 256KW turned out to be too small for some files. There is a difference in the coordination of segments and pages. GE645 segments had their own page tables. iNtel segments are offset into a global page table. This makes sharing small segments practical. You might think of them more as capability pointers. It also means you don't have to do TLB flushes on every context switch. After Honeywell took over the Multics line (the H6180), their next architecture (the H6600, DPS8) used this global page table approach. (well, actually a Working-Space Quarter or something equally wierd).
munck@linus.UUCP (Robert Munck) (06/27/89)
In <196@uvacs.cs.Virginia.EDU> mac@uvacs.cs.Virginia.EDU (Alex Colvin) writes: > ... iNtel can select from 4 (segment registers). >GE segments were 1^18 words long, iNtel 2^16 bytes. Therein lies the A fount of mis- and semi-information. While I'm not up on machine-language programming, I believe the 386 has six simultaneous segment selectors -- DS, ES, FS, GS, CS, and SS (last two are code and stack). Also, 16,384 segments are just a tad slower to get to. True, GE segments were 2^18 (1^18 - typo) (36-bit) words, but be reminded that MULTICS only supported up to 2^16. Finally, of course, Intel segments can be up to 2^20 bytes in byte granularity or 2^20 (4096-byte) pages in page granularity. The latter is, of course, 2^32 bytes or 4 gigabytes. -- Bob Munck, MITRE
elg@killer.DALLAS.TX.US (Eric Green) (06/30/89)
in article <57877@linus.UUCP>, munck@linus.UUCP (Robert Munck) says: > A fount of mis- and semi-information. Who is? > programming, I believe the 386 has six simultaneous segment selectors -- > DS, ES, FS, GS, CS, and SS (last two are code and stack). Also, Where did FS and GS come from? Last I heard, the fab four were DS (Data Segment), ES (Extra Segment -- which all the string instructions use), CS and SS. Also note that, if I recall correctly, each 36-bit instruction under Multics contained a segment register selector, whereas if you want to use a different segment register on an Intel machine, you have to prefix the instruction with a segment selector instruction -- for each individual instruction that uses that different segment register. In other words, Multics segments are more like IBM 360 segments (offset+base register designator) than Intel segments (each instruction hard-wired to offset off of a dedicated segment register always, unless you use the obnoxious prefix byte). This is a bit more useful, in that you can access more memory efficiently, without reloading segment registers. > segments are just a tad slower to get to. True, GE segments were 2^18 > (1^18 - typo) (36-bit) words, but be reminded that MULTICS only supported > up to 2^16. According to various sources the original MIT MULTICS only supported 2^16 word segments. However, the Honeywell commercial version supported 2^18 word segments (or at least it did when I went Multics-hacking back in '81 or so, dunno about earlier). > Finally, of course, Intel segments can be up to 2^20 bytes in > byte granularity or 2^20 (4096-byte) pages in page granularity. The latter > is, of course, 2^32 bytes or 4 gigabytes. I must admit that Intel finally got at least one thing right -- for the '386, they made the segments big enough. One of Honeywell's problems with Multics was that to access files big enough to hold commercial databases, they had to cobble together multi-segment files (remember, in Multics the OS all files were segments and vice versa, so all files were memory-mapped). The 1 megabyte segment capacity that had seemed so extravagant in the '60s must have looked mighty small when they started trying to figure out how to commercialize the system. We all know the result of their attempted commercialization... Multics just wasn't designed with batch transaction processing in mind (punched cards, anyone?), and Honeywell didn't know how to market anything else. -- Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 "I have seen or heard 'designer of the 68000' attached to so many names that I can only guess that the 68000 was produced by Cecil B. DeMille." -- Bcase