Confusion: setup-semantics? PC not updated? Immediate operands?

Confusion: setup-semantics? PC not updated? Immediate operands?

[Hans-Peter Nilsson]

Hm, I can't get anything out from setup-semantics in a
define-isa, like (example only):

(define-isa
  (name cris)
  (base-insn-bitsize 16)
  (default-insn-word-bitsize 16)
  (liw-insns 1)
  (parallel-insns 1)
  (setup-semantics
   (error "Nothing happens"))
)

This when generating that big GCC-specific C switch
<arch>-switch.c, which seems generated from sim-cpu.scm.  From
what little scheme I understand (I'm blissfully naive), it seems
only sid-cpu.scm, not sim-cpu.scm, supports setup-semantics.
I'd use it for purposes similar to that of arm.cpu.
Should it work?

On a related matter, it seems pc isn't updated for non-CTI
insns; it's value is that of the first insn in the chain.
I need it as an operand in non-CTI insns.

Oh right, there's a further related issue in the pipeline: how
do I best specify 16-bit and 32-bit immediate operands?  The
immediate value is coded as indirect-pc-postincrement, "[pc+]",
where pc is mapped as one of the 16 general registers.  I'm
currently hacking the update of pc in sim/cris/mloop.in in the
case for "xextract-pbb" (based on fr30/mloop.in).  I guess it's
best to have a specific case for the "[pc+]" operand (leaving
cases for other registers in a generally specified insn), but I
need to at least tell CGEN to skip two or four bytes.  I just
can't see where to specify that.

brgds, H-P

Re: Confusion: setup-semantics? PC not updated? Immediate operands?

[Ben Elliston]

H-P,

>>>>> "Hans-Peter" == Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:

  Hans-Peter> This when generating that big GCC-specific C switch
  Hans-Peter> <arch>-switch.c, which seems generated from sim-cpu.scm.  From
  Hans-Peter> what little scheme I understand (I'm blissfully naive), it seems
  Hans-Peter> only sid-cpu.scm, not sim-cpu.scm, supports setup-semantics.
  Hans-Peter> I'd use it for purposes similar to that of arm.cpu.
  Hans-Peter> Should it work?

I think you are correct.  The setup-semantics work might need to be
back-ported to sim-cpu.scm.  Much of the work is completely analogous;
it shouldn't be too difficult.

arm.cpu was the first port to use setup-semantics and back then, we
were doing early SID component development.  The ARM was our first
hw-cpu-* component, which would explain why setup-semantics is only
supported by sid-cpu.scm.

Ben

Re: Confusion: setup-semantics? PC not updated? Immediate operands?

[Hans-Peter Nilsson]

> From: Ben Elliston <bje@redhat.com>
> Date: Wed, 30 Jan 2002 12:46:46 +1100 (EST)

> The setup-semantics work might need to be
> back-ported to sim-cpu.scm.  Much of the work is completely analogous;
> it shouldn't be too difficult.

I actually made a ham-fisted attempt and failed.  Oh no, please
don't tell me I have to learn scheme! :-)

BTW, the same thing seems to be true for (condition ...) which I
tried to abuse in place of (setup-semantics ...).  It gives no
output, no change at all.

(Clues are welcome.)

brgds, H-P

Re: Confusion: setup-semantics? PC not updated? Immediate operands?

[Frank Ch. Eigler]

Hi -

On Wed, Jan 30, 2002 at 12:46:46PM +1100, Ben Elliston wrote:
> [...]
> arm.cpu was the first port to use setup-semantics and back then, we
> were doing early SID component development.  [...]

Odd - I thought that this setup-semantics stuff was just an
experimental stub, like a bunch of other cgen constructs.
Normally I would try getting this sort of work done outside
cgen, within the hand-written portion of instruction execution
loops.

As to the original question of who increments the PC, this
depends on several parameters: whether sid or sim family,
whether scache or pbb generated kernel.  AFAIK the
setup-semantics stuff is never actually *necessary*.

- FChE

Re: Confusion: setup-semantics? PC not updated? Immediate operands?

[Hans-Peter Nilsson]

> Date: Tue, 29 Jan 2002 23:06:49 -0500
> From: "Frank Ch. Eigler" <fche@redhat.com>

> On Wed, Jan 30, 2002 at 12:46:46PM +1100, Ben Elliston wrote:
> > [...]
> > arm.cpu was the first port to use setup-semantics and back then, we
> > were doing early SID component development.  [...]
> 
> Odd - I thought that this setup-semantics stuff was just an
> experimental stub, like a bunch of other cgen constructs.
> Normally I would try getting this sort of work done outside
> cgen, within the hand-written portion of instruction execution
> loops.

Seeing it in the manual and not marked as experimental made me
think it was ready for the masses.  (Same goes for "condition".)

> As to the original question of who increments the PC, this
> depends on several parameters: whether sid or sim family,
> whether scache or pbb generated kernel.  AFAIK the
> setup-semantics stuff is never actually *necessary*.

Could you please elaborate?  I agree that the setup-semantics
feature isn't necessary in general, though it helps simplifying
the CGEN description.  But you mention this in context of
(incrementing) PC, so it looks as if you mean something
specific.  Not necessary to obtain a PC value?  I can't get a
correct PC value for non-CTI insns.

brgds, H-P

[RFA:] support setup-semantics in sim-cpu.scm (was: Re: Confusion: setup-semantics? ...)

[Hans-Peter Nilsson]

> From: Ben Elliston <bje@redhat.com>
> Date: Wed, 30 Jan 2002 12:46:46 +1100 (EST)

> >>>>> "Hans-Peter" == Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 
>   Hans-Peter> This when generating that big GCC-specific C switch
>   Hans-Peter> <arch>-switch.c, which seems generated from sim-cpu.scm.  From
>   Hans-Peter> what little scheme I understand (I'm blissfully naive), it seems
>   Hans-Peter> only sid-cpu.scm, not sim-cpu.scm, supports setup-semantics.
>   Hans-Peter> I'd use it for purposes similar to that of arm.cpu.
>   Hans-Peter> Should it work?
> 
> I think you are correct.  The setup-semantics work might need to be
> back-ported to sim-cpu.scm.  Much of the work is completely analogous;
> it shouldn't be too difficult.

Is this the right approach?  The right thing seems to happen for
play.cpu, when I test by inserting (setup-semantics (c-call VOID
"gobbledegook" pc)) in the defin-isa body, with both
(cgen-semantics.c) and (cgen-sem-switch.c).  (After removing
addv2, that is.)  To wit: I just copied the "if" clause in front
of the gen-semantic-code call in -gen-sem-case in sid-cpu.scm,
replacing rtl-c++ with rtl-c and made it part of
gen-semantic-code, but wrapping the two parts in string-append.

By the way, sid-cpu.scm does not emit the setup-semantics code
in its gen-semantic-code define as below.  Instead it's emitted
at the call site of gen-semantics-code, but only at one of the
two places, and then at a third place.  I don't know if that's
right or wrong, but it looks like it could lack support for
setup-semantics in some conditions.  I'm probably confused.
Maybe a comment is missing.

Ok to commit?

2002-03-20  Hans-Peter Nilsson  <hp@axis.com>

	* sim-cpu.scm (gen-semantic-code): Prepend with setup-semantics
	code.

*** sim-cpu.scm.old	Tue Jan 29 00:30:59 2002
--- sim-cpu.scm	Thu Mar 21 01:07:13 2002
*************** SEM_FN_NAME (@prefix@,init_idesc_table) 
*** 529,543 ****
  ; Return C code to perform the semantics of INSN.
  
  (define (gen-semantic-code insn)
!   ; Indicate generating code for INSN.
!   ; Use the compiled form if available.
!   ; The case when they're not available is for virtual insns.
!   (let ((sem (insn-compiled-semantics insn)))
!     (if sem
! 	(rtl-c-parsed VOID sem nil
! 		      #:rtl-cover-fns? #t #:owner insn)
! 	(rtl-c VOID (insn-semantics insn) nil
! 	       #:rtl-cover-fns? #t #:owner insn)))
  )
  
  ; Return definition of C function to perform INSN.
--- 529,554 ----
  ; Return C code to perform the semantics of INSN.
  
  (define (gen-semantic-code insn)
!   (string-append
!    (if (and (insn-real? insn)
! 	    (isa-setup-semantics (current-isa)))
!        (string-append
! 	"  "
! 	(rtl-c VOID (isa-setup-semantics (current-isa)) nil
! 	       #:rtl-cover-fns? #t
! 	       #:owner insn)
! 	"\n")
!        "")
! 
!    ; Indicate generating code for INSN.
!    ; Use the compiled form if available.
!    ; The case when they're not available is for virtual insns.
!    (let ((sem (insn-compiled-semantics insn)))
!      (if sem
! 	 (rtl-c-parsed VOID sem nil
! 		       #:rtl-cover-fns? #t #:owner insn)
! 	 (rtl-c VOID (insn-semantics insn) nil
! 		#:rtl-cover-fns? #t #:owner insn))))
  )
  
  ; Return definition of C function to perform INSN.

brgds, H-P

Re: [RFA:] support setup-semantics in sim-cpu.scm (was: Re: Confusion: setup-semantics? ...)

[Hans-Peter Nilsson]

Ping!  Unreviewed patch:

2002-03-20  Hans-Peter Nilsson  <hp@axis.com>

	* sim-cpu.scm (gen-semantic-code): Prepend with setup-semantics
	code.

<URL:http://sources.redhat.com/ml/cgen/2002-q1/msg00089.html>.

brgds, H-P

Re: [RFA:] support setup-semantics in sim-cpu.scm

[Hans-Peter Nilsson]

> Date: Thu, 21 Mar 2002 01:47:47 +0100
> From: Hans-Peter Nilsson <hp@axis.com>

> 2002-03-20  Hans-Peter Nilsson  <hp@axis.com>
> 
> 	* sim-cpu.scm (gen-semantic-code): Prepend with setup-semantics
> 	code.

Committed, approved by Doug Evans.

brgds, H-P

Confusion: setup-semantics? PC not updated? Immediate operands?

[Doug Evans]

Hans-Peter Nilsson writes:
 > On a related matter, it seems pc isn't updated for non-CTI
 > insns; it's value is that of the first insn in the chain.
 > I need it as an operand in non-CTI insns.

Catching up on old mail ...

In the computed-goto engine, the pc is lazily updated.

Off the top of my head, I _think_ what should happen is that
the code generator for non-CTI insns that reference pc
should recognize the situation and update pc appropriately.

Confusion: setup-semantics? PC not updated? Immediate operands?

[Doug Evans]

I wrote:
> In the computed-goto engine, the pc is lazily updated.
> 
> Off the top of my head, I _think_ what should happen is that
> the code generator for non-CTI insns that reference pc
> should recognize the situation and update pc appropriately.

Hmmm, either that or
- mark such insns such that they begin chains
- arrange pc references to be lazy-pc-update aware