On 25 aug 2006, at 01:09, Frank Heckenbach wrote:
You once suggested to rewrite packed array support significantly, also for other reasons. What are your current plans? If you're not planning to do it now, perhaps we should implement a temporary solution, even if less efficient, to fix the bug.
I have in the mean time implemented packed array support in FPC. I noticed GPC uses double precision shifts even in some cases where it is not needed at all, see e.g. http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/tests/test/ tparray7.pp?rev=4444&view=markup
In the nested loop at the start of the test8bit procedure, GPC uses double precision shifts (64 bit shifts on 32 bit) and a lot of conditional code (on PowerPC at least, with -O2), although plain 8 bit loads/stores are enough.
If you want to have a look at how FPC does things, the code is in http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/compiler/ cgobj.pas?rev=4491&view=markup
Search for a_load_subsetref_reg (load from an x-bitsized memory location into a register) and a_load_reg_subsetref (store from a register into an x-bitsized memory location). We use the same memory layout in both big and little endian as GPC.
The code there is 100% cpu-independent and should be fairly straightforward to understand. That said, I'm under the impression that GPC's bitpacked array support is implemented at a higher level (depending on lower level GCC support routines which may be similar to what in FPC above), so I don't know how useful this is for you.
The resulting code is fairly good in general (even when not optimized) and only uses basic operators (and, or, shl, shr, not).
Jonas