IA64?

[jchi...@gmail.com]

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?

[Vyacheslav Egorov]

Amount of bits is not an issue here at all, for example V8 already runs on x86-64 just fine.

Despite confusingly similar names ia32 and IA64 (Itanium) are *very* different architectures.

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.

[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, <jchi...@gmail.com> 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
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeffrey Chimene]

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, <jchi...@gmail.com> 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
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
--
v8-dev mailing list
v8-...@googlegroups.com
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 v8-dev+un...@googlegroups.com.

[Rodolph Perfetta]

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.

[Vyacheslav Egorov]

Let me repeat: at the moment V8 works on x86-64 just fine, both Linux builds of Chromium and node.js on various 64bit OSes are using it without any issues.

Vyacheslav Egorov

[Jeffrey Chimene]

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

[Vyacheslav Egorov]

> And therein lies the problem: x86-64 instruction set isn't compatible with IA64 instruction set

That is exactly what we are talking about: it's instruction set that is the issue, not the amount of bits (32 vs. 64).

Vyacheslav Egorov

[Jeffrey Chimene]

On 4/27/2013 9:18 AM, Vyacheslav Egorov wrote:

Let me repeat: at the moment V8 works on x86-64 just fine, both Linux builds of Chromium and node.js on various 64bit OSes are using it without any issues.

I'm interested in OpenVMS; which is a 64bit OS that doesn't run on an x86-64 machine. It runs on an IA64 machine.
My concern is that the x86-64 code generated by V8 won't run on the IA64.

Cheers,
jec

[Jeffrey Chimene]

On 4/27/2013 9:22 AM, Vyacheslav Egorov wrote:

> And therein lies the problem: x86-64 instruction set isn't compatible with IA64 instruction set

That is exactly what we are talking about: it's instruction set that is the issue, not the amount of bits (32 vs. 64).

Exactly. My apologies for not being clearer. That's always been by concern. The 09 post was merely the springboard for this thread. It conflated the two issues: pointer size and machine code generation.

Thank-you for your patience.

Cheers,
jec

[Jeffrey Chimene]

On 4/27/2013 9:22 AM, Vyacheslav Egorov wrote:

> And therein lies the problem: x86-64 instruction set isn't compatible with IA64 instruction set

That is exactly what we are talking about: it's instruction set that is the issue, not the amount of bits (32 vs. 64).

So, to move the discussion along: the code is 64bit clean, but there is no IA64 machine code.

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?

Jeff Chimene

[Jakob Kummerow]

On Sat, Apr 27, 2013 at 6:31 PM, Jeffrey Chimene <jchi...@gmail.com> 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! 

[Jeffrey Chimene]

On 04/27/2013 10:18 AM, Jakob Kummerow wrote:

On Sat, Apr 27, 2013 at 6:31 PM, Jeffrey Chimene <jchi...@gmail.com> 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

--