I know the boards used in the IPX and IPC had a sparc with a specific way of partitioning memory at very high and low addresses. Sparcs didn't have all the address mapping gunk that the Intel cpus have, and so sun came out with a way to have a small footprint of memory have a block of memory mapped low and very high in the address space. this allows the upward growing or block memory to be allocated in a large area from 0->up and the descending growing things like stacks to be allocated high and grow down, as the system ran. No need to put them in a low space and then have the collide. I understand this is a memory allocation / O/S thing and the specific problem was to make the page tables or what have you not have a big hole in the middle where there never would be any memory. If you have an address space, the page tables or whatever they are called tend to reflect the physical memory, so if you want to address a block of it low and hi, you have a big block of zeros in the middle. I think there is some sort of offset that allows you to have the high and low memory, and have all the table entries hit together with a concept of wrapping the spaces low and hi together. I.E. the first table entry would not be for page 0, but could be for something like the first page of the high memory. The page 0 entry would be in the middle of the table somewhere. But there would be no unused block. I am sorry not to have the exact terms here, but I heard this account from someone who has coded extensivly on the Sun platform doing malloc and memory allocation work in the system. I don't know which this is, but am sure it is for the cheepo platforms, which they did like the IPX IPC. At the time of the first pizza box, Sparc-2 that was a high end workstation so it would not have had this as a design goal. Jim Jochen Kunz wrote:

I don't suppose it occurred to either of you to actually go and check? NetBSD's code is available for inspection, and while I haven't checked, I feel certain OpenBSD's is too. I just had a quick look at the NetBSD code. The biggest differences seem to be in the pmap, which deals with the MMU; there are other checks for SUN4 vs SUN4M vs SUN4C scattered around, but they are mostly various drivers that know things like "this device appears attached to obio only on 4c machines". It's possible to build a kernel supporting any desired subset of the three types; if you build a kernel supporting more than one type, you will pay a marginal speed penalty since some things will make run-time checks for the architecture, checks which are effectively done at compile time in a single-architecture kernel. You might want to check it before suggesting it. I just had a look and found nothing of any real use to an OS writer. It talks only in generalities far too vague to write code to. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B