Re: Portable dumper ideas

OG> On Thu, Feb 17, 2000 at 03:40:59PM -0800, Martin Buchholz wrote: OG> Then you'll lose space. OG> All real-world alignments are powers of two. As a consequence, most OG> of the time[1], you can know the alignment requirement of a bunch of OG> data by looking at the biggest power of two which divides its size. OG> That's what the align_table does. OG> Now, let's take a cons. 12 bytes. So the alignment is 4. If you put OG> a cons at a 4-bytes aligned address, the next address is still 4-bytes OG> aligned. That means you can pack conses next to each other without OG> losing space. In fact, you can pack anything 4-bytes aligned without OG> losing space. Oh. Finalement je compris. Light bulb. Hmmmm The packing works if the size of our C structures is the same as the C sizeof (structtype), but not in general for flexible arrays that have arbitrary data hanging off the end. For example, struct foo { double d; size_t obj_count; Lisp_Object obj[1]; } If there are a variable number of obj's, and the size method returns offsetof (foo, obj[obj_count]), then we cannot portably pack foo's using the size method. If you want to save the space, then you must either do this non-portably, or perhaps add alignment information to the lrecord_description, or add an `align' method to struct lrecord_description. Most lrecords would use ALIGNOF (union { Lisp_Object obj; void *p; }). But some, like Lips_Opaque, would use ALIGNOF (max_align_t) I think we should try to get this right, else we'll again have weird platform-dependent crashes or platform-dependent inefficiency on unaligned accesses, which might be very difficult to diagnose if the maintainers never get access to such a system. OG> The last thing the see is that a (say) 8-bytes alignement is also a 4, OG> 2, and 1-byte one. OG> So if you dump the data biggest alignement first, without putting any OG> padding between elements, you actually are respecting alignements OG> without losing space. You also don't need to make any assumptions on OG> the maximum possible alignment (expect that I put a 256-bytes max OG> alignement assumption for simplicity). OG> Strings' data. But strings data is either in a string_chars_block (it would be nice to just copy all the string_chars_blocks into the dumped data, preferably after compacting), or malloc()ed for big strings, in which case the extra padding space will be insignificant. OG> Opaques are lrecords, all lrecords have an hardcoded 4-byte minimal OG> alignment (because of opaques, actually :-). Actually, that should be OG> 8 on computers with 64 bits pointers, now that I think of it. I was wondering about that hardcoded 4. Use ALIGNOF (max_align_t) instead? OG> [1] Opaques are the only exception in our case. I hardcoded a minimal OG> 4 bytes alignment for all lrecords because of them. Martin