Hi mailing-list people,

For my final-year Computer Science course project, I have decided to write a
dynamically-recompiling ARM emulator for the x86 platform, which I guess
some of you might find interesting. Ideally, I would like to be able to
test binaries (nothing complicated, just "hello world", dhrystone, etc.)
on a real ARM processor (I have a StrongARM Risc PC currently running
NetBSD/arm32 v1.4.1), before testing them on the emulator (on a second
machine running Linux/x86). I don't want to emulate an entire machine if I
can help it (at least not at the start of the project), so any system calls
(eg, I/O stuff) will be faked by the emulator. At the moment I have most of
a standard (non-recompiling) emulator written, and I'm ready for some
extensive testing of what I've done so far.

OK, so why am I telling you this? I'd just like to confirm a couple of
things about NetBSD internals:

 * Firstly, should there be any problems in loading statically-linked
binaries (a.out) at a fixed address in memory (0x1000) then jumping directly
into the entry point? (ie, will I have to do any link editing?)

 * What values should registers hold on entry to programs - need anything
other than the stack pointer and program counter be valid? At the moment, I
just set r13 to 2Mb and go, which seems to *almost* work.

 * As I understand various bits of the code, system calls are implemented
as equivalently-numbered SWIs. As in APCS, r0-r3 hold the first four
arguments to system calls, with the remainder on the stack if necessary.
SWI zero is a special case for calling a general system call, with r0
holding the system call number and r1-r3 holding the first three arguments
to that system call and the remainder on the stack if necessary. r0 and r1
hold return values on exit from the calling SWI. Is all this correct, or
have I misunderstood something?

 * Is this sort of thing documented anywhere other than in the source code?
I've not looked very hard, admittedly, I've just assumed it isn't :-/.

The current state of play is that "Hello world" (with puts()) gets about as
far as trying to register an atexit handler, then infinite-loops somewhere
in the malloc code. I hope this is due to minor bugs rather than fatal
flaws...

Thanks for any help or advice you may have to offer,

Julian

-- 
Julian Brown, Queens' College Cambridge