> I was pondering some of the "build lab" problems, and it occurred to me
> that while cross-compiling is nice, it would be nicer to run native
> compilers for the slow ports (such as sun3 and vax).  But of course
> you'd really like to run them on fast hardware.

I'm really interested in this for a variety of reasons:

    1. You can prototype new CPU instruction sets and toolchains on real-
	world application code, just by tweaking the toolchain and emulator.
	(Were I a semiconductor vendor, I would pay REAL money to have this.)
    2. If it can be made compatible with the foreign O/S emulations, it
	opens up the possibility of Linux or FreeBSD emulation on all arches
	(nothing wrong with emulating FreeBSD/i386 on VAX, if it means a
	reliable netscape!!).
    3. It lets multi-arch networks of machines all run the same binaries
	and userland environment (via chroot and NFS magic) for parallel
	processing purposes. (Like building pkgsrc with -j99 ...)
    4. Sick as it sounds, this has one advantage over real cross-builds in
	that it perfectly emulates the installation of binaries on top of
	a running system. Of course it is debatable whether this can really
	be called an advantage.

Once the emulators get sophisticated enough to do dynamic recompilation,
this technology becomes much more interesting. I've worked on interpretive
emulators in past jobs and mused about this sort of thing for quite some
time.

> I was thinking of doing this as an emulation package in the kernel,

Yeah. Note that on at least m68k/i386 there is floating point emulation
code in the kernel, and on i386 it could really use some work. (Maybe soon
I will get back on that, ahem ahem)

> (a) Emulating the instructions
> (b) Emulating failure modes
> (c) Emulating syscalls
> (d) Getting it started

Don't forget signal delivery, and debugging would be good to have eventually.

Todd Whitesel
toddpw @ best.com