Gpc July 2004

gpc@gnu.de

19 participants
27 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

-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

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

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

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

gpc-20040516 released
by Frank Heckenbach 22 Jul '04

22 Jul '04

I have uploaded a new beta version of GPC to <http://www.gnu-pascal.de/beta/>. This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work. Waldek Hebisch and I are currently working on some larger changes, including qualified identifiers, range checking and support for gcc-3.4.0. An alpha version with these changes, which might be less stable, will probably be released in a few weeks. BUILD NOTE: If you modify the GPC sources, you now need bison-1.875c and flex-2.5.27 (<http://lex.sourceforge.net>) to rebuild. These versions must be matched exactly. Newer flex versions, in particular 2.5.31, might work as well, but contain a known unportability, so I did not test them, and I recommend 2.5.27. (Other programs such as yacc and lex instead of bison and flex also will not do.) I have included the files generated by bison and flex in the distribution (also in the "minimal" distribution), so you should not need these tools when you only want to build GPC. NOTE: The `Pipe' unit was renamed to `Pipes' because of a name conflict. Unfortunately, this requires a small change to all programs that use this unit. New features: * arithmetic expressions now work as lower array/subrange bounds (fjf248.pas, fjf293.pas, fjf336.pas, fjf346a.pas, fjf622.pas) * records/objects with many fields are processed faster * parameters of procedural types now support Standard Pascal procedural parameters, conformant/open arrays and `type of' inquiries (fjf939*.pas) * empty parameter lists can be written as `()' (chief54*.pas, delphi6*.pas) (D) * GMP unit: `mpf_sin', `mpf_cos' * the test suite output is now by default stored in DejaGnu compatible files `gpc.log' and `gpc.sum' in the `p/test/' directory; other available test targets are `pascal.check-short' and `pascal.check-long' (@) * new options `-W[no-]dynamic-arrays' (fjf931*.pas) * new argument to `_p_initialize' (@) * new function `UMask' * new option `--no-debug-source' * new lexer (no directly user-visible difference, but should allow for better handling of lexer-based problems in the future) Fixed bugs: * `pow' and `**' are really EP conformant now (in particular `x pow y' and `x ** y' are an error if x = 0 and y <= 0) (emil27*.pas) * `protected var' parameters must only accept references (unlike `const' parameters) (gale5*.pas) * `pack' must not pack the component type of arrays (fjf940[b-e].pas) * in some circumstances packed fields were allowed as `var' parameters (fjf940a.pas) * bugs with nonlocal gotos out of routines declaring file variables (nonloc*.pas) (fix involved a change in the internal representation of file variables) * 'foo'#42 must not be rejected in `--borland-pascal' (chief53.pas) * `--implementation-only' didn't work correctly (bo4-19.pas) * messages referring to object methods now point to the method declaration rather than the end of the object type declaration * initializers for types containing nested schemata now work (fjf914*.pas) * various smaller bugs Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

11 50

Re: problem building GPC 20040516 on AIX - continued
by Gert Doering 21 Jul '04

21 Jul '04

Hi, On Wed, Jun 16, 2004 at 08:30:38PM +0200, Frank Heckenbach wrote: > Gert Doering wrote: > > > I'm trying to build the gpc-20040516 "beta" snapshopt with GCC-3.3.x on > > AIX 5.1. GCC-3.x itself supports AIX 5, I have a working version on > > the system (binary install, not compiled-it-myself). [..] > > the line 511 is this one: > > > > TARGET_CPU_CPP_BUILTINS (); > > > > ...which fully escapes me as for why it might not compile...!?? [..] > Unless you need very particular system conditionals (Pascal programs > usually don't), just insert the line > > #define rs6000_cpu_cpp_builtins(foo) > > in lang.c. Thanks for your quick reply. Unfortunately, I didn't see it before today because my spam filter didn't know about the GNU Pascal list yet (all e-mails with unknown To:/CC: headers are quarantained as "maybe spam". Stupid me.) I will try this approach over the weekend. In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken). The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj". The error is this: gmake[2]: Entering directory `/s1/gpc-build/gcc/p/utils' ../.././xgpc -B../.././ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" collect2: library libgpc not found gmake[2]: *** [binobj] Error 1 gmake[2]: Leaving directory `/s1/gpc-build/gcc/p/utils' gmake[1]: *** [pascal.utils] Error 2 gmake[1]: Leaving directory `/s1/gpc-build/gcc' If I change the -B invocation to use an absolute path, the library is found, but the (AIX) ld doesn't really like the result either: ../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status I've checked with "nm", and it looks like all the stuff should be there: gd@hilb3:/s1/gpc-build/gcc/p/utils> nm ../../libgpc.a | grep Tempdir Tempdirectory.1 U - Tempdirectory.1 d 37956 8 Tempdirectory.1.P8 d 37952 4 Tempdirectoryset.0 d 37948 4 Since I had the nagging suspicion that there might be something in the pascal libraries that the system ld doesn't understand, I tried installing the GNU binutils, ./configure'd again, and rebuilt. Built bombed in libgcc (gcc created stuff that gas didn't like). Removed gas, ./configure'd again, rebuilt. Same error as above (collect2 not finding libgpc). Trying again with absolute paths and GNU ld linked into the "-B" directory as "real-ld" led to a new error: ../.././xgpc -B/gnulocal/src/gcc-3.2.3/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/rts --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempdirectory.1' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempstr.4' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Buffer.8' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Zero.3' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Epoch.6' collect2: ld returned 1 exit status (the -B path is different from the example above, because it's a different system - the other one doesn't have the GNU binutils installed yet - but don't let that confuse you) --> so it seems that actually the library itself has unresolved symbols, and not the "binobj.pas" program it tries to link. "ranlib" doesn't help either. Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers... thanks again, gert -- Gert Doering gd(a)medat.de MEDAT Muenchen Tel: 089/126808-0 Fax: -50

4 19

www.gnu-pascal.de up again
by Eike Lange 19 Jul '04

19 Jul '04

Hi Folks! The server is up again. Latest uptime was 394 days :-) The mainboard becomes too warm or the BIOS detects the wrong temperature. However, if you are a "contributor" with files on this server, please make a private backup. I'm going to backup the complete files to a cdrom. If someone would like to contribute a new server hardware, you are welcome. ;-) Please send me a private mail in this case. Eike -- http://www.gnushi.de

1 0

www.gnu-pascal.de down!
by Eike Lange 18 Jul '04

18 Jul '04

Hi folks! Currently our GPC-Server is down. As I do not know the reason, I cannot tell you the time to fix. I hope it will be soon. Yours Eike -- http://www.gnushi.de/

1 0

ANNOUNCEMENT: Unit for multithreading (and some more stuff)
by Markus Gerwinski 18 Jul '04

18 Jul '04

Markus Gerwinski proudly presents: GNU Application Libraries for Pascal, in short GNUALP, pre-release 0.1.4. The current status of the package contains units for - exception handling, - standard collection types (lists, hashtables etc.), - system time and calendar functions, - and last but not least: multithreading. You can download a tarball with the current sources from http://www.markus.gerwinski.de/gnualp/gnualp-0.1.4.tar.gz. The library is tested on SuSE Linux 8.0, 9.1, and Windows XP with MinGW. You can install the tarball just the usual way, i.e. unpack it into your source directory, then run "./configure", "make", "make install", and everything will be in place. The API units will then be installed to a directory named /usr/local/units/gnualp-0.1. This also generates a shared library, libgnualp.so, which you'll have to link against. E.g. to compile a program foo.pas which uses the GNUALP library units, your gpc compiler call will have to look like this: gpc --automake --unit-path=/usr/local/units/gnualp-0.1 foo.pas -o foo -lgnualp This library is work under development and far from being complete, so it is all undocumented up to now. However, since several folks seemed to have a pressing urge for multithreading, I'll give a short introduction here on how to use the resp. features of the library: - Include `AlpThreads' into the uses clause of your program. Declare any threads you want to start as vars of type `pThread'. - To run some simple procedure as a thread, give it a parameter list like this: Procedure doingSomething ( thread: pThread; data: pointer ); You can then from anywhere in the program create a thread object for this procedure with the following statement: someThread:= new ( pSimpleThread, start ( doingSomething, nil ) ); The thread then starts running immediately and will automatically dispose itself after it is ready. It can be stopped from within the doingSomething procedure using the command `thread^.stop'. In this case, it will also dispose itself. For more sophisticated thread handling, derive an object type from the abstract tThread type and override the `work' method to do whatever the thread is supposed to do; if need be, you can also override the `cleanup' method. This one's always executed at the end of the thread, no matter if it was regularly ended or `stop'ped in-between. - Mutexes and semaphores are represented by the tMutex and tSemaphore object types. To create e.g. a mutex, just call mutex:= new ( pMutex, init ); To lock the mutex, call `mutex^.lock'; to unlock it, call `mutex^.unlock'. To dispose it after use, call `dispose ( mutex, fini )'. Just as simple. :-) Semaphores work in an analogous way; they only require an integer parameter in their constructor to determine the maximum count of threads they may be accessed by. For usage examples, see the files simplethreads.pas, mutexes.pas, and semaphores.pas in the demos/pas subdirectory of the gnualp package. They aren't documented or commented either, since I've only set them up as a test for myself, but I hope the code isn't too difficult to read. :-} Regards, Markus

1 0

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 July 2004