Gpc January 2001

gpc@gnu.de

25 participants
28 discussions

StringUtils, FileUtils
by Frank Heckenbach 31 May '02

31 May '02

Hi, in the current GPC version, I've included a StringUtils unit for general string handling routines (on a higher level than the built-in and RTS routines). Up to now, it only contains routines for a string hash table, but I'm planning to add some more routines. Perhaps some of you also have some routines to contribute (or features to request). Conditions for inclusion into this unit should be, IMHO: - Generally useful (not meant specifically for a certain program or something), - self-contained (not relying on an external library etc.), - new functionality compared to the existing routines (whereas the same or similar functionality under a different interface for compatibility purposes should go into other units, like GPCUtil for compatibility to `Turbo Power' units), - and, of course, compilable with the current GPC version, portable, bug-free, etc. ;-) The same goes for the FileUtils unit which has been there for some months already. 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 10

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

operators pow and **
by Maurice Lombardi 01 Feb '02

01 Feb '02

Hi all, It seems that operators pow and ** cannot be redefined in gpc. Is that expected ? I work with djgpp / w98 dos box (should be irrelevant I think) Thanks 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

4 4

Re: Memory use problem
by david＠tcs01.demon.co.uk 07 May '01

07 May '01

In message <Pine.LNX.4.21.0011240232590.265-100000(a)rusty.russwhit.com> Russ Whitaker writes: > > Hi > > suggestion: a script to take a snapshot of the /proc filesystem > so you can find what's growing > > take a look at > dir /proc > and cat /proc/<ID>/status > or cat /proc/<ID>/maps The application has been running for some 21 hours now, and I've been taking occasional snapshots both of status and maps. status shows VmSize and VmRSS growing. maps shows the end of the rwxp region that starts at 08171000 growing - can I deduce anything more from this? (for example is it likely to be Pascal heap space or something else?). Both status and maps snapshots follow. Any further suggestions will be gratefully received ... status ====== Name: webmake.e State: S (sleeping) Pid: 27006 PPid: 31555 Uid: 500 500 500 500 Gid: 500 500 500 500 Groups: 500 VmSize: 110776 kB VmLck: 0 kB VmRSS: 108340 kB VmData: 107944 kB VmStk: 84 kB VmExe: 1172 kB VmLib: 1360 kB SigPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 800000000000a006 SigCgt: 0000000008094000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 maps ==== 08048000-0816d000 r-xp 00000000 03:07 32300 /var/rally/bin/webmake.e 0816d000-08171000 rw-p 00124000 03:07 32300 /var/rally/bin/webmake.e 08171000-0e9d0000 rwxp 00000000 00:00 0 40000000-40013000 r-xp 00000000 03:05 34138 /lib/ld-2.1.3.so 40013000-40014000 rw-p 00012000 03:05 34138 /lib/ld-2.1.3.so 40014000-40015000 rw-p 00000000 00:00 0 40015000-40016000 r--p 00000000 03:06 94 /usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES 40016000-40017000 r--p 00000000 03:06 96660 /usr/share/locale/en_US/LC_MONETARY 40017000-40018000 r--p 00000000 03:06 96662 /usr/share/locale/en_US/LC_TIME 40018000-40019000 r--p 00000000 03:06 96661 /usr/share/locale/en_US/LC_NUMERIC 4001a000-4001b000 rwxs 00000000 00:00 0 4001b000-4001e000 r-xp 00000000 03:06 96925 /usr/lib/libpanel.so.4.0 4001e000-4001f000 rw-p 00002000 03:06 96925 /usr/lib/libpanel.so.4.0 4001f000-40054000 r-xp 00000000 03:06 96923 /usr/lib/libncurses.so.4.0 40054000-4005d000 rw-p 00034000 03:06 96923 /usr/lib/libncurses.so.4.0 4005d000-40061000 rw-p 00000000 00:00 0 40061000-4007d000 r-xp 00000000 03:05 34156 /lib/libm-2.1.3.so 4007d000-4007e000 rw-p 0001b000 03:05 34156 /lib/libm-2.1.3.so 4007e000-4016b000 r-xp 00000000 03:05 34145 /lib/libc-2.1.3.so 4016b000-4016f000 rw-p 000ec000 03:05 34145 /lib/libc-2.1.3.so 4016f000-40174000 rw-p 00000000 00:00 0 40174000-4017c000 r--p 00000000 03:06 96658 /usr/share/locale/en_US/LC_COLLATE 4017c000-40192000 r--p 00000000 03:06 96659 /usr/share/locale/en_US/LC_CTYPE 40192000-401cc000 rwxs 00000000 00:00 0 401cc000-40292000 rwxs 00000000 00:00 0 bffeb000-c0000000 rwxp fffec000 00:00 0 -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

5 11

install gpc on AIX 4.3.3
by Paul Tedaldi 10 Feb '01

10 Feb '01

Hi, installation of gpc-20010111 on AIX 4.3.3 had the following problems: - while linking gpc1 the TOC overflows: ld: d: 0711-781 ERROR: TOC overflow. TOC size: 67732 Maximum size: 65536 The problem can be circumvented by adding the "-Wl,'-bbigtoc'" flag to LDFLAG (assuming gcc is used to call ld, for xlc it's just "-bbigtoc") It strikes me as odd that all other gcc compilers (gcc, g++, f77, objective c and java do not overflow the TOC during install. - while compiling the RTS with xgpc, rts/internal.pas produces invalid assembler code. rts/internal.pas contains procedure RunFinalizers (var AtExitProcs : PProcList); asmname 'gpc$runfinaliz ers'; The AIX assembler does not allow "$" in symbols ! After changing "gpc$runfinalizers" to "_p_runfinalizers" the RTS could be built. Of course the magic name is now destroyed. Is it possible to fix the above problems in the distribution so that GPC can be installed on AIX in a standard manner ? Kind Regards Paul -- ======================================================================== Paul Tedaldi | Zentrum Informatikdienste | Email: Paul.Tedaldi(a)zi.unizh.ch Universitaet Zuerich | Winterthurerstr. 190 | Tel: +41 (0)1 635 4523 CH-8057 Zuerich | Fax: +41 (0)1 635 4505 Switzerland | ========================================================================

2 1

Pascal GNU Compiler for Solaris 8 ?
by br＠is.informatik.uni-kiel.de 30 Jan '01

30 Jan '01

Hello, I'm not used to Sun Solaris but I need to work with an Ultra10 for my new projects. Can somebody give me a short reply about: Does the Pascal GNU Compiler work with Solaris 8 ? I saw some 'extra binaries' on a polish website and all other releases only for Solaris 2.x or 7. Thanks Bernd -- Bernd Rehling Institut fuer Informatik Christian-Albrechts-Universitaet Kiel

3 2

[Fwd: Re: memset]
by George Shapovalov 29 Jan '01

29 Jan '01

In Borland Pascal you would use fillchar(var x;value:word [size:word]); so the invoking would look exactly like your example: fillchar(x,0,sizeOf(x)); However with BP you can do it to the <64K in size variables (as this is a maximal size for "regular" variable in BP). Does this work for gpc as well? George Steve Loft wrote: > Is there a fast way to zero a large array, e.g. an equivalent to the > following C fragment? > > int x[100,100]; > memset(x, 0, sizeof(x)); > > -- > Steve

3 4

memset
by Steve Loft 28 Jan '01

28 Jan '01

Is there a fast way to zero a large array, e.g. an equivalent to the following C fragment? int x[100,100]; memset(x, 0, sizeof(x)); -- Steve

2 1

Stack problems?
by Steve Loft 26 Jan '01

26 Jan '01

I'm using gpc 20010115 on a Linux system. I'm having problems with a program I've written which has recursive function calls, which I thought may be down to blowing the stack. If I run the program in gdb, when it crashes I can't get it to display a backtrace: Program received signal SIGSEGV, Segmentation fault. 0x240804e7 in ?? () (gdb) bt #0 0x240804e7 in ?? () Cannot access memory at address 0xbabffff5 So I compiled it with --stack-checking, and now it crashes much earlier, with a segmentation fault on a 'var' statement. It's at about 20 levels of recursion, and the function only uses three of four integers of local variables; uname -s tells me I have 8196k of stack, so I'm puzzled as to why I'm blowing the stack, if indeed I am. Is a SIGSEGV what you would expect to see as a result of turning on stack checking? Are there any known problems in gpc in this area? Any suggestions as to what I can do to investigate further? Steve

4 6

documents on Compiling ASM
by Anuradha 25 Jan '01

25 Jan '01

Hello , I need a good manual to help me convert the Intel syntax into AT&T syntax. I had a look at : ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/gpcasm.zip Though it is mentioned that i can have more information in http://www.dcs.warwick.ac.uk/~jules/nasm1.html and http://www.tu-chemnitz.de/~rho/rhide.html I am not able to get the right link because there are some missing letters in the link. can you kindly let me know the complete site? Thank you Regards, Anu

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