> [ Sorry for the cross-post, but I wanted to make sure and catch everyone
>   running ports that can actually use this code.  --thorpej ]
> 
> This is mostly a heads-up/FYI...
> 
> In just a bit, I'm going to be committing code to the trunk of the NetBSD 
> source tree which implements binary compatibility with MID_M68K4K 
> executables (the type used by the hp300 port) on all m68k ports where 
> NBPG == 4096 (it's ... fairly difficult to make this work on ports where 
> NBPG == 8192, and it's not clear that it would be worth the effort...)

Feel free to tell me to shut up here... 8-).

I have been pursuing running Intel binaries on the PPC.  The way I do
this is to define an execution class loader for the Intel magic numbers
that loads an interpreter with the binary as an argument, in the same
way that ":\n" works to load /bin/sh as an interpreter for a shell
script.


The "interpreter" mmap's the image into the executable space, and handles
all processor page faults, etc., and translates the system calls for the
native system (this is a strong argument *against* register parameter
passing of system call arguments, per the Linux model, since it should
work across word size and endianess for various processor architectures
if you don't screw with the stack calling convention).

It seems to me that the page issues would be inre: data references, and
with a minor amount of hacking, you could set up two page mappings for
the process, and map references from the "expected address" through the
handler to simulate a 4k page boundry break.

This would mean taking an exception for each data page reference, but
it would also mean that the things would run.


Since you are not doing processor emulation, it seems to me that you
could establish the trap handler and the code mapping for the handler
pages at executable load time, and fall through to the normal code
mappings for the executable itself.

This is sort of the intended design for the ELF ld.so; the ELF ld.so
is expected to be mapped into the process address space by the executable
loader for the system (hence the large base offset in the SVR4 EABI
standard).  This means that there is not supposed to be any difference
between the crt0.o's for dynamically linked vs. statically linked ELF
binaries (again, Linux made errors in this area; they corrected one
error by moving the relocation address, but they still use the ld.so
to determine whether the binary is an SVR4 ELF binary or a Linux ELF
binary -- mistake).

It seems that this would be a workable method for supporting 4k "pages"
on 8k machines, and 8k "pages" on 4k machines, with not a lot of effort,
though with some overhead.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.