[M3devel] <*LAZYALIGN*>

[Mika Nystrom]

Hi Rodney,

I am not sure if I am reading your email entirely correctly, but I
think so... you're trying to figure out things like offsets so the
Pickle runtime can re-build arbitrary data structures.

When we were doing some concurrent programming in my group about ten
years ago, we were using a user-level threading system (very similar
but not identical to the old user-level threads in M3) and we needed
to figure out the location of the stack pointer in a C jmp_buf.

We just wrote a program to do it...

Could you do that?  Write some arbitrary data whose bit pattern
you know to a field, cast it to char * (or some such), and search
for the bit pattern?  Do it over and over with random data, and there
you go... 

    Mika

"Rodney M. Bates" writes:
>The word "Packing" in RTPacking is perhaps misleading.  Using BITSIZE,
>etc. only works for getting object layouts as on the machine executing
>the code, which is all that is needed when writing a pickle.
>
>When reading, Pickle code needs to know the layouts of a type both as
>it is on the reading machine and as it was on the machine that wrote
>the pickle.  The type description that the compiler generates is
>excerpted and contains no field displacements, just lists of field
>types (which are either recursive type descriptions or builtin types).
>So it is independent of word sizes, etc.
>
>Pickles regenerates the displacements using the few target machine
>characteristics in a RTPacking.T  It traverses a type description and
>simultaneously computes two sets of field displacements, both as they
>are on the reading machine and on the writing machine.  For the latter,
>the value of RTPacking.T is (after a compact bit encoding) stored in the
>header of the pickle file.  For the former, it's gotten by techniques like
>using BITSIZE.  This is actually all done in RTTipe, part of m3core, and
>called by Pickle code.
>
>This is very fragile.  RTTipe has to duplicate the compiler's layout
>behavior.  There is no shared code.  Making it common would involve
>quite a bit of rework, as the two use substantially different data
>structure and code organization.  It will be obvious what kind of bit
>damage could occur if the two algorithms didn't agree.
>
>This is why I am obsessing over LAZYALIGN.  I have been comparing the
>field displacement computations in RTTipe and in the compiler.  The
>former is oblivious to LAZYALIGN.
>
>Note that all this is required even without any packing of small fields
>within words.  E.G., a record with two INTEGER fields, pickled on a
>32-bit machine and unpickled on a 64.
>
>Tony Hosking wrote:
>> Rodney,
>> 
>> Why does there need to be an entry for LONGINT in RTPacking?  I would  
>> have thought all packing is done on word-sized units anyway. Each  side 
>> of the connection can check BITSIZE(LONGINT) to figure out what  to do 
>> presumably no differently from the way INTEGER is communicated  between 
>> 32-bit and 64-bit machines.  Am I missing something?
>> 
>> -- Tony
>> 
>> On Feb 15, 2008, at 10:51 AM, Tony Hosking wrote:
>> 
>>> Ah, OK.  I don't much delve in pickle-land.  Anything I can help with?
>>>
>>> On Feb 14, 2008, at 11:02 PM, Rodney M. Bates wrote:
>>>
>>>> 1) RTPacking.T and needs to have a separate size for LONGINT,
>>>>    (which can vary independently of the size of INTEGER).
>>>> 2) Variable length values of subrange bounds found in type
>>>>    descriptions (in TipeDesc.i3) can now have values beyond
>>>>    what the native word size can represent.
>>>> 3) RTType.Kind.Longint (which I presume you, Tony, added recently)
>>>>    is not handled by Pickles.
>>>>
>>>> I have done some coding on this, but have been interrupted.
>>>>
>>>> Tony Hosking wrote:
>>>>
>>>>> Why is LONGINT for pickles not yet supported?
>>>>
>>>>
>>>> -- 
>>>> -------------------------------------------------------------
>>>> Rodney M. Bates, retired assistant professor
>>>> Dept. of Computer Science, Wichita State University
>>>> Wichita, KS 67260-0083
>>>> 316-978-3922
>>>> rodney.bates at wichita.edu
>> 
>> 
>> 
>
>-- 
>-------------------------------------------------------------
>Rodney M. Bates, retired assistant professor
>Dept. of Computer Science, Wichita State University
>Wichita, KS 67260-0083
>316-978-3922
>rodney.bates at wichita.edu