[M3devel] <*LAZYALIGN*>
Darko
darko at darko.org
Tue Feb 19 21:23:23 CET 2008
Thanks for raising a very good point. I'd say make it that traced
references will not be non-word aligned as a part of the alignment
behaviour.
On 20/02/2008, at 4:31 AM, Tony Hosking wrote:
> I get an error:
>
> "../src/Main.m3", line 6: Could not find a legal alignment for the
> packed type.
>
> for the type:
>
> TYPE
> T = RECORD
> a: BITS 8 FOR [0..255];
> c: BITS 16 FOR [0..65535];
> b: BITS 32 FOR INTEGER;
> END;
>
> Are you saying that lazy alignment permits this to compile?
>
>
> This is very scary! What happens if you write the following?
>
> TYPE
> T = RECORD
> a: BITS 8 FOR [0..255];
> c: BITS 16 FOR [0..65535];
> b: BITS 32 FOR ROOT;
> END;
>
> Now b is a *hidden* reference (because it is unaligned) that the
> garbage collector will not find if T describes a stack variable t:
>
> PROCEDURE p (x: ROOT) =
> VAR t: T;
> BEGIN
> t.b := x;
> x := NIL;
> ...
> garbage collector runs and moves object referred to by t.b but
> doesn't find t.b reference in stack!
> t.b^ causes chaos and destruction...
> END p;
>
> Thus, lazy alignment should only be permitted in UNSAFE modules. I
> hope that this is the case!
>
> On Feb 19, 2008, at 5:02 AM, Darko wrote:
>
>> There wouldn't be any explicit expression. in the source, but there
>> would be a flag in Target.i3 for turning it off and on for
>> different platforms.
>>
>> Although the details may be a bit off, the principal is this:
>>
>> before byte alignment change:
>>
>> RECORD
>> a: BITS 8 FOR 0..255; (* takes 32 bits *)
>> b: BITS 32 FOR INTEGER; (* takes 32 bits *)
>> c: BITS 16 FOR 0..65000; (* takes 32 bits *)
>> END;
>>
>> after byte alignment change:
>>
>> RECORD
>> a: BITS 8 FOR 0..255; (* takes 8 bits *)
>> b: BITS 32 FOR INTEGER; (* takes 32 bits *)
>> c: BITS 16 FOR 0..65000; (* takes 16 bits *)
>> END;
>>
>>
>> On 19/02/2008, at 3:40 PM, Tony Hosking wrote:
>>
>>> Thanks for the explanation! How does one express the alignment
>>> you support?
>>>
>>> It does sound like <*LAZYALIGN*> can go away.
>>>
>>> On Feb 18, 2008, at 8:44 PM, Darko wrote:
>>>
>>>> Actually rather than compilain rather grumpily, maybe I can just
>>>> make the
>>>> changes required to RTTipe and do the work to reomve the pragma.
>>>> I can
>>>> work with Randy to ensure it doesn't break pickles, there is no
>>>> reason why
>>>> it should.
>>>>
>>>> On tha subject Randy, I assume pickles encode the number of BITS
>>>> FOR
>>>> for a field? If not it should.
>>>>
>>>>
>>>>> We seem to be going through these same point several times. I'm
>>>>> not sure
>>>>> what the difficulty is, I'm just repeating myself.
>>>>>
>>>>> Keep in mind this applies *only* to packed structures, ie BIT
>>>>> FOR or bit
>>>>> fields.
>>>>>
>>>>> The change I put in libralised the *M3* alignment rules so that
>>>>> BITS FOR
>>>>> fields in structures would align on byte boundries if possible
>>>>> instead of
>>>>> restricting them to word alignment generally. GCC happily
>>>>> generates code
>>>>> for this. There may be restrictions in GCC's C as to how you can
>>>>> arrange
>>>>> bit fields but I don't see what they have to do with M3.
>>>>>
>>>>> This is absolutely essentail for using the native APIs on Mac OS
>>>>> X and its
>>>>> removal would make M3 pointless for use on the Mac, at least
>>>>> more me.
>>>>>
>>>>> This should be the default behviour. If you are using BITS FOR
>>>>> it's
>>>>> becuase you want to arrange the fields in a record in particular
>>>>> way. Why
>>>>> then arbitrarliy pad out the fields? If performance is an issue,
>>>>> the user
>>>>> should be using appropriate field bit sizes. The implementation
>>>>> rule for
>>>>> BITS FOR in M3 is implementation dependent, there are no
>>>>> language issues.
>>>>>
>>>>> The LAZYALIGN pragma (that is, the prgama itself) is something
>>>>> Olaf
>>>>> created and had nothing to do with me. I diagreed with it and
>>>>> never used
>>>>> it in the version of the compiler I ran. I support its removal.
>>>>>
>>>>>
>>>>>
>>>>>> On Feb 18, 2008, at 3:01 PM, Darko wrote:
>>>>>>
>>>>>>> The alignment behaviour is absolutely crucial to programming
>>>>>>> natively in Mac OS X and should be kept. I have a great need
>>>>>>> for it.
>>>>>>>
>>>>>>> The PRGAMA is of no use and can be removed.
>>>>>>>
>>>>>>> Does anyone have any objections to making this alignment
>>>>>>> behaviour
>>>>>>> standard?
>>>>>>
>>>>>> What do you mean make LAZYALIGN standard? Why wouldn't we go
>>>>>> with
>>>>>> the standard gcc-backend alignment? Perhaps I don't understand
>>>>>> what
>>>>>> it is you are doing or trying to do. Again, please remind me
>>>>>> what it
>>>>>> is that LAZYALIGN does and why it is needed.
>>>>>>
>>>>>>> On 19/02/2008, at 4:36 AM, Tony Hosking wrote:
>>>>>>>
>>>>>>>> Can someone remind me again why we need LAZYALIGN? I concur
>>>>>>>> with
>>>>>>>> Randy that if it is rarely used and moreso breaks things I
>>>>>>>> would
>>>>>>>> argue to abandon it.
>>>>>>>>
>>>>>>>> On Feb 18, 2008, at 10:56 AM, Randy Coleburn wrote:
>>>>>>>>
>>>>>>>>> I use pickles extensively and they are used also by network
>>>>>>>>> objects.
>>>>>>>>> I've never used LAZYALIGN.
>>>>>>>>> My vote is that we don't break something (pickles/netobj) to
>>>>>>>>> add
>>>>>>>>> support for something that is rarely used.
>>>>>>>>> Regards,
>>>>>>>>> Randy
>>>>>>>>>
>>>>>>>>>>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 2/15/2008 5:06
>>>>>>>>> PM >>>
>>>>>>>>> I'll put it in comments in the code. I am sure I can fix it
>>>>>>>>> to
>>>>>>>>> handle LAZYALIGN too, just not sure whether I can do it
>>>>>>>>> without
>>>>>>>>> requiring existing pickle files to be regenerated and/or
>>>>>>>>> existing
>>>>>>>>> code that reads/writes pickles to need recompilation.
>>>>>>>>>
>>>>>>>>> Anybody on this list who has code that might be affected if
>>>>>>>>> pickles
>>>>>>>>> or compiled code were invalidated by a change?
>>>>>>>>>
>>>>>>>>> I do propose we change the way of telling the compiler to do
>>>>>>>>> LAZYALIGN so that it is a property of a type and affects all
>>>>>>>>> variables of that type.
>>>>>>>>>
>>>>>>>>> Olaf Wagner wrote:
>>>>>>>>>> Perhaps we should check-in this description somewhere near
>>>>>>>>>> the
>>>>>>>>>> actual code? Or is there enough documentation already?
>>>>>>>>>>
>>>>>>>>>> Olaf
>>>>>>>>>>
>>>>>>>>>> PS: Based on your description, I'd say we should abandon
>>>>>>>>> LAZYALIGN.
>>>>>>>>>> Or at least put a big sticker on that it will break
>>>>>>>>>> pickles.
>>>>>>>>>>
>>>>>>>>>> Quoting "Rodney M. Bates" <rodney.bates at wichita.edu>:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
More information about the M3devel
mailing list