bfd macro conversion to inline functions
[deliverable/binutils-gdb.git] / sim / ppc / BUGS
index 81e7870b88541ad1f157e7ba3c7784e7d35f10df..362b079e90c9144723795c2ed0d5c1670dae94ee 100644 (file)
@@ -2,6 +2,7 @@ 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
@@ -9,7 +10,8 @@ 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
+
+VEA:
 
 Missing VEA system calls.
 
@@ -17,15 +19,13 @@ ppc-instructions:
 
 Missing or commented out instructions.
 
+
 64bit:
 
 64bit target untested. 64bit host broken.  For instance use of scanf
 "%x", &long long.
 
-events.c:
 
-Event code for pending events from within signal handlers not
-finished/tested.
 
 hw_*.c:
 
@@ -40,8 +40,84 @@ implementations of classic C use signed chars); Use of long long which
 restricts the target compiler to be GCC.
 
 
-device_ioctl():
+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.
 
-Should have an extra argument (unsigned request) as standard.
+               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"
This page took 0.02574 seconds and 4 git commands to generate.