Waldek Hebisch wrote:
The main reasons for FPC to always use 32 bits are
a) binary compatibility b) performance (even on 64 bit machines, loading/storing a 32 bit value from/to memory is often faster)
I think that there is a subtle iteraction between space usage and instruction count. For data-heavy program storing sets as byte sequences will minimize space usage which may pay reducing cache misses. OTOH 64 bit machines tend to have 64 bit buses, so working in cache machine should handle 64 bit chunk as fast as 32 bit chunk. Hence, for mass operations (copy, sum or intersection) on moderate or large sets 64 bit chunks should give much better speed then 32 bit chunks.
Also things might change in the future, more likely to favour 64 bit access, so I don't think we should optimize too much for today's and yesterday's machines.
If someone sees a way to automatically detect the used set format inside gdb itself, that would be great as well of course.
What do you think?
My first thought was to change GPC representation to match gdb, but while we can rather easily (and with minor performance impact) change bit order in sets, the alignment problem remains...
Technically in the compiler proper the change would be just to set a few parameters to different value. The main change would be to runtime support. Here we depend very much on set alignment (of course removing alignment is doable, but we would get both lower performing and more complicated code).
Yes. I don't think that's worth it to please the debugger. I don't suppose there's a way to get GNU Modula 2 to align as well (should be more efficient for them, too), is there?
In principle gdb could try to detect the compiler: gpc uses some pretty characteristic symbols (like `_p_GPC_RTS_VERSION_20060215') and I suspect that FPC is doing something similar.
A nicer way would be to attach the necessary information to the type debugging info (e.g., a flag for alignment, and a size info or a base type for the size issue). I'm not sure what the various debug info formats support, though ...
BTW, one way to get rid of the size dependence (but not alignment) would be to be fully big-endian on big-endian machines, i.e. store the highest words first. That would also require code changes, but not nearly as much as removing alignment, and also only incur a minor performance hit, I think. Then it wouldn't matter whether they're accessed in 64 or 32 bit parts or whatever (modulo alignment padding, but this could perhaps be inferred from the total size). It wouldn't be compatible with FPC either, AIUI ...
Frank