Gpc April 1997

gpc@gnu.de

24 participants
111 discussions

Re: Standard Compatibility [was: Re: New Alpha]
by Frank Heckenbach 07 Apr '97

07 Apr '97

Nils Bokermann wrote: > I don't like the idea of a local (user) configuration file as GPC.CFG or > .gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler > which is a borland like compiler for standard, might there be a compile-time > switch? Let's consider something like > ./configure --try-to-be-a-borland-compiler or > ./configure --use-standard-pascal. I think, hardcoded options would be about the worst solution. Besides the reasons given by Jan-Jaap and Peter, consider compilers on multi-user systems. If e.g. in a school or university, different teachers used different language standards, their classes would need different compilers... :-( Personally, I think options that describe the source (e.g. language dialect, extended syntax, field widths) should be put into the source. Other people don't seem to like this idea, but anyway, there will be enough ways by using config files, aliases, scripts and/or environment variables, that should all be possible (more or less easy) on any system. > > - Naming the program gpc, spc, epc and bpc seems like a sensible way for > > Un*x, but on systems that don't support either hard or symbolic links > > (aka DOS), it would mean 4 separate binaries - probably not a good solution > > there (although those DOS users who want to do only Borland style could > > rename gpc.exe to bpc.exe). So this could be one, but not the only, way to > > choose the defaults. > > Isn't there a way by making *.BAT-Files in dos? That is something like a > shell-script, isn't it? Yes, that's right. Also, modern DOSes have something like aliases. Though they're not the same as symlinks, they can be used for this purpose. > Ok, I can imagine that Makefiles are a bit complicatet... And (hopefully) unnecessary for Pascal... :-) > As there a _too_ many programs which put there .foobar-File to my > home-directory I don't like the *.CFG or .foobarrc idea. If gpc whould be as > kind as it should, there should be a system-wide rc-file (That's ok to me) and > there _might_ be a users rc-file. But the user has to make it _manually_. I agree. I also don't like yet another config file in the home directory. > But GPC should _not_ rely on the system-wide rc-file, so that I (for my system) > can remove it an GPC does run. > > The system-wide file should IMHO also be installed manually (By the Sysadmin of > course). Also agreed, since on big sites, a global config file wouldn't make much sense anyway, since different users would want different preferences. -- 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

Binary files.
by Berend De Schouwer 07 Apr '97

07 Apr '97

Hi Sorry if this was handled in a FAQ, but I haven't found it. I'd like to read bytes from a file, so I looked at some of the examples. I found an assign(file of byte...). Cool. It doesn't seem to work to great tho... How big does it read? Are you sure its just 1 byte? How big is a byte anyway? Looking at the examples and the info file, I get confused. Is an integer 16bit or 32bit? What happens with type byte=0..255; I tried defining them like in the info file (using __short__, etc.) but it doesn't compile. When I use the example's stuff it does compile. Hmmm... I am converting some stuff from borland, and some from fpk, so I would like to know how to get 8, 16 and 32 bit signed and unsinged integers. I don't mind doing a search/replace on the source, but I do need to know how big each thing is. AND how to apply them properly to files ;) Cheers Berend.

1 0

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

← Newer
1
...
5
6
7
8
9
10
11
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 April 1997