mike%brl-vgr@sri-unix.UUCP (02/07/84)
From: Mike Muuss <mike@brl-vgr> Herm - First, it is not clear whether your intent was to get more than 64K code, or 64K data. Also, is this for the UNIX Kernel, or for user mode code, or both? On our (BRL's) PDP-11 systems, we implemented (as 2 separate, but related projets) code to support: *) More than 64 K of Kernel I-space. Still stuck with 64K of D-space, but buffers-out-of-kernel space code actually helps this a lot. *) More than 64 K of User I-space. Still stuck with 64K of D-space. Because the iAPX88 processor (that's the PC's processor, right? I'm not a PC person) uses 4-spaces (I,D,Stack,Extra), with addressing in each segment being simply offset from the segment base register (yuck, real IBM style), it seems to me that you could use the EXTRA segment much the way we used the PDP-11 KISAR7 register to "map" in external code segments. It's a pity that this kind of crap is necessary for processors built in the 1980s. Sigh. It is relatively easy to see how this extra segment capability can be used to map in an arbitrary quantity of additional code in a completely programmer-transparent way. But, there is no easy way to do this for data-space AT ALL. Extentions to data space would be programmer visible. Furthermore, due to the lack of fine-grain control over the memory management (just 4 segments), it is unlikely that BOTH I-space and D-space extentions could be used at the same time without a rather excessive amount of (needless) context switching (of the EXTRA segment base value) happening all the time. RECOMENDATION. Buy a 68000 or a 68010, or (gasp!) a BELMAC-32 (WE-32?) or some other "real" 32-bit CPU. Back! PC Hackers! -Mike
DBrown.TSDC%hi-multics@sri-unix.UUCP (02/07/84)
Look for a compiler which claims to accept the "large memory model",
which means that the compiler treats pointers as 32-bit entities, and
always generates long jumps and segment-register/offset-register address
constants.
Digital Research has one for the 8086 (reputedly), but it only runs
under DR's CP/M...
--dave (buy a coprocessor board!) brown
DBrown.TSDC at HI-MULTICS.ARPA
watbun!drbrown at watmath.UUCP
dave at CCSC-SDO.Minneapolis.HoneywellHFISCHER@USC-ECLB.ARPA (02/13/84)
In response to your message sent Mon, 6 Feb 84 23:05:10 EST Mike, My desire was to get Ada compilers running under PC's Unix. I know of three efforts which are relevant: Irvine Computer Science, who claims to need over 64K of user-I space but not D space, University of York, (no knowledge about their needs), and Alsys West (Ichbiah's Boston startup) who claims to need over 64K of user-D space but not I space. (AJPO says both York and Alsys have formally indicated intent to validate this year; Irvine says me too.) I would accept some form of hack which killed swapping and multiprocessing for a while (e.g., during compiling) in turn for finding and siezing lots of (either) user I or user D space. As we used to do on the good ol' 360's, you can reload bases (ES) to your heart's content if you know that your memory is not being swapped or physically moved about. I agree that another processor would've been better. Unfortunately, corporate america has bought IBM's marketing pitch, and the likes of my and similar companies have so many PC's in house and on order that to ask for something else is to not be serious. We need standardization and transportability, and the PC and Unix to some vague degree give us that. So, back to my question, are there folks who have tried this sort of hack, knowing full well that technology is capable of giving us "better" solutions, but nontheless, ... Herm Fischer -------