[movitz-devel] OS decisions

[Frode V. Fjeld]

Brian Makin <merimus at gmail.com> writes:

> Some architecture questions... some of which may not have been
> decided yet.
>
> Do we want to support 32 and 64 bit?

I think 64-bit is definitely the way to go, because the increased word
size is beneficial to lisp, and the increased address space (same
thing obviously) is beneficial to OS hacking.

> SMP?

Of course.

> Will there be virtual memory?

I think "virtual memory" is these more-or-less separate things:

  1. Swapping: A way to increase the memory size by means of secondary
     storage.

  2. Circumventing the problems that come from the (too) limited
     address space.

  3. Aid the loading of static (non-position-independent) code. By
     offering the exact same (virtual) address space to each program,
     addresses can be hard-coded into the (compiled) program's file
     image, making loading/linking a no-op.

Some thoughts on each poing wrt. Movitz:

  1. Primary storage (DRAM) is dirt cheap now.
  2. 64-bit more or less makes this a non-issue.
  3. This is not so interesting for dynamic systems.

> Memory protection?
> What kind of file system? or use an existing one?
> Will it have a console or be gui driven?

In my personal vision for Movitz, these design questions belong to the
architectural layer above Movitz. That is, I've tried so far to make
everything agnostic to these things, allowing for a big solution space
for systems built atop Movitz. So for example, there is no explicit
SMP support, but everything is designed so that introducing SMP should
not break anything (there's no issues like "the big central
interpreter lock" or somesuch). This is to explain why I've kept my
focus somewhat low-level, and haven't built much higher-level stuff
that would probably have attracted more attention (and perhaps code
contributions.. I guess this is part of the Worse is Better argument:
start with the shiny veneer and the hull will get filled much more
quickly than if you start with a boring core.. :)

-- 
Frode V. Fjeld