Hi, Any progress on this ? I have exactly the same problem, I'm trying to run v8 on an ARMv4 720T - 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 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... > > plus de détails » -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
