In message 20010310012841.A3478@esmeralda.gerwinski.de Peter Gerwinski writes:
David James wrote:
Have there been any changes in the packing of data in records or packed records between 19991030 and 20010306? Or any changes in the data transfer between variables and typed files (is that the correct name? I mean FILE OF Twhatever, where Twhatever is a TYPE defined in the source)?
I am not aware of any.
But do not rely too much on such things since they might change, for instance, when new types of processors show up.
My need is that I have FILEs of Twhatever that have been written by executables compiled under GPC 19991030 and I now want to read them using executables compiled under GPC 20010306.
Now I'd like to report a difference in this area (actually in the in-memory usage) between GPC19991024 and GPC20010306:
The following program:
program test9(input,output); const maxnum=4; TYPE T1=RECORD a1:array[1..maxnum] of byte; END; T2=RECORD a2:packed array[1..maxnum] of byte; END; T3=RECORD a3:packed array[1..maxnum] of 0..255; END; T4=RECORD a4:array[1..maxnum] of 0..255; END; begin writeln('t1: ',sizeof(t1):1); writeln('t2: ',sizeof(t2):1); writeln('t3: ',sizeof(t3):1); writeln('t4: ',sizeof(t4):1); end.
gives
t1: 4 t2: 4 t3: 16 t4: 16
under GPC20010306, and gives 4,4,4,16 under GPC19991030.
That is the PACKED ARRAY of 0..255 occupied 4 bytes under the old version and now occupies 16 bytes. Whilst I clearlyu have a workaround by switching from 0..255 to byte, that behaviour doesn't seem right to me.
That is the PACKED ARRAY of 0..255 occupied 4 bytes under the old version and now occupies 16 bytes. Whilst I clearlyu have a workaround by switching from 0..255 to byte, that behaviour doesn't seem right to me.
0..255 is an enumeration, of the base type, which is a 32-bits integer on a 32-bit computer/compiler (at least with my limited knowledge of the standard)
An array of 32-bits values don't need packing, so both are the same
I wouldn't consider this a bug, I think it is a TP incompability however, though I haven't tested it under TP.
David James wrote:
The following program:
program test9(input,output); const maxnum=4; TYPE T1=RECORD a1:array[1..maxnum] of byte; END; T2=RECORD a2:packed array[1..maxnum] of byte; END; T3=RECORD a3:packed array[1..maxnum] of 0..255; END; T4=RECORD a4:array[1..maxnum] of 0..255; END; begin writeln('t1: ',sizeof(t1):1); writeln('t2: ',sizeof(t2):1); writeln('t3: ',sizeof(t3):1); writeln('t4: ',sizeof(t4):1); end.
gives
t1: 4 t2: 4 t3: 16 t4: 16
under GPC20010306, and gives 4,4,4,16 under GPC19991030.
That is the PACKED ARRAY of 0..255 occupied 4 bytes under the old version and now occupies 16 bytes. Whilst I clearlyu have a workaround by switching from 0..255 to byte, that behaviour doesn't seem right to me.
Indeed, this seems like a bug to me (daj14.pas). GPC supports a non-standard `packed' for subranges (shrinking them to the smallest size possible, as opposed to the more efficient natural integer size), so the followwing is also a work-around (and the real bug seems to be that GPC doesn't carry over the `packed' to the array component).
a3:packed array[1..maxnum] of packed 0..255;
Frank
On 15 Mar 2001, at 2:07, Frank Heckenbach wrote:
David James wrote:
That is the PACKED ARRAY of 0..255 occupied 4 bytes under the old version and now occupies 16 bytes. Whilst I clearlyu have a workaround by switching from 0..255 to byte, that behaviour doesn't seem right to me.
Indeed, this seems like a bug to me (daj14.pas).
Regarding the PACKED keyword, the EP standard has only this to say (section 6.4.3.1):
"The designation of a structured-type as packed shall indicate to the processor that data-storage of states should be economized, even if this causes operations on, or accesses to components of, variables possessing the type to be less efficient in terms of space or time."
The word "should" above indicates, I believe, that GPC may either reduce the storage size or not reduce the storage size, i.e., PACKED may do something, or it may not; it's up to the compiler. Of course, it would be helpful if GPC did reduce the size, either to the minimum number of bits required, or to some multiple of the minimum addressable storage element (e.g., a byte for most machines).
...(and the real bug seems to be that GPC doesn't carry over the `packed' to the array component).
a3:packed array[1..maxnum] of packed 0..255;
I'm not sure whether you intend for "packed" to be carried over to _all_ array components, but note that the same section of the EP standard says:
"The designation of the structured-type as packed shall affect the representation in data-storage of that structured type only; i.e., if a component is itself structured, the component's representation in data-storage shall be packed only if the type of the component itself is designated packed."
This appears to state that:
a : packed array [1..5] of array [1..5] of 0..255;
...is _not_ equivalent to:
a : packed array [1..5] of packed array [1..5] of 0..255;
-- Dave
J. David Bryan wrote:
The word "should" above indicates, I believe, that GPC may either reduce the storage size or not reduce the storage size, i.e., PACKED may do something, or it may not; it's up to the compiler. Of course, it would be helpful if GPC did reduce the size, either to the minimum number of bits required, or to some multiple of the minimum addressable storage element (e.g., a byte for most machines).
Yes, according to the standard, it's not required (so even Borland is conforming in this respect ;-), but since we've decided to do packing at all, we should also do it "reasonable"...
...(and the real bug seems to be that GPC doesn't carry over the `packed' to the array component).
a3:packed array[1..maxnum] of packed 0..255;
I'm not sure whether you intend for "packed" to be carried over to _all_ array components, but note that the same section of the EP standard says:
"The designation of the structured-type as packed shall affect the representation in data-storage of that structured type only; i.e., if a component is itself structured, the component's representation in data-storage shall be packed only if the type of the component itself is designated packed."
This appears to state that:
a : packed array [1..5] of array [1..5] of 0..255;
...is _not_ equivalent to:
a : packed array [1..5] of packed array [1..5] of 0..255;
I'll note that (daj14b.pas).
Frank
On 16 Mar 2001, at 2:56, Frank Heckenbach wrote:
...but since we've decided to do packing at all, we should also do it "reasonable"...
One question is whether it is more "reasonable" to pack to bit or byte level. That is, should:
a : packed array [1..3] of 0..31;
...take two bytes or three? (It will take two if it's packed to the bit level, where each element uses five bits, or three if it's packed to the byte level, where each element uses eight bits. Presumably, an equivalent unpacked array would use twelve bytes, where each element uses four bytes if the "natural" word size is 32 bits.)
I suppose packing would be most "reasonable" if it packed to the bit level, as one could always explicitly pad to a byte boundary if desired, whereas it would take a fair programming effort (i.e., shifts and masks) to effect bit packing if GPC only packed to the byte level. I've used compilers that took the opposite approaches, and it seemed to me to be easier and cleaner from a user's programming perspective to work with the compiler that packed to the bit level.
Of course, that is easy for me to say, as I have no idea how hard it would be to implement either scheme in GPC! ;-)
-- Dave
J. David Bryan wrote:
On 16 Mar 2001, at 2:56, Frank Heckenbach wrote:
...but since we've decided to do packing at all, we should also do it "reasonable"...
One question is whether it is more "reasonable" to pack to bit or byte level. That is, should:
a : packed array [1..3] of 0..31;
...take two bytes or three? (It will take two if it's packed to the bit level, where each element uses five bits, or three if it's packed to the byte level, where each element uses eight bits. Presumably, an equivalent unpacked array would use twelve bytes, where each element uses four bytes if the "natural" word size is 32 bits.)
I suppose packing would be most "reasonable" if it packed to the bit level, as one could always explicitly pad to a byte boundary if desired, whereas it would take a fair programming effort (i.e., shifts and masks) to effect bit packing if GPC only packed to the byte level. I've used compilers that took the opposite approaches, and it seemed to me to be easier and cleaner from a user's programming perspective to work with the compiler that packed to the bit level.
Agreed.
Of course, that is easy for me to say, as I have no idea how hard it would be to implement either scheme in GPC! ;-)
GPC implements bit-level packing already (with `packed 0..13'), so I think it's only a matter of setting some flag in the right place in the compiler...
Frank
-
david＠tcs01.demon.co.uk -
Frank Heckenbach -
J. David Bryan -
marcov＠stack.nl