Hi Max,
On Jan 7, 2015, at 1:42 PM, Max Leske <maxle...@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. > > Cheers, > Max Eliot (phone) > >> On 07 Jan 2015, at 22:27, Max Leske <maxle...@gmail.com> wrote: >> >> Hi Clément >> >>> On 30 Dec 2014, at 12:36, Clément Bera <bera.clem...@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. >>> >>> 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 >
