[RFA:] Fix breakage of manually building SID CPU

[RFA:] Fix breakage of manually building SID CPU

[Hans-Peter Nilsson]

See dev.scm.  The recentlish (within the last years) enumeration
SID-SIMULATOR, split off from SIMULATOR, isn't handled in
dev.scm, causing the cload after load-sid to error.  It means my
how-to-repeat description for the SID-generator-problem with
cris.cpu at <URL:http://sourceware.org/ml/cgen/2004-q4/msg00015.html>
broke with the SID-SIMULATOR introduction.  I.e.:

(load "dev.scm")
(load-sid)
(cload #:arch "../../cpu/cris" #:options "with-scache" #:machs "crisv32")
(cgen-decode.cxx)

got, at the (cload ...):

Backtrace:
In dev.scm:
  84: 0  [error "unknown application:" SID-SIMULATOR]
  52: 1  (case APPLICATION ((UNKNOWN) (error "application not
loaded")) ...)
  33: 2  (let (# # # #) (letrec # #) (case APPLICATION # # ...))
In standard input:
   3: 3* [cload #:arch "../../cpu/cris" #:options "with-scache"
#:machs "crisv32"]

dev.scm:84:13: In procedure error in expression (error "unknown
application:" APPLICATION):
dev.scm:84:13: unknown application: SID-SIMULATOR
ABORT: (misc-error)

Which begs the question: how do people debug their new SID CPU
ports these days?

Maybe the fix is as simple as copying the SIMULATOR case?
A patch follows for that.  It works for the guile sequence
above.  With CGEN sources at the time of this writing, I no
longer get the error above or at the URL.  I haven't checked
whether the generated code is correct, though.

Ok to commit?

cgen:
	* dev.scm (cload) <SID-SIMULATOR>: New case, duplicated from
	SIMULATOR.

Index: dev.scm
===================================================================
RCS file: /cvs/src/src/cgen/dev.scm,v
retrieving revision 1.9
diff -p -u -r1.9 dev.scm
--- dev.scm	15 Jun 2005 21:28:18 -0000	1.9
+++ dev.scm	23 Jan 2006 03:28:55 -0000
@@ -76,6 +76,11 @@
 			     sim-init!
 			     sim-finish!
 			     sim-analyze!))
+      ((SID-SIMULATOR) (cpu-load (string-append "./cpu/" arch ".cpu")
+			     keep-mach keep-isa options
+			     sim-init!
+			     sim-finish!
+			     sim-analyze!))
       ((SIM-TEST) (cpu-load (string-append "./cpu/" arch ".cpu")
 			    keep-mach keep-isa options
 			    sim-test-init!

brgds, H-P

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

[Dave Brolley]

Hans-Peter Nilsson wrote:

>See dev.scm.  The recentlish (within the last years) enumeration
>SID-SIMULATOR, split off from SIMULATOR, isn't handled in
>dev.scm, causing the cload after load-sid to error.  It means my
>how-to-repeat description for the SID-generator-problem with
>cris.cpu at <URL:http://sourceware.org/ml/cgen/2004-q4/msg00015.html>
>broke with the SID-SIMULATOR introduction.  I.e.:
>
>  
>
>Which begs the question: how do people debug their new SID CPU
>ports these days?
>  
>
I generaly clone a similar port and go from there using the Makefiles.

>Maybe the fix is as simple as copying the SIMULATOR case?
>A patch follows for that.  It works for the guile sequence
>above.  With CGEN sources at the time of this writing, I no
>longer get the error above or at the URL.  I haven't checked
>whether the generated code is correct, though.
>
>Ok to commit?
>  
>
The patch looks ok to me. Please go ahead and commit it.

Dave

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

[Hans-Peter Nilsson]

> Date: Mon, 30 Jan 2006 12:21:20 -0500
> From: Dave Brolley <brolley@redhat.com>

> The patch looks ok to me. Please go ahead and commit it.

Finally done.

I must mention at least for the record that I see further errors
stopping generation of a SID cgen-cpu description with sources
as of today, for example the guile command sequence:

(load "dev.scm")
(load-sid)
(cload #:arch "../../cpu/cris" #:options "with-scache" #:machs "crisv32")
(cgen-semantics.cxx)

Gets:
... (seemingly successfully output C++ semantic translations.)
  return status;
#undef FLD
}

Processing semantics for bcc-b: "b${cc} ${o-pcrel}" ...

Backtrace:
In ./rtl-c.scm:
1400:  0* [string-append "(delay ...) rtx applied to wrong type of operand '" ...]
1398:  1  [context-error #f ...
1393:  2* (if (let # #) (context-error # #))
1387:  3  (let* (# # #) (if # #) (if # #) ...)
1385:  4  (case APPLICATION ((SID-SIMULATOR) (let* (# # #) (if # #) ...)) ...)
In unknown file:
   ?:  5  [#<procedure #f (estate options mode num-node ...)> #(# #) () DFLT ...]
In ./rtl-traverse.scm:
1019:  6  [apply #<procedure #f (estate options mode ...)> (#(# #) () DFLT ...)]
1018:  7  (if (procedure? fn) (apply fn (cons estate (cdr expr))) fn)
1017:  8  (if fn (if (procedure? fn) (apply fn (cons estate #)) fn) expr)
1015:  9  (let* ((rtx-obj #) (fn #)) (if fn (if # # fn) expr))
1013: 10  (if (pair? expr) (let* ((rtx-obj #) (fn #)) (if fn (if # # ...) ...)) ...)
In ./rtl-c.scm:
 434: 11* [rtx-eval-with-estate (delay () DFLT # ...) #(# #) #(# #)]
 434: 12  (let ((evald-src #)) (if (not #) (error assert-fail-msg #)) ...)
 417: 13  (cond ((c-expr? src) (cond # # ...)) ((rtx? src) (let # # ...)) ...)
 415: 14  (let ((mode #)) (cond (# #) (# #) (# #) ...))
 488: 15* [-rtl-c-get #(#("object" # #f ...) (# #f # ...)) DFLT ...]
 488: 16  (let (#) (if # #) result)
 870: 17* [rtl-c-get #(#("object" # #f ...) (# #f # ...)) DFLT ...]
 870: 18* [cx:c ...
 869: 19* [string-append "if (" "tmp_truthval" ")" " { " ...
 868: 20  [cx:make DFLT ...
    ...
In unknown file:
   ?: 21  [s-if #(#("object" # #f ...) (# #f # ...)) DFLT ...]
In ./rtl-c.scm:
1725: 22  [apply #<procedure s-if (estate mode cond then . else)> (# DFLT # #)]
In unknown file:
   ?: 23  [#<procedure #f (estate options mode cond ...)> #(# #) () DFLT ...]
In ./rtl-traverse.scm:
1019: 24  [apply #<procedure #f (estate options mode ...)> (#(# #) () DFLT ...)]
1018: 25  (if (procedure? fn) (apply fn (cons estate (cdr expr))) fn)
1017: 26  (if fn (if (procedure? fn) (apply fn (cons estate #)) fn) expr)
1015: 27  (let* ((rtx-obj #) (fn #)) (if fn (if # # fn) expr))
1013: 28  (if (pair? expr) (let* ((rtx-obj #) (fn #)) (if fn (if # # ...) ...)) ...)
In ./rtl-c.scm:
 307: 29* [rtx-eval-with-estate (if () DFLT # ...) #(# #) #(# #)]
 307: 30* [rtl-c-get #(# #) #(# #) ...
 307: 31  [cx:c ...
1206: 32* [rtl-c-with-estate #(# #) #(# #) (if () DFLT # ...)]
In unknown file:
   ?: 33* [#<procedure #f (e)> (if () DFLT ...)]
   ?: 34* [map #<procedure #f (e)> (# # # #)]
   ?: 35  [apply #<primitive-procedure map> (#<procedure #f (e)> (# # # #))]
In ./utils.scm:
  96: 36* [apply #<primitive-procedure map> (#<procedure #f (e)> (# # # #))]
  96: 37  [apply #<primitive-procedure string-append> ...
In ./rtl-c.scm:
1205: 38* [string-map #<procedure #f (e)> (# # # #)]
1197: 39* [string-append "{ " "  BI tmp_truthval; " ...
1196: 40  [cx:make DFLT ...
    ...
In unknown file:
   ?: 41  [s-sequence #(#("object" # #f ...) (# #f # ...)) DFLT ...]
In ./rtl-c.scm:
1741: 42  [apply #<procedure s-sequence (estate mode env . exprs)> (# DFLT # # ...)]
In unknown file:
   ?: 43  [#<procedure #f (estate options mode locals ...)> #(# #) () DFLT ...]
In ./rtl-traverse.scm:
1019: 44  [apply #<procedure #f (estate options mode ...)> (#(# #) () DFLT ...)]
1018: 45  (if (procedure? fn) (apply fn (cons estate (cdr expr))) fn)
1017: 46  (if fn (if (procedure? fn) (apply fn (cons estate #)) fn) expr)
1015: 47  (let* ((rtx-obj #) (fn #)) (if fn (if # # fn) expr))
1013: 48  (if (pair? expr) (let* ((rtx-obj #) (fn #)) (if fn (if # # ...) ...)) ...)
In ./rtl-c.scm:
 307: 49* [rtx-eval-with-estate (sequence () DFLT # ...) #(# #) #(# #)]
 307: 50* [rtl-c-get #(# #) #(# #) ...
 307: 51  [cx:c ...
 383: 52  [rtl-c-with-estate #(# #) #(# #) (sequence () DFLT # ...)]
 382: 53  (let ((estate #)) (rtl-c-with-estate estate mode x))
In ./sid-cpu.scm:
 707: 54  [rtl-c++-parsed #(# #) (sequence () DFLT # ...) () ...]
 706: 55* (if (insn-compiled-semantics insn) (rtl-c++-parsed VOID # ...) ...)
 705: 56  (let ((sem-c-code (if # # #))) sem-c-code)
 749: 57* [gen-semantic-code #(#("object" # bcc-b ...) (# #f # ...))]
 725: 58  [list "// ********** " bcc-b ... ...
 723: 59  (let (# #) (string-list "// ********** " # ": " ...))
In ./utils.scm:
 425: 60* [-gen-scache-semantic-fn #(#("object" # bcc-b ...) (# #f # ...))]
 425: 61* [-string-write #(print-state 0) ...
In unknown file:
   ?: 62* [#<procedure #f (arg)> #(#("object" # bcc-b ...) (# #f # ...))]
In ./utils.scm:
 425: 63  [for-each #<procedure #f (arg)> (#(# #) #(# #) #(# #) #(# #) ...)]
 424: 64* (let ((pstate -current-print-state)) (for-each (lambda # #) arglist))
In ./sid-cpu.scm:
 766: 65  [string-write-map #<procedure -gen-scache-semantic-fn (insn)> (# # # ...)]
 765: 66  (if (with-scache?) (string-write-map -gen-scache-semantic-fn insns) ...)
 764: 67  (let (#) (if # # #))
In ./utils.scm:
 414: 68* [-gen-all-semantic-fns]
 414: 69  [-string-write #(print-state 0) ...
 412: 70* (cond ((string? expr) (display expr)) ((symbol? expr) (display expr)) ...)
 403: 71* [-string-write #(print-state 0) #<procedure -gen-all-semantic-fns ()>]
In unknown file:
   ?: 72* [#<procedure #f (elm)> #<procedure -gen-all-semantic-fns ()>]
In ./utils.scm:
 403: 73* [for-each #<procedure #f #> #]
 401: 74  (let ((pstate (make-print-state))) (set! -current-print-state pstate) ...)
In ./sid-cpu.scm:
 802: 75  [string-write "#define GET_ATTR(name) GET_ATTR_##name ()   " ...]
In standard input:
   4: 76* [cgen-semantics.cxx]

./rtl-c.scm:1400:15: In procedure string-append in expression (string-append "(delay ...) rtx applied to wrong type of operand '"\
 (car rtx) ...):
./rtl-c.scm:1400:15: Wrong type argument (expecting STRINGP): set
ABORT: (wrong-type-arg)

Similar error when substituting #:machs "crisv10" on the cload
line, but then the first line reads:

Processing semantics for ret-type: "ret/reti/retb" ...

(i.e. the earliest occurrence of "delay" for the enabled mach).
I guessed this could be related to some change in delay
semantics, but the usage in cris.cpu seems no different to other
*.cpu.  Except that some *.cpu use (delay (const 1) ...) instead
of (delay 1 ...) but unfortunately that doesn't help; changing
that doesn't affect the behavior.

brgds, H-P

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

[Dave Brolley]

Hans-Peter Nilsson wrote:

>(i.e. the earliest occurrence of "delay" for the enabled mach).
>I guessed this could be related to some change in delay
>semantics, but the usage in cris.cpu seems no different to other
>*.cpu.  Except that some *.cpu use (delay (const 1) ...) instead
>of (delay 1 ...) but unfortunately that doesn't help; changing
>that doesn't affect the behavior.
>
>  
>
(delay 1 ...) vs (delay (const 1) ...) won't make a difference. They are 
identical.

However, It seems that CGEN generating SID expects a different syntax 
for delay than CGEN generating SIM.

CGEN generating sid expects

    (set (delay 1 pc) retaddr)

while CGEN generating SIM expects

    (delay 1 (set pc retaddr))

I do recall the new syntax being introduced some time ago, however, I 
don't recall that the old syntax was depricated. Does anyone know if 
both are still supposed to work?

Dave

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

[Hans-Peter Nilsson]

> Date: Tue, 14 Mar 2006 11:46:45 -0500
> From: Dave Brolley <brolley@redhat.com>

> However, It seems that CGEN generating SID expects a different syntax 
> for delay than CGEN generating SIM.
> 
> CGEN generating sid expects
> 
>     (set (delay 1 pc) retaddr)
> 
> while CGEN generating SIM expects
> 
>     (delay 1 (set pc retaddr))
> 
> I do recall the new syntax being introduced some time ago, however, I 
> don't recall that the old syntax was depricated. Does anyone know if 
> both are still supposed to work?

FWIW, the "new syntax" didn't catch my eye as I saw only
src/cpu/mt.cpu using it; none in src/cgen/cpu.  Maybe some wart
was introduced in whatever compatibility there is.

brgds, H-P

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

[Frank Ch. Eigler]

Hi -

> >(i.e. the earliest occurrence of "delay" for the enabled mach).
> >I guessed this could be related to some change in delay
> >semantics, but the usage in cris.cpu seems no different to other
> >*.cpu.  [...]

I believe (delay) was never implemented properly for the SIM backend,
only for SID.  I expect it to be treated rather like a no-op for SIM,
or equivalently, that any SIM-targeting .cpu users of (delay) should
work just as well without.

- FChE

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

[Hans-Peter Nilsson]

> Date: Tue, 14 Mar 2006 12:16:55 -0500
> From: "Frank Ch. Eigler" <fche@redhat.com>

> > >(i.e. the earliest occurrence of "delay" for the enabled mach).
> > >I guessed this could be related to some change in delay
> > >semantics, but the usage in cris.cpu seems no different to other
> > >*.cpu.  [...]
> 
> I believe (delay) was never implemented properly for the SIM backend,
> only for SID.  I expect it to be treated rather like a no-op for SIM,
> or equivalently, that any SIM-targeting .cpu users of (delay) should
> work just as well without.

Um, what (delay) are you referring to above?
A (delay 1 (set pc something)) certainly is different
to (set pc something).

I now think it's the cris.cpu pc setter function that may have
something that causes the SID cgen-cpu generators to barf.

brgds, H-P

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

[Dave Brolley]

Hans-Peter Nilsson wrote:

>>Date: Tue, 14 Mar 2006 12:16:55 -0500
>>From: "Frank Ch. Eigler" <fche@redhat.com>
>>    
>>
>>I believe (delay) was never implemented properly for the SIM backend,
>>only for SID.  I expect it to be treated rather like a no-op for SIM,
>>or equivalently, that any SIM-targeting .cpu users of (delay) should
>>work just as well without.
>>    
>>
>
>Um, what (delay) are you referring to above?
>A (delay 1 (set pc something)) certainly is different
>to (set pc something).
>
>I now think it's the cris.cpu pc setter function that may have
>something that causes the SID cgen-cpu generators to barf.
>
>  
>
(delay 1 (set pc something))

was already implemented and working for SIM (fr30 uses it). It appears that

(set (delay 1 pc) something)

was only implemtned for SID. Furthermore, SIM now only accepts the 
former and SID only accepts the latter, making it difficult 
(impossible?) to share a .cpu file for both back ends.

Dave

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

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Hi -

> [...]
> (delay 1 (set pc something))
> was already implemented and working for SIM (fr30 uses it). [...]

I'm curious how exactly that works.  fr30 isn't in src/sim/ at the
moment, is it?

> (set (delay 1 pc) something)
> was only implemtned for SID. 

I recall now that when we built support for a nasty open-pipelined
machine, this notational change made sense, since it was only register
sets that were "delayable", not general RTL expressions.

> Furthermore, SIM now only accepts the former and SID only accepts
> the latter, making it difficult (impossible?) to share a .cpu file
> for both back ends.

That's true.

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Dave Brolley]

Frank Ch. Eigler wrote:

>Hi -
>
>  
>
>>[...]
>>(delay 1 (set pc something))
>>was already implemented and working for SIM (fr30 uses it). [...]
>>    
>>
>
>I'm curious how exactly that works.  fr30 isn't in src/sim/ at the
>moment, is it?
>  
>
Oh yes, that's right it was removed. However, I can attest to the fact 
that it *did* work. Looks like Peter has found other ports that use it 
as well.

Dave

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

[Hans-Peter Nilsson]

> Date: Tue, 14 Mar 2006 17:48:43 -0500
> From: "Frank Ch. Eigler" <fche@redhat.com>

> > (delay 1 (set pc something))
> > was already implemented and working for SIM (fr30 uses it). [...]
> 
> I'm curious how exactly that works.  fr30 isn't in src/sim/ at the
> moment, is it?

Not sure what you mean by "exactly", but it works.  Even as per
the documentation!  See src/sim/cris and src/cpu/cris.cpu.

> > (set (delay 1 pc) something)
> > was only implemtned for SID.
> 
> I recall now that when we built support for a nasty open-pipelined
> machine, this notational change made sense, since it was only register
> sets that were "delayable", not general RTL expressions.

Judging from the documentation, I guess the "only" refers to the
CGEN-SID delay support.  If the latter, I don't mind very much
changing the port, if there can be sim support as well (Someone
writing it, or perhaps Someone handholding me through
implementing it), or (worse) some test-conditional applicable
for defining a pmacro with differing contents (see
src/cpu/mt.cpu:dset).

brgds, H-P

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

[Hans-Peter Nilsson]

> Date: Wed, 15 Mar 2006 01:20:06 +0100
> From: Hans-Peter Nilsson <hp@axis.com>
> > Date: Tue, 14 Mar 2006 17:48:43 -0500
> > From: "Frank Ch. Eigler" <fche@redhat.com>
> 
> > > (delay 1 (set pc something))
> > > was already implemented and working for SIM (fr30 uses it). [...]

(FWIW, it certainly worked for SID too, some time ago.)

> > > (set (delay 1 pc) something)
> > > was only implemtned for SID.
> > 
> > I recall now that when we built support for a nasty open-pipelined
> > machine, this notational change made sense, since it was only register
> > sets that were "delayable", not general RTL expressions.
> 
> Judging from the documentation, I guess the "only" refers to the
> CGEN-SID delay support.  If the latter, I don't mind very much
> changing the port, if there can be sim support as well

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?  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?

Index: cris.cpu
===================================================================
RCS file: /cvs/src/src/cpu/cris.cpu,v
retrieving revision 1.5
diff -p -u -r1.5 cris.cpu
--- cris.cpu	6 Dec 2005 21:48:28 -0000	1.5
+++ cris.cpu	15 Mar 2006 01:01:25 -0000
@@ -306,6 +306,8 @@
 	((Pd INT -1)) ())
 )
 
+(define-pmacro (dset dest src) (set (delay 1 dest) src))
+
 (define-pmacro (crisv32-timing-destreg d)
   "Timing for instructions running on a crisv32 model"
   ((crisv32
@@ -2629,7 +2631,7 @@
    ((SI retaddr))
    (set retaddr Ps)
    (reset-x-p)
-   (delay 1 (set pc retaddr)))
+   (dset pc retaddr))
 )
 
 ; MOVE    [Rs],Pd         [ Pd | 10100011 | Rs ]
@@ -3991,8 +3993,7 @@
 
    (reset-x-p)
    (if truthval
-       (delay 1
-	      (set pc o-pcrel))))
+       (dset pc o-pcrel)))
  (.splice (.unsplice (simplecris-timing))
 	  (crisv32 (unit u-branch) (unit u-exec)))
 )
@@ -4004,8 +4005,7 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (set pc o-pcrel)))
+   (dset pc o-pcrel))
  ((crisv32 (unit u-jump) (unit u-exec)))
 )
 
@@ -4028,8 +4028,7 @@
 
    (reset-x-p)
    (if truthval
-       (delay 1
-	      (set pc o-word-pcrel))))
+       (dset pc o-word-pcrel)))
  (.splice
   (.unsplice (simplecris-common-timing ((unit u-const16) (unit u-exec))))
   (crisv32 (unit u-const16) (unit u-branch) (unit u-exec)))
@@ -4042,8 +4041,7 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (set pc o-word-pcrel)))
+   (dset pc o-word-pcrel))
  (.splice
   (.unsplice (simplecris-common-timing ((unit u-const16) (unit u-exec))))
   (crisv32 (unit u-const16) (unit u-jump) (unit u-exec)))
@@ -4063,11 +4061,8 @@
        ; used in the v32 trampoline.  See comment at bdapqpc.
        ; CGEN-FIXME: can't use (regno srp) [== (regno (reg h-sr 11))]
        (c-call VOID "cris_flush_simulator_decode_cache" pc))
-   (delay 1
-	  (sequence
-	    ()
-	    (set Pd (add SI pc 4))
-	    (set pc Rs))))
+   (dset Pd (add SI pc 4))
+   (dset pc Rs))
  ((crisv32 (unit u-jump-r) (unit u-jump) (unit u-exec)))
 )
 ; Same semantics in pre-V32, except no delay-slot.
@@ -4093,11 +4088,8 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (sequence
-	    ()
-	    (set Pd (add SI pc 8))
-	    (set pc const32))))
+   (dset Pd (add SI pc 8))
+   (dset pc const32))
  ((crisv32 (unit u-const32) (unit u-jump) (unit u-exec)))
 )
 
@@ -4134,8 +4126,7 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (set pc Ps)))
+   (dset pc Ps))
  ((crisv32 (unit u-jump-sr)
 	   (unit u-exec)))
 )
@@ -4149,11 +4140,8 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (sequence
-	    ()
-	    (set Pd (add SI pc 8))
-	    (set pc const32-pcrel))))
+   (dset Pd (add SI pc 8))
+   (dset pc const32-pcrel))
  ((crisv32 (unit u-const32) (unit u-jump) (unit u-exec)))
 )
 
@@ -4166,11 +4154,8 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (sequence
-	    ()
-	    (set Pd (add SI pc 8))
-	    (set pc Rs))))
+   (dset Pd (add SI pc 8))
+   (dset pc Rs))
  ((crisv32 (unit u-jump-r) (unit u-skip4) (unit u-jump) (unit u-exec)))
 )
 
@@ -4183,11 +4168,8 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (sequence
-	    ()
-	    (set Pd (add SI pc 12))
-	    (set pc const32))))
+   (dset Pd (add SI pc 12))
+   (dset pc const32))
  ((crisv32 (unit u-const32) (unit u-skip4) (unit u-jump) (unit u-exec)))
 )
 
@@ -4200,11 +4182,8 @@
  (sequence
    ()
    (reset-x-p)
-   (delay 1
-	  (sequence
-	    ()
-	    (set Pd (add SI pc 12))
-	    (set pc const32-pcrel))))
+   (dset Pd (add SI pc 12))
+   (dset pc const32-pcrel))
  ((crisv32 (unit u-const32) (unit u-skip4) (unit u-jump) (unit u-exec)))
 )
 

brgds, H-P

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

[Dave Brolley]

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

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

[Doug Evans]

Dave Brolley writes:
 > >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.

What dictionary are you looking in? :-)

 > The "new" delay implementation [...].
 > [...]
 > I think that if both can be supported then that would be "a good thing 
 > (tm)".

Both what?  Maybe you can elaborate on why both are needed
at the rtl level? [I'm thinking in language terms, not implementation.]

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

[Dave Brolley]

Doug Evans wrote:

>Dave Brolley writes:
> > >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.
>
>What dictionary are you looking in? :-)
>  
>
For the record, I agree with you that it's a s-t-r-e-t-c-h.

> > The "new" delay implementation [...].
> > [...]
> > I think that if both can be supported then that would be "a good thing 
> > (tm)".
>
>Both what?  Maybe you can elaborate on why both are needed
>at the rtl level? [I'm thinking in language terms, not implementation.]
>  
>
They're not both needed in language terms. Everything can be done using 
the "new" implementation. I was just thinking that the "old" should 
still work for legacy code.

Dave

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

[Hans-Peter Nilsson]

> Date: Wed, 15 Mar 2006 12:07:57 -0500
> From: Dave Brolley <brolley@redhat.com>

> >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.

But it's not.  A delayed branch doesn't (necessarily or usually)
run in parallel with the delayed instruction or the one after
the delayed one.

brgds, H-P

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

[Dave Brolley]

Hans-Peter Nilsson wrote:

>But it's not.  A delayed branch doesn't (necessarily or usually)
>run in parallel with the delayed instruction or the one after
>the delayed one.
>
>  
>
Hence the s-t-r-e-t-c-h??  :-)

FWIW, in case anyone is wondering, I didn't invent or implement this 
feature but I am using it.

Dave

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

[Frank Ch. Eigler]

Hi -

> But it's not.  A delayed branch doesn't (necessarily or usually)
> run in parallel with the delayed instruction or the one after
> the delayed one.

One could sort of consider the delayed update to PC running in
parallel with the next instruction, sort of.  I don't recall all
aspects of the design/notational decisions now.  The work was
certainly done for a processor that was "worst" of all worlds in terms
of VLIW and open pipelines.  Association with the cpu "parallel" field
may have been for simplicity, using that as a mode selector instead of
searching through the entire rtl for occurrences of (delay).

See also: http://sourceware.org/ml/cgen/2003-q1/msg00004.html

- FChE