> On 08 Jan 2015, at 07:02, Eliot Miranda <[email protected]> wrote: > > Hi Max, > > > On Jan 7, 2015, at 1:42 PM, Max Leske <[email protected] > <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Clément >>> >>>> On 30 Dec 2014, at 12:36, Clément Bera <[email protected] >>>> <mailto:[email protected]>> 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%20adaptive%20optimizations.pdf>. >>>> >>>> >>>> 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 > [email protected] <mailto:[email protected]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel>
