<br><br><div class="gmail_quote">On Fri, May 4, 2012 at 7:44 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 04.05.2012, at 16:33, David T. Lewis wrote:<br>
<br>
> On Fri, May 04, 2012 at 02:36:28PM +0200, Bert Freudenberg wrote:<br>
>><br>
</div><div class="im">>> The OP's question was about a Cog VM compiled for x86_64 - is that easily available?<br>
>><br>
>> - Bert -<br>
><br>
> No, that would be a larger project. Eliot could speak to this better<br>
> than I can, but in general terms I expect that this would involve first<br>
> building a 64-bit StackVM (i.e. the current StackVM compiled in 64-bit<br>
> mode), and then developing the code generation for Cog. Both of these<br>
> would involve work above and beyond what I described above for the<br>
> interpreter VM. My assumption would be that these are large enough<br>
> chunks of work that we should not expect them to happen on a strictly<br>
> volunteer basis.<br>
><br>
> Dave<br>
<br>
</div>I thought that x86-64 was a strict extension of the 32 bit x86 model. So Cog's generated 32 bit code should work just fine even under x86-64.<br></blockquote><div><br></div><div>That's not quite true. x86-64 is actually a different ISA that adds 8 registers and a pc-relative addressing mode drops some instructions (inc dec, others?). IIRC one has to go through a mode switch to But the processor can execute both ISAs. On x86-64, x86 is a "sub-mode" and is entered via interrupts or "gate descriptors" (?). See e.g. <a href="http://wiki.osdev.org/X86-64#Entering_Long_Mode_directly">http://wiki.osdev.org/X86-64#Entering_Long_Mode_directly</a>. So executing 32-bit code inside a 64-bit process isn't trivial. Instead most x86-64 platforms do provide support for running x86 binaries in the x86 submode.</div>
<div><br></div><div>I wish it was easy, but I fear not. At the very least we would want a 32-bit to 64-bit transition on calling the FFI. Alternatively we could look at extending the Cog glue so that generated code is x86 but the glue calls x86-64 code in the rest of the VM. I don't have cycles for this, and personally would rather see work on a real x86-64 code generator with a full 64-bit image.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cog would have to be cleaned up for pointer operations of course, just as you did for the interpreter.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Bert -<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>