Subject: Re: NetBSD without MMU ?
To: Ignatios Souvatzis <firstname.lastname@example.org>
From: Neil Ludban <email@example.com>
Date: 04/14/2002 16:50:36
Ignatios Souvatzis wrote:
> OS-9 (OS-9, NOT MacOS 9) has done Multi-user/Multi-tasking right from
> the start in a single 64 kByte address space on the MC6809 CPU).
> But then, the compiler made sure that all data accesses were relative
> to the U register (or the DP register for the first 256 bytes of
> the area). OS9 F$FORK is no Unix fork(), but it starts a new
> (possibly same) program module with a seperate data space. No data
> sharing. (But the calling process can pass a parameter area.)
> Code sections are sharable (and generated with only relative accesses
> by the compilers).
> Similar trick, I think, for OS9/68000, but that book is not in the shelf
> I can reach while sitting at the keyboard.
> OS9/6809 Level Two supported a limited hardware MMU - basically a fast static
> RAM translating the upper few (e.g., three) address bits. Real memory
> protection is still very limited.
There was a port of gcc targeting OS9/68k (around 5-7 years ago?)
which would have supported a base register for the data section...
I also vaguely recall a more general option to do this (useful for
embedded systems, eg a 68k instruction using register+16 bit offset
is 2 bytes smaller than absolute 32 bit offset, on a board with 64k
RAM mapped at 1Meg). Nearest I can find now in the gcc 2.95 info-
Generate code for the Medium/Anywhere code model for embedded
systems: assume a 32 bit text and a 32 bit data segment, both
starting anywhere (determined at link time). Register %g4 points
to the base of the data segment. Pointers still 64 bits.
Programs are statically linked, PIC is not supported.
Put global and static items less than or equal to NUM bytes into
the small data or bss sections instead of the normal data or bss
section. This allows the assembler to emit one word memory
reference instructions based on the global pointer (GP or $28),
instead of the normal two words used. By default, NUM is 8 when
the MIPS assembler is used, and 0 when the GNU assembler is used.
The `-G NUM' switch is also passed to the assembler and linker.
All modules should be compiled with the same `-G NUM' value.
The OS9 process model had a couple other differences- the program's
code and initialized data had to be preloaded into memory. Then a
fork() meant create a new process, stack, and copy of initialized
data (and zero the uninitialized data); exec() was similar except
it reused the current process after freeing its data. Both could
pass argv, and had extra parameters for priority/stack limit/file
descriptors to leave open/etc.
On the 68k, MMU was optional. IIRC, it was for protection only
(great for debugging, faster turned off in production systems) and
may not have been used for defragmentation (no big deal, there was
also an API for colored memory allocation).
So how much work would it take to make NetBSD do _something_ on a
non-MMU system, since most of us who have wished for it were stuck
with the CPU, and a couple missing/changed syscalls beats getting
a completely different OS?