(Hmm, this mail hasn't appeared on the list yet, resending...) Den 01. sep. 2011 16:52, skrev ext Thiago Macieira: > On Thursday, 1 de September de 2011 15:09:27 [email protected] wrote: >>> It doesn't and that's the problem. The ARM simulator is supported right >>> now on >>> i386 only. Not even x86-64 is supported. See above. >> Hmmm... I didn't know that. I thought it was generic C++ code interpreting >> ARM instructions. Kent, can you have a look? > It is. The problem is that the ARM instructions are 32-bit, so they can't > reference the entire 64-bit address space. E.g.: > > src/3rdparty/v8/src/arm/assembler-arm-inl.h:254:49: error: cast from > 'v8::internal::Address' to 'int32_t' loses precision [-fpermissive] > > > From that i can think of the possibilities: > > 1) write a pseudo-processor that compiles to p-code and is executed by the > simulator only. > > 2) extend the MIPS code to support MIPS64 and simulate MIPS64 on 64-bit > processors > > 3) "invent" ARM64 (by extending ARMv7 like MIPS64 extends MIPS32) and simulate > that on 64-bit platforms > > 4) if all the addresses that the ARM code needs to load are in memory block > allocated by the engine, then modify the engine to be able to call back into > 64-bit code and, in the process, add the "high word" part of the 32-bit > registers. > > I think #4 -- my original intention -- is unlikely. > > MIPS32 and MIPS64 differ only that the latter has 64-bit registers and two > more > instructions ("load double" and "store double") and that 32-bit operations on > the registers clear the high word (like x86-64). Therefore, extending either > the MIPS engine to MIPS64 or the ARM engine to "ARM64" would involve extending > the register size, patching the code that loads/stores to memory pointers to > use the 64-bit operation and then adapting the simulator. > > The changes wouldn't be that big. It would start by replacing int32_t with > intptr_t everywhere where a pointer is being managed and in the register file. > > The advantage of MIPS64 over "ARM64" is that the instructions exist in the > ISA, so we don't have to "guess" where ARM will place the instructions in the > future. The advantage of ARM is that the code is more likely to be working at > all times, given Nokia and Google's priorities these days. > > However, neither simulator is meant for efficiency. They are meant for > debugging > the MIPS and ARM assemblers, so in that sense option #1 is preferable. > > Given unlimited time and unlimited resources, my recommendation would be > option #1. As that is not the case, options 2 and 3 are more likely. >
Great summary. Option 2 seems the most reasonable/low-effort to me, as MIPS64 is already an established architecture, and it doesn't differ much from MIPS32, as you pointed out. I created http://code.google.com/p/v8/issues/detail?id=1655 and sent a mail to the main MIPS/V8 guy, let's see what they say. Wish I could contribute, as I know MIPS32/64 quite well :( We do have collaborators at Szeged university who have V8 commit rights and can help us with this type of thing. Kent _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
