Thank you Rodolph, You're right ! I'll try to change the ABI of our platform for something more up to date. This is not "easy" in our position. However we could know for sure if this is the reason of our troubles.
I'll keep you updated. Yoann 2011/2/14 Rodolph Perfetta <[email protected]> > Hi Yoann, > > The issue look to be around the ABI on your platform: is it really OABI or > some kind of variant. Anyway, as I mentioned before, OABI has been > deprecated for quite a while, so moving to a more recent filesystem is your > best chance. > > Cheers, > Rodolph. > > > On 14 February 2011 14:04, Yoann Sculo <[email protected]> wrote: > >> 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 >> > > -- > 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
