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
