The problem mmap(2) runs into is that the only way to get the remappable memory is to use /proc/self/mem. You can't just mmap the rom, because the alignment is all wrong, and you can't just keep remapping portions of /dev/zero, since they won't point at the same stuff.

You can't use SysV shm for it, as those aren't mmap(2)'able.

The last time someone tried this trick on BSD, it failed most spectacularly -- I suspect /proc/self/mem isn't mmap()'able there.

I haven't checked it terribly recently (about a year ago IIRC), but the posix shm API works close enough to the spec for things to do the Right Thing under linux. The biggest setback was the complete lack of documentation mentioning librt.so.

As for why it didn't just use a pointer table, the idea was to remove as much of the overhead as possible, partly just to see if I could. If you sacrifice a few rarely used capabilities (executing from register space mostly) you completely remove any memory range checks from the instruction fetch path. It isn't dynarec, but it's several orders of magnitude simpler.

The segv approach would be highly dependent on the access pattern and signal overhead -- on the upside, the kernel doesn't do a whole lot on that one. It'd be a tradeoff like most tricks, if register read/writes outnumber non-register read/writes by too much it loses. Cases like that Nina-1 would probably still be best handled by a handler, though it'd be the only one in the list, and then only for writes.

I may get around to running some tests to find out exactly how long it takes to deliver a segv signal, but it does have the potential to speed the core up a fair bit when you take into account the fact that the memory read/write path would not have any jumps. Even with a Nina-1 handler, that would be one predictable jump, as opposed to the usual tree of rather unpredictable jumps, or one completely unpredictable indirect jump.

Admittedly, for the 6502, this is overkill for overkill's sake. On the other hand, the x86 has to do all of the protection checks on every access anyways, why not use 'em? =)