This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [DFA]: Scheduling for zSeries and S/390


Hartmut Penner wrote:
> 
> I'm in progress to write the DFA based scheduling description for the
> zSeries pipeline.
> 
> The pipeline is a single-issue pipeline with 6 stages. The pipeline is
> optimized for
> register-memory instructions (RX), allowing execution in 1 cycle. This is
> done by doing the
> address generation right after decode. Due to this early address
> generation, the
> change of a address relevant register has to be issued 4 cycles before the
> usage, in order
> to avoid a pipeline stall. Certain instruction (load, load address) have a
> bypass to reduce
> the pipeline stal to 1 or 2 cycles.
> 
> My question is, how can I model this pipeline structure best with the new
> DFA based scheduler.
> 

  With my point of view, your description adequately describes the
processor. Usage of bypasses with a guard function is also right way to
describe generation of addresses on decoding stage.

  I'd name your variant of description as a structural one because it is
close to processor documentation. You could also use what I name a
behavioural description.  Such description does not follow processor
description but correctly describes all pipeline hazards.  For example,
you could remove dec, agen, c1, and c2 and still get the same
automaton.  Usage of structural or behavioral description is a matter of
taste.

  In overall, as I said, your description is fine.

Vlad


> The first draft of such a description I append here.
> 
> Z900 microarchitecture:
> http://www.research.ibm.com/journal/rd/464/schwarz.html
> 
> ;; Scheduling description for z900 (cpu 2064).
> ;;   Copyright (C) 2002 Free Software Foundation, Inc.
> ;;
> ;; This file is part of GNU CC.
> ;;
> ;; GNU CC is free software; you can redistribute it and/or modify
> ;; it under the terms of the GNU General Public License as published by
> ;; the Free Software Foundation; either version 2, or (at your option)
> ;; any later version.
> ;;
> ;; GNU CC is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ;; GNU General Public License for more details.
> ;;
> ;; You should have received a copy of the GNU General Public License
> ;; along with GNU CC; see the file COPYING.  If not, write to
> ;; the Free Software Foundation, 59 Temple Place - Suite 330,
> ;; Boston, MA 02111-1307, USA.
> 
> ;;
> ;; References:
> ;;   The microarchitecture of the IBM eServer z900 processor.
> ;;   E.M. Schwarz et al.
> ;;   IBM Journal of Research and Development Vol. 46 No 4/5, 2002.
> ;;
> ;;            z900 (cpu 2064) pipeline
> ;;
> ;;                         dec
> ;;                     --> | <---
> ;;  LA bypass  |    agen  |
> ;;                    |      |      |
> ;;                     --- c1     |  Load bypass
> ;;                           |      |
> ;;                          c2----
> ;;                           |
> ;;                          e1
> ;;                           |
> ;;                         wr
> 
> (define_automaton "ipu")
> (define_cpu_unit "dec " "ipu")
> (define_cpu_unit "agen" "ipu")
> (define_cpu_unit "c1"   "ipu")
> (define_cpu_unit "c2"   "ipu")
> (define_cpu_unit "e1"   "ipu")
> (define_cpu_unit "wr"   "ipu")
> 
> (define_insn_reservation "la" 1 (eq_attr "type" "la")
>                 "dec,agen,c1,c2,e1,wr")
> 
> (define_insn_reservation "larl" 1 (eq_attr "type" "larl")
>                 "dec,agen,c1,c2,e1,wr")
> 
> (define_insn_reservation "load" 1 (eq_attr "type" "load")
>                 "dec,agen,c1,c2,e1,wr")
> 
> (define_insn_reservation "store" 1 (eq_attr "type" "store")
>                 "dec,agen,c1,c2,e1,wr")
> 
> (define_insn_reservation "call" 4 (eq_attr "type" "jsr")
>                 "dec,agen,c1,c2,e1*5,wr")
> 
> (define_insn_reservation "o2" 2 (eq_attr "type" "o2")
>                 "dec,agen,c1,c2,e1*2,wr")
> 
> (define_insn_reservation "o3" 3 (eq_attr "type" "o3")
>                 "dec,agen,c1,c2,e1*3,wr")
> 
> (define_insn_reservation "int" 1 (and (eq_attr "type" "integer")
>                                       (not (eq_attr "atype" "mem")))
>                 "dec,agen,c1,c2,e1,wr")
> 
> (define_insn_reservation "mem" 1 (eq_attr "atype" "mem")
>                 "dec,agen,c1,c2,e1,wr")
> 
> ;;
> ;; s390_agen_dep_p returns 1, if a register is set in the
> ;; first insn and used in the dependend insn to form a address.
> ;;
> 
> ;;
> ;; If a intruction uses a register to address memory, it needs
> ;; to be set 5 cycles in advance.
> ;;
> 
> (define_bypass 5 "int,mem" "mem,la,call,load" "s390_agen_dep_p")
> 
> ;;
> ;; A load type instruction uses a bypass to feed the result back
> ;; to the address generation pipeline stage.
> ;;
> 
> (define_bypass 3 "load"    "mem,la,call,load" "s390_agen_dep_p")
> 
> ;;
> ;; A load address type instruction uses a bypass to feed the
> ;; result back to the address generation pipeline stage.
> ;;
> 
> (define_bypass 2 "larl,la" "mem,la,call,load" "s390_agen_dep_p")
> 
> Mit freundlichem Gruß / Best regards,
> 
> Hartmut Penner
> GCC for S/390 Development


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]