Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!bionet!ames!haven!decuac!felix!preston From: preston@felix.UUCP (Preston Bannister) Newsgroups: comp.os.minix Subject: Why the 8086 architecture is wonderful :-) Message-ID: <84154@felix.UUCP> Date: 22 Feb 89 00:49:41 GMT References: Sender: daemon@felix.UUCP Lines: 57 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: main () { if (fork()) for (;;) printf("Heave"); else for (;;) printf("Ho"); } 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). Guess which one is faster :-) 2. If you want a real virtual memory system, using the Intel 286 (i.e. an AT-clone) in "protected" mode is the least expensive solution. The 286 effectively has an MMU on chip. True, it is segment-based (no paging), but you can't beat the price. The MMU on-chip also means fewer delays between the CPU and memory, i.e. for a given clock rate you can use slower (less expensive) RAM. All this is not to say the I think the Intel 8086 architecture is truly wonderful, just that it does have _some_ advantages. When I read about the 8086 architecture I was working on a UCSD Pascal system. If you are used to thinking in terms of shared libraries, a 64kb limit on the size of one code segment is not bad. In fact good programming practice would tend to break up such large modules. Given a good set of shared libraries, large monolithic programs are much less likely. None of which is much help when trying to port GNU Emacs... -- Preston L. Bannister USENET : hplabs!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister