ammended COPROC REGS function to use new spec system. FPU registers
display formatted values
removed RegisterStatus() function for now. the ARM status register is
more complex in reality than how I've modelled it (CSPR vs ASPR and and
an ESPR in some models). the information is there but not in a coherent
way. probably requires adding a status register group
previously I was using the composite member size and adjusting the
address accordingly. this is wrong however and doesn't take into account
the alignment required by the processor
the correct method is to use the Member Location attribute to offset
from the base address of the composite
this called in the same way as the corresponding functions in the
television and reflection packages
list of locals is updated when emulation is paused. this allows the list
of locals to be visible immediately on program start and when execution
is halted in the VCS part of the execution (as opposed to yielding in
the ARM part of the execution due to a breakpoint)
fixed race condition caused by local variable window
lexical scope is used to decide if the variable is present in the list.
while this might not be completely accurate in all instances it presents
a more natural view. in any case, the value of the variable won't be
wrong because it isn't locatable
stipulated that the coprocessor takes extended register values in the
Register() and SetRegister() functions. extended register check in
coprocessor implementation (ie. ARM)
"ROM Setup" is too confusing a state to be useful. Initialisation, based
on the current emulation state, might be more helpful but it fails for
the same reason as "ROM Setup" (which was based on screen stability) in
that it doesn't really fit in with the current method of keeping
profiling statistics
renamed KernelVCS (from profiling package) to Focus. this better
describes what the intention of the type is
renamed Performance window to Profiling
renamed references to illegal accesses to faults. the new name is
simpler and more flexible
faults locking was already independent of source lock
single MemoryFault() function in coproc developer interface
simplified faults window
because of how we have implemented branches we need special
consideration for breakpoints afterwards. the branch instruction will
have altered the PC and adjusted it for the pipeline fill (cycle
accumulation for the pipeline fill is handle indpendently). because of
that we need to test for a breakpoint for the PC before the pipeline
fill
