Re: Portable dumper ideas
On Thu, Feb 17, 2000 at 03:40:59PM -0800, Martin Buchholz wrote:
If it doesn't cost us anything to use oversized alignments, why
not
just always use ALIGNOF (max_align_t) to align everything we dump?
Then you'll lose space.
All real-world alignments are powers of two. As a consequence, most
of the time[1], you can know the alignment requirement of a bunch of
data by looking at the biggest power of two which divides its size.
That's what the align_table does.
Now, let's take a cons. 12 bytes. So the alignment is 4. If you put
a cons at a 4-bytes aligned address, the next address is still 4-bytes
aligned. That means you can pack conses next to each other without
losing space. In fact, you can pack anything 4-bytes aligned without
losing space.
The last thing the see is that a (say) 8-bytes alignement is also a 4,
2, and 1-byte one.
So if you dump the data biggest alignement first, without putting any
padding between elements, you actually are respecting alignements
without losing space. You also don't need to make any assumptions on
the maximum possible alignment (expect that I put a 256-bytes max
alignement assumption for simplicity).
Are we likely to actually dump anything that is going to have 1-byte
alignment?
Strings' data.
We might be able to do this for some opaque's, but since
the dumping code doesn't know how the opaques will be used, we can't.
And opaques have memory returned from malloc(), so it will also be
max_align_t-aligned.
Opaques are lrecords, all lrecords have an hardcoded 4-byte minimal
alignment (because of opaques, actually :-). Actually, that should be
8 on computers with 64 bits pointers, now that I think of it.
OG.
[1] Opaques are the only exception in our case. I hardcoded a minimal
4 bytes alignment for all lrecords because of them.