September 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

gpc20060325 says "new style GCC `-H' output detected" and doesn't want to build
by Igor Marnat 03 Oct '06

03 Oct '06

Hello List! I've built two toolchains (native for i386-linux and cross for ppc-linux target) based on gpc 20060325 and gcc 4.0.3. I have the units that use {$L file.c} directive. Native compiler build them just fine but cross compiler of the same version gives an error "new style GCC `-H' output detected" and stops build. I couldn't find any information in Google and GPC mailing lists. Please, any ideas? Native compiler version: [igor@marnat2 main_program]$ gpc -v Using built-in specs. Configured with: ../gcc-4.0.3/configure --enable-languages=c,pascal --enable-threads=posix --prefix=/home/igor/src-big/tools Thread model: posix gpc version 20060325, based on gcc-4.0.3 Cross compiler version: [igor@marnat2 main_program]$ ppc-linux-gpc -v Using built-in specs. Configured with: ../configure --prefix=/home/igor/src-big/ELDK4.0/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libgcj --target=ppc-linux --with-newlib --enable-languages=c,pascal --enable-multilib=no --disable-multilib Thread model: posix gpc version 20060325, based on gcc-4.0.3 (DENX ELDK custom version 4.0.3-1) Best regards, Igor Marnat mailto:marny@rambler.ru

3 16

packed array size
by Jonas Maebe 03 Oct '06

03 Oct '06

Hello, What is the size of this packed array in gpc on 64 bit systems: type ta = 0..$7fffffff; tb = packed array[0..799] of ta; Is it 3100 or 3104 bytes? On a related note, can someone explain me how to build gpc for Mac OS X/ppc64? powerpc64-apple-darwin8 doesn't seem to be a supported target, but maybe it's called differently? Thanks, Jonas

5 13

import gpc
by Bastiaan Veelo 26 Sep '06

26 Sep '06

Hi there, Is it correct that gpc does not look in its own units directory by default? If I have a main.pas that does import gpc, I have to build with something like (on windows): @gpc --print-file-name=units > temp.tmp @SET /p GPC_UNITS=<temp.tmp DEL temp.tmp gpc --unit-path="%GPC_UNITS%" --automake main.pas Can this not be done more straightforward? gpc.exe 20051116, based on gcc-3.2.3 (mingw special 20030504-1) Best regards, Bastiaan.

3 4

Strange up-to-date check failure.
by Bastiaan Veelo 26 Sep '06

26 Sep '06

Hi, I finally reproduced an unjust "`somfile.gpi' must be recompiled" message with a minimal example. This is the tree: \ywin.pas \testy.pas \contrib\gpc.o \contrib\gpc.gpi gpc.* are compiled from gps.pas as supplied with the compiler. ywin.pas and testy.pas are as follows ============== ywin.pas START =================== MODULE ywin; EXPORT ywin = (dummy); IMPORT gpc only (PCStrings, CParamCount, CParameters); procedure dummy; end; procedure dummy; begin end; { dummy } end. ============= ywin.pas END ===================== ============= testy.pas START ==================== program testy; import ywin; begin end. ============= testy.pas END ====================== ============ Compile log START ================ >gpc -c -g --unit-path=contrib ywin.pas >gpc testy.pas testy4.pas:3: `ywin.gpi' must be recompiled ============= Compile log END =================== If ywin.pas and testy.pas live in the same directory you can get around this problem by making testy.pas with --automake, but if they live in different directories that does not work. The problem goes away if gpc.* are put together with ywin.pas. I have not tested whether this is a particular problem of gpc.pas or whether it happens with any unit interface. Best regards, Bastiaan.

2 1

clreol, wherex, etc how?
by Toby Ewing 15 Sep '06

15 Sep '06

Hi, all I'm running gpc-20041218, based on gcc 3.3.3, on a pc running RH Enterprise. I have several programs that use basic cursor controls -- wherex, wherey, clreol, and so on -- which I used to grab as externals: Procedure clreol; C; Procedure gotoxy (x : integer; y : integer ); C; Function wherey : integer; C; I have been unable to get the externals to "take" on this version of gpc, though I've tried about 20 variants -- external, asm_name, just about anything I could find in the docs and demos. It seemed logical to just "use crt" instead. Unfortunately, the CRT unit has resisted all my attempts at compilation. Specifically: * crt.pas won't compile unless crtc.c has been compiled first * "gcc -c crtc.c" fails because ncurses.h, panel.h, and term.h are missing. (In fact, panel.h and term.h are in the units directory, but presumably gcc wants them somewhere else.) My system claims to have ncurses 5.4-13 installed, but apparently that is not sufficient. I tried Willett's ncurses.gpc 20060207, but configure failed loudly because it couldn't find ncurses.h (WHICH ncurses.h, and where does it want it?). I tried the PDCurses-2.6 on the GPC libraries page, and here again configure failed (couldn't find Intrinsic.h). I am stumped. What can I do to get simple cursor control in my programs? many thanks, Toby

3 2

internal compiler error when trying to use record variable declared using "absolute" keyword
by Igor Marnat 04 Sep '06

04 Sep '06

Hello, List! Trying to build the program below using gpc 20060325 based on gcc 4.0.3 I've got "Internal compiler error". Sorry for a bit complicated test program but it's the simplest one I could produce to reproduce the bug. Error message: [igor@marnat2 internal_compiler_error]$ make gpc --automake test.pas <var_decl 0x401910d8 Eepromstor.155419 type <pointer_type 0x4018ec3c type <pointer_type 0x4018ea8c Eepromptr type <record_type 0x4018e510 Eepromtype> unsigned SI size <integer_cst 0x40139888 constant invariant 32> unit size <integer_cst 0x401398a0 constant invariant 4> align 32 symtab 0 alias set -1 main_variant <pointer_type 0x4018ea8c Eepromptr> pointer_to_this <pointer_type 0x4018ec3c>> unsigned SI size <integer_cst 0x40139888 32> unit size <integer_cst 0x401398a0 4> align 32 symtab 0 alias set -1 main_variant <pointer_type 0x4018ec3c>> used unsigned ignored SI file test.pas line 26 size <integer_cst 0x40139888 32> unit size <integer_cst 0x401398a0 4> align 32 context <function_decl 0x4018ee58 Eep> (reg/f:SI 0 ax [orig:63 Eepromstor.155419 ] [63]) chain <var_decl 0x40191144 D.606>> test.pas: In function `EAdvLineInfo': test.pas:31: internal compiler error: in expand_expr_real_1, at expr.c:6800 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. make: *** [all] Error 1 Offending program: program test; type LinesInfoPtr = ^LinesInfoType; LinesInfoType = array [0..99] of word; type EEPROMType = record LinesInfo: word; end; type StoragePtr = ^StorageType; StorageType = array [0..99] of byte; type EEPROMPtr = ^EEPROMType; var EEPROMStor: StoragePtr; EEPROMData: EEPROMPtr absolute EEPromStor; function EEP ( W: word): pointer; begin EEP := pointer (word (EEPromData) + W) end; function EAdvLineInfo (Line: ShortWord): word; begin EAdvLineInfo := LinesInfoPtr (EEP (EEPROMData^.LinesInfo))^ [Line]; end; begin writeln (integer (EAdvLineInfo (1))); end. ~ -- Best regards, Igor mailto:marny@rambler.ru

2 2