Gpc December 2002

gpc@gnu.de

35 participants
51 discussions

Re: MinInt (was: Bug? Identifier Integer sometimes fails)
by da Silva, Joe 13 Dec '02

13 Dec '02

Please see below ... Joe. > -----Original Message----- > From: Frank D. Engel, Jr. [SMTP:fde101@yahoo.com] > Sent: Friday, December 13, 2002 12:45 AM > To: Frank Heckenbach; gpc(a)gnu.de > Subject: Re: Bug? Identifier Integer sometimes fails > > > > CONST > > > maxint = 32767; (* redefine *) > > > minint = -32768; > > > To be pedantic, you might want to write `MinInt = -MaxInt;' since > > the standard demands a symmetric range of Integer. > > Uh... > > '-MaxInt' would imply -32767..32767, which wastes a potential stored > value (and cannot accomidate interfacing with other languages, which do > not have this restriction). > > '-MinInt' would imply -32768 (yes, negative; run the negation in 2's > compliment and you will see what I mean). > > By 'symmetric,' do you mean that the Pascal standard actually calls for > the INTEGER type to have the same negative range as positive? > [Joe da Silva] That's right, Pascal does NOT assume two's complement integer representation, so the standard range for an integer is -maxint to +maxint. Indeed, much of the early work on Pascal was done on CDC machines that had a sign & magnitude integer representation, hence this really was the range for integers. Although these days, two's complement integer implementations are all you are likely to encounter, in theory you should avoid -maxint-1 for portability. This value is a non-standard integer value, or a non-standard language extension, if you like. You may use it in that knowledge. Note that NW was quite happy for Pascal implementations to have whatever non-standard extensions were appropriate, he and KJ were only seeking to define a common, minimalist language, that all implementations must support. > ===== > ======= > Frank D. Engel, Jr. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com

1 0

Smart recompilation, interfaces and implementation
by Nick Ioffe 12 Dec '02

12 Dec '02

Hi! We're converting large (about 300 modules) project from DEC-PASCAL to GPC. The problem is that building the project after changing some file is very time-consuming, since when I change module implementation the interface is recompiled as well. I keep both interface and implementation in the same file, so when the file is changed I've no way telling the make what have changed - interface or implementation , don't I? If there is an option then I can use --interface-only and --implementation-only options in gpc. Thus number of questions : 1. Is there any "normal" way (without keeping previous version of .pas) to tell what have been changed? 2. How do you handle such problems? 3. Is there any automatic tool which can keep and provide the makefile with dependency structure of modules? The obvious way of updating Makefile manualy with steps like moduleX: moduleX_interface, moduleY, moduleZ gpc --implementation-only ModuleX for each of 300 modules which has "thick" dependency sounds not good Thank you in advance, Nick

4 8

Some tests on gpc321 for DJGPP
by CBFalconer 12 Dec '02

12 Dec '02

I ran the following little tests. There are some comments in the source. In particular I am worrying about the use of field width specifications. 0 is illegal in ISO7185, legal in 10206. -ve are illegal in both, and not detected. I really have no great objections to this, but if it is not detected lets at least put it to good use. I recommend using -ve values to cause left justification in the field. I also consider the failure to stop compilation on the final '.' a serious fault. This feature makes the sources immune to the lack of line termination at the end of the source file, and allows appending useful commentary there. Some of my files end with ^Z (for EOF on CP/M or MsDos) and a two byte CCIT CRC checksum. This makes it extremely easy to detect corruption. Heeding the final '.' makes the system immune to the OS handling of EOF markers. BTW what is the effect, if any, of the -pedantic, -W, -Wall gcc options? Should we be using -gstabs+ (my practice) or just -g. Under DJGPP in particular. PROGRAM misctests(input, output); (* Compiled with --standard-pascal *) CONST maxi = 32767; mini = -32768; maxwd = 65535; TYPE integer = mini .. maxi; word16 = 0 .. maxwd; VAR ch : char; i, j : integer; BEGIN (* misctests *) writeln('Hello, World'); writeln('"', 'string in field of 25' : 25, '"'); writeln( '"1234567890123456789012345"'); writeln('Maxint = ', maxint : 0); writeln('Maxi = ', maxi : -20, ' Mini = ', mini : 1); (* disappointing that -ve field neither left justifies *) (* nor is flagged as an error *) (* My pref: 0 default, -ve for left just, +ve as usual *) writeln('Enter lines until eof'); WHILE NOT eof DO IF eoln THEN BEGIN writeln; write(input^, 'Enter: new line: ' : 6); (* This ^ should be a blank *) (* Check truncates *) readln; END ELSE BEGIN output^ := input^; put(output); get(input); END; writeln('Fld ActualFld'); writeln('=== ======...'); FOR i := -8 TO 8 DO writeln(i : 3, '"', maxi : i, '"'); i := maxi - 4; (* FOR j := maxi - 3 TO maxi + 3 DO BEGIN *) (* now throws a constant out of range error gpc321 *) (* which is definite progress towards range checks *) FOR j := -3 TO +3 DO BEGIN i := succ(i); write(i : 6); (* should crash *) END; writeln; writeln(' Should have crashed here after 32767'); END. (* misctests *) (* ^ Nothing should count after this period *) (* However gpc throws errors down here *) (* unless commented out *) -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

4 7

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 12 Dec '02

12 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

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 December 2002