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
> > >> > > > > > > > "8.263547083e-315" and the strange issue for the date.
> >
> > >> > > > > > > > I cannot find if it comes from V8 or uClibC.
> >
> > >> > > > > > > > I've tried unsuccessfully to use a standard libC in our
> > >> > environment
> > >> > > > > > > > but it a to complex modification in our system.
> >
> > >> > > > > > > > Do you have any idea ?
> >
> > >> > > > > > > > Best regards.
> > >> > > > > > > > Julien.
> >
> > >> > > > > > > > On Nov 26, 1:29 pm, Rodolph Perfetta <
> > >> > [email protected]>
> > >> > > > > > > > wrote:
> > >> > > > > > > > > Hi,
> >
> > >> > > > > > > > > I couldn't reproduce your issue, an armv4 build of
> > >> > bleeding_edge
> > >> > > > > > gives me
> > >> > > > > > > > > the right result.
> >
> > >> > > > > > > > > Are the C libraries on your platform working properly?
> Could
> > >> > you
> > >> > > > try
> > >> > > > > > and
> > >> > > > > > > > > narrow it down a bit: is it Math.floor or Math.random
> (or
> > >> > both)
> > >> > > > which
> > >> > > > > > is
> > >> > > > > > > > an
> > >> > > > > > > > > issue?
> >
> > >> > > > > > > > > Cheers,
> > >> > > > > > > > > Rodolph.
> >
> > >> > > > > > > > > On 25 November 2010 14:09, JulienC <[email protected]>
> wrote:
> >
> > >> > > > > > > > > > Hi all,
> >
> > >> > > > > > > > > > I currently encounter 2 issues with V8 on armV4
> (arm920t),
> > >> > I
> > >> > > > don't
> > >> > > > > > > > > > know if they are related or not.
> >
> > >> > > > > > > > > > The first is with Math.random() when I try to get a
> number
> > >> > in
> > >> > > > 0-9,
> >
> > >> > > > > > > > > > on my mac, it works well:
> > >> > > > > > > > > > >Math.floor(Math.random()*10)
> > >> > > > > > > > > > 2
> >
> > >> > > > > > > > > > on armV4, strange behaviour:
> > >> > > > > > > > > > >Math.floor(Math.random()*10)
> > >> > > > > > > > > > 1.6427083566e-314
> >
> > >> > > > > > > > > > I'm using the trunk but it seems to do the same for
> all
> > >> > > > versions.
> >
> > >> > > > > > > > > > The second issue is concerning the Date object, when
> I try
> > >> > to
> > >> > > > set a
> > >> > > > > > > > > > date, it always return 01/01/1970...
> >
> > >> > > > > > > > > > on my mac:
> > >> > > > > > > > > > > new Date()
> > >> > > > > > > > > > Thu Nov 25 2010 14:59:26 GMT+0100 (CET)
> > >> > > > > > > > > > > new Date(2009, 11, 30)
> > >> > > > > > > > > > Wed Dec 30 2009 00:00:00 GMT+0100 (CET)
> >
> > >> > > > > > > > > > on armV4:
> > >> > > > > > > > > > > new Date()
> > >> > > > > > > > > > Thu Nov 25 2010 00:00:00 GMT+0000 (UTC) ...
> >
> > read more ยป
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
