Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!aramis.rutgers.edu!athos.rutgers.edu!rbthomas From: rbthomas@athos.rutgers.edu (Rick Thomas) Newsgroups: comp.os.minix Subject: Re: Compress (really "Large Model" compilers) Message-ID: Date: 20 Jul 89 06:43:05 GMT References: <4660@crash.cts.com> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 47 The MS-DOS / UNIX-286(all flavors) concept of "memory size models" for the i286 is an abomination, and I strongly resist any attempt to add such a thing to Minix! For the 80[34]86, and above, there is no problem. All code is one model, because segments can be any "reasonable" size (though some of the Supercomputer users around here are talking seriously of 32 bits not being enough for addresses... (8*) Minix on a Cray-2 anyone?) So we just use GCC and be done with it for these machines. For the 8086 and 80286 there are two solutions that are acceptable. Multiple memory models (a concept which the ANSI C standards committee wisely refrained from including in their language) is not acceptable. The first acceptable solution is the current Minix solution, namely 64K-i/64K-D with 16 bit pointers and 16 bit int's and that's that; the second is to support arbitrary i and d by code-generator kludges with 32-bit pointers and int's. There is too much existing code that assumes sizeof(int) == sizeof (char *) to allow anything with 16-bit int's and 32-bit pointers or vice versa. The required code-generator kludges include things like adding the separate halves of an int sum in separate registers, and dis-assembling pointers when they are loaded into registers. Multiplication of int's becomes a genuine nightmare! (I don't even want to think about division!) The problem with the first solution is that it doesn't support big programs. The problem with the second solution is that it is *SLOW*. (I have talked to some people who have tried it, and they claim a factor of 3 or 4 performance hit over the solution 1 approach.) We simply have to admit that there are a lot of brain-damaged machines out there and accept their limitations. The "teaching" value of Minix would be totally destroyed by having a compiler that required a two week short course to describe its non-standardness, and a lifetime to discover all its pitfalls. Personally, I prefer the first solution (current Minix). Small IS beautiful, in this case. Rick -- Rick Thomas uucp: {ames, att, harvard}!rutgers!jove.rutgers.edu!rbthomas internet: rbthomas@JOVE.RUTGERS.EDU bitnet: rbthomas@zodiac.bitnet Phone: (201) 932-4301