Gpc

gpc@gnu.de

5400 discussions

DejaGnu anybody?
by Jan-Jaap van der Heijden 07 Apr '97

07 Apr '97

Hello all, I've inserted hooks in the GPC Makefiles for a DejaGnu based compiler testsuite, like other GNU software (gcc, gdb etc.) has. The testsuite itself has to be written though. It would have to cover all language constructions (which are expected to pass) and a number of tests which the compiler should reject (because they are invalid Pascal). There's just one problem: I have never set up an autmated testsuite and I have virtually no experience with DejaGnu. So: Is there anybody out there who has worked with dejagnu and can give me some help? Also, how do I set up such a testsuite? Take the ISO spec and start writing small programs for every paragraph of chapter 6 in the ref? Right now I have one program that passes ("Hello world") and one broken program which fails (as expected) ... Greetings, JanJaap --- Thus spake the master programmer: "After three days without programming, life becomes meaningless." [The Tao Of Programming]

1 0

How should a make-time field width option look like?
by Peter Gerwinski 07 Apr '97

07 Apr '97

Hello everybody, I just had a look at the GPC configuration scripts and makefiles in order to implement the compile-time `--field-widths' option. It makes trouble. * GPC's configuration scripts are written using `autoconf'. I have no idea how to implement such an option there. But even if I had, it would disappear again when GPC will be integrated into the main distribution line of the GNU compiler. * It is easier to implement an option to `make' rather than to `configure': With small changes to `rts/rts.h' I can provide the following: make CFLAGS="-O2 -D INT_OUT_WIDTH=12 -D REAL_OUT_WIDTH=24" install Alternatively, you can edit the Makefile to pass these definitions. Would this be enough? It doesn't look too nice for me. And: This might also cause trouble when GPC will be integrated into the GCC main distribution line because the other compilers will see those `-D's, too: make LANGUAGES="c,c++,pascal" \ CFLAGS="-O2 -D INT_OUT_WIDTH=12 -D REAL_OUT_WIDTH=24" install * We already had some discussions about configuration files. I am just adding a "*gpc1:" line to the `specs' file Jan-Jaap wrote about. Below the "*gpc1:" there are two empty lines. Whatever you write there will be passed to the GNU Pascal compiler as additional command-line options, for instance *gpc1: -ffield-widths=10,25,7 Note that `--foo' switches are not supported; you have to specify them as `-ffoo'. Similarly, `--pedantic' must be `-pedantic' (*not* `-fpedantic'). The default contents of this `specs' line can be specified at make-time either using make CFLAGS="-O2 -D GPC1_SPEC=\\\"--field-widths=10,25,7\\\"" install or by editing the Makefile. But when looking at those triple backslashes it seems more comfortable for me to edit `specs' after having installed GPC. The run-time `--field-widths' switch ("run-time" means: when you compile a program by running GPC), in contrast, does not seem to cause major problems. There will be no variables like "default_int_width" like I wrote about on 5 Apr. Such variables would require the compiler switch (*$field-widths*) to produce executable code - which is not its purpose. But the switch will act as a local switch (as promised). Please let me know your suggestions about that global compile-time configuration problem. Yours, 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Unsubscribing
by Amy Williams 07 Apr '97

07 Apr '97

Hi, I've lost the info for unsubscribing, please let me know how to do so. TIA, Amy Williams epic(a)aros.net http://amys.base.org

2 1

[BUG] GPC - a char killer?
by Sven Engelhardt 06 Apr '97

06 Apr '97

Hallo dear Hackers, hi Peter, I found a bug in GPC (my version: 970401/linux/i586)? I wrote the following little program: { -- the buggy program - see below ----------------} {Warning getchar may be implemented as a macro to getc(stdin), so this may be, this will not work for you } program test1(input,output); function getchar:integer; C; var k:integer; begin k:=getchar; while (k<>-1) do begin writeln(k); k:=getchar; end; end. {--- The same as C-Source -- works ok. ---} #include <stdio.h> void main() { int k; k=getchar; while (k!=-1) { printf("%i\n",k); k=getchar; } } { --------------------------------------- } Ok. Compiling test1.pas - no errors. Running test1 Enter an 'N' press return you will see '78 10' - thats right. Now the following: echo "N">data test1 <data Now you will see '10' - thats wrong. test1 has eaten up the first char. (Doing the same with the compiled C-Source gives '78 10', the correct result.) It does not even help to compile a readkey.o from a C-Source and use the Readkey procedure from that. Obviously Gpc-Runtime does something strange at startup. In real live my stdin will be connected to a socket so that's not easy to be worked around. Quick responses appreciated. thanks Sven

1 0

DOS batch files (was: Standard Compatibility)
by Peter Gerwinski 06 Apr '97

06 Apr '97

Nils Bokermann wrote: > > Isn't there a way by making *.BAT-Files in dos? That is something like a > shell-script, isn't it? Yes. bpc.bat: @gpc -g -O2 --borland-pascal --automake="-g -O2 --borland-pascal" %1.pas -o %1.exe %2 %3 %4 %5 %6 %7 %8 %9 The `@' means "don't echo this command to the screen". AFAIK, there are no `\' signs in DOS to break long lines. The "%2 %3 %4 ..." are there to pass additional command-line parameters given to `bpc.bat' to `gpc'. Problem with such batch files: These will easily bump against the 128-character limitation of command-lines under DOS ... :-( 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Standard Compatibility [was: Re: New Alpha]
by Peter Gerwinski 06 Apr '97

06 Apr '97

According to Berend de Boer: > > [...] > > gpc isn't developed for the dos platform. GPC has been developped for *all* platforms including DOS. :-) > Borland excellently fills that need. No. Borland *did* excellently fill that need, but there has been no progress in Borland Pascal since BP 7.0 appeared in 1992 - 5 years ago. Borland does not support the DOS platform any more so there *is* need for a better Pascal compiler for DOS which allows to orientate towards Linux, OS/2 and other systems as alternatives to Windows 95. > I want gpc to create truly platform independent programs > for my unix machine. Here we agree completely. (-: 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Configuration files (was: Standard compatibility)
by Peter Gerwinski 05 Apr '97

05 Apr '97

According to Frank Heckenbach: > > Does this also include the "-o ..." option? In this case, this "problem" > would also be solved by putting "{$o destname}" into the main program. That's problematic because the `-o' option is handled by the `gpc' driver program, not by the `gpc-cpp' preprocessor or the `gpc1' compiler which read the source. > BTW: Are compiler options case sensitive? Otherwise there would be a possible > confusion with BP's "{$O filename}" for overlays. GPC's compiler options are not intended to be compatible to Borland Pascal's ones (except perhaps the most "basic" ones like $R, $I, $S which are compatible between UCSD and Borland). These options are too system-specific; especially the "overlay" option makes no sense for GPC. But an `o' option (output file name) would crash with `O' (optimization), so these options should be replaced by long names, e.g. (*$output-file-name *) and (*$optimize *). > I also suggest a compiler switch that will always choose the base filename as > the destination filename, unless an explicit "-o ..." option is given. > Then I could put this switch into a global configuration file/specs/whatever > and wouldn't usually have to worry about "-o ..." options. Here I agree. BTW, EMX derives the name of the output file name from that of the first input file name. > In such a way that they can be changed at any point in the source, like in > this (extreme and not very sensible) example: > write({$field-widths=0,0,0}a,{$field-widths}b) This requires additional work due to the method how field widths are handled by the run time system. It would be easier to make the default field widths variables accessible to your program, e.g. if you write Var DefaultIntegerWidth: asmname 'default_int_width' Integer; DefaultRealWidth: asmname 'default_real_width' Integer; DefaultBooleanWidth: asmname 'default_bool_width' Integer; Then you can save their values in local variables and restore them later ... > Perhaps also "--no-field-widths", equivalent to "--field-widths=0,0,0"? Perhaps ... :-/ > The "-O" (optimization) switches could also be useful in the source, like: > > [some non-time-critical code] > > {$O2} > > [very time-critical code] > > {$O0} > > [some non-time-critical code] (* Why don't you want to compile your whole program with -O2? I would not release an unoptimized program as "production version". (I have been doing this long enough with BP now ...) *) > This example also shows that it can be desirable to "push" and "pop" options. > It would be better to write e.g. (tentative syntax): > > [...] > > Then, after the "{$END}", the options would be like they were before the > "{$BEGIN}", and if "-O2" was given from the command line, it would still > be on in the last part of the code. This would be relatively hard to implement. I will not do that in the near future, but I wouldn't mind if somebody else would take care of that. ;-) But we must ensure that this will not break existing features of the preprocessor. Also remember that (*$foo*) can also be written as #foo <eol> ... > In fact, this is a missing feature of BP, and is often solved by workarounds > like: > > {$IFOPT R+}{$DEFINE R}{$ENDIF}{$R-} > [...] > {$IFDEF R}{$R+}{$ENDIF} > > This works for a switch with only 2 possible values ({$R+} and {$R-}), but for > siwtches like {$field-width=x,y,z}, it's not possible to do it like that, and > it's not very nice anyway... > So, pushing and popping options would really be a plus. I agree, but see above. > > In fact DJGPP supports symbolic links on DOS. > > Really? I didn't find an "ln" command on my system. Install GNU fileutils 3.13 or later. See the DJGPP FAQ, chapter 22, for more about symbolic links under DOS. > I installed just the > necessary DJGPP stuff, do I need some more packages for symlinks? And do > symlinks also work for executables, or only for files accessed from within > DJGPP programs? Vice versa, they seem to work *only* for executables ... (?) > Anyway, I don't think this would be a good solution for > DOS systems, Why not? It works well for other DJGPP programs. > but as many of you have shown, there are enough ways to supply > default switches on any system, with or without an IDE... Correct. However we must carry those options too far: even experienced users will not like to deal with hundreds of command-line options ... 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Standard Compatibility [was: Re: New Alpha]
by Berend de Boer 05 Apr '97

05 Apr '97

You wrote: >> Because that is how a majority of Pascal compilers do it. > >But the majority is using borland and therefore this behaviour IS >NOT >USUAL for the majority of programmers, source-code-programs etc.pp. >Maybe it is for YOU and YOUR compiler. The majority of Pascal programmers use a Borland product, nobody disagrees about that. However, the majority of programmers are they using Borland or did they use Borland. Wil they prefer Borland compatibility? I don't. gpc isn't developed for the dos platform. Borland excellently fills that need. I want gpc to create truly platform independent programs for my unix machine. Groetjes, Berend. (-:

1 0

Re: Configuration files (was: Standard compatibility)
by Frank Heckenbach 05 Apr '97

05 Apr '97

Peter Gerwinski wrote: > However I have planned to make it possible to put all compiler options > (including `--automake' :) into the source, so you will be able to > compile any Pascal program just with "gpc progname.pas". That would be great! Putting "--automake" into the source seemed strange to me at first sight, but when I think about it, it can be useful for distributing programs. Does this also include the "-o ..." option? In this case, this "problem" would also be solved by putting "{$o destname}" into the main program. BTW: Are compiler options case sensitive? Otherwise there would be a possible confusion with BP's "{$O filename}" for overlays. I also suggest a compiler switch that will always choose the base filename as the destination filename, unless an explicit "-o ..." option is given. Then I could put this switch into a global configuration file/specs/whatever and wouldn't usually have to worry about "-o ..." options. > * I will try to make it possible to pass these command-line options > as compiler directives, e.g. (*$field-widths=12,24,6*). In such a way that they can be changed at any point in the source, like in this (extreme and not very sensible) example: write({$field-widths=0,0,0}a,{$field-widths}b) Perhaps also "--no-field-widths", equivalent to "--field-widths=0,0,0"? The "-O" (optimization) switches could also be useful in the source, like: [some non-time-critical code] {$O2} [very time-critical code] {$O0} [some non-time-critical code] This example also shows that it can be desirable to "push" and "pop" options. It would be better to write e.g. (tentative syntax): [some non-time-critical code] {$BEGIN}{$O2} [very time-critical code] {$END} [some non-time-critical code] Then, after the "{$END}", the options would be like they were before the "{$BEGIN}", and if "-O2" was given from the command line, it would still be on in the last part of the code. In fact, this is a missing feature of BP, and is often solved by workarounds like: {$IFOPT R+}{$DEFINE R}{$ENDIF}{$R-} [...] {$IFDEF R}{$R+}{$ENDIF} This works for a switch with only 2 possible values ({$R+} and {$R-}), but for siwtches like {$field-width=x,y,z}, it's not possible to do it like that, and it's not very nice anyway... So, pushing and popping options would really be a plus. > In fact DJGPP supports symbolic links on DOS. Really? I didn't find an "ln" command on my system. I installed just the necessary DJGPP stuff, do I need some more packages for symlinks? And do symlinks also work for executables, or only for files accessed from within DJGPP programs? Anyway, I don't think this would be a good solution for DOS systems, but as many of you have shown, there are enough ways to supply default switches on any system, with or without an IDE... -- 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: Unsubscribing
by Peter Gerwinski 05 Apr '97

05 Apr '97

According to Amy Williams: > > I've lost the info for unsubscribing, please let me know how to do so. >From the GPC FAQ: How to post to the mailing list You can send a message to the GPC mailing list by sending email to the list address <gpc(a)hut.fi> as if it were a person. How to become a subscriber to the mailing list You can join the mailing list by sending a message to <gpc-request(a)hut.fi> (NOT <gpc(a)hut.fi> !) with your request to be added to the list. Maintenance is done by hand, so some delay is possible. How to unsubscribe from the mailing list To leave the mailing list, send a message to <gpc-request(a)hut.fi>. Hope this helps, 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 [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

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