Subversion Repositories or1k

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"