On Sat, Apr 27, 2013 at 6:31 PM, Jeffrey Chimene <[email protected]> wrote:
> > There is a Mips instruction set simulator. It's probably going to be the > case that it will have to be a starting point. Or, is the mismatch between > the RISC and VLIW too great to use that as a starting point? > A few points: - There is also an ARM simulator; the two are fairly similar. - I'm not sure what problem you're trying to solve by using either of them as a "starting point" for IA64. I would probably use the x64 port as a basis because it matches IA64's pointer width. - The point of having simulators is that hardware architecture doesn't matter, as only compiled C++ code is executed. Theoretically, you should be able to compile V8 with the ARM simulator on an IA64 box today, it should "just work". - Simulators are slow. On an x86 workstation, running ARM code in the ARM simulator is about 100x slower than native ia32 code. Meaning: the ARM/MIPS simulators are super useful for development and testing, but rather pointless for production use cases. - As a consequence of the above, it might be a good idea to implement an IA64 simulator, at least if you want any help from people who don't have access to IA64 hardware (which isn't exactly common). For this particular sub-task, it would of course make sense to take a look at how the existing simulators are implemented. - Since you suggested to spearhead an IA64 port, I would have assumed that you are familiar with the characteristics of that architecture. If you aren't, then this may be a good time to discard the idea ;-) - Creating a new port is a significant amount of work. It takes at least one person-year to get the port up and running initially (about 50K LoC including lots of hand-written assembly need to be ported), and after that it's roughly one person's full-time job to keep it up to date. It is extremely unlikely that the V8 project would accept responsibility for maintaining an IA64 port after it is finished; you would have to do that yourself for the foreseeable future. - Personally I'm not convinced that investing time into the "Itanic" architecture is worthwhile, but that's obviously your choice. Feel free to fork V8 on github and get cracking! > > Jeff Chimene > > > Vyacheslav Egorov > > > On Sat, Apr 27, 2013 at 6:18 PM, Jeffrey Chimene <[email protected]>wrote: > >> On 4/27/2013 9:14 AM, Rodolph Perfetta wrote: >> >> In 2009 v8 didn't have a 64bits port, now as mentioned by Vyacheslav, it >> has (for intel x86-64). So the amount of bits is not a problem. >> >> >> And therein lies the problem: x86-64 instruction set isn't compatible >> with IA64 instruction set >> >> >> >> On 27 April 2013 16:29, Jeffrey Chimene <[email protected]> wrote: >> >>> On 4/27/2013 8:17 AM, Vyacheslav Egorov wrote: >>> >>> Amount of bits is not an issue here at all, for example V8 already runs >>> on x86-64 just fine. >>> >>> I should have been clearer. I'm referring to a thread from 2009 >>> >>> https://groups.google.com/forum/#!searchin/v8-dev/ia64/v8-dev/GuP1ZlPVIpE/uUUNjmXCJ-wJ >>> >>> Making V8 work on 64-bits is much much bigger than changing some types >>> around and changing the scons. It probably deserves some fairly big >>> design discussions, and I would guess it would take at least a few >>> months, and it will be hard not to fracture the code a bunch, with >>> separate code for 32/64 bit (GC, object layout, etc). >>> >>> >>> and in reply >>> >>> I'm certainly not expecting that type changes will magically make this >>> code 64-bit clean. If that were true, it would've been done already. >>> >>> If it would be better, I can do these changes out of tree and come back >>> with things when I have them working. My question from the previous email >>> is whether or not generic changes would be accepted into the tree or not - >>> if the answer is no, that's fine. >>> >>> >>> Despite confusingly similar names ia32 and IA64 (Itanium) are *very* >>> different architectures. >>> >>> Agreed. The mode on the IA64 that executes 32 bit instructions isn't >>> available on VMS >>> >>> >>> >>> I'd say generating efficient code for IA64 is much harder because >>> compiler has to carefully schedule instructions in instruction bundles >>> (IA64 is VLIW) to saturate execution units and avoid dreadful stalls. >>> >>> Agreed. That may be why IA64 hasn't been produced. OTOH. it may be that >>> the V8 code isn't 64-bit clean. >>> >>> >>> [though I heard that newest Itanium micro-architecture actually is >>> more forgiving to poor scheduling and is capable of a good built-in >>> out-of-order execution, but I am not closely following this things so I >>> might be wrong] >>> >>> >>> >>> >>> >>> Vyacheslav Egorov >>> >>> >>> On Sat, Apr 27, 2013 at 4:50 AM, <[email protected]> wrote: >>> >>>> Hi Folks, >>>> >>>> I'd like to spearhead a port to IA64 on OpenVMS, which does not support >>>> IA32 subset. Am I correct that this is a deal breaker in that true 64 bit >>>> is a major initiative? >>>> -- >>>> -- >>> >>> -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
