[m-dev.] Why do strings in Mercury need to be word aligned?

Peter Ross pdross at gmail.com
Wed May 6 22:46:09 AEST 2009


On Wed, May 6, 2009 at 6:57 PM, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> On Wed, May 06, 2009 at 06:31:26PM +1000, Peter Ross wrote:
>> Hi,
>>
>> Why does a MR_String need to be word-aligned?  What code will ever
>> look at the tag bits of a string and hence do the wrong thing?  I'm
>> sure that there is code, but I just can't think of what it is.
>
> I think that if you have:
>
> :- type maybe(T)
>    --->    yes(T)
>    ;       no.
>
> And then use the value yes("fish") the word-aligned string is packed with the
> tag bits for maybe so that it uses only two memory cells one for the actual
> string and one for maybe.
>
>  +-----+---------+        +--------+
>  | tag | pointer |------> | String |
>  +-----+---------+        +--------+
>
> If we couldn't use the lower two bits of the string pointer this structure
> would have to be:
>
>  +-----+---------------------------+     +----------------+     +--------+
>  | tag | pointer to string pointer |---> | String Pointer |---> | String |
>  +-----+---------------------------+     +----------------+     +--------+
>
> Other examples with other structures will also do similar things.  It also
> doesn't require use of the ploymorphic type as above.
>
Sounds like a reasonable explanation to me, only one slight concern is
that the compiler doesn't seem to do this optimization today at least
for the following function.

:- func f(string) = maybe(string).
f(A) = yes(A).

Is the reason above correct, or is there another more fundamental
reason than not allowing an optimization?

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list