Hi Julien, Is there something preventing you moving to a newer software platform? OABI has been deprecated for quite some time and its support is likely to be removed in a number projects and you are likely to hit more and more these kind of issues. how about debian?
Cheers, Rodolph. On 25 December 2010 12:53, Alexandre Rames <[email protected]>wrote: > Hi Julien, > > Sorry but I'm on holidays. I'll try to have a look when I get back home. > > Merry christmas, > > Alexandre > > > On Tue, Dec 21, 2010 at 12:09 PM, JulienC <[email protected]> wrote: > >> Hi Alexandre, >> >> Sorry to bother you, but have you got time to look at the results and >> do you have an solution for my issue ? >> >> Best regards, >> Julien. >> >> On Dec 10, 2:32 pm, JulienC <[email protected]> wrote: >> > 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 ordate. >> > >> > > > > >> > 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 theDateissue. 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.... >> > >> > 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 > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
