Gpc

gpc@gnu.de

5400 discussions

[RFA] p-exp.y uppercasing change
by Pierre Muller 06 Nov '01

06 Nov '01

In order to allow GPC compiled programs to find fields of structures, I need to change p-exp.y so that the case is only modifed if the symbol is really found. I also added a check for the standard GPC case which uses names in capitalized form (i.e. first char in uppercase, rest in lowercase). Note: before this patch, it is impossible to get any field of a record (pascal structure) compiled with GPC. Should I consider changing 5.1 branch also ? Changelog: 2001-11-06 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-exp.y (): only change case of expression if symbol is found. Also check for GPC standard name form. Index: p-exp.y =================================================================== RCS file: /cvs/src/src/gdb/p-exp.y,v retrieving revision 1.6 diff -u -r1.6 p-exp.y --- p-exp.y 2001/06/10 16:25:51 1.6 +++ p-exp.y 2001/11/06 15:27:02 @@ -1306,14 +1306,48 @@ { if ((tmp[i]>='a' && tmp[i]<='z')) tmp[i] -= ('a'-'A'); - /* I am not sure that copy_name gives excatly the same result ! */ + } + sym = lookup_symbol (tmp, expression_context_block, + VAR_NAMESPACE, + &is_a_field_of_this, + (struct symtab **) NULL); + if (sym) + for (i = 0;i <= namelen;i++) + { if ((tokstart[i]>='a' && tokstart[i]<='z')) tokstart[i] -= ('a'-'A'); + } + } + /* Third chance Capitalized (as GPC does) */ + if (!sym) + { + for (i = 0;i <= namelen;i++) + { + if (i==0) + { + if ((tmp[i]>='a' && tmp[i]<='z')) + tmp[i] -= ('a'-'A'); + } + else + if ((tmp[i]>='A' && tmp[i]<='Z')) + tmp[i] -= ('A'-'a'); } - sym = lookup_symbol (tmp, expression_context_block, + sym = lookup_symbol (tmp, expression_context_block, VAR_NAMESPACE, &is_a_field_of_this, (struct symtab **) NULL); + if (sym) + for (i = 0;i <= namelen;i++) + { + if (i==0) + { + if ((tokstart[i]>='a' && tokstart[i]<='z')) + tokstart[i] -= ('a'-'A'); + } + else + if ((tokstart[i]>='A' && tokstart[i]<='Z')) + tokstart[i] -= ('A'-'a'); + } } /* Call lookup_symtab, not lookup_partial_symtab, in case there are no psymtabs (coff, xcoff, or some future change to blow away the Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

1 0

Re: Re :Typecasting | record-field boundary
by Frank Heckenbach 05 Nov '01

05 Nov '01

Anuradha wrote: > The machine i am working with is sparc sun-solaris.Can you tell me more > on the alignment problem? Yes, Sparcs have strict alignment requirements. So I suggest to either use `SizeOf (LongestInt)' instead of 2 or, as I already said, avoid the extra code entirely and just use GetMem/FreeMem (the latter with only one argument if you like) instead of getmemory/freememory (provided you don't need the extra size information for any other purpose besides freememory). > I don't get the error with the original code if i just add "packed" > before the "record". GPC generates special code for packed records which avoids the alignment problem, but it clearly less efficient. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

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

05 Nov '01

Hey - you're right! "Word" is (usually) 32 bits for GPC. Lesson : Read the latest doc's, don't rely on the old ones! <G> Anyway, this issue shouldn't matter for the sample code presented, so we'll wait for some more input from Anuradha ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, November 05, 2001 12:00 PM > To: gpc(a)gnu.de > Subject: Re: Re :Typecasting | record-field boundary > > da Silva, Joe wrote: > > > 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, > > In fact, for GPC this is true for *none* of the platforms -- > `Integer' and `Word' are at least 32 bit (64 on some). Of course, > you can redeclare `Word' (see the System unit), though this is not > recommended. > > > this is another potential problem > > with the code. > > I think I mentioned this in my last mail. > > 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

1 0

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

Jump to page:

2025

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