blob: 300c79120ce5a3914253f947d724bbc5aed6e4fc (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
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.
powerpc.igen:
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"
|
