Re: Removing SunOS/68k compatibility before 8.0

[Frank Wille <frank%phoenix.owl.de@localhost>]

Swift Griggs wrote:

> Since the VAS is independent of the PAS, shouldn't simply increasing
> the size of the page table that tracks the virtual memory increase it's
> upper limit? I'm guessing for some reason it's not that easy.

I'm not sure. I haven't done anything with 68k MMUs in the last two decades.

It wouldn't surprise me when there is some pmap init code which only creates
the page tables for a limited address space, like 0x00000000 to 0x1fffffff.

Otherwise all I know are the parameters in amiga/include/vmparam.h. I would
probably move USRSTACK (currently at 0x1e000000), which defines the
VM_MAX_ADDRESS, and then adapt the MAXDSIZ for a process accordingly.


> I can't think of any reason why the 68k would limit you doing that at a
> ISA or architectural level.

The 68k is not problem. It can handle 4GB VM just fine. The problem for me
is to find all required modifications in the source.


> The
> issue you mention about SunOS not being able use the MSB of a pointer,

Forget that. At the first glance I noticed that the address space of a user
process was limited to 32MB code and 224MB data, so I was guessing that no
more than 256MB of virtual address space would ever be used.

Which is wrong. The user stack ends at 0x1e000000.

I didn't see any problem in the source with SunOS myself, to be honest. I
just remember that Michael van Elst mentioned long ago on this list that
SunOS compatibility is the reason for the limited virtual address space.


> I do have a few 68k Macs, though.

Currently the maximum data segment size for a mac68k user processes is
limited to only 64MB. Maybe we can increase that too, if you like to test.


> it's just that I've been working on learning 68k ASM all
> year and studying the 68k in my spare time, so I'm curious and excited
> about this topic.

Most is C in NetBSD, but it is often required to know details about the CPU
architecture.

Good choice to play with 68k, BTW! I know no better CPU for having fun with
assembler programming. :)

-- 
Frank Wille