124 lines
2.4 KiB
Plaintext
124 lines
2.4 KiB
Plaintext
|
ChangeLog
|
||
|
|
||
|
See the ChangeLog file looking for lines taged with the word FIXME.
|
||
|
|
||
|
|
||
|
COREFILE.C:
|
||
|
|
||
|
The implementation of corefile.c (defined by corefile.h) isn't the
|
||
|
best. It is intended to be functionaly correct rather than fast. One
|
||
|
option being considered is to add a data cache to reduce the overhead
|
||
|
of the most common case of data read/writes.
|
||
|
|
||
|
|
||
|
VEA:
|
||
|
|
||
|
Missing VEA system calls.
|
||
|
|
||
|
ppc-instructions:
|
||
|
|
||
|
Missing or commented out instructions.
|
||
|
|
||
|
|
||
|
64bit:
|
||
|
|
||
|
64bit target untested. 64bit host broken. For instance use of scanf
|
||
|
"%x", &long long.
|
||
|
|
||
|
|
||
|
|
||
|
hw_*.c:
|
||
|
|
||
|
Better and more devices.
|
||
|
|
||
|
PORTABILITY:
|
||
|
|
||
|
(Notes taken from Michael Meissner): Heavy use of the ## operator -
|
||
|
fix using the clasic X/**/Y hack; Use of the signed keyword. In
|
||
|
particular, signed char has no analogue in classic C (though most
|
||
|
implementations of classic C use signed chars); Use of long long which
|
||
|
restricts the target compiler to be GCC.
|
||
|
|
||
|
|
||
|
TRACING:
|
||
|
|
||
|
debug.c: Macro's should be extended to include:
|
||
|
|
||
|
IS_*TRACE: True if tracing enabled
|
||
|
*TRACE_PREFIX: Outputs just the prefix line
|
||
|
|
||
|
hw_trace.c: Flush, replace with a psim_set_tracing or some
|
||
|
such program.
|
||
|
|
||
|
|
||
|
CIA/NIA:
|
||
|
|
||
|
Replace with functions to return/increment the CIA?
|
||
|
|
||
|
|
||
|
|
||
|
SMP & GDB:
|
||
|
|
||
|
GDB doesn't understand SMP!
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
OVERALL STRUCTURE:
|
||
|
|
||
|
A new file pstruct.h is to be created that contains a single flat data
|
||
|
structure containing:
|
||
|
|
||
|
pstruct {
|
||
|
events;
|
||
|
core;
|
||
|
processor[nr_cpus];
|
||
|
monitor;
|
||
|
devices;
|
||
|
trace;
|
||
|
}
|
||
|
|
||
|
The CPU's structure, in turn would contain the VM sub structures.
|
||
|
|
||
|
When SMP==0, everything would have PSTRUCT passed. In SMP mode,
|
||
|
however, there are two choices: PSTRUCT + CPU_NR or PROCESSOR. I
|
||
|
suspect the latter is better.
|
||
|
|
||
|
It is believed that this would significantly improve performance (at
|
||
|
the price of reduced control over object scope).
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
IGEN:
|
||
|
|
||
|
Igen at present can't do the following:
|
||
|
|
||
|
o duplication is an all or nothing afair.
|
||
|
|
||
|
It should be configurable according to
|
||
|
the instruction or the sub-table.
|
||
|
|
||
|
|
||
|
o Due to the naming, only a single generated
|
||
|
simulator can be included in a program.
|
||
|
|
||
|
IGEN should be able to generate multiple
|
||
|
engines that can all be included in a program
|
||
|
|
||
|
o handle alternate architectures.
|
||
|
|
||
|
|
||
|
o Igen should support the generation of a
|
||
|
disasembler and posibly an assembler.
|
||
|
|
||
|
I suggest that the table be extended to
|
||
|
include, for each instruction, additional
|
||
|
lines describing the extual format of the
|
||
|
instruction.
|
||
|
|
||
|
One possible format is:
|
||
|
|
||
|
"mtlr %RS":SPR.something
|
||
|
"mtspr %SPR, %RS"
|