Gpc

gpc@gnu.de

5400 discussions

Re: Translation Scheme
by da Silva, Joe 12 Dec '02

12 Dec '02

Hmmm ... Do you perhaps want a P4 P-Code to 386 translation scheme instead? I'm assuming here that P4000 is some derivative of the P4. Since you already have a front-end, it may be easier to translate it's output to 386 as a separate program, instead of modifying the existing "front-end". Perhaps someone here may know of existing code to perform such a translation or at least know where to find decent documentation of the P4 P-Code (BTW, if so, I may be interested too;-). Joe. > -----Original Message----- > From: a2782(a)dis.ulpgc.es [SMTP:a2782@dis.ulpgc.es] > Sent: Thursday, December 12, 2002 10:56 AM > To: gpc(a)gnu.de > Subject: Translation Scheme > > Didn\'t you go to school? :) Weren\'t you ordered to make a simple > compiler which accepted a Pascal subset and generated machine code? > > I will tell you why do I want this translation scheme. I am involved in > a project in which one of its steps is taking a compiler of a language > called \'LC99\' (it is very close to Pascal or Algol) which actually > generates P-Code (from Pascal compiler P4000) and change it in order to > make it generates i386 code. It\'s the first time I make a pure back-end > (I\'ve been always working on front-ends, which make me happier :). I am > not interested in optimizations, because my project has only academical > purposes (it\'s a visualizator of memory implemented over GDB). > > Of course, implementation of GPC (front-end+Tree+RTL+back-end) crashes > with I want to get (lex,parser,semant-->code). I knew it. But I thought > any of you had some experience in something like this. > > Many thanks to Marcel, Frank Heckenbach, Waldek Hebisch, Russell > Whitaker, Maurice Lombardi and The African Chief (who has a Pascal-to- > 386 compiler which may be helpful to me). Thanks indeed to Joe da > Silva ;P. > > Ciao!

4 4

Delphi compatibility
by Prof. A Olowofoyeku (The African Chief) 12 Dec '02

12 Dec '02

Hi all Newer versions of Delphi (IIRC, from v4.0 onwards) permit a somewhat C-like procedure/function call - e.g., if you have these routines: function foo : integer; procedure bar; You can call them like this; i := foo; // GPC expects this bar; // -- ditto -- j := foo (); // Delphi accepts, but GPC doesn't bar(); // -- ditto -- I thing that it would be nice if GPC could support the addition of the brackets, but there may well be strong reasons for not doing so (for one, it is un-Pascalish). I also do not know whether it would be easy or difficult to implement. I fully appreciate that there are many other things that are far greater priorities - but if it could be done easily then should it? I find that many Delphi programmers are increasingly doing this (probably those who came from a C/C++ background) and so it gets a bit cumbersome to deal with them when trying to port free Delphi code to GPC. Any comments? Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

13 33

Re: New alpha
by da Silva, Joe 12 Dec '02

12 Dec '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, December 11, 2002 3:47 PM > To: gpc(a)gnu.de > Subject: Re: New alpha > -------- snip -------- > Of course, if you really want to, you can "bite the bullet" and try > integration right now. But I'm quite sure it will be much more work > in total than is doing it in the proper order, and it will be > technically dubious solutions (both from the GCC and the GPC > viewpoint, in different areas). > > OTOH, I don't see any big advantage in hurrying it. It may be easier > for distribution makers (so I see your POV, Matthias), but then > again, I suppose you have your build scripts in place for the > current situation, and changing them to a cleaner (in this regard) > style now or later doesn't make a big difference. I don't know about > the "simtel distribution" Chuck mentioned -- it's no problem today > to make distributions in any form (in source, if wanted, including > the GCC sources, already patched possibly; sure, the archive would > be a little bigger, some 15 MB instead of 2 MB, but from my > impression, most Internet users won't even notice the diffrence > today ;-). > > Actually I wonder where this "panic" about gcc integration comes > from. Since some time, I keep hearing these requests every other > week. GPC has been developed for years without such an integration, > and I doubt it would have been essentially better if it was > integrated -- maybe even worse; currently, when there are severe > backend problems (such as the `goto' bug in 2.95 on Solaris/Sparc), > there is the recourse to try another GCC version; if it was > integrated and tied to one GCC version, we'd depend on that version > [Joe da Silva] The advantage of integration is that it will give GPC vastly more exposure to potential users and give them the confidence to try it. For the same reason, this must not be done until it is really ready, otherwise it will just give rise to lots of queries and bug reports, which will slow down further progress. Just MHO. > ... > > Finally, if all that doesn't convince you, I'll put it in a more > selfish way. The main reason why I do GPC development is that I also > use GPC myself, and it's both useful and interesting to improve the > tools I'm using. GCC integration doesn't provide any direct > advantage to my work using GPC, so I don't feel like putting any > unnecessary work in it (which would be caused by hurrying it). > > So, everyone who wants to actually help the GCC integration, just > pick your job from the list above (or another one I may have > missed). So far only Waldek (with the "port" for gcc-3) and Eike > (with the manual license change to FDL, which was another > requirement) have done so (and I have done some things WRT the > Makefiles and in the code which I found also useful independently of > the GCC integration ;-). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html > GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 > 1707

1 0

Translation Scheme
by a2782＠dis.ulpgc.es 11 Dec '02

11 Dec '02

Didn\'t you go to school? :) Weren\'t you ordered to make a simple compiler which accepted a Pascal subset and generated machine code? I will tell you why do I want this translation scheme. I am involved in a project in which one of its steps is taking a compiler of a language called \'LC99\' (it is very close to Pascal or Algol) which actually generates P-Code (from Pascal compiler P4000) and change it in order to make it generates i386 code. It\'s the first time I make a pure back-end (I\'ve been always working on front-ends, which make me happier :). I am not interested in optimizations, because my project has only academical purposes (it\'s a visualizator of memory implemented over GDB). Of course, implementation of GPC (front-end+Tree+RTL+back-end) crashes with I want to get (lex,parser,semant-->code). I knew it. But I thought any of you had some experience in something like this. Many thanks to Marcel, Frank Heckenbach, Waldek Hebisch, Russell Whitaker, Maurice Lombardi and The African Chief (who has a Pascal-to- 386 compiler which may be helpful to me). Thanks indeed to Joe da Silva ;P. Ciao!

1 0

Re: Translation Scheme
by da Silva, Joe 11 Dec '02

11 Dec '02

Is this a joke? If not, I suggest you find out what "compiler" means! <G> Joe. > -----Original Message----- > From: a2782(a)dis.ulpgc.es [SMTP:a2782@dis.ulpgc.es] > Sent: Wednesday, December 11, 2002 10:31 AM > To: gpc(a)gnu.de > Subject: Translation Scheme > > Hi to all! > > Has anyone a Translation Scheme from Pascal to Intel 80386 code? Or > does anyone know how to get it? > > Thanks in advance.

9 11

gcc-3.2.1_gpc-20021128 16#80000000 difference
by Martin G C Davies 11 Dec '02

11 Dec '02

First, Frank, thanks for the advice on using Initialize to work around my file problem - works a treat. Now I have bumped into a difference (I have an easy workaround for me real code but I thought people might be interested). Build and run the program below. program mgcd_program; var num : integer ; begin num := -2147483648 ; if num = 16#80000000 then writeln( 'equal' ) else writeln( 'not equal' ) end. When I build with Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 2.1 (20020510), based on gcc-2.8.1 I get the output "equal". When I build with Reading specs from /ClearCase_01/mgcd/gcc-3.2.1_gpc-20021128_install.dir/lib/gcc-lib/sparc-sun- solaris2.6/3.2.1/specs Configured with: /ClearCase_01/mgcd/gcc-3.2.1/configure --prefix=/ClearCase_01/mgcd/gcc-3.2.1 _gpc-20021128_install.dir Thread model: posix gpc version 20021128, based on gcc-3.2.1 I get the output "not equal". The C program:- main() { int num = -2147483647 - 1 ; if ( num == 0x80000000 ) printf( "equal\n" ) ; else printf( "not equal\n" ) ; } always returns "equal". Anyway, clearly there is an inconsistency between the GPC versions. Cheers, Martin G C Davies

3 5

Re: Type extension
by Frank Heckenbach 11 Dec '02

11 Dec '02

Frank D. Engel wrote (by private mail, but from the content I suppose it was meant for the list; excuse me if I'm wrong): > How about addition, since in 'subclassing' we would be adding fields: > > TYPE > base = NIL + RECORD > i : INTEGER; > j : INTEGER > END; > > child = base + RECORD > x : REAL; > y : REAL > END; > > otherchild = base + NIL; > > hotdog = NIL + (x : INTEGER; y : REAL); > > cheesedog = hotdog + (t, q : CHAR); > > > Or something similar (prob. the first three preferred; the latter two > are a wild shortcut idea). At first sight, it's certainly a little strange ... BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges). The situation would be a little different from records -- you could assign a value of a small type to a larger one, not vice versa. You wouldn't need `is' and `as', simple comparisons and assignments will do. I don't know if any dialect has something like this. If not, and we'd make up something new, maybe we could use a common (or similar) syntax with extensible records ... Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

5 7

off topic
by Russell Whitaker 11 Dec '02

11 Dec '02

Hi Today is my 70th birthday. Suspect I'm the oldest subscriber on the list. Russ

2 1

Translation Scheme
by a2782＠dis.ulpgc.es 10 Dec '02

10 Dec '02

Hi to all! Has anyone a Translation Scheme from Pascal to Intel 80386 code? Or does anyone know how to get it? Thanks in advance.

1 0

makefile and crt
by mattias/spikboll 10 Dec '02

10 Dec '02

Hello, I have written a small app for school that uses a small module (written by me) and crt. It compiles fine with --automake, but I need to have a Makefile. My problem is that I don't know how to tell make to find crt.pas & co. should I move crt.pas, gpc.pas and all files they depend on into the build directory? /Mattias Ãstergren -- mattias Ã¶stergren | /"\ compsci student | \ / ASCII Ribbon Campaign gÃ¤vle, sweden | X No HTML in e-mail http://spikboll.net | / \

3 4

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