Gpc May 1997

gpc@gnu.de

30 participants
111 discussions

OOP (Was: bpcompat-1.0.zip)
by Frank Heckenbach 25 May '97

25 May '97

Pierre Phaneuf wrote: > Ah, I didn't knew the size was at the beginning of the VMT... But this > isn't quite the Right Way (if the VMT format changes for whatever reason), > no? Though the VMT format might not be likely to change, perhaps it would be better to have a built-in function of the compiler to return the object size of a given VMT link (should be easy to implement). > > 4) Call the object's `Load' constructor. > > This could cause problems. How shall I call the Load constructor? > > function CreateObject(VMTLink: pointer; S: PStream): PObject; > var > P: PObject; > Size: ^word; > begin > Size:=VMTLink; > getmem(P, Size^); > TypeOf(P):=VMTLink; > P^.Load(S); > end; > > This wouldn't work (in BP at least), since this will call TObject's Load > constructor and it will reset the type of the object to TObject, whatever > has been set with TypeOf(). Couldn't "Load" be a virtual method instead of a constructor (perhaps a Boolean function that returns if it didn't fail)? I'm not sure if a constructor does anything special besides setting the VMT link which has been done here anyway, so if it does more, this suggestion might not be possible. But if it's possible, you also wouldn't have to register the Load constructor (neither Store, of course), so the registration could also be simplified to something like RegisterType(ObjType, VMTLink:Word); and the programs that use this function don't have to declare a "StreamRec" manually, which would be another simplification. And it would be even better if the compiler could do this automatically, i.e. each object type could (optionally) declare an "ObjType" value, and the compiler would provide functions to get the ObjType from a VMT link and vice versa. Thinking about how to implement this, I realize this is basically the same as object constants -- something that's missing in BP and I could've used sometimes. This could be a useful extension to BP's objects. (The constants and their values would be inherited if not redeclared, just like virtual methods.) "ObjType" could then be a normal object constant with only 2 differences: the compiler should make sure that no two types within a program have the same ObjType (especially, that no type accidentally inherits its parent's value!), and there must be a special function to get the VMT link from an ObjType. And while I'm at it, class variables would also be nice, i.e. variables that exist only once for all instances of an object type (aka class). Again, I had some situations where I liked to have them. (For variables, there is a difference between object and class variables, for constants this difference doesn't matter.) Just some ideas... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: bpcompat-1.0.zip
by Peter Gerwinski 23 May '97

23 May '97

According to Pierre Phaneuf: > > I just checked out the new bpcompat sources... Did anyone actually *USED* > the OBJECTS.PAS unit??? More specifically, the TStream Put and Get > methods? They are obviously broken... This is a very first release, and the `tStream' object is marked as "{ !!! not complete !!! }". Now you know what was meant with the statement "and some of the routines do not work well" in the announcement. > Ok, so those are difficult parts, but still... What I need is two things: > a way to tell what is the real type of an object like the typeof() > function (didn't check if it was there), It is there since gpc-970510 (see the announcement). > and a way to construct an object > of an type as returned by typeof(). >From the announcement of gpc-970510: * `TypeOf' applied to object variables works now, too. As a GPC extension, you can explicitly assign a value to "TypeOf ( MyObj )" if extended syntax is ON (*$X+*). This means that, with (*$X+*), you can explicitly assign a `TypeOf' to an object. I implemented this extension just for the purpose to write the `tStream.Get' method. (In BP, this is achieved with assembler, but we want to have it portable for GPC.) > Something that would enable me to do something so that > new(typeof(TMyObject), Init) creates an instance of TMyObject, calls Init > and returns a pointer to the newly created object would be just *perfect*. Please add it to `objects.pas'! My suggestion: 1) Write a `RegisterType' function, so you can read the `ObjType' out of the stream and look up its `VmtLink'. 2) Replace the `New' in `tStream.Get' by a `GetMem' with the Size read off the VMT (a Word variable at the very beginning of the VMT). 3) Explicitly assign `VmtLink' to `TypeOf ( the new object )'. 4) Call the object's `Load' constructor. Please join us in improving GPC! Greetings, 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 [970510] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: bpcompat-1.0.zip
by The African Chief 23 May '97

23 May '97

On Thu, 22 May 1997 20:12:09 -0400 (EDT) Pierre Phaneuf <pp(a)gulliver.qc.ca> wrote: >I just checked out the new bpcompat sources... Did anyone actually *USED* >the OBJECTS.PAS unit??? Yes - see; TESTOBJ.PAS TESTCOLL.PAS TESTSTRM.PAS >More specifically, the TStream Put and Get methods? Yes - see; TESTSTRM.PAS > They are obviously broken... They worked okay in my tests. See the procedure "TestPut" in TESTSTRM.PAS. Can you post a copy of the code that is broken? BTW: it is stated clearly that TStream and some of the other objects are not complete - so, if anyone wants to implement the missing bits, please feel free to do so! >Ok, so those are difficult parts, but still... What I need is two things: >a way to tell what is the real type of an object like the typeof() >function (didn't check if it was there), and a way to construct an object >of an type as returned by typeof(). It isn't there - but you could write it :-). We would greatly welcome all contributions to the bpcompat package! Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

2 1

bpcompat-1.0.zip
by Pierre Phaneuf 23 May '97

23 May '97

I just checked out the new bpcompat sources... Did anyone actually *USED* the OBJECTS.PAS unit??? More specifically, the TStream Put and Get methods? They are obviously broken... Ok, so those are difficult parts, but still... What I need is two things: a way to tell what is the real type of an object like the typeof() function (didn't check if it was there), and a way to construct an object of an type as returned by typeof(). Something that would enable me to do something so that new(typeof(TMyObject), Init) creates an instance of TMyObject, calls Init and returns a pointer to the newly created object would be just *perfect*. Pierre Phaneuf

1 0

Re: GPC Question (or bug)
by Peter Gerwinski 22 May '97

22 May '97

According to Phil Robertson: > > I've ran into a problem compiling separate UNITS using > "borland-pascal" style syntax. Essentially individual > elements in an ENUM declared in an INTERFACE are not > "recognized" by gpc-2.0: I could reproduce this bug - and fix it. The next alpha release of GPC - perhaps this weekend ... or maybe we should start to call it a "beta" release ... - will compile your programs correctly. > I assume no "type cast" error is reported since full > pascal type/range checking is not as yet implemented. Indeed. I fixed this, too. Thanks for reporting these bugs, 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 [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

GPC Question (or bug)
by Phil Robertson 22 May '97

22 May '97

I've ran into a problem compiling separate UNITS using "borland-pascal" style syntax. Essentially individual elements in an ENUM declared in an INTERFACE are not "recognized" by gpc-2.0: testunit1.pas: UNIT TestUnit1; INTERFACE TYPE Wood = (Oak, Pine, Beech, Teak); Fruit = (Apples, Peaches, Lemons); CONST Oranges = Teak; PROCEDURE CheckFruit ( FruitType : Fruit ); IMPLEMENTATION PROCEDURE CheckFruit ( FruitType : Fruit ); BEGIN CASE FruitType OF Apples : Writeln ('Apples'); Peaches : Writeln ('Peaches'); Lemons : Writeln ('Lemons'); END; END; END. <gpc -c testunit1.pas> compiles with no errors. testunit2.pas: UNIT TestUnit2; INTERFACE USES TestUnit1; PROCEDURE UseFruit; IMPLEMENTATION PROCEDURE UseFruit; BEGIN CheckFruit (Apples); CheckFruit (Peaches); CheckFruit (Lemons); CheckFruit (Oranges); END; END. <gpc -c testunit2.pas> yields: testunit2.pas: In function `Usefruit': testunit2.pas:13: undeclared identifier `Apples' (first use this function) testunit2.pas:13: (Each undeclared identifier is reported only once testunit2.pas:13: for each function it appears in.) testunit2.pas:14: undeclared identifier `Peaches' (first use this function) testunit2.pas:15: undeclared identifier `Lemons' (first use this function) It's interesting that "Oranges" is recognized since it is a const. I assume no "type cast" error is reported since full pascal type/range checking is not as yet implemented. Does anyone know of a fix or work-around for this? We're trying to port some code still in production and are stuck with a 10 year old compiler from Silicon Valley Software (now defunct). Thanks; Phil ------------------------------------------------------------------------- Philip A. Robertson <phil_robertson(a)gilbarco.com> Gilbarco Inc. F-78 Phone (910) 547-5164 7300 W. Friendly Ave Fax (910) 292-8871 Greensboro, NC 27410 -------------------------------------------------------------------------

1 0

GPC ok (fwd)
by Vadim Aleksandrovich Denisyuk 21 May '97

21 May '97

GPC works. Thanks Go...Peter ---------- Forwarded message ---------- Date: Wed, 21 May 1997 15:41:16 +0200 (MET DST) From: Super-User <root(a)fis.unico.it> To: Vadim Denisyuk <denisyuk(a)fis.unico.it> Subject: GPC ok Ok, I finally succeeded in correctly compiling the new GPC. Amazingly, it works, thanks to the last suggestion.

1 0

GPC and G77 (was without subject)-;
by Peter Gerwinski 20 May '97

20 May '97

DENISYUK VEDIM A wrote: > ---------- Forwarded message ---------- > Date: Mon, 19 May 1997 15:13:18 +0200 (MET DST) > From: fB <frances(a)fis.unico.it> > To: Vadim Denisyuk <denisyuk(a)fis.unico.it> > Subject: GPC compiled, but it does not work. > [...] > ========================================================================= > % ./gpc -c test/standard_pascal/hello.pas > gpc: test/standard_pascal/hello.pas: linker input file unused since > linking not done > ========================================================================= > So I probably messed up the command parser somewhere (see note). You are using the wrong `gpc' driver program: It does not recognize Pascal source files and thinks they are for the linker. To fix this, make sure that the correct `gcc.o' is linked to produce the `gpc' driver program. It's the same problem as with `stor-layout.o' etc., and the solution is the same, too (see my previous mail). Good luck, 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 [970510] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

None
by DENISYUK VEDIM A 19 May '97

19 May '97

Hi guys, Did somebody have experience to install g77 and gpc together (the newest versions?)? If it is you can you read the set of messages below with me and my system administrator to help us. Yous, Vadim ---------- Forwarded message ---------- Date: Mon, 19 May 1997 10:47:30 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Aleksandrovich Denisyuk <denisyuk(a)fis.unico.it> Subject: Re: Linking errors (fwd) Peter wrote: > 1. Get a recent version of GNU make. Version 3.74 or better is known > to work. > 2. Build GCC in a seperate directory instead of using the GCC source > directory. > 3. Manually delete these files from the GCC object directory: > `stor-layout.o' `dbxout.o' `expr.o' `fold-const.o' `optabs.o' > `convert.o' `function.o' `setop.o' `toplev.o' then resume `make'. This was in the FAQ. Still I have: Undefined first referenced symbol in file reg_known_equiv_p ../gcc-2.7.2.2/sched.o read_dependence ../gcc-2.7.2.2/sched.o record_base_value ../gcc-2.7.2.2/loop.o output_dependence ../gcc-2.7.2.2/sched.o true_dependence ../gcc-2.7.2.2/cse.o anti_dependence ../gcc-2.7.2.2/sched.o flag_alias_check ../gcc-2.7.2.2/calls.o reg_known_value ../gcc-2.7.2.2/sched.o init_alias_analysis ../gcc-2.7.2.2/cse.o flag_move_all_movables ../gcc-2.7.2.2/loop.o flag_reduce_all_givs ../gcc-2.7.2.2/loop.o ld: fatal: Symbol referencing errors. No output written to gpc1 *** Error code 1 make: Fatal error: Command failed for target `gpc1' Most of these are defined in ../gcc-2.7.2.2/alias.o, so linking with that one (which _might_ be dangerous) gives: Undefined first referenced symbol in file flag_alias_check ../gcc-2.7.2.2/calls.o flag_argument_noalias ../gcc-2.7.2.2/alias.o flag_move_all_movables ../gcc-2.7.2.2/loop.o flag_reduce_all_givs ../gcc-2.7.2.2/loop.o these I can deal with. While I am pretty sure I can now produce an executable, you should carefully test it, as I did undocumented things to get it to work. fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 15:13:18 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Denisyuk <denisyuk(a)fis.unico.it> Subject: GPC compiled, but it does not work. Apparently, the new version of GPC does not interact well with the Solaris linker/loader. This might be due to the modifications I introduced in order to compile it with G77, though[1]. The error I get while compiling the hello.pas test is: ========================================================================= % gpc test/standard_pascal/hello.pas ld: fatal: file test/standard_pascal/hello.pas: unknown type, unable to process using elf(3E) libraries ld: fatal: File processing errors. No output written to a.out ========================================================================= So it seems like gpc passes the wrong arguments to ld, something which did not happen with the previous version. Indeed g77 and gcc work perfectly with the Solaris-provided ld. On second thought... it seems like gpc passes everything unchanged to ld, without even attempting to compile anything. Indeed: ========================================================================= % ./gpc -c test/standard_pascal/hello.pas gpc: test/standard_pascal/hello.pas: linker input file unused since linking not done ========================================================================= So I probably messed up the command parser somewhere (see note). I'd install gpc in a completely separate directory with it's own straightforward version of gcc, but I already tried to do this with the previous version and, alas, g77 was (rather mysteriously) broken. I might real soon now experiment a little with doing this again in my copious free time. BTW, in the meanwhile I updated GCC/G77 to version 2.7.2.2.f.2 on all machines, and left 2.7.2.1 installed so that the old version of gpc still works. This _seems_ not to cause any problem right now. [1] This essentially reduces to linking gpc1 with ../gcc-2.7.2.2/alias.o and introducing the G77-specific options in toplev.c. I also had to explicitly #define some constants in a couple of places, though. As I could not be bothered to read and understand the source I obviously don't know what it's going on. -- fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 15:43:56 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Denisyuk <denisyuk(a)fis.unico.it> Subject: Before you ask... I have done this (from the FAQ): A number of Unix configurations use their system's linker instead of GNU `ld'. Usually, GPC and GCC need a program called `collect2' before calling the system's `ld'. `collect2' is installed by GCC, and if you only install GPC, it will not find `collect2', and use the system linker directly, which will result in various linker errors. The solution is to copy `collect2' by hand from the GCC directory to the location where `gpc1' lives. -- fB ---------- Forwarded message ---------- Date: Mon, 19 May 1997 16:32:57 +0200 (MET DST) From: fB <frances(a)fis.unico.it> To: Vadim Aleksandrovich Denisyuk <denisyuk(a)fis.unico.it> Subject: Re: Before you ask... The new gpc compiles, but does not work. Seems like in order to make it to compile I screwed up the command parser. Sorry, but I exactly remade everything I made last time to compile V2.0 and it did not work anymore. Since I have one Pascal user and about thirty Fortran users, I'd rather break Pascal than Fortran. I will try again to check what the problem is, but I think that simply GPC is not yet able to peacefully coexist with G77. -- fB

1 0

New, experimental GPC version (pentium-gpc)
by Jan-Jaap van der Heijden 19 May '97

19 May '97

Hello all, I have something for the daring folks among you: a GPC, based on the latest Cygnus CDK snapshot. For those of you who don't know, the Cygnus snapshots are GCC development releases, so you could consider this to be a pre-2.8 GCC. I used GPC-alpha 970510. I tested it on linux and SGI irix and had no problems with it (yet). Now, GPC alpha releases are usually quite reliable, but this is a major change in code, so you could consider this _REALLY ALPHA_ ;-) It can do some cool things like pentium(pro) optimizations. I would love to hear from somebody who does lots of floating point on a pentium(pro) whether it's really is faster. Binaries for pentiumpro-intel-linux (RedHat 4.1) and mips-sgi-irix6.2 are available. The mips binary is not targeting 64bits because of the immaturity of mips64 support in GCC. The linux binary installs in /opt/cdkgpc-i970518. You can move it around, just make sure you don't install it over your existing GCC. URL: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygnus-970507 Apart from numerous "easy fixes" and manual patching, these changes were necessary because of changes in GCC internals: gpc-decl.c: build_complex(): extra argument. setop.c: clear_storage(): New last argument. Probably clear blocksize. set to 1. Not most efficient, but works. gpc-cccp.c: quick hacks to add: int c89 UCHAR is_space Known bugs: (1) "automake" is completely broken. Still looking for a fancy solution that enables us to share the `gcc' driver with GCC. (2) Some files not modified but reused from 2.7.2.x: gpc-cccp.c, gpc-lex.c Todo: All cygwin32 related patches were removed from GPC and must be put back in. Must check for cygwin32-beta18 compatibility. *maybe* do a djgpp version. BTW: I don't plan to maintain a seperate Cygnus CDK GPC source tree. You could consider this a techdemo: the effort and results will pay off once GCC 2.8 is released, because porting GPC will be much easier then. Happy hacking! JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

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 May 1997