1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
;; ARM 926EJ-S Pipeline Description
;; Copyright (C) 2003 Free Software Foundation, Inc.
;; Written by CodeSourcery, LLC.
;;
;; This file is part of GCC.
;;
;; GCC 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.
;;
;; GCC 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 GCC; see the file COPYING. If not, write to the Free
;; Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
;; 02110-1301, USA. */
;; These descriptions are based on the information contained in the
;; ARM926EJ-S Technical Reference Manual, Copyright (c) 2002 ARM
;; Limited.
;;
;; This automaton provides a pipeline description for the ARM
;; 926EJ-S core.
;;
;; The model given here assumes that the condition for all conditional
;; instructions is "true", i.e., that all of the instructions are
;; actually executed.
(define_automaton "arm926ejs")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Pipelines
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; There is a single pipeline
;;
;; The ALU pipeline has fetch, decode, execute, memory, and
;; write stages. We only need to model the execute, memory and write
;; stages.
(define_cpu_unit "e,m,w" "arm926ejs")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ALU Instructions
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ALU instructions require three cycles to execute, and use the ALU
;; pipeline in each of the three stages. The results are available
;; after the execute stage stage has finished.
;;
;; If the destination register is the PC, the pipelines are stalled
;; for several cycles. That case is not modeled here.
;; ALU operations with no shifted operand
(define_insn_reservation "9_alu_op" 1
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "alu,alu_shift"))
"e,m,w")
;; ALU operations with a shift-by-register operand
;; These really stall in the decoder, in order to read
;; the shift value in a second cycle. Pretend we take two cycles in
;; the execute stage.
(define_insn_reservation "9_alu_shift_reg_op" 2
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "alu_shift_reg"))
"e*2,m,w")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Multiplication Instructions
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Multiplication instructions loop in the execute stage until the
;; instruction has been passed through the multiplier array enough
;; times. Multiply operations occur in both the execute and memory
;; stages of the pipeline
(define_insn_reservation "9_mult1" 3
(and (eq_attr "tune" "arm926ejs")
(eq_attr "insn" "smlalxy,mul,mla"))
"e*2,m,w")
(define_insn_reservation "9_mult2" 4
(and (eq_attr "tune" "arm926ejs")
(eq_attr "insn" "muls,mlas"))
"e*3,m,w")
(define_insn_reservation "9_mult3" 4
(and (eq_attr "tune" "arm926ejs")
(eq_attr "insn" "umull,umlal,smull,smlal"))
"e*3,m,w")
(define_insn_reservation "9_mult4" 5
(and (eq_attr "tune" "arm926ejs")
(eq_attr "insn" "umulls,umlals,smulls,smlals"))
"e*4,m,w")
(define_insn_reservation "9_mult5" 2
(and (eq_attr "tune" "arm926ejs")
(eq_attr "insn" "smulxy,smlaxy,smlawx"))
"e,m,w")
(define_insn_reservation "9_mult6" 3
(and (eq_attr "tune" "arm926ejs")
(eq_attr "insn" "smlalxy"))
"e*2,m,w")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Load/Store Instructions
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; The models for load/store instructions do not accurately describe
;; the difference between operations with a base register writeback
;; (such as "ldm!"). These models assume that all memory references
;; hit in dcache.
;; Loads with a shifted offset take 3 cycles, and are (a) probably the
;; most common and (b) the pessimistic assumption will lead to fewer stalls.
(define_insn_reservation "9_load1_op" 3
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "load1,load_byte"))
"e*2,m,w")
(define_insn_reservation "9_store1_op" 0
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "store1"))
"e,m,w")
;; multiple word loads and stores
(define_insn_reservation "9_load2_op" 3
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "load2"))
"e,m*2,w")
(define_insn_reservation "9_load3_op" 4
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "load3"))
"e,m*3,w")
(define_insn_reservation "9_load4_op" 5
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "load4"))
"e,m*4,w")
(define_insn_reservation "9_store2_op" 0
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "store2"))
"e,m*2,w")
(define_insn_reservation "9_store3_op" 0
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "store3"))
"e,m*3,w")
(define_insn_reservation "9_store4_op" 0
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "store4"))
"e,m*4,w")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Branch and Call Instructions
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Branch instructions are difficult to model accurately. The ARM
;; core can predict most branches. If the branch is predicted
;; correctly, and predicted early enough, the branch can be completely
;; eliminated from the instruction stream. Some branches can
;; therefore appear to require zero cycles to execute. We assume that
;; all branches are predicted correctly, and that the latency is
;; therefore the minimum value.
(define_insn_reservation "9_branch_op" 0
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "branch"))
"nothing")
;; The latency for a call is not predictable. Therefore, we use 32 as
;; roughly equivalent to positive infinity.
(define_insn_reservation "9_call_op" 32
(and (eq_attr "tune" "arm926ejs")
(eq_attr "type" "call"))
"nothing")
|
