This is the mail archive of the cgen@sourceware.org mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA:] Fix breakage of manually building SID CPU


Hans-Peter Nilsson wrote:

Seems the implementation has introduced a false assumption.
Changing the cris.cpu file with the patch below and retrying as
per previous description I sent, results in:

./utils-cgen.scm:167:15: In procedure error in expression (apply error (cons # arg)):
./utils-cgen.scm:167:15: delayed operand in a non-parallel cpu:
ABORT: (misc-error)

So, uh, why would only parallel CPUs have delay-slots?  Or do we
actually have differing perceptions and definitions of what a
"delay" is?

It's more of an extension of the notion of what parallel is. The "new" delay implementation (SID only) thinks of a delay as something to be done later, in parallel with something else. I seem to recall that it was intended that delay could be used to implement

1) exposed pipelines
2) delay slots
3) VLIW parallelism

It looks like there are no examples of ports which use the "new" delay in the public sources. To make it work, you will need to:

1) Add (parallel-insns 2) to your define-isa to make the error above go away.
2) Generate write.cxx since the "new" delay uses the write stacks which are generated there.
3) Declare '%cpu%::write_stacks' in your cpu class
4) Declare 'int tick' in your cpu class
5) Add 'write_stacks.reset (); tick = 0;' to your %cpu%::reset () method
6) Add the following to %cpu%::step_insns after executing the insn (and catching any exceptions) and before checking for triggerpoints:


     // Execute writeback
     try {
       write_stacks.writeback (tick, this);
     }
     catch (cpu_memory_fault& t)
       {
         this->memory_trap (t);
       }
     catch (cpu_exception& t)
       {
         this->yield ();
       }

     // move ahead thru circular pipeline
     tick = (tick + 1) % %cpu%::pipe_sz;

Supposing that those definitions are mergeable,
would it be ok to put back support for the "old" definition in
SID-CGEN? If not, what can be done?


I think that if both can be supported then that would be "a good thing (tm)".

Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]