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) //no time ? > > > > > > > new Date(2009, 11, 30) > > > > > > Thu Jan 01 1970 00:00:00 GMT+0000 (UTC) // wrong date ! > > > > > > > I hope that someone has any idea about one of those issues. > > > > > > > Best regards. > > > > > > > -- > > > > > > 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 > > > -- > > 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
