Gpc September 2005

gpc@gnu.de

17 participants
24 discussions

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 (… [View More]

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 (… [View More]

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, … [View More]

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 … [View More]

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 … [View More]< 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/> [View Less]

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.… [View More]

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, … [View More]

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. > … [View More]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/ [View Less]

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 … [View More]

3 12

2025

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