August 2004 - Gpc

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 (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

-mlong-double-128
by Adriaan van Os 13 May '05

13 May '05

The following produces an internal compiler error: [G4:~/gnu/testgpc/adriaan] adriaan% cat compare.pas program Compare; procedure R ( var r1, r2: real); begin if r1 <> r2 then r1:= r2 - 1.0 end; begin end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o compare compare.pas -mlong-double-128 compare.pas: In procedure `R': compare.pas:6: error: unrecognizable insn: (insn 26 34 27 2 0x0 (set (reg:SI 126) (subreg:SI (reg:TF 33 f1) 0)) -1 (nil) (nil)) compare.pas:6: internal compiler error: in extract_insn, at recog.c:2175 It may be, of course, that the Darwin target doesn't properly support the -mlong-double-128 PowerPC processor option. If it's a gcc back-end bug, I can report it to Bugzilla. However, the "real" type used is 64-bit on the Darwin target, with or without -mlong-double-128 ... The option only changes the size of the "longreal" and "extended" types to 128-bit. Regards, Adriaan van Os [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc33d7/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d7/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d7 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3

6 15

cast increases required alignment of target type
by Adriaan van Os 15 Feb '05

15 Feb '05

Consider the followig test program: program TestCast; type BytePtr = ^Byte; IntPtr = ^Integer; var theBytePtr : BytePtr; theIntPtr: IntPtr; begin theBytePtr := nil; theIntPtr:= nil; theIntPtr:= IntPtr( theBytePtr); {testcast.pas:11: warning: cast increases required alignment of target type} BytePtr( theIntPtr) := theBytePtr; theBytePtr:= BytePtr( theIntPtr); IntPtr( theBytePtr):= theIntPtr; {testcast.pas:14: warning: cast increases required alignment of target type} end. 1. Compiling with gpc produces two warnings as indicated in the comment. The compiler warns if the "casting" pointer type (outside the parenthesis) points to a larger type than the "casted" pointer type (inside the parenthesis). Gale Paper brought to my attention that the same holds on the left side of an assignment and I am inclined to regard this as a bug - the compiler should check here for a smaller type, rather than a larger type. 2. the -Wcast-align and -Wno-cast-align command-line switches don't seem to work with gpc. Regards, Adriaan van Os

2 5

Environment variables on Mac OS X
by Adriaan van Os 01 Nov '04

01 Nov '04

As discussed before, shared libraries on Mac OS X can not reference the environ variable directly, where applications can. This is a show stopper on Mac OS X, because of the internals of autoconf and because the environ variable is referenced in gpc's runtime library. To solve this problem, I apply the following patch: --- gcc/p/rts/rts.c.orig Wed Apr 16 01:58:46 2003 +++ gcc/p/rts/rts.c Fri Jun 6 11:35:50 2003 @@ -195,7 +195,15 @@ extern int errno; #endif -#if defined (HAVE_ENVIRON) || defined (environ) +/* needed by Mac OS X */ +#if defined (__MACH__) && defined(__APPLE__) +#include <crt_externs.h> +#endif + +/* on Mac OS X the environ variable can not be referenced in shared libraries */ +#if defined (__MACH__) && defined(__APPLE__) +#define environ (*_NSGetEnviron()) +#elif defined (HAVE_ENVIRON) || defined (environ) #if !defined (environ) && !defined (ENVIRON_DECLARED) extern char **environ; #endif I would be grateful if this patch is merged with gpc's sources. Regards, Adriaan van Os

2 4

gpidump
by Adriaan van Os 19 Oct '04

19 Oct '04

Another problem - with most .gpi files, gpidump stops with the following error: gpidump: ... .gpi: unexpected flag `unused lang flag 1' I tried this with gpc-20030830 and gpc-20040516, both with gcc-3.3.2 on powerpc-apple-darwin. Regards, Adriaan van Os

5 9

Re: GPC and Threads
by Jose Pascual 07 Oct '04

07 Oct '04

Hi Markus, first of all thank for you answer. > Jose Pascual wrote: > > I'm working in port some of my little application to linux. > All of my > > application has been writting in pascal. My porting to > linux is going > > ok but some of them use threads. > > > > I have read in GPC lists there are people working in a > thread unit for > > GPC, aren't you? > > Yep. great! > > Could someone share this unit with me? I could help to debugging it. > > I'm almost done with the threads themselves and mutexes. If > that is sufficient for your purposes, I'll put it online as > soon as I've finished testing. It'll be afable! I'm in a hurry so I have made some very alpha version with importing funtion from libpthread so I'd like to test your beta version. I'll need threading an semaphore in my application. Do you know (more or less) you are going to put it online? > > thank you so much > > You're welcome, > > Markus thank again best regards Jose Pascual

15 117

building GPC toolchain. Large Files Support.
by Igor Marnat 22 Sep '04

22 Sep '04

Hello dear list! I'm building GPC for arm-elf target. In the source directory in files p/rts/configure.in and rts.h options "_LARGEFILE64_SOURCE" and "_FILE_OFFSET_BITS 64" are hardcoded. Is it really necessary? Is it possible to build GPC without large file support as it doesn't make sense for embedded platforms? It doesn't depend of version of GPC sources. Best regards, Igor Marnat mailto:marny@rambler.ru

3 9

Mac OS X Pascal Interfaces for GNU Pascal
by Adriaan van Os 09 Sep '04

09 Sep '04

Peter N. Lewis and Gale Paeper have been working hard on the Mac OS X Pascal Interfaces for GNU Pascal. The results are impressive: - added 59 new units, to a total of 268 units and 197731 lines of Pascal - added CFSTR support - added support for four char code constants - added compatible Interfaces for MetroWerks Pascal. The software can be downloaded from <http://www.microbizz.nl/gpc.html>. Detailed release notes are included. Regards, The Mac OS X Pascal Interfaces team: Peter N. Lewis <peter(a)stairways.com.au> Gale Paeper <gpaeper(a)empirenet.com> Adriaan van Os <gpc(a)microbizz.nl>

6 9

mySQL
by Adriaan van Os 24 Aug '04

24 Aug '04

From <http://www.gnu-pascal.de/contrib/eike/> I downloaded GPC interfaces to mySQL, contributed by Eike Lange - thanks Eike for contributing them. With some necessary changes, I got things working on Mac OS X. > { This unit interfaces MySQL libs. > Copyright (C) 2003 by Eike Lange > Author: Eike Lange <eike(a)g-n-u.de> > > This unit is free software; you can redistribute it and/or modify > it under the terms of the GNU Library General Public License as > published by the Free Software Foundation, version 2. I don't think full copyright can be claimed, because the Pascal interfaces are based on C-headers, copyrighted by mySQL AB. > /* Copyright (C) 2000-2003 MySQL AB > > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or > (at your option) any later version. Now, we have an "original work" copyrighted by MySQL AB and licensed under the GPL, plus a "new work" based on the "original work" copyrighted partly by Eike Lange and licensed under the LGPL. (sigh) From a lawyers point of view - I don't think that this is all correct. From a programmer's point of view - Please (!) don't introduce unneeded copyright claims in interface files, except as needed to respect the original works. With all respect for the GPL and the LGPL, I would argue strongly that Pascal interface files be left uncopyrighted. Regards, Adriaan van Os

4 13

GTK-unit
by David Righart 21 Aug '04

21 Aug '04

Arpa Intrabouw I am using Cygwin GPC version 20030830 and Red Hat Linux GPC version 20030830. Last week I downloaded GtkUnits-20010602.tar.gz from Nicola but I can't compile it. The tag asmname is used in the units which I replaced with external name. Does the tag asmname not work with GPC? Now, the linker is complaining with errors. Maybe the units are to old to use with this version of GPC? Is there a newer version of GPC GTK-units? Can anyone help me using Gtk under GPC?? Regards, David.

3 2