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
