Gpc July 1997

gpc@gnu.de

22 participants
111 discussions

--
by Herbert Voss 28 Jul '97

28 Jul '97

Hello, I'm a novice in gpc and I hav a lot of problems. Here comes the first one: unit unit1; { reine testunit fuer gpc } Interface Procedure ClrScr; Implementation Procedure ClrScr; Var i : Real; Begin For i := 0 to 25 Do WriteLn; End; Begin End. I run gpc under Linux 2.0.30 and had the following output: voss@crazy_horse:/home/voss/pascal > gpc unit1.pas /usr/lib/crt1.o: In function start': /usr/lib/crt1.o(.text+0x5a): undefined reference to main' Another problem comes, when I choosed the Type Byte for the variable i. Herbert

1 0

Re: Allocation/Memory Leak question
by Peter Gerwinski 26 Jul '97

26 Jul '97

According to Ken: > > program allo2; > var > mm: array[1..500000] of real; > indx : __long__ integer; (* JFYI, `__long__ Integer's have 64 bits. For your program, an ordinary 32-bit `Integer' would be sufficient. *) > ma: array[1..500000] of real; > [...] > This program realy does nothing of value but when the second FOR > loop is running, the program starts eating up memory. Really at the second FOR loop, not already at the first one? I don't know the details of the memory management of Linux, but AFAIK, the storage is physically allocated when the array is referenced. > According to TOP, > the program uses 8094 kBytes just before the loop ends. Why should > this program be so memory hungry at that time? [...] Simply because one `Real' has eight bytes, and you are allocating one million of `Real's. 8000000 bytes are 7812.5kB; if you include code, runtime library, etc., 8094kB seems realistic for me. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: problems with allocation?
by Peter Gerwinski 26 Jul '97

26 Jul '97

According to Giuseppe Petrella: > > The following simple program gave segmentation fault compiled on > digital alpha running osf > > PROGRAM prova(input,output); > var > mm: array[1..500000]of real; > BEGIN > END. Global variables of the program are allocated in the stack segment, not in the data segment. DJGPP limits the stack to 256kB, Linux seems to have no limit here. Obviously, OSF has a limit, too. This is a known problem. I would like to do something against it, but I was told that this would break Extended Pascal's nonlocal `goto' (whatever that is), so I don't dare to touch this part of the compiler as long as I don't have test programs. To work around, either move the array to a Unit (or Module), or make it a `__static__ array [...] of Real'. ^^^^^^^^^^ Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Allocation/Memory Leak question
by Ken 25 Jul '97

25 Jul '97

Just a quick note/question/observation. Consider this program: ---------------------------------------------------------------------------- program allo2; var mm: array[1..500000] of real; indx : __long__ integer; ma: array[1..500000] of real; begin for indx := 1 to 500000 do begin mm[indx] := indx / 2.2; if indx = 1 then ma[indx] := 1.0 else ma[indx] := (ma[indx-1] + mm[indx]) / indx; end; for indx := 1 to 500000 do writeln(indx, mm[indx], ma[indx]); end. ---------------------------------------------------------------------------- This program realy does nothing of value but when the second FOR loop is running, the program starts eating up memory. According to TOP, the program uses 8094 kBytes just before the loop ends. Why should this program be so memory hungry at that time? FYI, I am using GPC 2.0 with Linux 2.??? later... Ken L.

1 0

Re: problems with allocation?
by Ken 25 Jul '97

25 Jul '97

At 05:28 PM 7/25/97 +0200, Giuseppe Petrella wrote: >Hallo! >The following simple program gave segmentation fault compiled on >digital alpha running osf > >PROGRAM prova(input,output); >var > mm: array[1..500000]of real; >BEGIN >END. > >however array[1..1000] gives no problem. ???? >Thank you for your attention >Fulvio Ciriaco > > Compiles fine on a Linux box. What version of GPC are you using? Later... Ken L.

1 0

problems with allocation?
by Giuseppe Petrella 25 Jul '97

25 Jul '97

Hallo! The following simple program gave segmentation fault compiled on digital alpha running osf PROGRAM prova(input,output); var mm: array[1..500000]of real; BEGIN END. however array[1..1000] gives no problem. ???? Thank you for your attention Fulvio Ciriaco

1 0

Re: SizeOf with Objects BUG
by Frank Heckenbach 25 Jul '97

25 Jul '97

Bernhard Tschirren wrote: > You cannot use SizeOf with objects?!?! It just does not work. It either > aborts during compilation, or it returns rediculous values during execution. Did you initialize the object with a constructor call? BTW: There is a little difference to BP: In BP, objects that have neither constructors, destructors nor virtual methods don't have a VMT link. So it's possible in BP to get their size without initalizing them. I think that's kind of a misfeature, since the following program produces the wrong result for vy in BP, so IMHO, BP's behaviour should not be duplicated by gpc. (Though it's not 100% BP compatible then, a good BP program shouldn't make use of it, anyway.) type x=object a:integer; end; y=object(x) b:integer; end; procedure w(var p:x); begin writeln(sizeof(p)) end; var vx:x; vy:y; begin w(vx); w(vy); end. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: SizeOf with Objects BUG
by Peter Gerwinski 24 Jul '97

24 Jul '97

According to Bernhard Tschirren: > You cannot use SizeOf with objects?!?! It just does not work. It either > aborts during compilation, or it returns rediculous values during execution. Some of my test programs check that `SizeOf' *does* work with objects. If it doesn't for one of your programs, please post it here. Thanks for your cooperation, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

SizeOf with Objects BUG
by Bernhard Tschirren 24 Jul '97

24 Jul '97

You cannot use SizeOf with objects?!?! It just does not work. It either aborts during compilation, or it returns rediculous values during execution. Bye ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

__Volatile__ BUG
by Bernhard Tschirren 24 Jul '97

24 Jul '97

OK, the following code does not seem to actually define the variable - just take a look at the asm produced by gpc! Unit Testing; Interface Var TheBug : __Volatile__ Integer; Implementation End. To work around this bug you can use the code below: Unit Testing; Interface Var TheBug : __Volatile__ __AsmName__ 'Thebug' Integer; TheBug : Integer; Implementation Begin Asm(".globl _Thebug"); End. WHY: The __AsmName__? GPC defines '_thebug' instead of '_Thebug' (capital) The second definition? GPC does not define TheBug with __Volatile__. It knows that 'TheBug' exists, but it does not output it into the asm. The explicit .globl? GPC forgets to do this! Cya ________________________ | _) | | e-mail: bernie(a)icenet.com.au |___)ernhard |_|schirren ptschirrenb(a)cc.curtin.edu.au www: www.geocities.com/CollegePark/Quad/8070/

1 0

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 1997