Gpc September 2005

gpc@gnu.de

17 participants
24 discussions

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

Type compatibility rules?
by Peter N Lewis 04 Oct '05

04 Oct '05

Currently, this compiles, I would think it would give a type check error: program peter112; type p1 = ^MedInt; p2 = ^MedInt; procedure doit( p: p1 ); begin end; var p: p2; begin doit( p ); end. Should p1 and p2 be parameter type compatible? MWPascal complains of the type check on the parameter...? I tried searching the docs for type compatibility, but did not find anything on the subject, perhaps I need to read the spec? Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

7 15

Array splices?
by Peter N Lewis 30 Sep '05

30 Sep '05

I thought GPC handled array splices, but this: program peter109; type MyArray(count: Integer) = array[1..count] of Integer; var p: ^MyArray; begin New(p,10); p^[1..5] := p^[2..6]; end. Gives a compiler error: peter109.pas:9: error: type mismatch in array assignment It works for strings, but I guess strings have all that packed array of char type checking extra baggage. Should I just go back to BlockMoveData, or is there a way for array splice assignments to work, and if so, are they safe for overlapping moves? While I'm at it, is there any better way to zero part of such an array than: FillChar( p^[3], 4 * SizeOf(p^[3]), 0 ); And further while I'm at it, I looked at the docs for MoveLeft et al, and they are all under construction. Would it be worth while setting up a wiki for the docs? The docs already have an organizational layout, which is very helpful for starting a wiki and letting others add information. I've never set up a wiki before, but I'd be happy to set it up and look at transferring the existing documentation over if people thought it was a good idea. I know the docs are all tied in with the make system, and there might be some loss with regard to automation of that, but on the other hand it might mean more people participate in improving the docs so it might be an overall win. Anyway, just a thought, if there is no interest, I'll go back to reading move.pas to figure out what the RTS does ;). Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

2 5

GPC alpha
by Tom Schneider 27 Sep '05

27 Sep '05

Frank: > > | strawberry 40% cat t.p > > | program t (output); > > | begin > > | writeln(output,'hello world'); > > | end. > > | strawberry 41% /usr/local/gpc/bin/gpc t.p > > | strawberry 42% a.out > > | Segmentation Fault > > | > > | :-( > > Aha, so it isn't GPC that crashes, but the compiled executable. > That's already more information than in your last mail. Right. Sorry my previous email wasn't clear about that. > One possibility could be a confusion of runtime library versions or > compiler parts. I see your admin installed GPC in a nonstandard > directory. Did he do this correctly, i.e. either set the --prefix on > configure, or else set GPC_EXEC_PREFIX? I don't know, I'll pass this on to him. > If that's ok, can you run the program in a debugger to find out > where it crashes? Sure. ******************************************************************************** % cat t.p program t(output); begin writeln(output,'hello world'); end. % /usr/local/gpc-20050331/bin/gpc -v Reading specs from /export/data/local/gpc-20050331/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.3/specs Configured with: /export/home/bryantd/gpc-build/../gcc-3.3.3/configure --enable-languages=pascal --prefix=/usr/local/gpc Thread model: posix gpc version 20050331, based on gcc-3.3.3 % /usr/local/gpc-20050331/bin/gpc -g t.p % gdb t GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... (gdb) run Starting program: /home/strawberry/toms/work/emptytest/t Program received signal SIGSEGV, Segmentation fault. 0x189dc in _p_ReturnAddr2Hex () (gdb) quit The program is running. Exit anyway? (y or n) y I see now that my sysadmin did this: > I had compiled gpc on sparky so that it would be "solaris-8- > compatible", and then installed it on strawberry. I guess I could try > compiling the whole thing on strawberry and see if it makes any > difference. but uname -aimnprsvX gives SunOS strawberry 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Blade-1000System = S unOS Could that have caused this effect? Sparky is Solaris 2.8 and Strawberry is 2.9. Why GDB said 2.9 I don't know ... ******************************************************************************** > > | strawberry 44% /usr/local/gpc/bin/gpc -v > > | Reading specs from /export/data/local/gpc/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.3/specs > > | Configured with: /export/home/bryantd/gpc-build/../gcc-3.3.3/configure --enable-languages=pascal --prefix=/usr/local/gpc > > | Thread model: posix > > | gpc version 20050331, based on gcc-3.3.3 > > | > > | When I try to use /usr/local/bin/gpc-2.1 in my gpcc script > > | (/home/strawberry/toms/work/emptytest/gpcc2.1), I get: > > | > > | gpc1: Invalid option `-Wno-identifier-case-local' > > | > > | so I can't compile until this is fixed ... > > Uhm, fixed? gpc-2.1 is 3 years old, and we don't actually plan to > backport new features to it. If it's just this one (you don't > require other newer features), you can take out this option for 2.1 > (which simply didn't exist back then). I'm confused. All I knew was that I got this 'Invalid option' message, which seemed unrelated and off the wall. But it could mean that `-Wno-identifier-case-local' is no longer a valid option? Looking in what seems to be the current manual at http://www.gnu-pascal.de/gpc/GPC-Command-Line-Options.html#GPC-Command-Line… that flag is listed. Doesn't that mean it is a valid option? So I'm puzzled as to why it was objected to. I can't replicate the problem now so maybe sys admin was moving things around and I ended up working with an old version for a few minutes. ******************************************************************************** > > My gpcc script is at > > ftp://ftp.ncifcrf.gov/pub/delila/gpcc > > in gpcc2.1 I just modified the location of the compiler. > > It's a bit longish, so I can't read it all now. No problem, I included it only for completeness. > : # -Widentifier-case-local Please accept my apologies for that. It was material that went into the script when the issue first came up. I have removed it and tried to clarify the issue in the documentation. > 1. Do it yourself. I'm not an expert such as yourself. I have many papers to write and no time to become a GPC expert (though it would be fun to help you more than just reporting bugs). > 2. Ask politely and/or convince someone to do it for you. Please accept my apologies. > 3. Pay someone to do it for you. Unfortunately science has a shrinking budget in the USA ... My text modules are compiler independent and are not always consistent, so I had to just turn off the flag. > BTW, your quick jumping to conclusions that "[GPC] is too alpha" > when in fact it may just be an installation problem on your (or your > admin's) part, or claiming that an older version not supporting > newer options is something that needs to be "fixed" I am reporting a problem to you as best as I can. I'm not an expert, I do not know the guts of GPC. I did not know that an incorrect installation (if that's what happened) could cause such an effect as I have never seen that happen before. All I meant was that "this particular installation of a GPC alpha didn't work". GPC itself is clearly quite robust (thanks to you!), which is why I use it. The alpha GPC that we have produced a binary that crashed. I don't know why that may be. Alphas in general can crash - this is true for Mozilla. I would never ask you to 'fix' an older version! That's wasting your time! Isn't this 20050331 a newer version? Best Regards, Tom Dr. Thomas D. Schneider National Institutes of Health National Cancer Institute Center for Cancer Research Nanobiology Program Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.ccrnp.ncifcrf.gov/~toms/

3 2

CRT on mingw
by Andres K. Foerster 22 Sep '05

22 Sep '05

Hello, I normally do my programming with Free Pascal. But I wanted to give GNU Pascal a try again. Well I don't have any problems under GNU/Linux anymore, but the version for MinGW makes trouble with the CRT unit. I have installed PDCurses 2.6-2 for MinGW. Programs using the CRT unit do compile and the output stuff is all okay, but the input doesn't work as it should. On most keypresses ReadKey just returns #0+#255, just occasionly it returns the correct keycode. ReadLn also behaves strange: It takes and displays the entered text correctly, but when I press the Enter-key, it just displays a musical note (the character of #13). When I repeat typing the Enter key, then at some point it is accepted. But the input string still has all the other #13's at its end. Is GPC for MSYS better? Why is there a separate version anyway? I mean, MSYS belongs to MinGW, isn't it? I've seen, that GPC still doesn't support "{$AppType GUI}" or "{$AppType Console}". That's an extension comming from Delphi. Free Pascal supports it on the Windows and the Amiga platform. I found out, that in GPC they correspond to the linker-parameters "-mwindows" or "-mconsole". But it would be nicer to have it in the source code. -- AKFoerster

3 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc September 2005