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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
peripherals: 0.980
hypervisor: 0.978
permissions: 0.972
performance: 0.970
device: 0.969
arm: 0.967
semantic: 0.967
architecture: 0.965
PID: 0.964
debug: 0.964
graphic: 0.964
vnc: 0.963
register: 0.962
assembly: 0.961
user-level: 0.961
boot: 0.959
socket: 0.959
kernel: 0.955
risc-v: 0.954
ppc: 0.951
virtual: 0.949
VMM: 0.946
files: 0.944
TCG: 0.939
KVM: 0.937
x86: 0.919
network: 0.918
mistranslation: 0.918
i386: 0.825
fpu/softfloat: round_to_int_and_pack refactor broke TriCore ftoi insns
After the refactor from ab52f973a504f8de0c5df64631ba4caea70a7d9e the bahaviour of int32_to_float32() was altered.
helper_ftoi() in target/tricore/fpu_helper.c relied on int32_to_float32 to raise the invalid flag if the input was NaN to properly return 0. Likewise if the input is infinity.
The obvious fix for softfloat would be to raise this flag in round_to_int_and_pack(). However,
I'm not sure if this breaks other targets and I have no easy way to test it.
Yeah it looks like it was missed, the round_to_uint code does it.
Do you have a test case I can verify?
On 04/10/2018 10:07 PM, Alex Bennée wrote:
> Yeah it looks like it was missed, the round_to_uint code does it.
>
> Do you have a test case I can verify?
>
For the NaN input 0xffffffff the expected result for the flags is that
flag_invalid is raised.
I can provide you with some TriCore asm, but it is a bit of pain to get
the gnu assembler to build, since the public version is a decade old.
Cheers,
Bastian
Bastian Koppelmann <email address hidden> writes:
> On 04/10/2018 10:07 PM, Alex Bennée wrote:
>> Yeah it looks like it was missed, the round_to_uint code does it.
>>
>> Do you have a test case I can verify?
>>
>
> For the NaN input 0xffffffff the expected result for the flags is that
> flag_invalid is raised.
>
> I can provide you with some TriCore asm, but it is a bit of pain to get
> the gnu assembler to build, since the public version is a decade old.
I'll trust you if you send me a static binary for this particular
verification ;-)
It would be nice to TriCore tests building in tests/tcg/ but I guess we
need an up to date cross compile environment somewhere.
>
> Cheers,
> Bastian
--
Alex Bennée
On 04/11/2018 01:01 PM, Alex Bennée wrote:
>
> Bastian Koppelmann <email address hidden> writes:
>
>> On 04/10/2018 10:07 PM, Alex Bennée wrote:
>>> Yeah it looks like it was missed, the round_to_uint code does it.
>>>
>>> Do you have a test case I can verify?
>>>
>>
>> For the NaN input 0xffffffff the expected result for the flags is that
>> flag_invalid is raised.
>>
>> I can provide you with some TriCore asm, but it is a bit of pain to get
>> the gnu assembler to build, since the public version is a decade old.
>
> I'll trust you if you send me a static binary for this particular
> verification ;-)
>
> It would be nice to TriCore tests building in tests/tcg/ but I guess we
> need an up to date cross compile environment somewhere.
That is the problem. There is a gcc/binutils port done by some german
company. And it's not easy to get the source. The one they provide is
pretty old and needs some patching to get in building on modern
machines. Right now I'm trying to set up a test environment.
Cheers,
Bastian
On 04/11/2018 01:01 PM, Alex Bennée wrote:
> Bastian Koppelmann <email address hidden> writes:
>
>> On 04/10/2018 10:07 PM, Alex Bennée wrote:
>>> Yeah it looks like it was missed, the round_to_uint code does it.
>>>
>>> Do you have a test case I can verify?
>>>
>>
>> For the NaN input 0xffffffff the expected result for the flags is that
>> flag_invalid is raised.
>>
>> I can provide you with some TriCore asm, but it is a bit of pain to get
>> the gnu assembler to build, since the public version is a decade old.
>
> I'll trust you if you send me a static binary for this particular
> verification ;-)
I set up a github repo with working binutils and the corresponding testcase:
https://github.com/bkoppelmann/tricore-fpu
The one caveat is, that we cannot produce any binaries with the TriCore
ISA > 1.3.
In this testcase the last ftoi instruction is supposed to raise the
invalid flag and return 0 since the input was NaN. We did that by only
checking for NaN if any flag was raised after ftoi, then do the NaN
check, and if positive, return 0.
Cheers,
Bastian
Bastian Koppelmann <email address hidden> writes:
> On 04/11/2018 01:01 PM, Alex Bennée wrote:
>> Bastian Koppelmann <email address hidden> writes:
>>
>>> On 04/10/2018 10:07 PM, Alex Bennée wrote:
>>>> Yeah it looks like it was missed, the round_to_uint code does it.
>>>>
>>>> Do you have a test case I can verify?
>>>>
>>>
>>> For the NaN input 0xffffffff the expected result for the flags is that
>>> flag_invalid is raised.
>>>
>>> I can provide you with some TriCore asm, but it is a bit of pain to get
>>> the gnu assembler to build, since the public version is a decade old.
>>
>> I'll trust you if you send me a static binary for this particular
>> verification ;-)
>
> I set up a github repo with working binutils and the corresponding
> testcase:
>
> https://github.com/bkoppelmann/tricore-fpu
>
> The one caveat is, that we cannot produce any binaries with the TriCore
> ISA > 1.3.
>
> In this testcase the last ftoi instruction is supposed to raise the
> invalid flag and return 0 since the input was NaN. We did that by only
> checking for NaN if any flag was raised after ftoi, then do the NaN
> check, and if positive, return 0.
Well it builds and I get an fpu-test.elf but I'm a bit stuck on how to
run it. What are the runes for launching the test?
>
> Cheers,
> Bastian
--
Alex Bennée
On 04/12/2018 03:41 PM, Alex Bennée wrote:
> Bastian Koppelmann <email address hidden> writes:
>
>> On 04/11/2018 01:01 PM, Alex Bennée wrote:
>>> Bastian Koppelmann <email address hidden> writes:
>>>
>>>> On 04/10/2018 10:07 PM, Alex Bennée wrote:
>>>>> Yeah it looks like it was missed, the round_to_uint code does it.
>>>>>
>>>>> Do you have a test case I can verify?
>>>>>
>>>>
>>>> For the NaN input 0xffffffff the expected result for the flags is that
>>>> flag_invalid is raised.
>>>>
>>>> I can provide you with some TriCore asm, but it is a bit of pain to get
>>>> the gnu assembler to build, since the public version is a decade old.
>>>
>>> I'll trust you if you send me a static binary for this particular
>>> verification ;-)
>>
>> I set up a github repo with working binutils and the corresponding
>> testcase:
>>
>> https://github.com/bkoppelmann/tricore-fpu
>>
>> The one caveat is, that we cannot produce any binaries with the TriCore
>> ISA > 1.3.
>>
>> In this testcase the last ftoi instruction is supposed to raise the
>> invalid flag and return 0 since the input was NaN. We did that by only
>> checking for NaN if any flag was raised after ftoi, then do the NaN
>> check, and if positive, return 0.
>
> Well it builds and I get an fpu-test.elf but I'm a bit stuck on how to
> run it. What are the runes for launching the test?
qemu-system-tricore -M tricore_testboard -kernel fpu-test.elf -nographic
However, this is not really a test. I usually run these against
Infineons golden (sadly proprietary) simulator and compare register
dumps. I have some more regression tests but I haven't had the time make
them into proper tests, such that we don't need this golden model.
Cheers,
Bastian
|