Hello, I work with Julien and Guillaume on the same project. We still haven't found a way to fix this issue. This is quite blocking actually.
Alexandre, I think the issue could be more low-level than the random numbers generation, which appears to be one of the consequences. We have seen the problem sounds hidding in the process of rereading a floatting value, that has been already written. But writing a value works fine, the issue could be located in the rereading... :( Frederic, any progress on your side ? Thanks Yoann On Jan 19, 7:47 pm, "fred.ac" <[email protected]> wrote: > Hi, > > Any progress on this ? > I have exactly the same problem, I'm trying to run v8 on anARMv4720T > - soft float - OABI - ulibc. > Compilation process : > - scons mode=release arch=arm library=shared prof=off os=linux > profilingsupport=off snapshot=off > - execinfo.h doen't exist in ulibc, backtrace methods implemented with > null/no return. (julienC do you have a better alternative ?) > Float values are wrong and when I execute an operation on them, the > program (shell) stops with an illegal instruction. > Here is an example: > V8 version 3.0.7>var a = 0.5 > >print (a) > >5.29462817e-315 > >var b = 0.5 > >print(b) > >5.29462817e-315 > >print (a-b) > > Illegal instruction > > All float related operations (date, floor, random, ...) fail. I hope > that all are related to the same problem. > > I'm impatient to run successfully v8 on our payment terminals > (embedded linux). > Developing on this kind of device in javascript with v8 performance is > I think a very good alternative to good "old" c and the "heavy" java > vm. > I will try to investigate the problem deeper but it is not easy for a > novice to debug v8, specially the assemble part. > > If somebody could help it will be great. > > Thanks! > > On 21 déc 2010, 12:09, 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 forrandomordate. > > > > > > > >> > 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 > > > > > > >> > foarmV4 > > > > > > >> > (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 OABIarmV4(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 > > > > > > >> >armv4on > > > > > > >> > > > > > 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... > > > plus de détails » -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
