On 08 Jan 2015, at 07:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Max,
On Jan 7, 2015, at 1:42 PM, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
Just to be sure: is the size of the header stil 32 bits? Or is it now 64 bits? Or is it 32 bits for now and will then become 64 bits? If it will become 64 bits anyway, we might aswell store 64 bits right away. That way we wonât have to make another change later on.
The method header is 32-bits;it's a SmallInteger. In the 64-bit VMs (standard and Spur) it is a 64-but integer but only 32-bits are used. If we were to use more bits then it would be very difficult to serialize and deserialize code between 64- & 32-bit images; it would require a recompile. Also the VMs would be a bit different and the image code for the compiler etc. so basically it's not going to happen. It breaks too many things.
I see. So Iâll use a 32 bit signed int representation. Thanks
Cheers, Max
Eliot (phone)
On 07 Jan 2015, at 22:27, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
Hi Clément
On 30 Dec 2014, at 12:36, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:
Hello,
As some of you may know, Pharo is being enhanced with support for multiple bytecode sets. This will allow to run at the same time compiled methods with 2 different bytecode sets for experimentation and to add easily the new bytecode set described in this ESUG paper <http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_A%20bytecode%20set%20for%...>.
The virtual machine knows which bytecode set the compiled method uses for its encoding based on the sign of its header. This means that on the contrary to right now, a compiled method *can* have a negative header.
The issue is that typically operations such as #bitAnd: or #+ to access bits of the smallinteger does not work the same way on negative integers (2 complement's implementation of integers), resulting in incorrect values. I am fixing the problematic cases in Pharo.
One case is in Fuel and I can't fix it myself. It's in:
FLCompiledMethodCluster>>#serializeInstance: aCompiledMethodToSerialize with: anEncoder
"some code" header := aCompiledMethod header. "some code" anEncoder encodeUint32: header "some code"
This looks problematic because now header is not a uint anymore but a sint. In addition, #encodeUint32: uses #bitAnd: which may work differently on negative integers.
What do you fuel experts think ? Is there anything to fix there ?
Replacing the header serialization with #encodeInt32: should fix the problem.
Every header will from now on be an sint, is that correct?
Iâll make the change and integrate.
Cheers, Max
Best,
Clement
_______________________________________________ Pharo-fuel mailing list Pharo-fuel@lists.gforge.inria.fr <mailto:Pharo-fuel@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel>