2010/7/30 Mariano Martinez Peck <[email protected]> > > > 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 ? >
Yes. The scheme provides IEEE double precision but with a smaller exponent so the range is the same as the 32-bit single-precision range. i.e. 3 bits are used as tag bits to distinguish SmallInteger SmallFloat Character and objects. That leaves 1 bit for sign, 52 bits for the mantissa and 8 bits for the exponent. The use of 3 tag bits comes from 64-bit pointers being 8-byte aligned and so having the least significant 3 bits 0. I don't want to defend that choice now just to give you a flavour of the representation: | 8-bit exponent | 52 bit mantissa | sign | tags | > >> 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
