Peter N Lewis wrote:

At 12:32 +0100 7/3/03, Adriaan van Os wrote:

...

We are running into a real problem while porting the Apple Pascal Interfaces to gpc.

Consider the following record definition:

type word16 = cardinal( 16); word32 = cardinal( 32); rec = record a: word16; b: word32 end;

For binary compatibility, the size of the 'rec' type must be 6 rather than 8.

...

Now, the problem is:

(1) --pack-struct doesn't seem to be available as a source code compiler option. (2) adding 'packed' to records makes it impossible to pass any field of the record as an actual 'var' parameter.

For these two reasons I have an urgent feature request, which is to make --pack-struct available as a compiler option that can be added to the Pascal source code.

Unfortunately, it looks like this will not help :-(

--pack-struct appears to do exactly the same thing as "packed record", which is too strong because of the added restriction of failing with var parameters.

What is needed is a relaxation of the alignment restrictions when building a record, without the onerous restriction of bitfield packing. Presumably this would help with Borland compatibility as well.

Basically, we need something like --record-alignment={1,2,4} (and a corresponding compiler directive we can add to the system interfaces) so that items N bytes or larger are aligned to N bytes (where N is 1 2 or 4).

If this sounds reasonable, and if folks have advice on the exact user interface for this, then I'm willing to take a crack at this in the source to "get my feet wet".

Specific advice would include the exact name "record-alignment", whether it should take a parameter, or instead be --no-record-alignment, --record-alignment1, --record-alignment2, --record-alignment4. The latter would seem more in keeping with the options in general, as I could not find any other compiler directive that took a parameter, but correct me if I'm wrong.

Without this, it'll be *very* challenging to get the Mac Pascal interfaces working, as many of them date back to the '80s on a 68000 which had generally 2 byte alignment.

It seems to me that the fundamental problem is to get the space correct. In which case changing the definition to:

type word16 = cardinal( 16); word32 = cardinal( 32); rec = record a : word16; b : array[1..2] of word16; end; or rec = record a, bhi, blo : word16; end;

should do it. Further interface code then needs to be generated to translate that b array, which should only depend on the word sex of the original.

Adriaan van Os wrote:

Peter N Lewis wrote:

...

What is needed is a relaxation of the alignment restrictions when building a record, without the onerous restriction of bitfield packing. Presumably this would help with Borland compatibility as well.

Basically, we need something like --record-alignment={1,2,4} (and a corresponding compiler directive we can add to the system interfaces) so that items N bytes or larger are aligned to N bytes (where N is 1 2 or 4).

If this sounds reasonable, and if folks have advice on the exact user interface for this, then I'm willing to take a crack at this in the source to "get my feet wet".

Specific advice would include the exact name "record-alignment", whether it should take a parameter, or instead be --no-record-alignment, --record-alignment1, --record-alignment2, --record-alignment4. The latter would seem more in keeping with the options in general, as I could not find any other compiler directive that took a parameter, but correct me if I'm wrong.

--record-alignment=n (where n=0, 1, 2, 4)

...

Without this, it'll be *very* challenging to get the Mac Pascal interfaces working, as many of them date back to the '80s on a 68000 which had generally 2 byte alignment.

--pack-struct is a gcc option, not a gpc option, so I wonder if packing is a front-end or a back-end issue. I hope Frank knows. The Apple version of gcc (front-end or back-end) has the following options: malign-mac68k, -malign-power and -malign-natural.

If there is a way to get C pragma's passed through from Pascal source code, Apple's "#pragma options align={mac68k|power|reset}" implementation is in file darwin-c.c located in the gcc/config directory of the GPC Mac OS X build source you are distributing from your GPC web page. In essense, all that is required to get mac68k alignment is to set maximum_field_alignment = 16 and for power alignment set maximum_field_alignment = 0. Apple's pragma code just maintains a save/restore stack and makes the appropriate assignment to maximum_field_alignment. (A batch file search on the sources will reveal maximum_field_alignment is used in stor-layout.c for field alignment for struct/record type layouts.)

If some sort of C pragma pass through isn't possible from Pascal source code, I suggest that the record alignment solution be compatible with Apple's solution which is in turn compatible gcc's general storage layout pragmas. That way we can piggyback off of Apple's efforts in maintaining mac68k and power record alignment working in gcc for Mac OS X.

Gale Paeper gpaeper@empirenet.com

Frank Heckenbach wrote:

Peter N Lewis wrote:

...

Basically, we need something like --record-alignment={1,2,4} (and a corresponding compiler directive we can add to the system interfaces) so that items N bytes or larger are aligned to N bytes (where N is 1 2 or 4).

Or would it be sufficient, say, to let `--pack-struct' pack to byte boundaries (more precisely, just like what GCC does), and only real `packed' structures to the bit level?

And add a compiler directive for `pack-struct'.

I will be pleased with the latter solution and it should be sufficient, especially in combination with a maximum-field-alignment directive. Besides, for binary compatibility, you can always add pad bytes.

I'm not exactly sure of the history, but I guess this was done before GPC supported bit-level packing at all (which wasn't implemented until 1997 IIRC). When it was added, maybe noone thought of the option, so I suppose the side-effects on the option's behaviour were never intended.

...

The Apple version of gcc (front-end or back-end) has the following options: malign-mac68k, -malign-power and -malign-natural.

I don't know what they do (don't seem to be part of official gcc-3.2.1). I hope they just set maximum_field_alignment.

Yes, non-standard gcc.

...

Also, it would be important to know if the restriction of passing fields of packed records as actual variable parameters could be relaxed to only those cases where the field isn't aligned on byte boundaries (as a non ISO-Pascal feature).

Too fragile -- adding, say a `Boolean' field before the field in question would break `var' parameter usage somewhere else.

OK, not needed with the above changes to --pack-struct.

Besides, some platforms require bigger alignment (many RISC machines). So, say, an Integer that happens to fall on an odd byte boundary would work as a `var' parameter on some machine and not on others.

Which implies that on such a platform --pack-struct will not pack on byte-boundaries but "more precisely, just like what GCC does" ?

Finally, this would be another standard incompatibility of dubious merit (if you want `var' parameters, don't use `packed', period) which is likely to cause problems when porting to other compilers ...

You migth say that it allows compilation of some BP (and maybe other dialect) programs which do use packed fields as `var' parameters (non-standard, since BP ignores `packed' completely). But it wouldn't work in general. A general solution to *this* problem would be a new option `ignore-packed' which is also easy to implement. Then BP compatibility would use `--pack-struct --ignore-packed'. :-)

Sounds logical.

Gale Paeper wrote:

...

If there is a way to get C pragma's passed through from Pascal source code, Apple's "#pragma options align={mac68k|power|reset}" implementation is in file darwin-c.c located in the gcc/config directory of the GPC Mac OS X build source you are distributing from your GPC web page. In essense, all that is required to get mac68k alignment is to set maximum_field_alignment = 16 and for power alignment set maximum_field_alignment = 0. Apple's pragma code just maintains a save/restore stack and makes the appropriate assignment to maximum_field_alignment. (A batch file search on the sources will reveal maximum_field_alignment is used in stor-layout.c for field alignment for struct/record type layouts.)

If some sort of C pragma pass through isn't possible from Pascal source code, I suggest that the record alignment solution be compatible with Apple's solution which is in turn compatible gcc's general storage layout pragmas. That way we can piggyback off of Apple's efforts in maintaining mac68k and power record alignment working in gcc for Mac OS X.

We don't need the `#pragma' syntax, I think. Implementing an option to set maximum_field_alignment would be easy. `maximum-field-alignment=N' (i.e. `--maximum-field-alignment=N' as a command-line option and `{$maximum-field-alignment N}' as a compiler directive; as usual these would be equivalent).

A maximum-field-alignment option and directive will be very welcome.

Regards,

Adriaan van Os

In article 200303110549.GAA21216@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes

OK. I also make `--ignore-packed' the default for `--ucsd-pascal', `--borland-pascal' and `--delphi' (perhaps also for `--mac-pascal', but someone will have to check the options for `--mac-pascal', anyway).

Why make ignore-packed the default for UCSD? It doesn't matter to us anymore but my recollection is that packing did work quite effectively in UCSD.

What does the following program do?

program test;

type Str255 = array[0..255] of char;

var a,b: Str255; begin a := a + b; end.

I would have expected it to error, but it compilers fine. Is this some sort of support for strings, cstrings or something?

I tried looking at the resulting .s file, but it produced quite a few lines of assembly code and I've never been good at reading PowerPC assembly. It had several memcpy calls in it.

Thanks, Peter.

At 14:28 -0800 11/3/03, Russell Whitaker wrote:

adding 3 more lines of code should answer your question:

...

program test;

type
  Str255 = array[0..255] of char;

var a,b: Str255; begin

 a := 'hello ';
 b := 'world';

...

a := a + b;

 writeln( a );

...

end.

Amusingly, yes, that is originally what I had. But since it only printed "hello" when I ran it, I presumed it was not what I expected. Indeed, when I run the above program, it outputs:

zany:~/unix/c% ./testpas2 hello zany:~/unix/c%

In fact, it seems to output "hello" followed by 256-5 spaces, followed by a newline.

So I'm still confused... Peter.

Peter N Lewis wrote:

What does the following program do?

program test;

type Str255 = array[0..255] of char;

var a,b: Str255; begin a := a + b; end.

I would have expected it to error, but it compilers fine. Is this some sort of support for strings, cstrings or something?

I think it's treating the arrays as strings (of fixed size), concats them, and truncates the result when assigning to a. So effectively, it does nothing. ;-)

That might be a misfeature, but I'm reluctant to do something about it now, until the whole string stuff is reorganized ...

Frank

At 18:54 +0100 10/3/03, Frank Heckenbach wrote:

...

Basically, we need something like --record-alignment={1,2,4} (and a corresponding compiler directive we can add to the system interfaces) so that items N bytes or larger are aligned to N bytes (where N is 1 2 or 4).

Or would it be sufficient, say, to let `--pack-struct' pack to byte boundaries (more precisely, just like what GCC does), and only real `packed' structures to the bit level?

And add a compiler directive for `pack-struct'.

Yes, I believe that would be perfectly sufficient. Any weird cases where there is:

record a: UInt8; b: UInt16;

can easily be fixed with a pad byte added in (and indeed probably long since have been in the interfaces anyway!).

We don't need the `#pragma' syntax, I think. Implementing an option to set maximum_field_alignment would be easy. `maximum-field-alignment=N' (i.e. `--maximum-field-alignment=N' as a command-line option and `{$maximum-field-alignment N}' as a compiler directive; as usual these would be equivalent).

This would be a bonus as well. The above would probably solve our problem sufficiently, the latter would allow is to translate pragma align mac68k and pragma align macpower directly to alignment=2 and alignment=4.

Thanks sounds great, thanks Frank! Peter.

Peter N Lewis wrote:

It seems it is not possible to use a conformant or open array to operator overloading, ie:

operator + ( const s1: array[n1..m1: Integer] of char; const s2: array[n2..m2: Integer] of char ) = ADD : Str255;

operator + ( const s1: array of char; const s2: array of char ) = ADD : Str255;

Whoa! That's a strange case even I hadn't thought of so far.

both fail with "operator must have two arguments", presumably because the conformant/open array passes hidden arguments for n1,m1 or High(s1) etc.

Is the error actually correct, or is the error just erroneously complaining about the hidden arguments (since there are two real arguments).

If the latter, it'd be nice to get this fixed since it would make porting of short strings a lot easier. If the former, are there any plans to remove this restriction?

The error message is indeed due to the hidden arguments, and removing it would be possible. But there are deeper problems. In the current implementation, overloaded operators are identified by type names, and conformant arrays have none. Solving that would require at least some extra code to make up special "names".

However, overloading shall be reimplemented sometime (though it's not a top priority for me). Also then I suppose conformant/open arrays would require some extra code, but quite different from what's required now.

So doing it now would in the long run be wasted effort, and I'm not actually sure of it's usefulness (see below).

Failing his, if I have six or seven string types (of different lengths), and I make an operator + and = for each pair, that is n**2 for each (perhaps 49 + operators and 49 = operators). Would doing this be stretching the compiler beyond it's design or would it be a perfectly reasonable thing to do?

I think the former. Writing 98 operators is not a problem by itself, but it's not a sign of good design.

Also, there's a rule of thumb, whenever there are already 7 items of something, more are likely to be added over time (well, weekdays may be an exception ;-) ...

Besides, an operator as above would accept too much (any array [with integer index] of char, not only the special "short strings"). You could check the lower index at runtime (so exclude 1-based "fixed strings"), but you'll get into trouble with BP-style "CString arrays" which are also 0-based.

Also, I noticed that := cannot be overloaded as an operator. This would also be a handy addition, although quite possibly it'd have to be a special case.

I don't think so. In Pascal (unlike C), `:=' is not an operator.

And I think it wouldn't really help you here. What about parameter passing? You'd need to convert them, so built-in routines like Length, Copy, SubStr, ... and RTS routines (a long list of string functions and another one of file name routines, etc.) will work. (Even if GPC supported function overloading, this would not be a realistic thing to do with so many functions, leave alone user-defined routines ...)

I once thought of something like "type cast operators" (as in C++), though I haven't thought about any details (syntax, how to implement it, probably not exactly easy) ...

All in all, I think implementing short strings in "user space" is a non-starter. You might have some limited success with quite some effort, but there will probably be restrictions and limitations all around. It's better done within the compiler.

Frank

Gale Paeper wrote:

...

I once thought of something like "type cast operators" (as in C++), though I haven't thought about any details (syntax, how to implement it, probably not exactly easy) ...

In a recent look at some PASCAL-XSC documentation, I noticed PASCAL-XSC provides support for both of these. I also noticed that type conversion/casting operators in conjunction with operator overloading is a bucket of worms in PASCAL-XSC just like it is in C++.

I feared so.

I'm just commenting on what PASCAL-XSC provides. Whether or not GPC should provide PASCAL-XSC compatibility support for those feature is a whole different subject.

I'm not sure if we should strive for full PXSC compatibility. It seems to have some more "interesting" issues. Maybe someday someone will try, but at least for now I won't ...

Frank