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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
