<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16608" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>I use pickles extensively and they are used also by network objects.</DIV>
<DIV>I've never used LAZYALIGN.</DIV>
<DIV>My vote is that we don't break something (pickles/netobj) to add support for something that is rarely used.<BR>Regards,</DIV>
<DIV>Randy</DIV>
<DIV><BR>>>> "Rodney M. Bates" <rodney.bates@wichita.edu> 2/15/2008 5:06 PM >>><BR>I'll put it in comments in the code. I am sure I can fix it to<BR>handle LAZYALIGN too, just not sure whether I can do it without<BR>requiring existing pickle files to be regenerated and/or existing<BR>code that reads/writes pickles to need recompilation.<BR><BR>Anybody on this list who has code that might be affected if pickles<BR>or compiled code were invalidated by a change?<BR><BR>I do propose we change the way of telling the compiler to do<BR>LAZYALIGN so that it is a property of a type and affects all<BR>variables of that type.<BR><BR>Olaf Wagner wrote:<BR>> Perhaps we should check-in this description somewhere near the<BR>> actual code? Or is there enough documentation already?<BR>> <BR>> Olaf<BR>> <BR>> PS: Based on your description, I'd say we should abandon LAZYALIGN.<BR>> Or at least put a big sticker on that it will break pickles.<BR>> <BR>> Quoting "Rodney M. Bates" <rodney.bates@wichita.edu>:<BR>> <BR>>> The word "Packing" in RTPacking is perhaps misleading. Using BITSIZE,<BR>>> etc. only works for getting object layouts as on the machine executing<BR>>> the code, which is all that is needed when writing a pickle.<BR>>><BR>>> When reading, Pickle code needs to know the layouts of a type both as<BR>>> it is on the reading machine and as it was on the machine that wrote<BR>>> the pickle. The type description that the compiler generates is<BR>>> excerpted and contains no field displacements, just lists of field<BR>>> types (which are either recursive type descriptions or builtin types).<BR>>> So it is independent of word sizes, etc.<BR>>><BR>>> Pickles regenerates the displacements using the few target machine<BR>>> characteristics in a RTPacking.T It traverses a type description and<BR>>> simultaneously computes two sets of field displacements, both as they<BR>>> are on the reading machine and on the writing machine. For the latter,<BR>>> the value of RTPacking.T is (after a compact bit encoding) stored in the<BR>>> header of the pickle file. For the former, it's gotten by techniques <BR>>> like<BR>>> using BITSIZE. This is actually all done in RTTipe, part of m3core, and<BR>>> called by Pickle code.<BR>>><BR>>> This is very fragile. RTTipe has to duplicate the compiler's layout<BR>>> behavior. There is no shared code. Making it common would involve<BR>>> quite a bit of rework, as the two use substantially different data<BR>>> structure and code organization. It will be obvious what kind of bit<BR>>> damage could occur if the two algorithms didn't agree.<BR>>><BR>>> This is why I am obsessing over LAZYALIGN. I have been comparing the<BR>>> field displacement computations in RTTipe and in the compiler. The<BR>>> former is oblivious to LAZYALIGN.<BR>>><BR>>> Note that all this is required even without any packing of small fields<BR>>> within words. E.G., a record with two INTEGER fields, pickled on a<BR>>> 32-bit machine and unpickled on a 64.<BR>>><BR>>> Tony Hosking wrote:<BR>>><BR>>>> Rodney,<BR>>>><BR>>>> Why does there need to be an entry for LONGINT in RTPacking? I <BR>>>> would have thought all packing is done on word-sized units anyway. <BR>>>> Each side of the connection can check BITSIZE(LONGINT) to figure <BR>>>> out what to do presumably no differently from the way INTEGER is <BR>>>> communicated between 32-bit and 64-bit machines. Am I missing <BR>>>> something?<BR>>>><BR>>>> -- Tony<BR>>>><BR>>>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote:<BR>>>><BR>>>>> Ah, OK. I don't much delve in pickle-land. Anything I can help with?<BR>>>>><BR>>>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote:<BR>>>>><BR>>>>>> 1) RTPacking.T and needs to have a separate size for LONGINT,<BR>>>>>> (which can vary independently of the size of INTEGER).<BR>>>>>> 2) Variable length values of subrange bounds found in type<BR>>>>>> descriptions (in TipeDesc.i3) can now have values beyond<BR>>>>>> what the native word size can represent.<BR>>>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently)<BR>>>>>> is not handled by Pickles.<BR>>>>>><BR>>>>>> I have done some coding on this, but have been interrupted.<BR>>>>>><BR>>>>>> Tony Hosking wrote:<BR>>>>>><BR>>>>>>> Why is LONGINT for pickles not yet supported?<BR>>>>>><BR>>>>>><BR>>>>>><BR>>>>>> -- <BR>>>>>> -------------------------------------------------------------<BR>>>>>> Rodney M. Bates, retired assistant professor<BR>>>>>> Dept. of Computer Science, Wichita State University<BR>>>>>> Wichita, KS 67260-0083<BR>>>>>> 316-978-3922<BR>>>>>> rodney.bates@wichita.edu<BR>>>><BR>>>><BR>>>><BR>>>><BR>>><BR>>> -- <BR>>> -------------------------------------------------------------<BR>>> Rodney M. Bates, retired assistant professor<BR>>> Dept. of Computer Science, Wichita State University<BR>>> Wichita, KS 67260-0083<BR>>> 316-978-3922<BR>>> rodney.bates@wichita.edu<BR>> <BR>> <BR>> <BR>> <BR><BR>-- <BR>-------------------------------------------------------------<BR>Rodney M. Bates, retired assistant professor<BR>Dept. of Computer Science, Wichita State University<BR>Wichita, KS 67260-0083<BR>316-978-3922<BR>rodney.bates@wichita.edu<BR><BR></DIV></BODY></HTML>