On 04/27/2013 10:18 AM, Jakob Kummerow wrote: > On Sat, Apr 27, 2013 at 6:31 PM, Jeffrey Chimene <[email protected] > <mailto:[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. > Thanks. I did not know that. > > * 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. > My point was that although the C++ code is 64bit clean, I'll still need a workbench on which to develop the machine code for the IA64 port. For that, I was going to start with a simulator. > > * 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". > Yes, I will try that. > > * 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. > Agreed. The simulator is merely a workbench, not intended for production. > > * 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. > That's why I was wondering if the "impedance mismatch" would be too great to use the existing simulators. I admit, I have only spent about 30 minutes peering at the code. From 10K feet it seemed to have an idea of specific machine instructions to simulate, but I could be wrong. > > * 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 ;-) > I'm not going to dish on IA64 in public, but I understand your point. I'm still trying to figure out what tools are available to me in the V8 toolbox. I now know that V8 is 64bit clean (which I was not sure of until this morning), and that there are two machine code simulators (arm and mips). There may be other reasons to discard the idea (viz. your next point) > > * 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. > Yeah, that's a considerable risk. > > * 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! > Fortunately, I'm not doing this on my own. It's in conjunction with the vms-ports project on Sourceforge. My goal is to enable what is currently called "payswarm" on VMS. To get there, among other issues, node.js must be ported. To enable node.js, V8 must be ported.
Thank-you for your detailed reply! Jeffrey Chimene > > > > Jeff Chimene > >> >> Vyacheslav Egorov >> >> >> On Sat, Apr 27, 2013 at 6:18 PM, Jeffrey Chimene >> <[email protected] <mailto:[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] >>> <mailto:[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 >>> >>> <https://groups.google.com/forum/#%21searchin/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] >>>> <mailto:[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 a topic in the > Google Groups "v8-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/v8-dev/HnPDu-HygB4/unsubscribe?hl=en. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- 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.
