From: john/lori (lgnjh_at_earthlink.net)
Date: 2005-04-23 17:56:17
Jim Brain wrote: > It gets worse. The opcode in question could have updated an internal > register: > > $67ff and #$10 > > 67ff (and) gets pulled. > > $6800 is page fault, so force 0. Uh oh, as now .A is corrupt, and there > is no way to reset it. > > The only real way to do this is not allow such things to occur. Scan > incoming code at page boundaries to insert BRK opcodes to handle such > issues before you step into them. Or, ensure code that runs in your > system does not create such issues. > > Jim There have been schemes (or so I've read) that run a slave processor in parallel to make internal stuff available that would not otherwise be available How about running a slave processor but let it lag by one instruction and take the internal stuff from it when your hardware throws an exception? Of course the devil is in the details (I'm imagining feeding the slave bytes through an fifo) The timing and/or hardware might get hairy, but I don't see a problem in principle (just off the top of my head), except being sure the slave behaved identically (eg. bug fixes or different behavior with undocumented "opcodes") Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.