[LispM-Hackers] Outageness

[John Morrison]

Hi;

ford@objs.com wrote:
> Paul knows this stuff much better than I, but I can confirm assumptions #1 & #3.
> I'm not sure about #2.  There was quite a bit of work on the boot process to
> speed things up.  For instance, I don't think most of the pages were copied
> from the band into memory until they were touched.

Thanks for the tips.

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.

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).

Then, hopefully, I could just play some stunts with the page tables so
that I don't have to blit stuff around.  Unfortunately, it's been over a
year since I hacked e3 at this level, so my recollection of the Explorer
page table stuff is fading, and it's been well over 2 years since I got
the Java OS stuff working at the bare x86 iron level, so that memory has
faded entirely.

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.

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?

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?  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?

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?

Thanks for any help!

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@mak.com