Gpc November 2001

gpc@gnu.de

28 participants
70 discussions

Re: GPC
by da Silva, Joe 05 Nov '01

05 Nov '01

You don't say what platform. For example, if it's DOS/DJGPP, Maurice has the most recent/stable build for this available via : ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip Joe. > -----Original Message----- > From: Vincent Derrien [SMTP:hyzzod@free.fr] > Sent: Wednesday, October 31, 2001 9:33 PM > To: gpc(a)gnu.de > Subject: GPC > > Hello, > > Can you say me where i can find the stable version of gpc please ? > I've got on the ftp, but i've just found the current (alpha) et old (2.0) > > thanks. > > -- > Vincent Derrien / hyzzod > hyzzod(a)free.fr

2 1

Re: Re :Typecasting | record-field boundary
by da Silva, Joe 05 Nov '01

05 Nov '01

Thanks for the clarification, Frank. Since the code "works with BP but not GPC", I presumed the hardware was X86 (IA32) ... I think Anuradha needs to clarify this, because as you say, misaligned access may not work with some other processors. BTW, the code also requires that a "word" is 16 bits - since the documentation implies that this is not true on all hardware, this is another potential problem with the code. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Saturday, November 03, 2001 4:52 AM > To: gpc(a)gnu.de > Subject: Re: Re :Typecasting | record-field boundary > > da Silva, Joe wrote: > > > So it seems this issue has arisen, because someone has decided > > to create 'getmemory' and 'freememory' routines, which simulate the > > functionality of 'new' and 'dispose' - strange!!! <g> > > Not quite. In BP (which the code was originally written for AFAIUI), > `New' does not support run-time variable sizes (there are no schema > types or similar in BP). So every allocation of variable size has to > be done via GetMem, and freed via FreeMem. Furthermore, BP does not > keep track of the size allocated by itself, and FreeMem must be > passed the correct size. So this stuff makes kind of sense for BP, > but is quite unnecessary for GPC. > > > Nevertheless, I can't see any reason why the sample code presented > > should fail, unless there is also some issue with accessing of record > > fields and their address alignment, right? > > Apart from the 2 vs. 4 bytes (i.e., SizeOf > (Integer/Word/SizeType/...)) problem, there can be alignment > problems. The Intel IA32 processors allow misaligned access, though > with a speed penalty, other processors will simply crash. > > With a "shift" of 2 bytes, you're sure to get alignment problems. > With a shift of 4 bytes (as would be reasonable for GPC, see above), > you might get problems with large types (LongInt, real types). Not > sure what diffferent processors require, but I wouldn't be surprised > if such code crashes on non-IA32 machines. > > 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 1

GPC
by Vincent Derrien 02 Nov '01

02 Nov '01

Hello, Can you say me where i can find the stable version of gpc please ? I've got on the ftp, but i've just found the current (alpha) et old (2.0) thanks. -- Vincent Derrien / hyzzod hyzzod(a)free.fr

1 0

How can I get a complete copy of gpc ready to run?
by arvid.herzenberg 02 Nov '01

02 Nov '01

Section 5.3 of the GNU Pascal Manual says that many things are needed to compile GPC and to make sure that all necessary support libraries are installed. Just to learn how to do these things would take this 76 year old prospective user many, many boring months. I would prefer to spend this time on physical problems I care about, rather than on computer science. Can anybody tell me where or how I can get (or buy) a complete compiled copy of gpc on a CD (or set of floppies), containing all necessary libraries etc, all ready to run on SuSE Linux 7.1?

1 0

Re: Re :Typecasting | record-field boundary
by da Silva, Joe 02 Nov '01

02 Nov '01

Cute! ;-) So it seems this issue has arisen, because someone has decided to create 'getmemory' and 'freememory' routines, which simulate the functionality of 'new' and 'dispose' - strange!!! <g> Nevertheless, I can't see any reason why the sample code presented should fail, unless there is also some issue with accessing of record fields and their address alignment, right? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Friday, November 02, 2001 4:50 AM > To: anuradha(a)adcc.alcatel.be; cbfalconer(a)worldnet.att.net; gpc(a)gnu.de > Subject: Re: Re :Typecasting | record-field boundry > > CBFalconer wrote: > > > Anuradha wrote: > > > > > > The whole code is in a function 'getmemory' that 'getmem's the > > > required number of bytes and stores the number of bytes in the > > > previous 2 bytes. > > > There is also a procedure 'freememory' that reads the previous > > > 2 bytes and frees as many bytes as was allocated earlier by > > > getmemory. what could be the problem ? > > > ----------------------------- > > > program typcast1; > > > type > > > Mytype=record > > > i : integer; > > > c:^char; > > > end; > > > var > > > p:pointer; > > > begin > > > getmem(p,sizeof(mytype)+2); > > > fillchar(p^,sizeof(mytype)+2,0); > > > word(p^):=sizeof(mytype); > > > p:=pchar(p)+2; > > > mytype(p^).c:=nil; > > > end. > > > > Totally unneccessary. The system remembers the size allocated all > > by itself. > > > > getmem(p, sizeneeded); > > operateon(p^); > > dispose(p); > > p := nil; (* safety measure *) > > > > Pascal is a simple language. It doesn't have pointer arithmetic > > for very good reasons. Don't try to contort it into C. > > > > (I believe. Certainly Pascalp operates this way, so does C, which > > supplies the underlying library for GPC. Frank can confirm or > > deny). > > Confirm. Dispose and FreeMem are completely equivalent in GPC, and > you even can omit the second parameter to FreeMem. So if you only > need the extra memory for this purpose, you can avoid it entirely > with GPC and replace getmemory by a simple GetMem. > > And, of course, the 2 vs. 4 bytes issue looks quite much like the > size of Integer, sso SizeOf (Integer) should work with both > compilers. (Think about it: GPC allows memory allocations greater > than 64 KB, so storing the size in 2 bytes is not a good idea. ;-) > > 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 1

Re :Typecasting | record-field boundry
by Anuradha 01 Nov '01

01 Nov '01

Hello, * Leave alone the const, even if i equate the pointer to 'nil' the problem occurs.{ofcourse i did remove the writeln statement that dereferences the pointer}. * Why such coding at all : The whole code is in a function 'getmemory' that 'getmem's the required number of bytes and stores the number of bytes in the previous 2 bytes. There is also a procedure 'freememory' that reads the previous 2 bytes and frees as many bytes as was allocated earlier by getmemory. what could be the problem ? ----------------------------- program typcast1; type Mytype=record i : integer; c:^char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=nil; end. ---------------------- regards, Anuradha "da Silva, Joe" wrote: > I hope when you say "change p:=pchar(p)+2; to p:=pchar(p)+4;", you also > change "getmem(p,sizeof(mytype)+2);" to "getmem(p,sizeof(mytype)+4);"! > <g> > > I'm sure we all agree that this is very ugly, dangerous coding, but that's > not the point. You are trying to "stretch the boundaries" of the compiler, > to see how it behaves and to find out if there are any areas which may > in practice cause problems with porting other code, right? > > Well, to be honest, I can't see what the problem is here, although it must > have something to do with 32 bit alignment. As far as I can see, the two > lines "fillchar(p^,sizeof(mytype)+2,0);" and "word(p^):=sizeof(mytype);" > are irrelevant. All you are doing is allocating 2 extra bytes of memory than > your record type ("Mytype") needs, then offsetting a pointer to this by 2 > bytes, thereby forcing the compiler to address the record (and in > particular, > the pointer "c" within the record) on a 16 bit boundary. > > That's as far as I can analyse the situation, based simply on the source > code presented. Since I don't know the "inner workings" of the compiler > myself, perhaps someone else can comment further about this apparent > alignment issue. > > Joe. > > > -----Original Message----- > > From: Anuradha [SMTP:anuradha@adcc.alcatel.be] > > Sent: Wednesday, October 31, 2001 10:19 AM > > To: gpc > > Subject: Re: Typecasting > > > > Hello, > > > > I am really sorry for having missed a ^ in the program but you see , > > the > > program really worked in BP and not in GPC.But i do know that it is > > stupid to > > manipulate some parts of the pointer.kindly delete the previous mail. > > It is this program that i have problems in. > > ----------------- > > program typcast1; > > const ct :char='h'; > > type > > Mytype=record > > i : integer; > > c:^char; > > end; > > var > > p:pointer; > > begin > > getmem(p,sizeof(mytype)+2); > > fillchar(p^,sizeof(mytype)+2,0); > > word(p^):=sizeof(mytype); > > p:=pchar(p)+2; > > mytype(p^).c:=@ct; > > writeln(mytype(p^).c^); > > end. > > ------------------------ > > > > But if i change p:=pchar(p)+2; to p:=pchar(p)+4; then it works.Is it > > something to do with the word-boundaries? > > > > Thanks and regards, > > Anuradha > > > > > > Marco van de Voort wrote: > > > > > > What is the purpose of these two lines : ? > > > > word(p):=sizeof(mytype); > > > > > > In real mode TP it sets the offset of the segment:offset pair to 1. > > > > > > Probably it originally was meant as a simple inc(p); > > > > > > The problem it expects that the offset part of a newly allocated block > > is > > > always zero, which is afaik not true. (real mode TP allocates per half > > > segment). > > > > > > > p:=pchar(p)+2; > > > > > > inc(p,2); or p:=@p[2]; > > > > > > The overall effect therefore is inc(p,3); or p:=pchar(p)[3]; > > > > -- > > S.Anuradha > > Generic Data Tools, > > Alcatel Chennai. > > Alcanet : 2-757-7123

4 3

Avoiding warning message
by Preben Mikael Bohn 01 Nov '01

01 Nov '01

Hi all.. Is there any way to avoid the warning message " warning: missing string capacity - assuming 255" (other than correcting the problem, that is :-))? Best regards Preben Bohn ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

2 1

Re: Avoiding warning message
by Oldham, Adam 01 Nov '01

01 Nov '01

gpc -w should omit warnings liek that Adam -----Original Message----- From: Preben Mikael Bohn [mailto:preben_bohn@yahoo.com] Sent: Thursday, November 01, 2001 9:41 AM To: gpc(a)gnu.de Subject: Avoiding warning message Hi all.. Is there any way to avoid the warning message " warning: missing string capacity - assuming 255" (other than correcting the problem, that is :-))? Best regards Preben Bohn ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

1 0

not used or set
by toms＠ncifcrf.gov 01 Nov '01

01 Nov '01

Folks: I am compiling my programs with both GPC and Sun's compiler. A service that the Sun compiler provides is to check that a variable is actually used or set. For example, it will say: pc0: WorkShop Compilers 4.2 01/04/00 Pascal 4.2 patch 104632-11 Wed Oct 31 08:05:05 2001 numcode.p: In procedure checkcount: w 18260 variable f is neither used nor set This would be a very useful feature to have as it allows one to remove unused or leftover variables. In this case I was using a global (output) when I should have been using the locally defined file! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

Probs building gpc on sparc/solaris
by Stephan Eickschen 01 Nov '01

01 Nov '01

Dear List, May be it's an OT but I couldn't find anything matching in the archives or at google. I downloaded gpc-20010924.tar.gz gcc-core-2.95.2.tar.gz unpacked them, followed the instructions in INSTALL (...) configure --enable-languages=pascal (...) executed a gmake and get: > cd /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info && makeinfo -I .. -I ../.. -I ../../generated -o gpc.info gpc.texi > Making info file `gpc.info' from `gpc.texi'. > ../install.texi:143: Unknown command `smallformat'. > ../install.texi:145: Unmatched `@end'. > ../install.texi:155: Unknown command `smallformat'. > ../install.texi:158: Unmatched `@end'. > ../reference.texi:8587: itemize requires an argument: the formatter for @item. > ../reference.texi:8599: itemize requires an argument: the formatter for @item. > makeinfo: Removing output file `gpc.info' due to errors; use --force to preserve. > gmake[1]: *** [/home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info/gpc.info] Error 2 > gmake[1]: Leaving directory `/home/AIDA301/eicksch/gpc/build/gcc' > gmake: *** [all-gcc] Error 2 uname -a SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10 Any suggestion / help??? Best regards, Stephan -- ---------------------------------------------------------------------- Stephan Eickschen Tel. : +49 (0)8153 28-1351 GeoForschungsZentrum Potsdam (GFZ) Fax. : +49 (0)8153 28-1207 Division 1, Section 1.2 c/o email: eicksch(a)gfz-potsdam.de DLR Oberpfaffenhofen www : http://op.gfz-potsdam.de Box 1116 82234 Wessling Germany ----------------------------------------------------------------------

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