<br><br><div class="gmail_quote">On Fri, May 4, 2012 at 12:31 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On 4 May 2012 18:27, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, May 4, 2012 at 7:44 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
>><br>
>><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>
>> >> 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>
>> 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>
><br>
><br>
> 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" target="_blank">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.<br>
><br>
> 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.<br>
><br>
<br>
</div></div>Yes, 64bit mode is similar but not the same as 32bit. And of course<br>
you cannot run binary compiled<br>
for 32bits and expect that it will work correctly.<br>
<br>
[a little OT] FWIW recently Camillo (with a bit of my help) added<br>
support for 64bit assembler in AsmJit project.<br>
So, actually we can produce 64-bit compatible code using smalltalk :)<br>
But of course it is too far from having JIT compiler in VM.<br></blockquote><div><br></div><div>Woot! Why not now apply that expertise to creating a CogIA64Compiler subclass of CogAbstractInstruction? Bochs is easily reconfigurable as an x86-64.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
>><br>
>><br>
>> Cog would have to be cleaned up for pointer operations of course, just as you did for the interpreter.<br>
>><br>
>> - Bert -<br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> best,<br>
> Eliot<br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Best regards,<br>
Igor Stasenko.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>