Gpc June 2001

gpc@gnu.de

22 participants
28 discussions

forward pointers
by Christopher Ferrall 22 Jun '01

22 Jun '01

This is listed in "Other known bugs" > forward referencing pointers generate debug info that appears as generic pointers; no information of `with' > statements is currently given to the debugger; error in debug entries generated for objects Is this the same as this problem: type xptr = ^x_type; x_type = record stuff ... next : xptr; end; var xlist, x : xptr; begin new(xlist); xlist.next:=nil; ... x := xlist; repeat with x^ do begin new(next); x := next; until no_more_to_create; At runtime: Program received signal SIGSEGV, Segmentation fault. Inside gdb: (gdb) print x[0] Attempt to dereference a generic pointer. Obviously next can be "pointer" and xptr can be defined after x_type, but it is inconvenient to change code based on one of the building blocks of Pascal. --Chris

3 2

Speed
by Miklos Cserzo 22 Jun '01

22 Jun '01

Hi Folks, I am optimizing a code for speed in gpc. Let me share some strange observations of mine. I have two vectors of size N and M. I need to perform a not too complex calculation between all the elements (NxM) two times. I thought I dump the result into an array of NxM and second time just read the array back and this should save me time on the expense of memory. In fact this is about 50% slower than generating the result dynamically twice!!! Is it normal in gpc? Why the handling of large arrays are so slow? The speed of the loops are also different by about 50% depending on the following alternative styles: 1) for i:= 1 to 10 do whatever; 2) const one=1; ten=10; .. for i:= one to ten do whatever; 3) var one, ten:integer; .. one:=1; ten:=10; for i:= one to ten do whatever; 4) var one, ten:integer; .. one:=1; ten:=10; for i:= one to ten * one do whatever; The real code use much longer loops in a nested fashion of course, so the speed difference is significant. Are there other speed-related tricks? I am using an outdated version of gpc (2.0) on IRIX. Are these things any better in a more recent release? Cheers, miklos

2 1

gcc 3.0
by Prof. A Olowofoyeku (The African Chief) 20 Jun '01

20 Jun '01

Hi all Now that gcc 3.0 has been officially released, does GPC fully support it now? There was recently a thread about patching GPC for gcc 3.0, but I am not sure what the conclusion of that thread was. Thanks all. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

2 2

case labels error
by Christopher Ferrall 17 Jun '01

17 Jun '01

For the code segment below I get the errors listed. An error is not generated for "blank" as a label, so it seems that indexing a constant array of char confuses the compiler. Help would be appreciated. --Chris Ferrall fmopt_client.pas:212: `case' label does not reduce to a constant of ordinal type fmopt_client.pas:213: `case' label does not reduce to a constant of ordinal type fmopt_client.pas:214: `case' label does not reduce to a constant of ordinal type type integer_options = (max_untyp,mxstarts,nfuncmax); const blank = ' '; imn : array[integer_options] of char = ('u','r','n'); var lt : char; ... case lt of imn[mxstarts] : read(x_file,iopts[mxstarts]); imn[nfuncmax] : read(x_file,iopts[nfuncmax]); imn[max_untyp] : read(x_file,iopts[max_untyp]); eooptln : readln(x_file); blank : ; otherwise writeln('invalid integer option ',lt); end;

3 3

Re: Speed
by Miklos Cserzo 17 Jun '01

17 Jun '01

On Sat, 16 Jun 2001, Maurice Lombardi wrote: > I have only the following experience with large arrays on gpc/djgpp > (DOS): There is a 50% - 100% variation in execution times due to > memory cache considerations (this cache is presumably the "level 2" > 256 or 512 kB cache of the Pentiums). Matrices are stored in pascal > row-wise (same for C but the opposite is true for fortran). If you > access elements row after row you minimize cache breaks. In a > So how have you stored and accessed your NxM elements ? The maximal size of my array is 2000x2000. Let's say I have: X:array[1..N,1..M] od real; I access it as: for i:= 1 to N do for j:= 1 to M do bla-bla-bla.. x[i,j]; That's what you call row-wise acces or just the opposite? miklos

3 3

[Fwd: Re: Speed]
by Maurice Lombardi 17 Jun '01

17 Jun '01

Miklos Cserzo wrote: > Hi Folks, > > I am optimizing a code for speed in gpc. Let me share some strange > observations of mine. > > I have two vectors of size N and M. I need to perform a not too complex > calculation between all the elements (NxM) two times. I thought I dump the > result into an array of NxM and second time just read the array back and > this should save me time on the expense of memory. In fact this is about > 50% slower than generating the result dynamically twice!!! Is it normal in > gpc? Why the handling of large arrays are so slow? I have only the following experience with large arrays on gpc/djgpp (DOS): There is a 50% - 100% variation in execution times due to memory cache considerations (this cache is presumably the "level 2" 256 or 512 kB cache of the Pentiums). Matrices are stored in pascal row-wise (same for C but the opposite is true for fortran). If you access elements row after row you minimize cache breaks. In a procedure to diagonalize symmetrical matrices, just swapping the indexes to access memory elements in right order gave that gain. The exact value of the gain depends of course on the size of the matrices (there is no gain for small matrices diagonalized many times), but also apparently on the version of the pentium. It depends also on the optimization switches of the compiler: there is no gain with BP which is not execution-optimized and thus very slow. Similarly in every textbook on these procedures is explained a "clever" trick: you can use only the lower (or higher) half of the matrix (due to symmetry) to store elements and use the remaining to store intermediate results needed later. But this also disrupts the row-wise use of elements. Reorganizing the same algorithm to use the full matrix in order to access as far as possible row-wise and recomputing twice the intermediate results needed gives a gain of the same order of magnitude. The loss in recomputing is only of order N^2, while the gain in better elements access is of order N^3 ! So how have you stored and accessed your NxM elements ? Maurice PS this is different of the "page breaks" you can monitor in linux: these page breaks correspond to breaks due to virtual memory use. Here it is a standalone programm all in real memory (bare DOS with CWSDPMI). -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

GNU PASCAL
by Cortelli Paolo 17 Jun '01

17 Jun '01

Hi, I have downloaded the GNU Pascal with the DJGPP; I have tried to compile a C program and all is ok. But when I tried to compile a Pascal program, the compilation is ok, while on linking it says it can't find lgcc, which in effect is not in my hard disk. How could I solve my problems? Thanks for your help. Paolo Cortelli

1 0

going over to the dark side...
by Toby Ewing 15 Jun '01

15 Jun '01

Hi, all I need to translate some lovely Pascal code into C. Not my choice, but I need to run it on a parallel supercomputer that can handle C but not Pascal... I'm looking for a translator. I downloaded ptoc, but it crashes on the first type declaration. I've heard of a p2c package, but haven't been able to find it. I'm a C novice, or I'd try doing it all by hand. Any suggestions? Toby

1 0

Re: going over to the dark side...
by Toby Ewing 15 Jun '01

15 Jun '01

Maurice, Adam, and others, Thanks for the pointers. I'll check out the DJGPP translator. For the record, I'm currently working on windows machines, though the parallel machine I'm working towards is linux-based. Toby > Toby Ewing wrote: > > I need to translate some lovely Pascal code into C. Not my choice, but > > I need to run it on a parallel supercomputer that can handle C but not > > Pascal... > > > > I'm looking for a translator. I downloaded ptoc, but it crashes on the > > first type declaration. I've heard of a p2c package, but haven't been > > able to find it. I'm a C novice, or I'd try doing it all by hand. Any > > suggestions? > > "p2c" David Gillespies Pascal to C translator Version 1.02 > has been ported to DJGPP V2.02 > > It is availabe from the Simtel Mirrors > v2gnu/p2c120s.zip Sources (going to %DJDIR%/gnu/p2c-120) > v2gnu/p2c120b.zip Binaries > > <Sigh> (never tried) > Maurice > > > -- > Maurice Lombardi > Laboratoire de Spectrometrie Physique, > Universite Joseph Fourier de Grenoble, BP87 > 38402 Saint Martin d'Heres Cedex FRANCE > Tel: 33 (0)4 76 51 47 51 > Fax: 33 (0)4 76 51 45 44 > mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Intalation with crt.
by Opie Pecheux 11 Jun '01

11 Jun '01

Hi, I helped a lot of persons with installation problems, but this time, i don't understand. The PC is a Compaq LTE LITE 4/33c 486 with 12MO of ram under Windows 95. Without uses crt, all's working but with a simple program like: program test; uses crt; begin end. appears the message: c:\djgpp\travail>gpc -o test.exe --autobuild -g test.pas Load error : no DPMI memory gpc1.exe c:/djgpp/bin/gpc.exe exited with status 1 gpc1.exe c:/djgpp/bin/gpc.exe exited with status 1 csdpmi5b vas not installed because of windows. All non crt program works. The installation vas first with the 2.952 version, but it do the same now with the 2.953 with rhide or under a dos windows. The files used are: - djdev203.zip - bnu2951b.zip - mak3791b.zip - rh1478b.zip - gcc2953b.zip - gpc2953b.zip (on ftp://agnes.dida.physik.uni-essen.de/home/maurice/) - pdcur24b.zip The file c:\djgpp\lib\libpdcurses.a was renamed in c:\djgpp\lib\libcurso.a What test do we have to performe? If we do gpc -o test.exe --autobuild -g test.pas -v we have a lot of screens. Is it possible to have a pipe (>> test.txt don't work)? Thank's for your help. Opie

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 June 2001