Gpc July 2008

gpc@gnu.de

6 participants
6 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

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

GNU Pascal based TeX
by Wolfgang Helbig 07 Jul '08

07 Jul '08

Hi, at http://www.ba-stuttgart.de/~helbig/tex-gpc/ you'll find a set of change files to build GNU Pascal based TeX, METAFONT, weave, tangle and some other related programs. Especially the file tex.ch contains lots of examples how to use GPC extensions. Enjoy, Wolfgang

1 0

Re: turn off lazyIO on disk files
by Wolfgang Helbig 04 Jul '08

04 Jul '08

Hi, Frank Heckenbach wrote: >> On writing, GPC doesn't buffer yet at all; it's not implemented yet. >> It's not that it couldn't be done, but it's more tricky, because GPC >> supports various ways of seeking, pre-reading, getting the file >> position etc., which all would have to take account of the buffers. >> >> If it's a serious problem you could kludge it by installing a >> user-defined file write routine which can do the buffering. If you >> know that your application only does sequential writes, this would >> work. I've done this once (see RewriteBuffer in cgi.pas in >> http://fjf.gnu.de/misc/cgiprogs.tar.bz2). Let me know if you need >> more details. >> >> Frank >> Thanks for the enlightement about buffering in GPC. And Emil Jerabek wrote: >The bottleneck in TeX's I/O is the output to the dvi file, which is >done byte by byte (there's no other choice in standard Pascal). Knuth >himself notes that this is inefficient, the porter is expected to >optimize it: >In the case of GPC, it is trivial to replace the write_dvi procedure >with a single call to BlockWrite. This makes a huge difference in the >running time. Did that. And the time command shows the difference: 64.45 real 15.16 user 48.45 sys 11.40 real 10.55 user 0.57 sys Compares pretty good to a web2c based distribution of TeX, in this case teTeX-3.0: 7.54 real 7.01 user 0.17 sys Thanks to both of you, Wolfgang Helbig -- "Dijkstra is right, but you don't say such things!" (A less courageous programmer)

1 0

turn off lazyIO on disk files
by Wolfgang Helbig 04 Jul '08

04 Jul '08

Hi, the program, Don Knuth's TeX adapted to GPC version 2.1, does heavy I/O on text files. I noticed a very high percentage of system time. I believe this is due to lazy I/O, which seems to be unbuffered. GPC should apply lazy/IO when the text file comes from the keyboard, but to use buffered I/O when it comes from the disk. Is there a way to turn off lazy/IO on nonterminal text files? Greetings, Wolfgang Helbig

3 2

Indent program for the GPC
by pripoae teodor anton 04 Jul '08

04 Jul '08

Hello. I read in the to-do list than a planned feature is a indent-like source code formatter for Pascal. I have three questions: 1. Is anybody who is doing this job? I saw something like this here: http://www.gnu-pascal.de/crystal/gpc/en/mail4247.html?pos=13294915#13294915 but it seems to be unfinished, and it seems to be very long time ago (in 2000). 2. What are the multi-styles for this (in the c indent program called indent, I know that there are a lot of styles: k&r, gnu, berkeleyetc...) 3. How can i contribute to GPC? I haven't tryed to contribute to GNU software yet. I wrote a pascal indent (with some modes, (unix/dos) and with output file), but it has only one mode (yet). Regards, Pripoae Teodor Anton, pripoae_teodor_anton(a)yahoo.com

4 3

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 2008