[gen] Generator 68000 emu bugs... testing against a real motorola
sunder at sunder.net
Tue Feb 24 13:08:39 GMT 2004
NeXTStep 3.3 won't allow me to directly modify data within text (code)
pages, so I wouldn't normally be able to do self modifying code, but there
is another way to do it:
I've added a few assembly functions to return pointers and offsets within
the assembly code function. Instead of calling asmtest directly, I do this:
1. alloc a chunk of RAM big enough to copy the whole function to.
2. copy the fn to the new space.
3. write the opcode to test over the NOP's
4. set a function pointer to the allocated memory
5. execute via the fn pointer.
There's still the issue of cache coherency, but I can get around this by
repeating the above steps, THEN freeing the previous chunk of RAM.
(By allocating a new block before freeing the old one I can guarantee that
malloc won't give me back the same space, which might still be cached by
the instruction cache with the old opcode.)
Thus, it is possible to do self modifying code on the MC68040. ;-D
(I'm not crazy about doing a lot of malloc/free cycles - I've seen problems
with this under some older stdlib's/OS's... if it becomes an issue, I'll
initially allocate a circular block of N function chunks, then rotate the
fn pointer through them...)
> Making a more efficient tester:
> I suppose that I could pad the opcode area I'm testing with say, 4 NOP's
> to provide enough padding for all opcodes, then get a pointer to the NOP
> area so that I could fill it with a new opcode to test. But, this
> causes cache coherency issues... Not an problem on the original 68000's,
> but anything above an 030 (maybe even 020?) will, according to the
> Motorola manuals, break.
> It might not even be at all possible as it depends on whether NeXTStep
> allows text pages to be modified. i.e. the OS might mark them as read
> only. (This is more likely of modern security conscious OS's, but
> possible for simplifying page/vm management.)
More information about the gen