Waldek Hebisch wrote:
Jonas Maebe wrote:
Anyway, you could still do the adding/subbing/... of sets by typecasting the set to a MedCard array of the appropriate size. This issue is only with inserting/removing/testing elements (and in that case you're doing more or less random access, so there is less chance that the chunk you need is already in the cache).
There is still issue of alignment: we need alignment to avoid shifts when lower bounds do not match, also set variables must be allocated on proper (word) boundary. Looks messy.
I agree.
There have been plans for a long time to do that in FPC as well. If you do this as meticulously as Delphi does (its set size grows by 1 byte at a time), then you more or less need by definition a little- endian representation of sets in all cases though (because of the left-over bytes at the end).
I would say proper big endian representation. Currently both GPC and FPC use little endian bit order for set hunks, which conflicts with big endian byte order.
Indeed, it's a bit strange as it is now. Using proper big endian representation we'd be independent of word size (though not alignment). The byte order would then be the same between big and little endian machines, though not the bit order within a byte, so no binary compatibility (but we don't have that now, so we wouldn't lose anything).
Using big endian bit order would remove this discrepancy. However, I think about much simpler scheme, trying to allocate 1, 2, 4, 8 bytes (in that order) and if that fails allocating sequence of 8 byte words (all that assuming 64 bit machine, with obvious changes for other wordlengths). The main reason is that with such a scheme one can perform operations on small sets inline, using just a couple of instructions.
Seems reasonable.
Delphi way require rather complicated instruction sequence or special runtime routines.
I'd imagine so. I don't think that's worth it for larger sets (saving a byte at some performance cost or so), so we shouldn't bother.
Hmm, let me see: if we use natural alignment (to the chunk boundary) and the set needs bigger alignment then the size of variable gets bigger. So we can detect alignment used from the set bound and size of the set variable. AFAIK it is possible to tell gdb about correct size. So, if we agree to use natural alignment gdb can detect the exact amount used (sometimes it can not detect if alignment is used at all, so gdb must know if the natural alignment rule is used).
So, ATM for me bit reversal (plus teaching gdb about alignment) is the most attractive solution.
AFAICS any method to choose between set representations is going to be non-standard. I am not sure if some ad hoc extensions to format of debug info are better.
If we can get the extensions working through the backend and gdb, and perhaps even "officially" approved, I'd certainly prefer this. Otherwise, the "alignment detection", though it seems a bit backward, looks best to me.
Frank