[LispM-Hackers] Outageness

[Nyef]

On Mon, 25 Feb 2002, John Morrison wrote:

> As I was thinking about getting this to run on bare iron, I was
> wondering how to handle loading the band given potentially limited
> physical memory, etc.

Stick the band in a partition on the hard drive. Add swap space. Demand
page the band in as needed. Make things so you don't absolutely have to
have etherboot in order to run it (etherboot doesn't seem to like PCMCIA
ethernet cards, and guess what my OS dev machine uses?).

> The way I was contemplating doing this at the beginning on bare iron was
> to (do this the same way I did the work on the Java OS and) use
> Etherboot to put the "microcode" down below the 1MB real-mode address
> limit (and below the 640KB frame buffers) so I don't have to do any
> funky relocation or kernel-payload encapsulation (like the Linux kernel
> does), and then have etherboot put the load band in higher memory, (very
> importantly) aligned on an x86 page boundary (which I hope I recall
> correctly is also 4KB just like in the LispM -- if not, or not some
> multiple, This Will Never Work).

The x86 page size is indeed 4k. I'd actually prefer to keep the low spaces
available for DMA buffers, given a choice, but that can be fixed later.

> I've also got to think deeply about address space issues and speed.
> I've got to build the "microcode" in such a way as that its entry point
> and pre-protected-mode preamble works correctly in real-mode, and that
> its protected mode addresses all work correctly later.  I would really
> like to use the MMU and pass e3 word addresses directly to it without
> having to execute any x86 instructions to figure out the x86 virtual
> address of the e3 virtual word address.

There are a couple problems with this idea. First is that you will need to
mask off at least some of tags at the top of an E3 data word. Second is
that E3 addresses are word indexed, and the MMU isn't responsible for
scaling them (you do have scaled addressing modes, though, so all is not
lost).

You _can_ have it such that you don't need a displacement, though. See
below.

> I used to link the JavaOS at an absolute address, but now I'm thinking
> maybe I screwed up and I should build position-independent code so that
> it would still work if I mucked around with the MMU?  Hmmm (I think
> maybe there were some complications deriving from using NASM for the
> real-mode stuff, and I think NASM was very particular about symbols and
> their relocations, but that was a Long Time Ago)...  Does anybody have
> any insights?

Set your code up at an absolute location really high up in memory. Write
the initialization code to set up the page tables for it (you can do this
from 32-bit protected mode). You need to identity-map the low part of
memory, add the mapping for the absolute final location, jump to it, and
then you can remove the identity-map.

> Should I use position independent code, and then put the microcode way
> above the 25 address space, and then "wire it down?"  Can we do similar
> stunts on the Linux build?

Position independant code on an x86 is extremely icky (something about the
lack of PC-relative addressing modes). I strongly advise against using it
if you can possibly avoid it.

>                             I know it's perfectly legal to read
> low-memory addresses (word 0) on the e3, but it wouldn't be on
> Linux/UNIX.  Can we trap the (infrequent?) reads to those addresses and
> then have a signal handler handle it, so that we can get some real speed
> going?

You _could_ just mmap() some memory to those addresses. Or use the user
LDT hacks to create a selector that you can use to reference the E3 memory
space that way...

And at addresses 0 and 5 are the symbols NIL and T. I somehow doubt that
those will be infrequent reads.

> Sorry for thinking out loud, and airing half-baked ideas, but maybe
> somebody out there knows.  I think Nyef mentioned something about VM
> emulation, and I have casually perused the emulation sites on the
> Internet.  Does anybody have a high-quality URL for such issues?

I doubt it, because almost nobody emulates systems with MMUs properly
(they usually cheat by messing with the page tables on the host system or
not emulating the MMU at all (which they can get away with if the software
they want to run doesn't use the MMU)).

The very few exceptions would be academic projects that aren't associated
with the rest of the emulation world and private projects that you can
only find out about by knowing the people involved.

Oh, and BOCHS, which is a PC emulator capable of running Linux and
Windows. Having just poked through the source code looking for the MMU
support, I see that it does emulate the TLB.

> Thanks for any help!
>
> -jm

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net