Gpc

gpc@gnu.de

5400 discussions

Sppeding & speading -> speeding ...
by Mirsad Todorovac 11 Jan '02

11 Jan '02

Hi, all - me again - I don't know how I managed to misspell speeding twice, and in the title ... Apology to all. Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

1 0

Sppeding up GPC :-) ...
by Mirsad Todorovac 11 Jan '02

11 Jan '02

Hi, all - have a nice weekend first, Since this is not a bug report, relax all! I was puzzled by 'Highlights' section of GPC manual that says how GNU Pascal compiler is substantially slower. I know of course that it uses proven GNU backend, so GPC team has little influence in making *that* part run faster. I know that reliability is more important than speed, but a question occured to me. While I was still at the college, we had an collegium called "Language Processors". It had subjects like LL-grammar, attribute grammar etc., which are mathematical background for compilers. On labs, we had a choice, whether to use code parser, or a 'finite stata automata' (FSA) driven parser. I chose the latter which made me a lot of complications; but impression of all students was that FSA parser is substantially faster. Why is this - FSA parser is very small piece of code driven by a table that represents it's wisdom and logic, which serves to approve or reject syntax. I realized GPC is using 'bison' parser as it's front end - and 'bison' (yacc successor) AFAIK uses code-driven parsing generated from attribute LALR(1) grammar, doesn't it? What is your estimate, is there a chance of leap increase of speed if switching bison to use FSA-syntax checker? So he would generate part of compiler that does the same grammar, but by different method, finite state automata (FSA). FSA parsers are known to be more compact, but harder to design. Modern machine architectures would make FSA parser run even faster, since (realtively small) table and driver code can fit into most processor's caches nowadays, making compilation fly. Besides that, grammar can be spearated from generated code, so (in some ideal case) there would be no need to recompile driver part of the compiler, only compiler table - when changing or debugging grammar. My estimation that this change could help reduce compile time by 50% to 70%; and decrease compiler binary size (parser part) by 30-60%, switching syntax (by compiler directive) would then be a switch of table, while automate driving code would remain the same. This change doesn't influence RTL generator and back-end, neither lexer front-end (but there's a room for finite-state automata strategy improvements there also). Of course, although this improvement would carry an opportunity to catch up with Borland Pascal in speed, but GNU backend's generality makes this very hard as I suspect. Now, these are only reflections, I haven't sunk that deep in 'bison' nor GPC internals - but please tell me that this line of research have a sense or not. Of course, counter-argument is always 'why touch something stable, when there's more important work to do, like catching up with standards?' - but tuning performance of code was always my weakness from college days ;-) Once again, have a nice weekend, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

1 0

GtkUnit
by Klaus F. Østergaard 11 Jan '02

11 Jan '02

> > Hi, > > I have downloaded the Gtkunit.=20 > On a linux box (Redhat 7.2) extracted it with tar -xvf to a temp on my = > home dir. > On my home I have installed a rather new GPC only a couple of weeks old. > When I try to run Makefile I get a error Permission denied, I have tried = > also as root, same problem. > How do I install the units? > I have assumed that this is the path to get a GUI with out programming = > all the buttons ect. by myself also the shortest path to make nice = > programs that runs under X? > > Thanks in advance for help, > > Klaus F. Oestergaard > > >

2 1

Re: Complex_SqRt bug
by da Silva, Joe 10 Jan '02

10 Jan '02

To be honest, the revised Complex_SqRt function you present is a bit too complicated for me. <G> So, my thinking is that, instead of re-writing the algorithm of Complex_SqRt and similar routines, it would be simpler and less error-prone in these situations, to utilize a new, alternative SqRt function, eg. : Function Clipped_SqRt (x : double) : double; {Alternative SqRt : Clips negative arguments, returning zero} begin {Clipped_SqRt} if x > 0 then Clipped_SqRt := SqRt (x) else Clipped_SqRt := 0 end; {Clipped_SqRt} Of course, you would only apply this alternative to SqRt when the argument cannot theoretically be negative ... Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Wednesday, January 09, 2002 3:54 AM > To: gpc(a)gnu.de > Subject: Complex_SqRt bug > > The complex square root function crashes with a funny error message > on some arguments close to the real line: > > [pas]% cat sqrt.pas > program SqrtTest (Output); > > var > C: Complex; > > begin > C := Sqrt (Cmplx (4.2, 1e-8)); > WriteLn ('OK') > end. > [pas]% uname -a ; gpc -v > Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 > unknown > Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs > gpc version 20011222, based on 2.95.2 19991024 (release) > [pas]% gpc sqrt.pas > [pas]% ./a.out > ./a.out: argument to `SqRt' is < 0 (error #708 at 805d837) > [pas]% > > > The square root is computed as > > \sqrt{X+iY} = \sqrt{(A+X)/2} + i \sqrt{(A-X)/2} sgn(Y), > > where A=|X+iY|. It seems that due to inaccuracies etc., A may > turn out to be _less_ than |X|, if |Y| << |X|, which means that > SqRt((A+-X)/2) gets a negative argument. I suggest the following patch. > > --------------------------------------------------- > diff -U3 orig/p/rts/math.pas p/rts/math.pas > --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 > +++ p/rts/math.pas Mon Jan 7 21:34:43 2002 > @@ -192,8 +192,7 @@ > > function Complex_SqRt (z: Complex): Complex; > var > - a: Double; > - Sign: Integer; > + a, b: Double; > begin > { SqRt (x + yi) = +/- (SqRt ((a + x) / 2) +/- i * SqRt ((a - x) / 2)) > > @@ -203,10 +202,15 @@ > Principal value defined in the Extended Pascal standard: Exp (0.5 * > Ln (z)), > i.e. Sign (Re (SqRt (z)) := 1, Sign (Im (SqRt (z))) := Sign (Im (z)) > } > a := Abs (z); > - if Im (z) < 0 then Sign := -1 else Sign := 1; > - if a <> 0 > - then Complex_SqRt := Cmplx (SqRt ((a + Re (z)) / 2), Sign * SqRt ((a > - Re (z)) / 2)) > - else Complex_SqRt := 0 > + if a = 0 then Complex_SqRt := 0 > + else begin > + b := SqRt ((a + Abs (Re (z))) / 2); > + if Abs (Im (z)) > Abs (Re (z)) then a := SqRt ((a - Abs (Re (z))) / > 2) > + else a := Abs (Im (z)) / (2 * b); > + if Re (z) < 0 then begin var c: Double = a; a := b; b := c end; > + if Im (z) < 0 then Complex_SqRt := Cmplx (b, -a) > + else Complex_SqRt := Cmplx (b, a) > + end > end; > > function Complex_Ln (z: Complex): Complex; > ---------------------------------------------------- > > It would also work to simply insert > > if Abs (Re (z)) > a then a := Abs (Re (z)); > > into the original version, but the patch above gives more accurate > results (even for arguments which do not trigger the bug). > > > When talking about math.pas, I also suggest a little optimization to > the complex logarithm function; \log \sqrt x = (\log x)/2, but the RHS > is (I guess) computed faster and more precisely: > > --------------------------------------------------- > diff -U3 orig/p/rts/math.pas p/rts/math.pas > --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 > +++ p/rts/math.pas Mon Jan 7 22:10:08 2002 > @@ -211,7 +211,8 @@ > > function Complex_Ln (z: Complex): Complex; > begin > - Complex_Ln := Cmplx (Ln (Abs (z)), ArcTan2 (Im (z), Re (z))) > + Complex_Ln := Cmplx (Ln (Sqr (Re (z)) + Sqr (Im (z))) /2, > + ArcTan2 (Im (z), Re (z))) > end; > > function Complex_Exp (z: Complex): Complex; > ----------------------------------------------------- > > > Emil Jerabek

2 1

Makeinfo & info misbehavior and like ...
by Mirsad Todorovac 08 Jan '02

08 Jan '02

Hi, all, Happy New Year to everybody!!! Best wishes for all your projects and all your areas of life! -------------------------------------------------------------------- You probably remember me having problems with iso-8859-2 (Latin 2) charset when translating GNU Pascal documentation to Croatian. If you are doing something similar to some other languages which require 8-bit (above first 127) characters, I've noticed some problems with the way GNU 'info' displays menu items that contain them - GNU 'info' shifts the "hotspots" of every menu item bellow first such character by one line, so you have to select a line bellow an item to select that item. I'm not to proud with the way I coped with this, since I had to leave those menu items in English, and translate them on the right side in description part (where 8-bit chars are treated correctly). Any better ideas? -------------------------------------------------------------------- 'makeinfo' inserts spurious line-breaks when 8-bit chars and DOS-style line-breaks are present. After figuring out to erase CTRL-M's from the file, 'makeinfo' output began to look as expected. The problematic was @table @asis ... @end @table section (others didn't show problems with or without CRTL-Ms ... I don't know whether GNU 'makeinfo' renders tables correctly under MS DOS enviroment (in this case my solution would break there)????? Thanks for help in advance? -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 2

³Ì·s®ø®§¤½§G , ½Ð°Ñ¾\¥»«Hªþ¥ó¤§»¡©úÀÉ . 4FxlrOMtTMAD0Q4cghe9Lhszm
by 4QY4B5jehlPBMS＠gcn.net.tw 07 Jan '02

07 Jan '02

. . . . .h

1 0

recent mingw32 (windows) binary available
by Jerry van Dijk 05 Jan '02

05 Jan '02

I wanted to give GPC a testdrive, but I could not find a recent mingw32 binary version, so I was forced to build my own. As it might be useful to others, I've made it available through my webpage: http://users.ncrvnet.nl/gmvdijk/pascal As I have only limited webspace, I had to keep the binary minimal. If someone wants to move the binary to another place where it will be more accessable, that would be fine, as would be adding the documentation, test programs, etc. to it. Note that this is a native windows build, not a cross build. It includes everything (including pdcurses) that was needed to run the testsuite with gpc and mingw32. If anyone has questions, please contact me directly, as I am not a member of this list. gr. Jerry. -- -- Jerry van Dijk | email: jvandyk(a)attglobal.net -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk

2 1

GPC 2.1 RC 2 released
by Frank Heckenbach 05 Jan '02

05 Jan '02

Hi everyone, GPC version 20011222, the release candidate #2 for GPC 2.1, has been uploaded to the usual places, CVS and FTP: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20011222.tar.gz The main changes made since RC 1 are in the searching of unit source and GPI files (thanks to a bug report by The Chief), the handling of packed arrays (thanks to a bug report by Emil Jerabek) and set constructors (due to some bugs found by myself). If you use any of these things, you might want to check if the changes didn't break any of your code. There is also one new "feature", the Intl (internationalization) unit by Eike Lange. (I know that normally one should not do major additions so short before a release, but the unit is completely separate from the rest of the compiler and run time system, so even a very unlikely fatal bug would not affect the stability of the whole system.) Again, I've tested it on some systems, test reports from other systems are welcome, and if you find new or especially important bugs, or very important missing features, please report them. Merry Xmas, Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 5

error in new gpc, not present earlier
by J.Booij＠wbmt.tudelft.nl 04 Jan '02

04 Jan '02

At the Delft University of Technology, Mechanical Engineering, Structural optimization and Computational Mechanics group we have been using gpc for quite a while for a fairly large project, a finite element package. This runs on linux. With the most recent version of gpc the compiler will not compile three of the files, the older version we have perfoms the compile without problems. Removing (by commenting out) a part of the code allowed the compiler to successfully terminate, but then the result is of course useless. I have tried to isolate the problem by including all the required information on types, variables, constants, etc with include files, but in that case the compilation is successful. One of the actual routines makes use of 17 units (with uses). I am sending this message in the hope that it will be of some use, I realize that I am providing only very scanty information, but sending all the necessary information would give much more than you would probably want. Posibly the gdb information will give some clues to where the problem arises. Please contact me if I can help by providing more information. I am working on Linux, the output of uname -a is: Linux dutw52.wbmt.tudelft.nl 2.4.7-10enterprise #1 SMP Thu Sep 6 16:48:20 EDT 2001 i686 unknown . The compilation ends with the message: #progress# ERROR/backmesh.p (428) gpc: Internal compiler error: program gpc1 got fatal signal 11 gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 The new version of gpc gives (from gpc -v) Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) The old one gives Reading specs from /usr/tm/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20001015, based on 2.95.2 19991024 (release) The output from gdb as suggested in your manual is: gdb /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 core GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 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 "i386-redhat-linux"... Core was generated by `/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 /tmp/ccd3UKqD.i -quiet -du'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x082412a2 in int_cst_lt_always (val1=0x83be324, val2=0x83b784c) at ../../../gcc-2.95.2/gcc/p/types.c:1816 1816 if ((TREE_UNSIGNED (val1) || TREE_UNSIGNED (TREE_TYPE (val1))) (gdb) backtrace #0 0x082412a2 in int_cst_lt_always (val1=0x83be324, val2=0x83b784c) at ../../../gcc-2.95.2/gcc/p/types.c:1816 #1 0x082416c9 in select_integer_type (val1=0x83b784c, val2=0x83b7890, why=LE_EXPR) at ../../../gcc-2.95.2/gcc/p/types.c:1900 #2 0x081f4af9 in build_pascal_binary_op (code=LE_EXPR, exp1=0x83b784c, exp2=0x83b7890) at ../../../gcc-2.95.2/gcc/p/gpc-common.c:2377 #3 0x0822ed32 in yyparse () at parse.y:4485 #4 0x081e3744 in compile_file (name=0xbfffeb91 "/tmp/ccd3UKqD.i") at ../../../gcc-2.95.2/gcc/p/../toplev.c:3265 #5 0x081e749b in main (argc=14, argv=0xbfffe9c4) at ../../../gcc-2.95.2/gcc/p/../toplev.c:5440 #6 0x40049507 in __libc_start_main (main=0x81e6274 <main>, argc=14, ubp_av=0xbfffe9c4, init=0x80491c8 <_init>, fini=0x8249590 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbfffe9bc) at ../sysdeps/generic/libc-start.c:129 J. Booij J.Booij(a)wbmt.tudelft.nl J.Booij(a)wbmt.tudelft.nl

1 0

Lazy I/O
by Emil Jerabek 02 Jan '02

02 Jan '02

Accordnig to both ISO standards, readln(f) should be equivalent to get(f), when eoln(f) is true. In GPC the former seems to be implemented as lazy I/O, while the latter does not. Here is an example (enter three lines of text to test it). ---------------------------- program echo3lines(input,output); procedure copyline; begin while not eoln do begin output^:=input^; get(input); put(output) end end; begin write('Enter the first line: '); copyline; readln; writeln; write('Enter the second line: '); copyline; get(input); writeln; write('Enter the last line: '); copyline; readln; writeln end. ---------------------------------------- Is this a bug or a feature? Emil Jerabek

4 15

Jump to page:

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