2010/7/29 Eliot Miranda <[email protected]> > > > 2010/7/29 Mariano Martinez Peck <[email protected]> > > Hi folks. Hope Eliot is reading this thread. >> > > Yes, I'm reading :) >
THanks Eliot for all the answers. It seems they are all good news :) > > >> It is time to think in Pharo 1.2 and we need to discuss if we want to have >> CogVM as the standard Pharo VM. >> >> Most of us have tried it and found it incredible fast. So it would be very >> good to take advantage of it. But I think there are a couple of things to >> be discussed: >> >> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot >> quotes: >> "The Cog VM is a just-in-time compiler that currently supports only x86 >> > > It is only initially aimed at x86. That's the most important platform by > far from Teleplace's perspective and I suspect the majority of the community > is on x86. But Cog was designed form the outset to be portable. The Cogit > is architected to support other ISAs. See CogAbstractInstruction and its > one subclass CogIA32Compiler. To port to another ISA you should > subclass CogAbstractInstruction and implement the same protocol > as CogIA32Compiler. > > I would love to see a CogARMCompiler and a CogPPCCompiler and encourage > anyone with low-level expertise on those platforms to have a go. I'm always > here to answer questions. > > > This is great Eliot. I thought that Cog was completly aimed to x86 and that would be difficult to port. That was my concern, but now with what you said it is much clear :) > No effort has been made to maintain 64-bit compatibility. Apologies, this >> was unaffordable." >> >> So...how much important is this for us? do we care? and if we want to do >> it, is it "doable" ? is it less doable than the normal squeak VM ? >> >> I really would like to have 64bits VM + 64bits images in a near >> future...but hat's just my thoguhts. >> > > I'm also thinking abut 64-bits but want to do 64-bits with a new object > representation based on my 64-bit objrep for VisualWorks, which would > include SmallFloat. Realistically this is a year out, because the 32-bit > version of the new objrep and the pinning GC need to be implemented before > I'll be able to do a 64-bit VM. But it's an obvious and logical direction > to go in. > Excellent!! Just by curious, your idea, or what you did in VW, was to be able to put SmallFloats directly inside the address ? just like we do nowadays with SmallInteger ? > > 2) The status of the external plugins. Are they working with Cog ? Not >> only the "core plugings" but FFI, OSProcess (I read some problems with it), >> TrueType, etc... >> > > ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) > should work. But people need to build and test. > > 3) Is it stable for production use? For example, I read that with seaside >> there are some crashes. >> > > Well, it is the production VM at Teleplace so at least for one context the > answer is certainly yes. There must be something obviously broken with > sockets (is it all platforms or only linux?) because we use sockets > intensively at Teleplace and only see problems on a single customer's > machine which looks to be to do with virus protection. I'm on holiday next > week and am rather busy right now, but perhaps later in August I can work > with Lukas to try and sort out the socket issues. > ok... > > 4) Depends on heroes. I never liked this idea. It has nothing to do with >> Eliot. He is very cool and helpful. But I wonder, do we understand the new >> VM and the changes? are we able to handle and fix it even without eliot ? >> > > THis is a serious issue. I need to be nagged to document the system on my > blog. I mean to get to this (perhaps in September?). Alas a Smalltalk JIT > is a complex beast, significantly more complex than the interpreter, and is > not the easiest thing to understand or debug. So even if it is well > documented it'll be more difficult to fix than the interpreter, but that's a > price one has to pay for this kind of performance. > > I agree. That's why my concern. > >> 5) Integration to VMMaker. I saw that they started to merge cog (actually, >> I think only stack vm?) to the trunk of VMMaker. This is really good news. I >> hope everything is there and merged. >> > > Cog is a fork of VMMaker. We may be able to merge at some stage, and Cog's > Slang should still work with the old Interpreter. But for now, inevitably, > it's a fork. I needed to add a lot of functionality to Slang to write Cog, > and I didn't have the cycles to keep Interpreter up to date. That's life :) > > ok > 6) Binaries. It seems the official released didn't come with binaries. So >> we should compile it for each OS. >> > > There is /no/ official release. Until Cog has stabilized and the VM > maintainers have taken it up it's definitely unoffficial :) > Ok...forget the "official" word....where should we get the sources (svn) and the VMMaker code in order to compile the latest and build binaries? > > Ok..that's all my thoughts. I would really like to have a discussion here >> and see what to do.....grrrrrr you are all in holidays, aren't you? hahah >> > > two days to go :) > enjoy ;) > > >> >> cheers >> >> Mariano >> > > best > Eliot > > >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
