Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cwjcc!hal!ncoast!allbery From: allbery@ncoast.ORG (Brandon S. Allbery) Newsgroups: comp.os.minix Subject: Re: Why the 8086 architecture is wonderful :-) Message-ID: <13428@ncoast.ORG> Date: 1 Mar 89 02:55:44 GMT References: <84154@felix.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.os.minix Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 58 As quoted from <84154@felix.UUCP> by preston@felix.UUCP (Preston Bannister): +--------------- | Before we get carried away trashing the Intel 8086 architecture lets not | forget it's advantages... | | 1. If you can restrict your program to 16-bit pointers (i.e. the "small"(?) | memory model), as does Minix, then: | | - Your code will tend to be both smaller and faster. (The code for "small" | 8086 programs tend to be smaller than "small" 68000 programs). | | - You can treat each segment as a seperate address space. Segments can be | moved around in memory as needed. This is the rather nifty trick Minix uses | to efficiently implement fork() without a real MMU. Since the 68000 has | a flat address space, the following program under ST Minix is incredibly | inefficient: > (...deleted...) | On each process switch ST Minix _must_ swap the parent and child data so | that the running process is in the same place in the address space. In PC | Minix the process switch only has to change a couple of segment registers. | (This _not_ a criticism of ST Minix, as this approach is a necessary | function of the 68000 architecture). +--------------- It is NOT necessary. For example, the Macintosh uses relative addressing almost exclusively. This results in 32K relocatable segments, as the 68000 uses signed 16-bit displacements. ST Minix could use the same trick (and with some hacking, it could use 64K segments if it wanted to deal with 32K of "negative" addresses), in which case your example reduces to exchanging the chosen base register, which is done when the process's quantum starts anyway. The main reason that this is not normally done is that it introduces the joys [ ;-) ] of large-model programming to the 68000. An ST-Minix program can be much larger than a PC-Minix program (witness gcc), because accessing an address outside the current segment is possible without munging the segment registers. (Note that this can still be done on the 68000, even if you use relative addressing: it's not a processor mode, it's the choice of instruction.) The Mac uses it so it can rearrange memory as necessary, as noted above for the "fork" trick -- otherwise, certain combinations of actions could generate lots of holes in memory (open DA, open application, close DA -- suddenly there's a sizeable chunk of "dead space" between the system heap and the application, where the DA used to be). An-relative addressing also makes for smaller and faster code, since only two bytes need be read from memory to fetch an address, vs. 4 for absolute addressing. (Counterpoint: protected-mode 386 programs can also use 4-byte addresses, so they are also potentially slower. I don't know whether any existing 386 programs actually use 4-byte addressing, though; with the 386es at Telotech came sdb, so I didn't have to learn the processor the way I had to with the adb-only 68000 in ncoast.) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser