August 2005 - 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

Re: GPC on i686-apple-darwin
by Waldek Hebisch 19 Jan '06

19 Jan '06

Adriaan van Os wrote: > You were quite right about -fPIC. All the failures, except emil9.pas > disappear with -fno-pic. However, many of the other tests fail with > -fno-pic, because the option disables dynamic linking on Mac OS X. The > PPC back-end has a workaround (-mdynamic-no-pic) but that doesn't seem > to work for i686-apple-darwin. > I have just realized that Darwin PIC problem have nothing to do with Linux PIC problems: Darwin does not use the binutils feature (ELF GOT relocations) that Linux uses. > Updating the linker and assembler to odcctools-20050327 had no effect > on testsuite results. > > So, I must either > - find a backport of i686-apple-darwin PIC fixes > - find a solution for gcc-3.4 bootstrap problems > - wait for gcc-4.0 support. > > Still, I am glad with the results so far. > Well, I was able build 3.3.6 based cross-compiler for i686-apple-darwin target, and I can see duplicate labels in the assembler output. It seems that 3.4.3 has changed the parts responsible for generating those labels. I have found that 3.4.[34] contain blatant bug with easy fix: --- gcc-3.4.4/gcc/config/i386/darwin.h.orig Thu Jun 16 01:10:29 2005 +++ gcc-3.4.4/gcc/config/i386/darwin.h Thu Jun 16 01:10:32 2005 @@ -43,7 +43,7 @@ /* Use the following macro for any Darwin/x86-specific command-line option translation. */ -#define SUBTARGET_OPTION_TRANSLATE_TABLE +#define SUBTARGET_OPTION_TRANSLATE_TABLE { 0, 0 } #define ASM_SPEC "-arch i386 \ %{Zforce_cpusubtype_ALL:-force_cpusubtype_ALL} \ After that I can build the compiler proper. However I get ICE when building gcc runtime. Trying gpc on knuth3.pas (to get assembler output) give me ICE. Both ICE-s seem related to generting labels needed in PIC code... So, it seems that nobody tried gcc-3.4.x for i686-darwin for almost a year (ChangeLog entry for SUBTARGET_OPTION_TRANSLATE_TABLE change is from 2004-08-23) -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 9

Success!
by Peter N Lewis 11 Jan '06

11 Jan '06

Thanks to all the help from Frank, Waldek, Adriaan, Gale and others, I now have all of Interarchy compiling and running under GPC. 270 files, 160,000 lines of code, 290 Mac Style object types, all compiling and working. There are probably a few glitches left here or there, but I've tested out the bulk of the program and nothing remains broken (that was not before - it is bug for bug compatible ;-). Thanks all! Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

6 5

gp -j4
by Peter N Lewis 23 Nov '05

23 Nov '05

I have added support to gp for compiling multiple files simultaneously (akin to the -j4 flag to make). Since I have a dual processor machine, this dropped the total compile time for Interarchy from 8.4 minutes to 6 minutes. I basically replaced ProcessDependencies and CompileIfNecessary, and hardly touched any of the rest of gp. But the sections replaced are essentially complete rewrites. It's not the most elegant of code, is still full of debugging code, is not written in gp-style, and does not currently support a command line switch, is minimally tested, and perhaps not all that efficient, but if anyone is interested, I'm happy to send them the code. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

3 4

compute_checksum speed
by Peter N Lewis 16 Nov '05

16 Nov '05

One thing that stood out in the profile was that compute_checksum, a two line function that is called once for each loaded gpi is responsible for 12% of the total time. It scans through the entire gpi bytes (in this case, including my GPCMacOSAll 27Meg gpi, once for each of the 250 units in my project), that adds up to around 43 seconds of the 6 minute rebuild time. static gpi_int compute_checksum_original (unsigned char *buf, gpi_int size) { gpi_int sum = 0, n = 0; for (n = 0; n < size; n++) sum += n * buf[n]; return sum; } It appears that gpc_int is a 64 bit int on my system. I did some timing of some improvements: time= 42.1 sum= 46473731586140096 compute_checksum_original time= 35.0 sum= 46473731586140096 compute_checksum_unrolled time= 18.8 sum= 8551919141529536 compute_checksum_native time= 12.2 sum= -2963523148067389 compute_checksum_shift time= 7.8 sum= -852473248 compute_checksum_add (time is roughly the time in seconds gpc is taking just calling compute_checksum on the GPCMacOSAll.gpi in my complete rebuild). The unrolled version is pretty trivial, chops about 7 seconds off and has no consequences. Switching to native int instead of gpi_int affects the value of the checksum, reducing it's precision somewhat, but given the purpose of the checksum, I dont think it would impact on its purpose. This drops the time down by a further 16 seconds. The negative is it changes the existing gpi checksum, meaning all gpis would have to be recompiled. Switching to using shift instead of multiply drops the time a further 6 seconds. However the PowerPC is very good at shifts (and quite good at multiplys for that matter), so this would be something that should be tested at least on an Intel system to see how it compares. Switching to just basic addition drops the time a further 4 seconds, but at the loss of quite a lot of bits in the checksum. I would recommend that the loop be unrolled (trivial and no consequences), and then one of the native checksum routines, or something like it, be used, and the code can then use the new routine for new gpi's, and when reading existing gpi's first check if the checksum matches the new value, or failing that if it matches the old value. That way users will never notice the change. A possible patch for this is included below. I implemented this and it dropped the time to build from 6 to 5 minutes. I've attached the testchecksum.c file I used to check various checksum times, which could be used to compare the speed to the different routines on an Intel platform to see how the relative speed compares so that a generally good solution could be chosen. Please note, I dont have any attachment to the particular checksum routines included in testchecksum.c, they were just some quick routines I wrote to try out various solutions to see the affect they would have. Any checksum routine that was fast would be fine - a table driven CRC might work for example. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

5 28

gp and .m (objective C) files
by Peter N Lewis 05 Sep '05

05 Sep '05

gp works fine with including objective C files via: {$L file.m} but does not include the language extension for .m. Here is a trivial patch: --- gp.pas (revision 363) +++ gp.pas (working copy) @@ -80,13 +80,13 @@ LanguageNormalizedKind: array [TFileKind] of TFileKind = (fk_None, fk_Program, fk_Program, fk_Program, fk_CFile, fk_Object); - LanguageSuffixes: array [TFileKind, 1 .. 7] of String (4) = - (('', '', '', '', '', '', ''), - ('.pas', '.p', '.pp', '.dpr', '', '', ''), - ('.pas', '.p', '.pp', '.dpr', '', '', ''), - ('.pas', '.p', '.pp', '.dpr', '', '', ''), - ('.c', '.cc', '.cpp', '.C', '.c++', '.cxx', '.s'), - ('.o', '', '', '', '', '', '')); + LanguageSuffixes: array [TFileKind, 1 .. 8] of String (4) = + (('', '', '', '', '', '', '', ''), + ('.pas', '.p', '.pp', '.dpr', '', '', '', ''), + ('.pas', '.p', '.pp', '.dpr', '', '', '', ''), + ('.pas', '.p', '.pp', '.dpr', '', '', '', ''), + ('.c', '.cc', '.cpp', '.C', '.c++', '.cxx', '.s', '.m'), + ('.o', '', '', '', '', '', '', '')); It's only applicable to those platforms with Objective C support, but probably wont hurt any to include in gp by default. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

5 7

Newer snapshot
by James A. Morrison 05 Sep '05

05 Sep '05

Hey, Is it worth putting up another gpc snapshot? -- Thanks, Jim http://phython.blogspot.com

2 1

gdb types?
by Peter N Lewis 22 Aug '05

22 Aug '05

Given type definitions (in an interface unit) of: SInt32 = Integer attribute( size = 32 ); UInt32 = Cardinal attribute( size = 32 ); gdb gives useless stuff like: Subjectlen=<incomplete type>, Ov=$60fb40, Oc=<unknown type> (Where Subjectlen: SInt32 and Oc: UInt32) Is there any way to have these types complete/known and get gdb to display them? Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

Compilation error for negative constant on right side of an operation
by Pascal Viandier 17 Aug '05

17 Aug '05

Hi GPC crew, The following sample code does not compile properly with GPC (20050331). Program Real; Var R1, R2 : Real; Begin R1 := 4.21; R2 := R1 * -1.0; WriteLn(R2); End. GPC output: real.pas:6: error: syntax error before `-' The problem occurs with negative integer constants and any operator (+-*/) as well. Strange enough, if I modify the code for: R1 := 4.21; R2 := -1.0; R2 := R1 * R2; Or even for: R2 := -1.0 * R1; The code compiles and the output is as expected. It looks like one can assign a negative constant to a variable but cannot use it as an operand if it is on the right side. This is not a problem for multiplying but for the other operators... Could this be a bug? Thanks Pascal Viandier pascal(a)accovia.com

3 3

Fill string
by Contestcen＠aol.com 17 Aug '05

17 Aug '05

Frank H: > As I said, GPC doesn't check for using undefined values at all. > (Currently, and this isn't going to change soon, as this is not > exactly trivial to implement in general ...) I am with Frank on this. Many years ago, before Pascal existed, I used the Watfor Fortran compiler. This compiler always checked for uninitialized variables. The check was made by initializing all variables to the value 666 according to length (e.g., Boolean variables were set to x'66', fullword integers to x'66666666' and so forth). Every time a value was fetched it was checked for these values. This nearly doubled running times. A bigger problem was that the value 666 sometimes came up naturally in the course of computation. That would abort your run. It took a great deal of tricky programming to prevent this from happening. The alternative method of checking for uninitialized variables is to have a separate set of flags, one for every variable and component of every array and data structure. This not only costs heavily in execution time, it also costs in storage. Switching back and forth from checking On to checking Off might be more complex than simply turning on and off the option. There may be consequences due to having your variables change location. All told, I don't think the check for uninitialized variables is worth the effort. Frank Rubin

2 1