October 2006 - 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

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

Re: Internal compiler error with non-matching method signatures
by Waldek Hebisch 08 Nov '06

08 Nov '06

Gale Paeper wrote: > Since the 20051116 workaround for the bug is to use the legal code > construct needed for a successful compile anyway, I don't have a presing > need for a 20051116 fix. Just reporting a bug to ensure it got fixed if > it hadn't already been taken care of in one of the later snapshots. > Thanks for the report. As I wrote it should be fixed in newer versions (unless the testcase hits two bugs and one is Mac specific). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

SDL and GNU Pascal
by Andreas K. Foerster 01 Nov '06

01 Nov '06

Hello sdl4fp-users, As some of you might remember, I wanted to use the SDL also with GNU Pascal in my project AKFQuiz. I tried to fiddle with the source code of SDL4Freepascal. But there was too much code to change just to find out how it works... So I decided to leave SDL4fp away and implement the few things I need from scratch. My project now is fully functional with GPC and SDL. It is not yet in the released version, but you can check out the CVS as described on the homepage (see link at the end of this mail). Now I want to share my findings with you, so probably you can use it for SDL4Freepascal... First of all, the types for variables are very different. SDL4fp uses "LongInt" for what is "int" in C - because LongInt happens to be 32Bit wide in FPC. But in GPC a LongInt is "at least" :-) 64bit wide! So it doesn't fit. Older versions of GPC intentionally kept the variable types compatible to their counterparts in C. Newer versions broke with that and introduced speacial types, like CInteger or CLongInt. Another difference to FPC is, that in GPC you have a more fine grained access to determine attributes, so you have really control about the size of variables. Here is the code snipplet for the types (from my "qsys.pas"): ----------------------------------------------------------------------- {$IfDef __GPC__} type Uint8 = Cardinal attribute (Size = 8); Uint16 = Cardinal attribute (Size = 16); Sint16 = Integer attribute (Size = 16); Uint32 = Cardinal attribute (Size = 32); Sint32 = Integer attribute (Size = 32); pByte = ^Uint8; {$if __GPC_RELEASE__ < 20041218} type CInteger = Integer; {$EndIf} { __GPC_RELEASE__ } {$Else} { not __GPC__ } type CInteger = LongInt; { @@@ for 32-Bit systems } CString = PChar; Uint8 = byte; Uint16 = word; Sint16 = SmallInt; Uint32 = cardinal; Sint32 = LongInt; pByte = ^Uint8; {$EndIf} { not __GPC__ } ----------------------------------------------------------------------- Note that you have to change "LongInt" to "CInteger" and "PChar" to "CString" in SDL4fp. SDL4fp links to the library by using the name 'SDL' after the "external" modifier. This doesn't work in GPC (yet). In GPC you have to use the compiler directive "{$L SDL}". In FPC there's also a possability to use it in a similar way with "{$LinkLib SDL}"... well it works, but not in every situation. So I decided to keep the name after the external clause, but with "IfDef"s around it. GPC compiles it without the IfDef, but there are lot of warning messages then. In FPC you must use the modifier "cdecl". In GPC that is the default, so you don't need it there. You can however declare it with "attribute(cdecl)", so you can simply write a macro to modify the "cdecl": "{$Define cdecl attribute(cdecl)}". C is case sensitive, while Pascal is not. So in GPC all Pascal identifiers are converted to lowercase at an early stage, this includes the procedure names. So you have a problem when your C identifiers need uppercase letters. This can only be solved by using an attribute which mentions the name again with its capitalisation: "name 'Example'". This name isn't converted to lower case, since it's a string-constant. FPC doesn't need that, but it doesn't harm there either. putting everything together it looks like in this example: procedure SDL_WM_SetCaption(title, icon: CString); cdecl; external {$IfDef FPC}'SDL'{$EndIf} name 'SDL_WM_SetCaption'; Well I still have a problem with CString parameters. FPC needs a type cast, while GPC doesn't accept a type cast here. I "solved" it again with "IfDef"s. Does anybody know a better solution? Please have a look at my source code for more information: http://cvs.sv.nongnu.org/viewcvs/akfquiz/srcbin/?root=akfquiz The relevant units are "sdlgrph.pas" and "sdlsnd.pas". The type definitions are in "qsys.pas". If you use my findings in SDL4fp, it would be nice, if you would mention me there as "AKFoerster". Related Links: GNU Pascal: http://www.gnu-pascal.de/ Free Pascal: http://www.freepascal.org/ SDL: http://www.libsdl.org/ SDL4Freepascal: http://sdl4fp.sourceforge.net/ AKFQuiz: http://akfquiz.nongnu.org/ -- AKFoerster

4 15

Problems after install
by Frank McCormick 30 Oct '06

30 Oct '06

Hello I am back trying my hand at Pascal again after a couple of years absence...and am relatively new to Linux so please bear with me. Just installed GPC with the built-in 3.3.3 GCC...but I can't compile any of the units in the units directory. I am using the commandline "gpc --automake crt.pas" I keep getting errors like this: /usr/lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' /tmp/ccOU5D50.o: In function `Textmode': crt.pas:(.text+0x125): undefined reference to `crt_Check_WinChanged' crt.pas:(.text+0x1a3): undefined reference to `crt_SetMonochrome' crt.pas:(.text+0x1b5): undefined reference to `crt_SetScreenSize' crt.pas:(.text+0x1e0): undefined reference to `crt_Window' crt.pas:(.text+0x1e5): undefined reference to `crt_ClrScr' /tmp/ccOU5D50.o: In function `crt_GetScreenSize': crt.pas:(.text+0x201): undefined reference to `crt_Check_WinChanged' //snip// What am I doing wrong ??? Thanks Cheers Frank in Montreal

2 2

Internal compiler error with non-matching method signatures
by Gale Paeper 27 Oct '06

27 Oct '06

While helping someone port a MacPascal Object Pascal program to GPC, an internal compiler error was encountered when an object method heading signature type declaration didn't match the method implementation's heading signature. A distilled down test program that reproduces the internal compiler error: {$mac-objects} program MethodParameterMismatchBug; type UInt8 = Byte; Str255 = record sLength: UInt8; sChars: packed array[1..255] of char; end; xButton = object procedure SetUp (name: Str255); end; procedure xButton.Setup(name: string); {WRONG} begin end; begin end. When you compile it with "gpc -c MethodParameterMismatchBug.pas", you get: MethodParameterMismatchBug.pas:17: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. The GPC used for compiling is the Mac OS X GPC that Adriaan is distributing from his web site. The specs are: Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/powerpc-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 It is obvious in this test program's small context that the parameter types are different between the declared method heading and the implementation method heading so the compiler should find an error since the two signatures don't match exactly. However, the error shouldn't be an internal compiler error. I'll mention there was a duplication of that parameter type mismatch with another object type's method heading in a larger code context that resulted in an error message something like the compiler was too confused to continue. However, I can't reproduce it with a small test program. Gale Paeper gpaeper(a)empirenet.com

2 1

Reading strings for old Pascal implementations
by Glenn Howes 27 Oct '06

27 Oct '06

if you had a Type like the following: ====================== Type TString12 = String[12]; ======================= and you had some old (PowerPC) code which read one in from a file as in: ====================== Procedure ReadStrings(FromFile:String); Var fToFile:Text; dataToRead: TString12; begin Open(fTextAbout, FromFile); ReadBytes:=ByteRead(fTextAbout, dataToRead,SizeOf (TString12)); ===================== Then how would you read it in using code that will work on both PowerPC and x86 processors? I looked at the data file, and it appears to be mainly text separated by null characters and occasionally null+linefeeds. Thanks. --glenn

1 1

gpc (MinGW) fails to compile
by Frank Kelly 20 Oct '06

20 Oct '06

Hi there, On attempting to compile Pascal code with gpc I get this message: >> gpc -v -c my_alg_boolv2.p Using built-in specs. Configured with: ../configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=pascal --disable-win32-registry --disable-shared --enable-sjlj-exceptions --without-x --enable-interpreter --enable-hash-synchronization Thread model: win32 gpc version 20051116, based on gcc-3.4.4 (mingw special) gpc1 -v -iprefix c:/mingw/bin/mingw32/3.4.4/ my_alg_boolv2.p -quiet -dumpbase my_alg_boolv2.p -famtmpfile=C:\Temp/cckFaaaa.gpa -version -o C:\Temp/ccuabaaa.s gpc: installation problem, cannot exec `gpc1': No such file or directory --------------------------------- I have these installed: gpc 20051116, based on gcc-3.4.4 (mingw special) gcc (GCC) 3.4.4 (mingw special) I had thought that these two were meant to be compatible with each other?!! Have checked and the actual path for gpc1.exe is C:\mingw\libexec\gcc\mingw32\3.4.4 Is there any way to fix this? Thanks in advance. -Frank

3 3