Gpc May 2005

gpc@gnu.de

18 participants
24 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

gcc-3.4.4
by Russell Whitaker 22 Jul '05

22 Jul '05

Hi Now that gcc-3.4.4 is out, thought I'd try it with gcc-20050331. Using gcc-3.4.3.diff, got these rejects: gcc.c.rej varasm.c.rej version.c.rej That last one I needed to patch version.c manualy so gcc would compile. After I did it, wondered if it might be beter to patch gpc instead? Since have 2 cpu's, tried "make -j3 bootstrap". The c part ran ok, it quit in the rts with an error message. "make bootstrap" & installed with no problem: Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-languages=c,c++,pascal Thread model: posix gpc version 20050331, based on gcc-3.4.4 Ran gpc's test using gcc-3.3.5 and then gcc-3.4.4, got one new fail: avo7.pas And ran the tests with "time make": gcc-3.3.5 gcc-3.4.4 ---------- ---------- real 22m24.452s 20m49.896s user 11m40.872s 10m52.583s system 10m25.648s 9m41.803s And that's it Russ

3 4

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

TRIM() wrong behavior or misunderstanding?
by Pascal Viandier 30 May '05

30 May '05

Hi, During some tests I ran with gpc 2050331 to evaluate the gap between SUN and GNU Pascal, I discovered that the function TRIM() is broken when it is passed a packed array of char. The small program bellow shows incorrect result: PROGRAM Trim; VAR St : PACKED ARRAY [1..20] OF CHAR; I : INTEGER; BEGIN WriteLn('Before assignment:'); FOR I := 1 TO 20 DO WriteLn('St[', i:2,']=', Ord(St[i])); { This shows a series of 0 } WriteLn('After assignment:'); St := 'The String'; FOR I := 1 TO 20 DO WriteLn('St[', i:2,']=', Ord(St[i])); { This shows the string padded with blanks (CHR(32)} St := Trim(St); WriteLn('After Trim:'); FOR I := 1 TO 20 DO WriteLn('St[', i:2,']=', Ord(St[i])); { ***This shows the string exactly AS BEFORE! } END. Am I right when I think the function TRIM should replace the blanks with some CHR(0)? Thanks Pascal Viandier

4 3

Pascal-OpenOffice.org binding
by Rick Engebretson 29 May '05

29 May '05

A Pascal binding to OpenOffice (StarOffice) seems possible. Visual Basic for Applications, the macro language bindings, is a lot like object pascal. OO.org uses new terms that are confusing to pascal unix users. But basically, OO.org is a "document object server" that uses TCP-IP over a client-server network. A Java Virtual Machine services the architecture. Pascal runs using the Operating System (or at least that's what I like about pascal). The less "virtual machine" the better. There are several IPC methods; "named pipes or fifos", and "sockets and socketpairs". So there are many types of bindings possible. These two programming environments might combine nicely.

1 0

Question about string type
by Pascal Viandier 28 May '05

28 May '05

Hi, I am porting SUN Pascal code to GNU Pascal. When I first read the GNU Pascal documentation (the pdf manual), I was pleased to see that GNU Pascal strings were in fact records with the length and the string text: this map perfectly with SUN Pascal VARYING[..] OF CHAR we use, since it is a record with 4 bytes for the length and an array of char. So, no porting problem... But now, I see in gdb that a GNU Pascal variable of type STRING(20) is not anymore as in the documentation: There are two fields of type Cardinal holding the capacity and the actual length of the string, plus the array of char. Since the low-level part of our applications are written in C, many of them get Pascal strings as parameters and map them on C struct's. They rely on the SUN Pascal type to find the length and the text. Is there a way (a compiler option?) to have the STRING type map as explained in the documentation, or will have I to modify all the C routines (a big task)? Pascal

4 4

shell scripts using pascal commands
by Rick Engebretson 26 May '05

26 May '05

I've been trying to learn how one would use pascal programs to be used in shell scripts. The original pascal used the program header to specify such input, output interfaces. ie; Program foo(input, output, file1, file2) ; The input and output are the standard in, out but are text file types. TurboPascal on DOS mostly forgot about this. Building shell commands with pascal seems promising.

4 13

Re: RE : bigsetdemo strange result
by Waldek Hebisch 25 May '05

25 May '05

Pascal Viandier wrote: > Hi, > > At your suggestion, I ran the gpc test suite. > Here is the summary result: > > Test Run By pascal on 2005-05-25 10:45:41 > Native configuration is sparc-sun-solaris2.6 (perfdev) > gpc 20050331, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused > > Nuber of tests: 4947 > Number of Ok: 4828 > Number of tests skipped: 7 > Number of failures: 56 (includes internal compiler error and some > coredumps) > Number of coredumps: 47 > Number of compiler errors: 2 > > > Should I worry? > Something is really broken. At first glance all failures involve sets, so it may be just a single problem. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

bigsetdemo strange result
by Pascal Viandier 24 May '05

24 May '05

Hi, Now that gpc runs, I compiled and tested the bigsetdemo sample program that comes with gpc. I am concerned with that since the SUN Pascal code I must convert to GNU Pascal uses some big sets. The program works, but outputs all the values I enter minus 1. I don't see anything strange in the source so, is there a bug in the 'set' mechanism? Here is a sreenshot of the bigsetdemo program: <Sigourney> bigsetsdemo Enter some numbers between 1 and 100000 (one or several per line). Enter an empty line when finished. 2 56 21 You entered the following numbers: 1 20 55 <Sigourney> bigsetsdemo Enter some numbers between 1 and 100000 (one or several per line). Enter an empty line when finished. 1 8352 76 You entered the following numbers: 75 8351 <Sigourney> Pascal Viandier pascal(a)accovia.com

2 1

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