My bad, I was not specific.
Actually, i am trying to run some test on qemu to verify some instructions.
For which i build a binary and load it on qemu in my environment and test
the output.
In this case even i am not sure, if the output i get from qemu is correct
or not.
[Use case]
[sample - Instruction : this is my .s file]
.section .text
.global _start
_start:
frecpe D21, D24
_test_pass:
mov x0 , #0x0
b _test_end
_test_fail:
mov x0, #0xffffffffffffffff
b _test_end
_test_end:
b .
[Reg values ]
These are the value in used to init my register.
X21.write(0xC2DC66415D15B180L)
X24.write(0x76b3630c86fae51f)
FPCR.write(0x5d931bb5)
FPSR.write(0x23c914ee)
I still need to confirm if its a issue.
Thanks,
Gaurav
On Fri, Aug 8, 2014 at 3:55 PM, Peter Maydell <peter.mayd...@linaro.org>
wrote:
> On 8 August 2014 11:02, Gaurav Sharma <gauravs.2...@gmail.com> wrote:
> > I am trying to test the floating point instruction for arm in qemu.
> > For floating point reciprocal estimate instruction, for a64 i see a check
> > for underflow condition in float64 HELPER(recpe_f64) method :
> >
> > " else if (f64_exp >= 1023 && fpst->flush_to_zero) "
> >
> > 1. how do we calculate the value to determine underflow ?
>
> By looking at the pseudocode in the ARM ARM which
> defines the condition under which we should signal
> underflow.
>
> > 2. Is the number 1023 correct for a64 ?
>
> The underflow condition for 64 bit in the ARM ARM is
> "Abs(value) >= 2.0^1022", which is a condition in the
> pseudocode on the true real-number value of the input.
> For QEMU we don't have a real-number value so we must
> figure out the correct checks to be made on the raw
> exponent/mantissa/sign fields of the IEEE format double.
> (Specifically, f64_exp is the raw exponent field.)
> Since we've already dealt with the NaN and infinity and
> denormal cases by this point in the code, we know that
> value == (-1)^S * 2^(exp-1023) * 1.frac
> If you plug in the value == 2.0^1022 and work it out
> you'll find that this corresponds to f64_exp == 1023.
>
> If you think we have a bug here (or elsewhere), it would be
> helpful if you either:
> * described a specific case where you put input values
> in and get a wrong value out (as compared with h/w)
> * described your reasoning for why you think we're wrong,
> with reference to the specifications
>
> If you just vaguely say "hey, is this right?" with no further
> detail then you're asking us to do all the hard work of thinking
> about the corner cases for you. If you think something is odd
> and you've thought about it and you still can't figure out
> why it's right, that's OK, but you need to tell us what you've
> already done and where exactly you're getting confused.
>
> thanks
> -- PMM
>
