October 2005 - Gpc

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

25 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

other compilers
by Andres K. Foerster 16 Nov '05

16 Nov '05

Hello, as I'm interrested in free software pascal compilers, I'd like to hear about your opinions about the others. I don't want to start a flamewar - of course yours's the best! But what experiences do you have with the others? I know Free Pascal very well. It comes with a lot of extensions, is fast and produces small binaries. But when you want to program for different platforms, you'll end up with lots of {$IfDef}s. I had a look at p2cc, but it seems very weak, isn't it? Has anybody experiences with the pascal compiler from the ACK package? http://tack.sf.net/ Are there others? -- AKFoerster

6 19

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

Mac objects and Delphi classes
by Waldek Hebisch 03 Nov '05

03 Nov '05

I would like to slightly update Mac objects and Delphi classes support. In particular I ma thinking about options names. AFAICS there five major axes which differentiate dialects that we would like to support: 1) Value versus reference model: BP - value model (objects are values) OOE, Delphi, Mac - pointer model (object are pointer to values) 2) Static versus virtual methods: OOE, Mac - mehods are always virtual BP, Delphi - there are static methods 3) Keywords used: BP, Mac - use "object" as a keyword (but with different semantics) OOE, Delphi - use "class" keyword 4) Method redefinition: BP - silent overriding Delphi - silent shadowing, override needs "override" OOE, Mac - explicit "override" needed 5) Base object: BP, Mac - no base object, multiple roots OOE - "Root" is the root of inheritance tree Delphi - "TObject" is the root of inheritance tree There is also question if constructors are mandatory for objects with virtual methods. ATM I think that we may tie this to object model: in value model (BP) make them mandatory, in reference mode make them optional. Namely, Mac objects have no constructors while OOE and Delphi will get them without any explicit declaration. I propose to have the following options: -fobjects-are-references -- choose reference model even if the declaration uses "object" keyword, on for Mac Pascal, off otherwise -fmethods-always-virtual -- leave it as is -fobjects-require-override -- to require "override" even for objects declared using "object" keyword (classes will always require "override") -fdelphi-method-shadowing -- redefinition without override will shadow (hide) old definition. By default to hide old definition one would have to use OOE "view" or Delphi "reintroduce" directive -fbase-object= -- to add default parent to object without an explicit parent the last option will require some effort to implement. Additionally, we may have -fmac-objects directive, which would be equivalent to sum of -fobjects-require-override, -fmethods-always-virtual and -fobjects-are-references. Comments? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

6 16

External CString
by Eike Lange 31 Oct '05

31 Oct '05

Hi Folks! In a C wrapper file, I have the declaration /* xmlc.c */ const char* _c_CXML_DEFAULT_VERSION = XML_DEFAULT_VERSION; Now, I would like to use it in pascal. { xml.pas, Unit } unit XML; interface var C_HELPER_XML_DEFAULT_VERSION: CString; external name '_c_CXML_DEFAULT_VERSION'; attribute (const); XML_DEFAULT_VERSION: TString = CString2String (C_HELPER_XML_DEFAULT_VERSION); implementation {$L xmlc.c} end. Using this unit results in an error: "cannot evaluate this expression from a global declaration" "Error initial value is of wrong type". How can I use my string constant in GPC? Eike

2 2

protected var parameters and operators
by Adriaan van Os 28 Oct '05

28 Oct '05

Consider the following test program. program test; type Str255 = record sLength: Byte; sChars: packed array[1..255] of Char end; operator + ( protected var s1, s2: Str255 ) = theResult : Str255; var len1, len2: Integer; begin len1 := s1.sLength; len2 := Min( 255 - len1, s2.sLength); theResult.sLength := len1 + len2; if len1 > 0 then theResult.sChars[1..len1] := s1.sChars[1..len1]; if len2 > 0 then theResult.sChars[len1+1..len1+len2] := s2.sChars[1..len2]; end; var s1: Str255 value ( sLength: 1, sChars: 'A'); s2: Str255 value ( sLength: 1, sChars: 'B'); s3: Str255 value ( sLength: 1, sChars: 'C'); s4: Str255; begin s4:=s1+s2+s3 { Error: reference expected, value given }; writeln( s4.sChars[ 1..s4.sLength]) end. The program triggers an error for s1+s2+s3. The error doesn't occur when the expression has only one + operator (e.g. s1+s2). The problem disappears when using const parameters. It looks like the internal representation of an intermediate result is triggering the compiler error ! Regards, Adriaan van Os

3 2

gcc-4.0.2
by Russell Whitaker 27 Oct '05

27 Oct '05

hi Now that gcc-4.0.2 is out, is there a patch file for it? (tried 3.4.3, dosen't work) russ

4 4