64 bits (was: Squeak Oversight Board minutes – 5/01/12)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

64 bits (was: Squeak Oversight Board minutes – 5/01/12)

Bert Freudenberg


On 04.05.2012, at 10:16, Casey Ransberger wrote:

> Below.
>
> On May 4, 2012, at 12:55 AM, Nicolas Cellier <[hidden email]> wrote:
>
> (huge snip, context is in the rest of the thread)
>
>> IMHO, that's not only a question of handling huge image, there might
>> be an advantage for some applications with more speed-efficient object
>> format like for example:
>>
>> 1) immediate double values (like VW SmallDouble)
>> 2) immediate characters
>> 3) 32 bit integers, signed or unsigned - that would simplify a lot of
>> handlings, and greatly accelerate LargeInteger arithmetic which is
>> still based on 8bit operations on our 64 bits machines !
>>
>> Nicolas
>
> Mr. Cellier, a.k.a. "nice," is supporting my point flawlessly. I threw out a couple of reasons to design in particular directions as a way to illustrate that the road to 64-bit is not well defined for us yet, I did so to point out that just bitwidth isn't the only important consideration, and he's pointed out that even the arguments I presented as examples *grossly* underthink the issues involved.
>
> To be clear: I'm quite passionate about seeing a 64-bit Cog walk, and I think it's something to strive for, but there are some wonderful people using this VM with different goals, and perhaps unfortunately, learning what we all need from a 64-bit VM is likely to be a longish conversation.
>
> In any event, though, #doIt! Make it work, if you want it, and then the rest of the world will be quite out of your way while you're using what you've made. At least in Squeak, we can do stuff like that.
>
> CC Eliot because it's his baby and I don't even know what I'm talking about:) At least, he can probably speak to the challenges around 64-bit support as well as absolutely anyone else around.
>
>
> Casey


IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: 64 bits (was: Squeak Oversight Board minutes ? 5/01/12)

David T. Lewis
 
On Fri, May 04, 2012 at 11:59:10AM +0200, Bert Freudenberg wrote:

>
>
> On 04.05.2012, at 10:16, Casey Ransberger wrote:
>
> > Below.
> >
> > On May 4, 2012, at 12:55 AM, Nicolas Cellier <[hidden email]> wrote:
> >
> > (huge snip, context is in the rest of the thread)
> >
> >> IMHO, that's not only a question of handling huge image, there might
> >> be an advantage for some applications with more speed-efficient object
> >> format like for example:
> >>
> >> 1) immediate double values (like VW SmallDouble)
> >> 2) immediate characters
> >> 3) 32 bit integers, signed or unsigned - that would simplify a lot of
> >> handlings, and greatly accelerate LargeInteger arithmetic which is
> >> still based on 8bit operations on our 64 bits machines !
> >>
> >> Nicolas
> >
> > Mr. Cellier, a.k.a. "nice," is supporting my point flawlessly. I threw out a couple of reasons to design in particular directions as a way to illustrate that the road to 64-bit is not well defined for us yet, I did so to point out that just bitwidth isn't the only important consideration, and he's pointed out that even the arguments I presented as examples *grossly* underthink the issues involved.
> >
> > To be clear: I'm quite passionate about seeing a 64-bit Cog walk, and I think it's something to strive for, but there are some wonderful people using this VM with different goals, and perhaps unfortunately, learning what we all need from a 64-bit VM is likely to be a longish conversation.
> >
> > In any event, though, #doIt! Make it work, if you want it, and then the rest of the world will be quite out of your way while you're using what you've made. At least in Squeak, we can do stuff like that.
> >
> > CC Eliot because it's his baby and I don't even know what I'm talking about:) At least, he can probably speak to the challenges around 64-bit support as well as absolutely anyone else around.
> >
> >
> > Casey
>
>
> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.
>
> - Bert -
>

I agree. Aside from the work of building and distributing these VMs, the
two most serious issues to be addressed are these:

http://bugs.squeak.org/view.php?id=7237
0007237: Make FFI work on 64 bit platforms

http://bugs.squeak.org/view.php?id=7433
0007433: Gstreamer and Pango plugins fail on 64-bit host

Both of these involve pointer-to-int issues affecting the image(s),
the Slang, and the support code on multiple platforms.

A set of fixes was available for the FFI issue a few years ago (but
not pushed through due to some other higher priorities). This could
presumably be updated and applied to the various FFIs now in circulation,
but it will take some work and coordiation of multiple branches and
platforms to pull it off.

No fix is available for the Gstreamer/Pango issue, but I regard this
as equally high priority because the underlying issue is in the
SurfacePlugin, and fixes are likely to involve updates to images,
VMMaker(s), and platform code.

Aside from these, I think that any remaining 64-bit issues are
likely to be easily dealt with, at least in the sense that the
fixes will be limited in scope and can be done without a lot
of image/vm/plugin/support code coordination.

I should say though that we are actually in much better shape
than might be implied by the above. I use a 64-bit VM pretty much
all the time on my desktop (Cog too of course) and I have no
problems (I don't use FFI or Pango). And a 64-bit VM is perfectly
suitable for server deployments. There is no problem at all for
someone who is aware of the limitations and willing to compile
their own VM. But distributing a 64-bit VM to lots of people
who expect it to "just work" is another matter, I don't think
we're there just yet.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

Bert Freudenberg

On 04.05.2012, at 14:21, David T. Lewis wrote:

> On Fri, May 04, 2012 at 11:59:10AM +0200, Bert Freudenberg wrote:
>>
>> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.
>>
>> - Bert -
>>
>
> I agree. Aside from the work of building and distributing these VMs, the
> two most serious issues to be addressed are these:
>
> http://bugs.squeak.org/view.php?id=7237
> 0007237: Make FFI work on 64 bit platforms
>
> http://bugs.squeak.org/view.php?id=7433
> 0007433: Gstreamer and Pango plugins fail on 64-bit host
>
> Both of these involve pointer-to-int issues affecting the image(s),
> the Slang, and the support code on multiple platforms.
>
> A set of fixes was available for the FFI issue a few years ago (but
> not pushed through due to some other higher priorities). This could
> presumably be updated and applied to the various FFIs now in circulation,
> but it will take some work and coordiation of multiple branches and
> platforms to pull it off.
>
> No fix is available for the Gstreamer/Pango issue, but I regard this
> as equally high priority because the underlying issue is in the
> SurfacePlugin, and fixes are likely to involve updates to images,
> VMMaker(s), and platform code.
>
> Aside from these, I think that any remaining 64-bit issues are
> likely to be easily dealt with, at least in the sense that the
> fixes will be limited in scope and can be done without a lot
> of image/vm/plugin/support code coordination.
>
> I should say though that we are actually in much better shape
> than might be implied by the above. I use a 64-bit VM pretty much
> all the time on my desktop (Cog too of course) and I have no
> problems (I don't use FFI or Pango). And a 64-bit VM is perfectly
> suitable for server deployments. There is no problem at all for
> someone who is aware of the limitations and willing to compile
> their own VM. But distributing a 64-bit VM to lots of people
> who expect it to "just work" is another matter, I don't think
> we're there just yet.
>
> Dave


The OP's question was about a Cog VM compiled for x86_64 - is that easily available?

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

David T. Lewis
 
On Fri, May 04, 2012 at 02:36:28PM +0200, Bert Freudenberg wrote:

>
> On 04.05.2012, at 14:21, David T. Lewis wrote:
>
> > On Fri, May 04, 2012 at 11:59:10AM +0200, Bert Freudenberg wrote:
> >>
> >> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.
> >>
> >> - Bert -
> >>
> >
> > I agree. Aside from the work of building and distributing these VMs, the
> > two most serious issues to be addressed are these:
> >
> > http://bugs.squeak.org/view.php?id=7237
> > 0007237: Make FFI work on 64 bit platforms
> >
> > http://bugs.squeak.org/view.php?id=7433
> > 0007433: Gstreamer and Pango plugins fail on 64-bit host
> >
> > Both of these involve pointer-to-int issues affecting the image(s),
> > the Slang, and the support code on multiple platforms.
> >
> > A set of fixes was available for the FFI issue a few years ago (but
> > not pushed through due to some other higher priorities). This could
> > presumably be updated and applied to the various FFIs now in circulation,
> > but it will take some work and coordiation of multiple branches and
> > platforms to pull it off.
> >
> > No fix is available for the Gstreamer/Pango issue, but I regard this
> > as equally high priority because the underlying issue is in the
> > SurfacePlugin, and fixes are likely to involve updates to images,
> > VMMaker(s), and platform code.
> >
> > Aside from these, I think that any remaining 64-bit issues are
> > likely to be easily dealt with, at least in the sense that the
> > fixes will be limited in scope and can be done without a lot
> > of image/vm/plugin/support code coordination.
> >
> > I should say though that we are actually in much better shape
> > than might be implied by the above. I use a 64-bit VM pretty much
> > all the time on my desktop (Cog too of course) and I have no
> > problems (I don't use FFI or Pango). And a 64-bit VM is perfectly
> > suitable for server deployments. There is no problem at all for
> > someone who is aware of the limitations and willing to compile
> > their own VM. But distributing a 64-bit VM to lots of people
> > who expect it to "just work" is another matter, I don't think
> > we're there just yet.
> >
> > Dave
>
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

Bert Freudenberg

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.

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

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

David T. Lewis
 
On Fri, May 04, 2012 at 04:44:49PM +0200, Bert Freudenberg 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 may be the case, I really am not sure. Eliot?


> Cog would have to be cleaned up for pointer operations of course, just as you did for the interpreter.
>
> - Bert -
>
Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

Eliot Miranda-2
In reply to this post by Bert Freudenberg
 


On Fri, May 4, 2012 at 7:44 AM, Bert Freudenberg <[hidden email]> 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 -





--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: 64 bits (was: Squeak Oversight Board minutes – 5/01/12)

Colin Putney-3
In reply to this post by Bert Freudenberg
 
On Fri, May 4, 2012 at 2:59 AM, Bert Freudenberg <[hidden email]> wrote:

> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.

+1

Basically all operating systems are 64-bit now, and 32-bit
applications are now considered "legacy support".

Colin
Reply | Threaded
Open this post in threaded view
|

Re: 64 bits (was: Squeak Oversight Board minutes – 5/01/12)

dcorking
 
On Fri, May 4, 2012 at 6:37 PM, Colin Putney wrote:
>> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.
>
> +1
>
> Basically all operating systems are 64-bit now, and 32-bit
> applications are now considered "legacy support".

AFAICT Fedora 14, 15 and 16 shipped a broken VM for x86_64.  Meanwhile
the Fedora i586 (32 bit) VM works flawlessly on 64-bit Linux: it is
just a case of downloading the right RPM and installing it. I might
not be following the right bugzilla issues, or mailing list, as I
haven't noticed if Fedora has plans to put the i586 VM in the yum
repositories for x86_64 users.

Anyone heard anything?

David
Reply | Threaded
Open this post in threaded view
|

Re: 64 bits (was: Squeak Oversight Board minutes – 5/01/12)

Bert Freudenberg


On 04.05.2012, at 20:16, David Corking wrote:

>
> On Fri, May 4, 2012 at 6:37 PM, Colin Putney wrote:
>>> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.
>>
>> +1
>>
>> Basically all operating systems are 64-bit now, and 32-bit
>> applications are now considered "legacy support".
>
> AFAICT Fedora 14, 15 and 16 shipped a broken VM for x86_64.  Meanwhile
> the Fedora i586 (32 bit) VM works flawlessly on 64-bit Linux: it is
> just a case of downloading the right RPM and installing it. I might
> not be following the right bugzilla issues, or mailing list, as I
> haven't noticed if Fedora has plans to put the i586 VM in the yum
> repositories for x86_64 users.
>
> Anyone heard anything?
>
> David


There is no open Fedora bug report on that:

        https://bugzilla.redhat.com/buglist.cgi?component=squeak-vm&product=Fedora

The way this works is that the Fedora maintainer takes the release tar ball and makes a spec file that says how to compile it. That is pushed to the build server (koji) which cranks out a build:

i686/x86_64:

        http://koji.fedoraproject.org/koji/packageinfo?packageID=7779

ARM:

        http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=8845

As you can see, the package has been maintained by Gavin Romig-Koch initially, lately Daniel Drake and Peter Robinson have done it (they're both working closely with SugarLabs/OLPC).

IMHO our best bet is to convince them to package the latest unix VM (currently 4.4.7.2357) which should fix both the problem of not working on x86_64 and not being able to open closure images. Bug reports from users using their packages are pretty convincing (hint, hint).

- Bert -

Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

CdAB63
In reply to this post by dcorking
 
On 04-05-2012 15:16, David Corking wrote:

>  
> On Fri, May 4, 2012 at 6:37 PM, Colin Putney wrote:
>> (...)
> AFAICT Fedora 14, 15 and 16 shipped a broken VM for x86_64.  Meanwhile
> the Fedora i586 (32 bit) VM works flawlessly on 64-bit Linux: it is
> just a case of downloading the right RPM and installing it. I might
> not be following the right bugzilla issues, or mailing list, as I
> haven't noticed if Fedora has plans to put the i586 VM in the yum
> repositories for x86_64 users.
>
> Anyone heard anything?
>
> David
>
In Fedora 16 I compiled a SqueakVM (x86_64) that is "working flawlessy"
as far as I don't need FFI or plugins that must seek for proper
libraries. These "buts" are big ones since relevant part of my work
involves merging with CUDA routines and other external stuff (libfann,
etc). Anyways, the x86_64 compiled SqueakVM is nice enough not to blue
screen on me :) (as far as I don't do stupid things like forcing i686
libraries into x86_64 code).

I use the i686 version of Cog in the x86_64 box. Again, it works because
I installed the i686 "compatibility libraries". But FFI fails and system
becomes unstable when library search order is forced to go first i686
(issues related to subjacent x86_64 stuff like x_org_drv_nvidia "et
cœtera"). In this case, forcing leads to system crasy (as in the case of
SqueakVM).

CdAB


signature.asc (270 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

Igor Stasenko
In reply to this post by Eliot Miranda-2

On 4 May 2012 18:27, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Fri, May 4, 2012 at 7:44 AM, Bert Freudenberg <[hidden email]> 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.
>

Yes, 64bit mode is similar but not the same as 32bit. And of course
you cannot run binary compiled
for 32bits and expect that it will work correctly.

[a little OT] FWIW recently Camillo (with a bit of my help) added
support for 64bit assembler in AsmJit project.
So, actually we can produce 64-bit compatible code using smalltalk :)
But of course it is too far from having JIT compiler in VM.


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



--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

Eliot Miranda-2
 


On Fri, May 4, 2012 at 12:31 PM, Igor Stasenko <[hidden email]> wrote:

On 4 May 2012 18:27, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Fri, May 4, 2012 at 7:44 AM, Bert Freudenberg <[hidden email]> 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.
>

Yes, 64bit mode is similar but not the same as 32bit. And of course
you cannot run binary compiled
for 32bits and expect that it will work correctly.

[a little OT] FWIW recently Camillo (with a bit of my help) added
support for 64bit assembler in AsmJit project.
So, actually we can produce 64-bit compatible code using smalltalk :)
But of course it is too far from having JIT compiler in VM.

Woot!  Why not now apply that expertise to creating a CogIA64Compiler subclass of CogAbstractInstruction?  Bochs is easily reconfigurable as an x86-64.



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



--
Best regards,
Igor Stasenko.



--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

dcorking
In reply to this post by CdAB63
 
On Fri at 8:27 PM, Casimiro de Almeida Barreto said:
> In Fedora 16 I compiled a SqueakVM (x86_64) that is "working flawlessy"
> as far as I don't need FFI or plugins that must seek for proper
> libraries.

Great! Does sound work? Sound causes the Fedora 14 stock binary to seg
fault for me.

David
Reply | Threaded
Open this post in threaded view
|

Re: 64 bits

CdAB63
 
On 04-05-2012 17:18, David Corking wrote:

>  
> On Fri at 8:27 PM, Casimiro de Almeida Barreto said:
>> In Fedora 16 I compiled a SqueakVM (x86_64) that is "working flawlessy"
>> as far as I don't need FFI or plugins that must seek for proper
>> libraries.
> Great! Does sound work? Sound causes the Fedora 14 stock binary to seg
> fault for me.
>
> David
>
Nope. Sound is in the category that includes "FFI or plugins". It
crashes (sigsegv) and as it happens "inside foreign stuff" and the vm
doesn't handle it (capture the signal and translate into an
Exception/Error).

CdAB


signature.asc (270 bytes) Download Attachment