Hi Alexandre,
Thanks, this should match your demand:
x86:
000000f03f
arm:
00f03f0000
void print(unsigned char tab[8])
{
int i;
for(i=0;i<8;i++)
printf("%x",tab[i]);
printf("\n");
}
int main()
{
double d=1;
print(&d);
}
> for(var i = 0; i < 20; i++) {print(Math.floor(2.123));}
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
> for(var i = 0; i < 20; i++) {print(Math.random())}
1.651509766e-314
2.0821911264e-314
1.7343027825e-314
2.1174813486e-314
1.9868044616e-314
8.620471736e-315
6.234858226e-315
1.988877371e-314
9.260478697e-315
9.218751257e-315
1.872862592e-314
9.614200787e-315
9.09641018e-315
8.74266173e-315
1.96833179e-314
1.7342867753e-314
8.432756346e-315
2.086748093e-314
2.0680944637e-314
6.89790512e-315
>
Best regards,
Julien
On Dec 10, 12:41 pm, Alexandre Rames <[email protected]>
wrote:
> Hi Julien,
>
> USE_ARM_EABI in code-stubs-arm.cc only select wether the double should be
> returned in the floating point unit or in registers r0 and r1.
> This is not your issue here. You get the correct object returned (the
> correct floating point value, but the order of the 2 32bit values is somehow
> mis-interpreted).
>
> I may have found a bug related to your issue.
> Is your system using big endian floating point? Please write some C code
> allocating a few 64bit doubles and dump the memory in hexa.
>
> Please also execute these scripts and send me the results.
> ___________________________
> for(var i = 0; i < 20; i++) {
> print(Math.random())}
>
> ___________________________
> for(var i = 0; i < 20; i++) {
> print(Math.floor(2.123));
>
> }
>
> Alexandre
>
>
>
>
>
>
>
> On Fri, Dec 10, 2010 at 10:55 AM, JulienC <[email protected]> wrote:
> > Hi Erik,
>
> > I've tried to change the define here "USE_ARM_EABI in code-stubs-
> > arm.cc" but nothing change.
> > I've done some new example:
> > V8 version 2.5.8
> > > 0.5+0.5
> > 1
> > > 0.5
> > 5.29462817e-315
> > > a = 0.5
> > 5.29462817e-315
> > > b = 0.5
> > 5.29462817e-315
> > > a + b
> > 1
> > > a = 0.5+0.4
> > -9.255967792281513e+61
> > > a + 0.1
> > 1
>
> > It seems that the in memory value is good but when a float comes from
> > memory to JS the value Mantissa and Exponent are inverted.
>
> > On parsing "5.29462817e-315" (ie: 0.5) I have the same issue:
> > > 0.5
> > 5.29462817e-315
> > > 5.29462817e-315 + 5.29462817e-315
> > 1
>
> > Using debugger is a bit difficult on our device...
>
> > Best regards,
> > Julien
>
> > On Dec 8, 11:05 am, Erik Corry <[email protected]> wrote:
> > > This is almost certainly an issue with the calling conventions.
>
> > > Search for USE_ARM_EABI in code-stubs-arm.cc. It does different
> > > things with the fp arguments to C functions depending on the calling
> > > convention.
>
> > > Put breakpoints in add_two_doubles etc. and check it gets the
> > > arguments in the right order and do si (step instruction) to see what
> > > V8 does with the result when you return.
>
> > > Good luck :-)
>
> > > 7. dec. 2010 14.53 skrev JulienC <[email protected]>:
>
> > > > Hi Alexandre,
>
> > > > I've already tried to change this part but in javascript side it
> > > > doesn't change anything.
> > > > I think that when I change "the endian floating point word ordering"
> > > > here, It just invert the C double representation of mantissa and
> > > > exponent
> > > > but as the inversion is done on write AND on read, it always print the
> > > > same on javascript (ie: 1.194530457405681e+103)
>
> > > > Best regards,
> > > > Julien.
>
> > > > On Dec 6, 6:48 pm, Alexandre Rames <[email protected]> wrote:
> > > >> Hi,
>
> > > >> I don't know about your system endianness, but have a look at
> > objects.h
> > > >> around line 1200. Using one or the other could do your trick.
>
> > > >> * // IEEE doubles are two 32 bit words. The first is just mantissa,
> > the
> > > >> second*
> > > >> * // is a mixture of sign, exponent and mantissa. Our current
> > platforms
> > > >> are all*
> > > >> * // little endian apart from non-EABI arm which is little endian
> > with big
> > > >> *
> > > >> * // endian floating point word ordering!*
> > > >> * #if !defined(V8_HOST_ARCH_ARM) || defined(USE_ARM_EABI)*
> > > >> * static const int kMantissaOffset = kValueOffset;*
> > > >> * static const int kExponentOffset = kValueOffset + 4;*
> > > >> * #else*
> > > >> * static const int kMantissaOffset = kValueOffset + 4;*
> > > >> * static const int kExponentOffset = kValueOffset;*
> > > >> * # define BIG_ENDIAN_FLOATING_POINT 1*
> > > >> * #endif*
>
> > > >> Alexandre
>
> > > >> On Mon, Dec 6, 2010 at 2:51 PM, JulienC <[email protected]> wrote:
> > > >> > Hi Alexandre,
>
> > > >> > I've check the double in "HeapNumber::set_value(double value)", and
> > > >> > tried (for testing) to invert mantissa and exponent and the hack
> > works
> > > >> > (more or less, C double is no more valid after that) for division
> > but
> > > >> > not for random or date.
>
> > > >> > I suppose that the issue comes from the VFP conversion function in
> > > >> > assembler-arm.cc
> > > >> > I'm not sure that I got the skills to investigate the C assembly
> > > >> > there.
>
> > > >> > Is there a specific compilation option, define, or a patch fo armV4
> > > >> > (arm920t) ?
>
> > > >> > Best regards,
> > > >> > Julien.
>
> > > >> > On Dec 3, 3:07 pm, Alexandre Rames <[email protected]>
> > wrote:
> > > >> > > Hi Julien
>
> > > >> > > ieee-64bi t 0x3fd5555555555555 = 0.3333333333333333
> > > >> > > 1.194530457405681e+103 = ieee-64bit
> > 555555553FD55555
>
> > > >> > > I guess you know what to investigate now!
>
> > > >> > > Alexandre
>
> > > >> > > On Fri, Dec 3, 2010 at 1:49 PM, JulienC <[email protected]> wrote:
> > > >> > > > Hi Alexandre,
>
> > > >> > > > I've just make some investigations and finally I found that
> > "float"
> > > >> > > > number seems to be wrong on our arm system
> > > >> > > > for example
> > > >> > > > >1/3
> > > >> > > > 1.194530457405681e+103
>
> > > >> > > > don't know if it can come from BIG_ENDIAN_FLOATING_POINT,
> > nothing
> > > >> > > > change when I try to play with it (1/3 always gives the same
> > result).
> > > >> > > > we are on an OABI armV4 (arm920t).
>
> > > >> > > > Best regards.
> > > >> > > > Julien.
>
> > > >> > > > On Dec 2, 7:23 pm, Alexandre Rames <[email protected]>
> > wrote:
> > > >> > > > > Well this must be a problem with your system then. I just spot
> > that
> > > >> > > > > 8.26...e-315 is not in the range of ieee 64bit floating
> > points!
> > > >> > > > > You can follow the call chain from
> > > >> > > > > CodeGenerator::GenerateRandomHeapNumner 's call to
> > > >> > > > > fill_heap_number_with_random_function (codegen-arm.cc)
> > > >> > > > > up to
> > > >> > > > > static uint32_t random_base(random_state *state) (v8.cc)
> > > >> > > > > which uses random_seed().
>
> > > >> > > > > You should try to investigate how your system is linked to v8
> > here.
>
> > > >> > > > > I think Math.floor does not return an integer on your platform
> > > >> > because it
> > > >> > > > > can't handle the illegal value generated by your Math.random.
>
> > > >> > > > > Alexandre
>
> > > >> > > > > On Thu, Dec 2, 2010 at 4:39 PM, JulienC <[email protected]>
> > wrote:
> > > >> > > > > > Hi Alexandre,
>
> > > >> > > > > > I think that our issue is caused by Math.random() and not
> > > >> > Math.floor()
> > > >> > > > > > because:
> > > >> > > > > > on mac:
> > > >> > > > > > >Math.random()
> > > >> > > > > > 0.8807874456979334
>
> > > >> > > > > > on arm:
> > > >> > > > > > >Math.random()
> > > >> > > > > > 8.263547083e-315 // 0.00000000000...826 so floor should
> > return 0
> > > >> > most
> > > >> > > > > > of time.
>
> > > >> > > > > > but on arm:
> > > >> > > > > > >Math.floor(2.1534)
> > > >> > > > > > 2
>
> > > >> > > > > > So floor seems to work correctly if the number is not to
> > big.
>
> > > >> > > > > > Best regards,
> > > >> > > > > > Julien
>
> > > >> > > > > > On Dec 2, 5:02 pm, Alexandre Rames <
> > [email protected]>
> > > >> > wrote:
> > > >> > > > > > > Hi Julien,
>
> > > >> > > > > > > I don't have actual ARM4 hardware, but everything works
> > fine for
> > > >> > me
> > > >> > > > on
> > > >> > > > > > the
> > > >> > > > > > > Simulator when disabling armv7 and vfp3 (equivalent to
> > using
> > > >> > armv4 on
> > > >> > > > > > v8).
>
> > > >> > > > > > > I don't know too much about the Date issue. It looks like
> > > >> > something
> > > >> > > > is
> > > >> > > > > > wrong
> > > >> > > > > > > in the bindings between v8 and your system.
>
> > > >> > > > > > > A few hints for the Math.floor issue:
> > > >> > > > > > > - Use a debug version of the shell to debug / carry your
> > tests.
> > > >> > > > > > > - Do you pass the cctests?
> > > >> > > > > > > tools/test.py --snapshot --mode=debug -j3
> > > >> > > > > > > - Especially do you pass the mjsunit/math-floor.js test?
> > > >> > > > > > > ./shell_g --enable-slow-asserts --debug-code --verify-heap
> > > >> > > > > > > --max-new-space-size=256 test/mjsunit/mjsunit.js
> > > >> > > > > > test/mjsunit/math-floor.js
>
> > > >> > > > > > > - You may want to check the hex value returned by your
> > call to
> > > >> > > > Math.floor
> > > >> > > > > > > with gdb / ddd.
> > > >> > > > > > > ARMv4 does not use an assembly optimization for
> > Math.floor, so it
> > > >> > > > seems
> > > >> > > > > > > unlikely that the result of the computation is false.
> > > >> > > > > > > You can try check the double returned by v8 to see if it
> > is
> > > >> > correct.
> > > >> > > > > > > I could not confirm on a quick test that
> > > >> > > > v8::internal::Runtime_Math_floor
> > > >> > > > > > > (runtime.cc) is called, but you may want to put a
> > breakpoint
> > > >> > there.
> > > >> > > > > > > Otherwise v8 may call a builtin. You can use a breakpoint
> > (with a
> > > >> > > > counter
> > > >> > > > > > to
> > > >> > > > > > > stop at the right time) in v8::internal::Invoke
> > (execution.cc)
> > > >> > around
> > > >> > > > > > value
> > > >> > > > > > > = CALL_GENERATED_CODE(... (~line 94) .
>
> > > >> > > > > > > I found an interesting issue while investigating your bug:
> > > >> > compiling
> > > >> > > > the
> > > >> > > > > > > shell in debug mode with the snapshot option on and
> > running with
> > > >> > > > > > > noenable_armv7 and noenable_vfp3 generates some
> > incoherency:
> > > >> > natives
> > > >> > > > are
> > > >> > > > > > > compiled with vfp3 and armv7, so we still execute this
> > code when
> > > >> > > > calling
> > > >> > > > > > > them!
> > > >> > > > > > > But this has nothing to do with your bug. This won't
> > happen on
> > > >> > actual
> > > >> > > > > > > hardware, and you would get an illegal instruction
> > exception or
> > > >> > so.
>
> > > >> > > > > > > Cheers
>
> > > >> > > > > > > Alexandre
>
> > > >> > > > > > > On Thu, Dec 2, 2010 at 11:35 AM, JulienC <
> > [email protected]>
> > > >> > wrote:
> > > >> > > > > > > > We are currently using uClibC, it works well for all the
> > system
> > > >> > we
> > > >> > > > > > > > have (glib + protocol buffer + mplayer + ...).
>
> > > >> > > > > > > > We compile V8, it almost work. But Math.random()
> > > >> > > > > > > > returns...
>
> read more »
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
