Subject: Re: NetBSD on non-MMU systems???
To: Todd Vierling <firstname.lastname@example.org>
From: Jim Wise <email@example.com>
Date: 01/08/2002 15:17:14
-----BEGIN PGP SIGNED MESSAGE-----
Yup, this is what MiNT did. But it's not _that_ drastic a step --
requiring a configuration of which of the addressing modes it already
chooses from are available -- at least in GCC.
Certainly less work than fully redefining what a pointer is -- which is
what classic MacOS does.
(In classic MacOS, almost all OS routines which accept or return a
structure, including memory allocation routines, work with `Handles',
which are pointers to an entry in a table of pointers at a fixed
location in the process' address space. Via this mechanism (using
pointers-to-pointers instead of pointers), the OS reserves to itself the
right to compact or relocate any part of a program's address space
(except for the table itself) at any time.
This is why direct ports of Unix software to older MacOS often have
_very_ odd memory usage characteristics -- in order to have malloc() and
friends work with pointers directly, Unix compatibility libs for old
MacOS have to lock in place all memory segments containing memory
allocated by malloc. When implemented in terms of the (Handle-based)
memory allocation APIs of the underlying OS, this quickly leads to
address-space fragmentation and other unpleasantness....)
On Tue, 8 Jan 2002, Todd Vierling wrote:
>On Tue, 8 Jan 2002, Jim Wise wrote:
>: Motorola 68k processors, for example, have a pretty wide array of
>: indirect and PC-relative addressing capabilities. Using the latter, and
>: a compiler configured to emit pointer references as PC-relative memory
>: access, a fairly simple-minded fork() (copy the whole damn address
>: space) is _certainly_ possible.
>Yes. This requires a modified compiler, as noted in my footnote. You'd
>have to ensure base-relative addressing for:
>* data loads/stores
>* load effective address (lea) of *code*
>: >[*] The only alternatives are to change the C compiler's notion of a pointer
>: > (not easy, to be sure), or to copy memory around every time a process
>: > context switches.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----