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 - |
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 |
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 - |
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 |
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 - |
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 - > |
In reply to this post by Bert Freudenberg
On Fri, May 4, 2012 at 7:44 AM, Bert Freudenberg <[hidden email]> wrote:
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.
best, Eliot |
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 |
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 |
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 - |
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 > 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 |
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. |
On Fri, May 4, 2012 at 12:31 PM, Igor Stasenko <[hidden email]> wrote:
Woot! Why not now apply that expertise to creating a CogIA64Compiler subclass of CogAbstractInstruction? Bochs is easily reconfigurable as an x86-64.
best, Eliot |
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 |
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 > doesn't handle it (capture the signal and translate into an Exception/Error). CdAB signature.asc (270 bytes) Download Attachment |
Free forum by Nabble | Edit this page |