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

[Dave Brolley <brolley@redhat.com>]

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