November 2007 - Gpc

Inefficiency of `mod'
by Emil Jerabek 26 Oct '10

26 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

New (gpc-20060325)
by Waldek Hebisch 08 Dec '09

08 Dec '09

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 Main change is preliminary gcc-4.0.x support. The other changes are rather small. Note that for "production use" 3.4.x and 3.3.x backend are prefered. Also, using 2.8.1, 2.95.3 and 3.2.3 backend should work, but is depreciated. For more detail see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20060325 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20060325 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

7 44

compiling static library + gpc runtime without _statvfs on Mac OS X for Intel
by Glenn Howes 20 Apr '08

20 Apr '08

Hello, After months of being distracted by another portion of my application, I'm back to creating a universal binary version of the Pascal based library we are linking into our C++ based application. The problem is the application will not launch under PPC on Mac OS X 10.3 (Panther). The console registers an undefined symbol: _statvfs expected to be defined in /usr/lib/libSystem.B.dylib After some research, I found this call is being used by the StatFS routine implemented in rts.c (line 1510) /** Get information about a file system. */ GLOBAL (Boolean _p_StatFS (char *Path UNUSED, StatFSBuffer *Buf)) { int Result; #ifdef HAVE_STATVFS struct statvfs b; errno = 0; Result = statvfs (Path, &b); Buf->BlockSize = (long long int) b.f_frsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_favail; #elif defined (HAVE_STATFS) struct statfs b; errno = 0; Result = statfs (Path, &b); Buf->BlockSize = (long long int) b.f_bsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_ffree; #else Result = -1; errno = ENOSYS; #endif if (Result == 0) return True; Buf->BlockSize = 0; Buf->BlocksTotal = 0; Buf->BlocksFree = 0; Buf->FilesTotal = 0; Buf->FilesFree = 0; return False; } It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files, which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library). Also, if I build my environment/library on a PowerPC using the build-on- powerPC-10.3.command, I end up with a different set of link problems involving the long double version of pow(). Besides which, I'd prefer to do my development on OS X for Intel going forward. I have tried hand editing the above routine and rebuilding my Pascal development environment, and pulling the statvfs.h file from my OS X SDK, and yet when my application links, it still has an unresolved reference to _statvfs. I'm not a build engineer, as my previous missives to this mailing list make clear, and I'm at a loss as to how to proceed. Just to be clear, I link in two static libraries: a universal version of the libgpc.a for the runtime, and a universal version of the library I've created. Neither of them contain the symbol _statvfs (at least I can't find that text in them). I link that with my application. The application now references _statvfs (I can now see the text in it's executable). I can't launch on 10.3. I comment out the calls to the Pascal library and recompile+relink, and the application no longer has the symbol and I can launch under 10.3. So something in either of the gpc associated libraries must be calling something which calls statvfs, making the linker (ld) mark statvfs as an unresolved symbol to be loaded in at runtime. At least that is my impression. So, I'd appreciate some suggestions. --glenn

4 8

Memory layout of array of variable size.
by Bastiaan Veelo 24 Dec '07

24 Dec '07

Hi, In an attempt to hook up to GTK+, I am trying to pass a Pascal array of varible size to C. Static arrays are fine, but these arrays carry some additional information like capacity and size, and I gues they could be received as a struct on the C-side. However, I cannot figure out the structure that the struc should have. I do like this in Pascal: procedure YGTK_init(var argc : CInteger; argv : array of CString); external name 'YGTK_init'; procedure Y_init; var argc : CInteger; argv : array[0..ParamCount] of CString; Counter : integer; begin argc := ParamCount+1; for Counter := 0 to ParamCount do begin argv[Counter] := NewCString(ParamStr(Counter)); end; YGTK_init(argc, argv); end; And like this in C: struct t_argv { int end; void *argv; }; void YGTK_init( int *argc, struct t_argv argv ) { printf("In ygtk.c:YGTK_init.\n"); printf("argv.end: %d\n", argv2.argc); printf("argv.argv address: %p\n", argv2.argv); printf("argv.argv int: %d\n", argv2.argv); printf("argv.argv string: %s\n", argv2.argv); printf("number of arguments: %d\n", *argc); } So I figured out that the first element in the struct is an integer containing the length-1 of the array, but what it should look like for the rest I do not know yet. Do you have an idea? Thanks, Bastiaan.

5 9

German Book about GNU-Pascal needs contributors
by Eike 06 Dec '07

06 Dec '07

Hi Folks! There is a book in German language about GNU-Pascal available at Wikibooks. See http://de.wikibooks.org/wiki/GNU-Pascal_in_Beispielen There is a publishing company, who is going to sell this and some other books from wikibooks. The money will be donated to the wikimedia foundation. I do not have the time, to step through this book again and fix all those things, which might have changed or should be rewritten. If someone would like to take this job, feel free. Translators are also welcome. Without your help, this book becomes more and more outdated and not worth publishing. Yours Eike

3 4

Updated review of GPC
by Scott Moore 27 Nov '07

27 Nov '07

I have completed a periodic update of a review for the GPC compiler with respect to its' ability to compile and run ISO 7185 level 0 standard programs. I present it here in advance of posting it on the web site: http://www.moorecad.com/standardpascal/compiler.html In order to give the members of the GPC group a chance to correct any errors or raise any complaints. You will please note that there is a section for GPC originator comments. I would be happy to accept any reasonable section the GPC group would wish to include in that section, limited only by size and taste concerns. I note that the web page for GPC does not specify who speaks for GPC, so I would only ask that if multiple people wish to post such a comment, the GPC group would work between its members to prepare a coordinated submittal. Thank you, Scott Moore <below contains the review> ======================================================================== GPC Last verified: November 25, 2007 ISO 7185 full standard test: One failure (see explanation) Version: gpc version 20051116, based on gcc-3.4.4 Pascal-s compile/run: Pass Implementation first order details: Processor run on: AMD Athlon 3200+ Bits: 32 Value of maxint: 2147483647 Default integer field width: 11 characters Default real format field width: 29 characters Default boolean field width: 6 Default character field width: 1 character. Implementation character set: ASCII My comments: 1. Test failure on ISO 7185 section 6.4.3.5, specifically the requirement that each line consist of a sequence of characters terminated by the eoln sequence. When a temporary (unnamed) file was output with an incomplete last line, and subsequently read back, the last eoln was found to be missing. The responsible parties for GPC have informed me that this problem has been fixed in the current version of GPC. When I am able to obtain and test that version, I will update this information. 2. The date of the version tested is fairly old (2005, above). The test was done using a "prebuilt" version of GPC (their terminology) from the GPC web site. The maintainers have recommended using a newer build of the source, which I didn't do for the following reasons. First, there is considerable effort involved with building GPC from source, and GPC is highly cross coupled to building GCC, itself a significant undertaking. Second, I don't believe most users would build their own new version, for similar reasons. Finally, the "current version" involves building from the current source with patches. It would be next to impossible for me to accurately specify such a "version" of the software. 3. The GPC documentation inaccurately states that the flag "--standard-pascal" is all that is needed to insure ISO 7185 level 0 compliance. In fact, this switch was found broken at the time of testing, and caused several normal ISO 7185 features to be incorrectly flagged as errors/warnings. In addition, the flag --field-widths was found to be needed. Finally, the version tested output several warnings with no relationship to Pascal (in fact, they were C language warnings). The net command syntax required to accurately compile ISO 7185 Pascal using GPC is: gpc --field-widths -Wno-warnings -o <program> <program>.pas Where <program> is the name of the Pascal program to be compiled. GPC originator comments: <Not supplied> =========================================================================

2 3

unsubscribe
by jamiekg＠wizardling.geek.nz 27 Nov '07

27 Nov '07

1 0

Most represented string in a TStringlist
by Contestcen＠aol.com 25 Nov '07

25 Nov '07

It looks like AOL may have converted my last message from plain text to HTML once again. Resending... Hi Is there an elegant way to determine which string is mostly represented in a TStringList? For instance if I've got the following the function should return 'Delphi': StringList[0] := 'Pascal'; StringList[1] := 'Pascal'; StringList[2] := 'Delphi'; StringList[3] := 'Delphi'; StringList[4] := 'Delphi'; - Wed, Nov 21 2007 1:04 pm 1 message, 1 author Probably the fastest way to do this is to hash each item to an integer and then count the occurrences of each hash value. Frank Rubin **************************************Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop00030000000001)

1 0

Most represented string in a TStringlist
by Contestcen＠aol.com 25 Nov '07

25 Nov '07

Hi Is there an elegant way to determine which string is mostly represented in a TStringList? For instance if I've got the following the function should return 'Delphi': StringList[0] := 'Pascal'; StringList[1] := 'Pascal'; StringList[2] := 'Delphi'; StringList[3] := 'Delphi'; StringList[4] := 'Delphi'; - Wed, Nov 21 2007 1:04 pm 1 message, 1 author Probably the fastest way to do this is to hash each item to an integer and then count the occurrences of each hash value. Frank Rubin **************************************Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop00030000000001)

1 0

ISO 7185 Failures [updated]
by Scott Moore 23 Nov '07

23 Nov '07

{****************************************************************************** GPC standard ISO 7185 test failures The following failures were found: =============================================================================== C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas fails.pas:115: error: ISO 7185 Pascal allows only simple constants fails.pas: In main program: fails.pas:136: error: this use of packed array components is an extension of fails.pas:136: error: Borland Pascal, traditional Macintosh Pascal fails.pas:137: error: this use of packed record fields is an extension of Borland fails.pas:137: error: Pascal, traditional Macintosh Pascal =============================================================================== None of these are valid failures, or indeed even have a reasonable explaination in the standard. Also, all of these used to work fine in GPC: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special) See the testing details for that compiler: http://www.moorecad.com/standardpascal/compiler.html Now, with "--standard-pascal" off: =============================================================================== C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas C:\GPC\usr\test>fails 1 10 100 2147483647 True False 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' =============================================================================== Items: 1. Integer field default appears to be "1". This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue. I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result. Again, this used to pass. 2. Boolean outputs nonstandard. There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be: True False For 4 (size of 'true') it would be: True Fals I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result. Again, this used to pass. 3. Last line in file without "eoln" not corrected as required by standard. In ISO 7185 "6.4.3.5 File types" lines without proper eoln are referred to as "partial lines", and are stated not to occur. In effect, the implementation must either make sure that an eoln is always generated at the end of the file, or that on read, an eoln is essentially inserted if missing at the end of the file. In effect, a text file must be completely empty or be structured as a series of whole lines, including an eoln at the end of each line. I don't believe this ever passed in GPC, but I was told it would be fixed in later revisions. Here is a -v dump on the GPC used: =============================================================================== C:\GPC\usr\test>gpc -v Reading specs from /ecos-c/gpc/usr/bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: ../configure --verbose --prefix=/usr --exec-prefix=/usr --sysco nfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --inf odir=/usr/share/info --enable-languages=c,pascal --enable-nls --without-included -gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --di sable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug -- enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sj lj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gpc version 20051116, based on gcc-3.4.4 =============================================================================== ******************************************************************************} program fails(output); const scst = 'this is a string'; type cset = set of char; prec = packed record i: integer; b: boolean; c: char; r: real; stc: cset; end; var i: integer; pavs: packed array [1..10] of cset; parec: prec; ft: text; ca: char; begin for i := 1 to 10 do pavs[i] := [chr(i+ord('a'))]; parec.stc := ['b'..'e', 'i']; writeln(1); writeln(10); writeln(100); writeln(maxint); writeln(true); writeln(false); rewrite(ft); writeln(ft, 'too much'); write(ft, 'too soon'); reset(ft); write(''''); while not eof(ft) do begin if eoln(ft) then write('<eoln>'); read(ft, ca); write(ca) end; write(''''); writeln(' s/b ''too much<eoln> too soon<eoln> '''); end.

3 3