David Edelsohn wrote:
Nathan Sidwell writes:
(define_insn_reservation "arith" 1 (eq_attr "type" "arith") "x")
(define_insn_reservation "loads" 2 (eq_attr "type" "load") "x,m")
(define_insn_reservation "stores" 3 (eq_attr "type" "store") "x,m*2")
Nathan> Stores don't really have a 'result', why have you set the cycle
Nathan> count to 3? Shouldn't it be '1'? (then you won't need store bypasses
Nathan> for autoincrements)
Stores do have results: memory. If one does not have a store
bypass in the processor, one needs to model the delay for the result to
appear in the cache and be available for a subsequent load.
Is that modelled by that bit of the scheduler? I thought the cycle count
in define_insn_reservation was for a register output that would be available
to a subsequent instruction.
The RAW contention you describe would need to be modelled separately (as
I've done in at least one port), because you could start the load insn
before the store had completed -- provided the load was processed in the
memory unit after the store has sufficiently completed. an absense_set would
be the way to model stalling a load whilst a store was being processed.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED] :: http://www.planetfall.pwp.blueyonder.co.uk
