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
