🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #1365

Re: Slandering Project MAC (was Slandering Intel)

#1365
From: Eric Green
Date: Fri, 30 Jun 1989 00:14
54 lines
3214 bytes
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
Technical Details
Message-ID: <8487@killer.DALLAS.TX.US>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!killer!elg
References: <57877@linus.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!killer!elg
From: elg@killer.DALLAS.TX.US (Eric Green)
Newsgroups: comp.arch
Subject: Re: Slandering Project MAC (was Slandering Intel)
Message-ID: <8487@killer.DALLAS.TX.US>
Date: 30 Jun 89 00:14:08 GMT
References: <57877@linus.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 54