This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
Re: [RFA:] Fix breakage of manually building SID CPU
- From: Dave Brolley <brolley at redhat dot com>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: cgen at sourceware dot org
- Date: Wed, 15 Mar 2006 12:07:57 -0500
- Subject: Re: [RFA:] Fix breakage of manually building SID CPU
- References: <200603150124.k2F1O5Rk014471@ignucius.se.axis.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