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
