2010/7/29 Eliot Miranda <eliot.miranda@gmail.com>

2010/7/29 Mariano Martinez Peck <marianopeck@gmail.com>

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
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project