Hello, It works !! Thank you so much for having pointed it out ! It took me a while... I've switched the ABI of our platform from OABI to EABI. It has involved *a lot* of problems. But now everything is fixed and v8 works perfectly fine !
>From now on, i'll think twice before choosing a deprecated ABI :) Thank you !! Yoann And for the record : Before (OABI) : > 0.5 5.29462817e-315 > 1/3 1.194530457405681e+103 > 3/4 5.297218497e-315 > 654979/42 1.6747441805184128e+279 > Math.random() 1.8338159666e-314 > Math.random() 5.94674714e-315 Now (EABI) : > 0.5 0.5 > 1/3 0.3333333333333333 > 3/4 0.75 > 654979/42 15594.738095238095 > Math.random() 0.9949778597801924 > Math.random() 0.40424828440882266 > Math.random() 0.7560287229716778 > Math.random() 0.7983868957962841 > Math.random() 0.9444687396753579 > Math.random() 0.11846696678549051 On Feb 14, 10:04 pm, Yoann Sculo <[email protected]> wrote: > 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) ? > > ... > > read more » -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
