On 13 jun 2007, at 07:26, Contestcen@aol.com wrote:
That's precisely the point. The Borland, TMT, FPC and GPC compilers are not compatible on bit-packing. By using the Macro Compiler you get bit- packing which is independent of the compiler, so that programs compiled with any of these Pascal compilers can exchange data.
The bitpacking format is defined in the ABI of the respective platforms (at least all SYSV processor-specific supplements define how you should bitpack), and gcc follows that ABI.
Some documentation: * http://www.sco.com/developers/devspecs/abi386-4.pdf : i386 sysv abi supplement, see p. 3-6 and following (look, SCO is still useful for something after all :) * http://refspecs.freestandards.org/elf/elfspec_ppc.pdf : ppc sysv abi supplement, see p. 3-8 and following
Jonas
Let me see if I follow this. You posted to this forum because you were having problems with bit-packing. You said that you wanted bit-packing that would allow data exchange between programs that were compiled with different compilers, and perhaps ran on different platforms. The Pascal Macro Compiler could make that possible.
Now you say that there are standards for bit-packing, and that the GCC compiler follows the standards. Apparently the other Pascal compilers don't follow the standard. (So far as I know, the Borland and TMT compilers don't do bit-packing at all.) Also, the standard does not seem to work across multiple platforms because of different unit sizes.
But you still won't use the Pascal Macro Compiler because it solves the bit-packing problem by a means other than enforcing the bit-packing standard on all Pascal compilers. Does that sum it up?
Frank
************************************** See what's free at http://www.aol.com.
Contestcen@aol.com schrieb:
But you still won't use the Pascal Macro Compiler because it solves the bit-packing problem by a means other than enforcing the bit-packing standard on all Pascal compilers. Does that sum it up?
How does the pascal macro compiler solve it? It tries to solve it for bit/booleans arrays but not for subrange types which are much harder because of endian issues. Tries because it doesn't take care of things like debugging.
On 14 jun 2007, at 06:26, Contestcen@aol.com wrote:
Let me see if I follow this. You posted to this forum because you were having problems with bit-packing. You said that you wanted bit- packing that would allow data exchange between programs that were compiled with different compilers, and perhaps ran on different platforms.
Not just different compilers, but also written in different languages. On different platforms is orthogonal: if the ABI on different platforms is the same, it will work, otherwise not. Exchanging bitpacked data between little and big endian won't work in any case, because the formats are different (the former starts packing data starting from the least significant bit, the latter from most significant bit).
Now you say that there are standards for bit-packing, and that the GCC compiler follows the standards.
Yes, it does.
Apparently the other Pascal compilers don't follow the standard.
GPC does to a large extent, but not entirely. As far as I can tell, it currently does the same as FPC. That was what my question was about. TP indeed never supported bitpacking, and neither does Delphi. I don't know about TMT.
But you still won't use the Pascal Macro Compiler because it solves the bit-packing problem by a means other than enforcing the bit-packing standard on all Pascal compilers. Does that sum it up?
Interoperability with libraries on the same platform but written in other languages is very important to me. I don't expect GCC is going to start using the Pascal Macro Compiler to lay out its bitpacked structs. Further, as Florian noted, the code you linked to is only useful for sets and arrays of 1 bit quantities, and does help with generating correct debug info for such constructions. It does not help for bitpacked records or arrays consisting of subrange types.
Jonas
-
Contestcen＠aol.com -
Florian Klaempfl -
Jonas Maebe