Gpc March 2005

gpc@gnu.de

32 participants
67 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

Passing by reference
by Adriaan van Os 06 Jun '05

06 Jun '05

Another problem, also reported on the macpascal mailing list and reproduced by the following program: [G5:gcc/p/test] adriaan% cat avo12.pas program avo12; type Str255 = record sLength: Byte; sChars: packed array[1..255] of char; end; function StringToStr255 ( const s: String ) = Result : Str255; begin Result.sLength := Min( Length( s ), 255 ); if Result.sLength > 0 then begin Result.sChars[1..Result.sLength] := s[1..Result.sLength]; end; end; procedure DrawString1( const s: Str255); external name 'DrawString'; procedure DrawString2( protected var s: Str255); external name 'DrawString'; begin DrawString1( StringToStr255( 'Hello')); {OK} DrawString2( StringToStr255( 'Hello')) {Error: reference expected, value given} end. [G5:gcc/p/test] adriaan% gpc avo12.pas avo12.pas: In main program: avo12.pas:19: error: reference expected, value given In gpc-20030830, this was no problem, but now it is no longer allowed, which is quite inconvenient. In the GPC interfaces for Mac OS X, we use the external declaration form with a "protected var" because (according to the gc docs) the "const" declaration form doesn't guarantuee that the parameter is passed by reference, which is an ABI requirement. Regards, Adriaan van Os

5 23

The CRT Unit
by Alex v.Below 06 Jun '05

06 Jun '05

Hello, I am trying to help students use gpc (on Mac OS X, in particular) instead of TurboPascal, which is still taught in some schools: http://macentwicklerwelt.net/index.php?title=Leben_ohne_TurboPascal (Sorry, German only) However, I have been unsuccessful in getting the CRT Unit to work on OS X: I tried to compile the crtdemo.pas in the demo folder, and after searching the mail archives, tried the --automake option. Neither was successful. Is there any other trick in getting the CRT Unit to work? I installed the binary installation of gpc for OS X. If anyone is interested I will gladly post the error output. I am a pretty skilled OS X coder, but my memory of pascal seems to have faded away... Thanks for your help! Alex

9 20

-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

bug: ncurses + slackware 10.0, 10.1
by Russell Whitaker 01 May '05

01 May '05

Hi Program below illustrates a bug: lower case a, lower case f thru z, and number 0 are printed with graphic characters. This bug did not appear in earlier versions of slackware. If you make the window with a frame around it, (uncomment the framewin line) the characters are printed normally, and afterwards any window written to is also printed normally. program ncurtest; uses GPC, GPCUtil, CRT, FrameWin; var submenu : WinState; Data : array[1..3] of string( 32 ) = ( 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz', '0123456789'); i : integer; begin i := (ScreenSize.X - 32) div 2; MakeWin( SubMenu, i, 2, i + 32, 7 ); { FrameWin('HELP: hit Enter to exit', DoubleFrame ); } FillWin( ' ', 16 * Blue ); HideCursor; for i := 1 to 3 do WriteStrAt( 2,i, Data[ i ], 16 * Blue + LightGray ); end. Russ Note to support(a)slackware.com, bug-ncurses(a)gnu.org: gpc(a)gnu.de is a pascal mailing list unit CRT is a pascal interface to ncurses

4 8

GPC ALPHA 20050331 released
by Frank Heckenbach 29 Apr '05

29 Apr '05

I have uploaded a new alpha version of GPC to <http://www.gnu-pascal.de/alpha/>. This is an ALPHA version. Not so many extensive tests have been made and the test suite is not expected to pass without errors. I'm not uploading binaries, diffs, separate test suite archives, updated web pages etc., just the source distribution. (Of course, others may feel free to upload binaries for various platforms.) I'm not aware of any serious bugs, but you have to decide for yourself whether to use it for production work. New features: * new options `--[no]-nonlocal-exit' (default in `--ucsd-pascal' and `--mac-pascal') (fjf988[fijk].pas, fjf1062*.pas) (U) (M) * new options `--[no]-object-checking' (on by default) to check on virtual method calls if VMT pointer is not nil and has matching `Size' and `NegatedSize' entries, new options `--[no]-range-and-object-checking' which are now equivalent to `$R[+-]' (fjf1053*.pas) (B) * new options `--[no]-pointer-checking', `--[no]-pointer-checking-user-defined'; new variable `ValidatePointerPtr' (fjf1052*.pas, pcerrorc.pas) (these options are _off_ by default!) * new options `--[no]-implicit-result' (fjf1022*.pas) (on by default *only* in `--delphi' mode!) (D) (@) * new options `--{en,dis}able-predefined-identifier' (fjf1037*.pas) - Bug fixes: * check initializers of unused types (fjf898*.pas) * check identifier scopes stricter (az25.pas, fjf1059*.pas) * in `--borland-pascal' give only a warning, not an error, for duplicate `case' elements (drf6*.pas) * multi-dimensional `packed' arrays are not correctly packed (fjf149*.pas) * check arithmetical overflow in constants somewhat better (fjf206*.pas) * check duplicate external declarations stricter (fjf948.pas) * check that actual discriminants match in parameters and assignments, and in strict EP mode, check that actual discriminants of parameters within one identifier list match (berend4.pas, fjf104[45]*.pas, typeof[2-4].pas) * check pointer to schema types stricter (fjf130.pas, fjf614.pas, schema3a.pas affected) * allow importing the same value as a result of distinct expressions under the same name for EP modules for ordinal, pointer, string and set constants (fjf1040*.pas, stef1.pas) * allow attributes for procedural types (chief56.pas) * problem with string operations and `goto' (contour0.pas, contourbug.pas, martin1.pas, berend3.pas) * check `goto' targets more strictly <261020020000077022%gpaeper(a)empirenet.com>, <Pine.LNX.4.44.0210281004000.31943-100000(a)duch.mimuw.edu.pl> (az48.pas, fjf701*.pas, fjf1038*.pas, gale6.pas) * `Result' is not completely Delphi compatible (fjf1022*.pas) * problem if a `Write' or `WriteLn' argument calls a routine which writes to the same file (fjf1036.pas) * `Update' as well as writing after reading or checking `EOF' can get the file position wrong in some cases (arp2*.pas, fjf159.pas, fjf160*.pas) 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

9 37

dereferencing untyped pointer
by Prof A Olowofoyeku (The African Chief) 23 Apr '05

23 Apr '05

Hi How does one get rid of the "dereferencing untyped pointer" error without endless typecasting? Is there a switch or compiler directive? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

8 18

framebuffer dev note
by Rick Engebretson 09 Apr '05

09 Apr '05

In playing with framebuffer drawing efforts, something interesting came up. In brief (so as not to bore everyone) the same draw program and unit works differently between fpc and gpc. But neither work. I suspect it is in the rewrite and/or blockwrite functions. I'm using 16bit pixels so I'm dealing with converting 16 bit to byte writes. Anyway, for a simple red horizontal line on a solid background. Fpc gives me two red lines on a clean blue background. While gpc gives me a single red line on a spotted blue background. Also, gpc gave me the proper error code for using blockwrite on a typed file. Conclusion; a bad program performs differently on fpc and gpc.

3 14

Who uses Pascal?
by John Ollason 06 Apr '05

06 Apr '05

Greetings, I follow the postings on the mailing list with interest but seldom feel that I have anything to contribute. I am becoming concerned that some fundamental questions that we ought to address are simply being ignored. The most important question is Is Pascal a dead language? This might look like flame bait, but it isn't. Evidently the development of GPC presents a variety of interesting technical problems in the construction of a portable compiler, but the solution of such problems, though interesting in itself, deteriorates into navel-gazing if there isn't a group of users, reasonably sophisticated programmers who use write programs in Pascal. While there is a cohort of people like me who learnt Pascal in the '70s and '80s, the language is no longer taught in the introductory courses in programming at Aberdeen University of which I am a member, and as far as I can discover it certainly is not taught at school. With the decreasing number of recruits to the population of Pascal programmers it seems to me that Pascal is dying out and there is little anybody can do to conserve it. Perhaps my perceptions are mistaken, perhaps there is still a thriving process of recruitment to the ALGOL tradition, but I fear that the recruitment is not happening in Britain and certainly not in America. I belong to a fortunate group of programmers, those whose first language was ALGOL 60, trapped for a while with FORTRAN 4---What a dog's dinner after ALGOL!--- forced on to PL/1---a dog's banquet after FORTRAN---starvation rations then with BASIC, then the revelation of Pascal, which I started to use in 1978 and have used ever since as my favoured language, currently using GPC under linux. My programming is entirely scientific, simulating dynamical systems of interacting animals. I have no interest in GUIs and all my programs work from the command line. With a colleague I used to teach an introductory programming course for students with an interest in ecological modelling, using Level 0 ISO Pascal. Now, I believe introductory courses are taught using Visual BASIC or Java, neither of which, it seems to me, have the elegance and security of Pascal. So the base of users in my immediate vicinity is shrinking year by year, and to my eyes the quality of programs written by graduate students and postdocs is much worse now than it was when Pascal was the first language learnt. After all when you have learnt how to program in Pascal, you can write Pascal in any language, even PERL. So the question is Where is Pascal taught and used? I don't think that it's in computing science departments: my contact with computer scientists suggests that they regard themselves as far too grand for code-bashing. I suspect that the language is primarily used by what we might call gentleman-programmers, people who need fairly elaborate programs for their work that don't fit easily into the Mathematica, Matlab, systems, but which, for all that, require fairly sophisticated number crunching. Typically such programs are used by the programmers who write them, and so there is little need for fancy user (noddy) friendly interfaces. So who uses Pascal now? Who teaches Pascal now? Anybody interested in discussing these matters? John O.

7 12

Who uses Pascal? Part 2
by John Ollason 01 Apr '05

01 Apr '05

My main reason for asking the question was to try to find out if there would be any interest in a modern primer, based on GPC, as an introduction to scientific programming. Years ago, with a colleague, we talked of writing a book entitled 'Brute force programming' which was designed for scientists. The design cycle was based on our appreciation of the fact that for our modelling work most of the time was spent on the development of the code, and only a small proportion spent on production running. This meant that we weren't concerned with saving bytes or running efficiently. All we wanted was to get our ideas coded and tested as conveniently (for us) as we could manage. We were teaching ISO Pascal level 0 at the time and thought that this would be the ideal language for our purposes. I am not sure that there is enough interest to make it worthwhile, or indeed, if our irresponsible approach would be valued by the wider programming community. John O.

3 4

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 March 2005