I don't think it's surprising that a 32 bit compiler likes to align data to 32 bit (4 byte) boundaries. ;-)

I'm no expert on this, but I suspect this may be an "optimisation" setting in the compiler build (for optimal code speed, I guess).

Another thing to try is the magic word "packed", as in "packed record", in lieu of simply "record" ...

Joe.

-----Original Message----- From: Oldham, Adam [SMTP:adam.oldham@marconi.com] Sent: Thursday, September 06, 2001 7:36 AM To: 'gpc@gnu.de' Subject: Problems/Questions/Answers

Well, I think I have figured out a way to work around the String problem. That being, to create types for each String I want to use and making it a packed array of whatever, for example: String2 = PACKED ARRAY[0..2] OF CHAR;

This will allow the length to be stored in byte 0, and allow data in 1..2. This does require that the CONCAT, etc functions to be modified, but that is far easier than modifying the GPC Source.

Now, I have a questions about GPC's word alignment. I currently have this source: =========================================================== program test;

type

desbuffer = packed array [1..8] of byte;

enum1 = (encrypt,decrypt);

record2 = record f1 : desbuffer; f2 : enum1; end;

record1 = record b1 : byte; b2 : byte; case INTEGER of 1 : (r2 : record2); end;

var r1 : record1;

begin

writeln('sizeof r1 = ',sizeof(r1));

writeln('r1.b1 = ',INTEGER(@r1.b1)); writeln('r1.b2 = ',INTEGER(@r1.b2)); writeln('r1.r2.f1 = ',INTEGER(@r1.r2.f1)); writeln('r1.r2.f2 = ',INTEGER(@r1.r2.f2));

end.

With, the alignment of the output is: sizeof r1 = 16 r1.b1 = 134678600 r1.b2 = 134678601 r1.r2.f1 = 134678604 r1.r2.f2 = 134678612

Our old compiler did this: sizeof r1 = 12 r1.b1 = 4197796 r1.b2 = 4197797 r1.r2.f1 = 4197798 r1.r2.f2 = 4197806

Basically, GPC adds 3 extra bytes between record r1's b2 variable and the variant part of the record, where our old compiler only used 1 byte more. Is there a way to get GPC to pack in more closely for this type of instance?

Next question regards ennumerated types, can enummerated type space be smaller than 4 bytes minimum? For example: TYPE: eVideoMode = (VideoStandard, VideoEnhanced); VAR a : eVideoMode;

BEGIN Writeln (sizeof(a)); end.

With GPC, the output is 4. With our old compiler, it stored the size of an enummerated variable as 1.

I know these questions may be annoying, and I apologize for that. But the compiler evaluation is almost complete. These are some of the last big features that we cannot find workarounds for.... so if you know any, please let me know.

Adam END

---

C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham@marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079

---

This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand.

---