[Vm-dev] 64 bits

Eliot Miranda eliot.miranda at gmail.com
Fri May 4 16:27:30 UTC 2012

On Fri, May 4, 2012 at 7:44 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 04.05.2012, at 16:33, David T. Lewis wrote:
> > On Fri, May 04, 2012 at 02:36:28PM +0200, Bert Freudenberg wrote:
> >>
> >> The OP's question was about a Cog VM compiled for x86_64 - is that
> easily available?
> >>
> >> - Bert -
> >
> > No, that would be a larger project. Eliot could speak to this better
> > than I can, but in general terms I expect that this would involve first
> > building a 64-bit StackVM (i.e. the current StackVM compiled in 64-bit
> > mode), and then developing the code generation for Cog. Both of these
> > would involve work above and beyond what I described above for the
> > interpreter VM. My assumption would be that these are large enough
> > chunks of work that we should not expect them to happen on a strictly
> > volunteer basis.
> >
> > Dave
> 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.

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.
http://wiki.osdev.org/X86-64#Entering_Long_Mode_directly.  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.

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.

> Cog would have to be cleaned up for pointer operations of course, just as
> you did for the interpreter.
> - Bert -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120504/89004c7f/attachment.htm

More information about the Vm-dev mailing list