Gpc April 1997

gpc@gnu.de

24 participants
111 discussions

New Alpha
by Peter Gerwinski 12 Apr '97

12 Apr '97

Hello folks, here is the next GPC alpha version. It implements most of the field-width options recently discussed, fixes some bugs, etc. In detail: Changes since gpc-970401: * Field widths still default to 0, i.e. no blank is output in front of Integer, Boolean, or negative Real values; one blank is output in front of positive Real values according to ISO. A new option `--field-widths=II,RR,BB' changes the default field widths to the numbers `II' for Integers, `RR' for Reals, and `BB' for Booleans. The arguments may be omitted in whole or in part. Just `--field-widths' yields `--field-widths=11,23,6' which ensures that at least one blank is output in front of positive numbers. `--no-field-widths' means `--field-widths=0,0,0'. The dialect options `--standard-pascal-level-0', `--standard-pascal', `--extended-pascal', and `--object-pascal' imply `--field-widths'. * A new command line option `--no-real-blank' switches the blank in front of positive Reals off; `--real-blank' switches it on again. This is useful together with compiler directives in the source (*$see-below *). * To specify default field widths, the strings written for "True" and "False" and similar things while compiling GPC, you can #define the symbols in gpc-defs.h and rts/rts.h, e.g. make CFLAGS="-O2 -DINT_OUT_WIDTH=8 -DFALSE_str=\"FOO\"" A more comfortable solution is being worked on. * String clipping can be switched off with `--no-clip-strings' or on with `--clip-strings'. The default is "on" unless `--borland-pascal' or `--delphi' has been specified. * The GNU compiler's global configuration file `specs' (or `specs.gpc' with DJGPP) now contains a line `*gpc1:' after which you can put your site-wide default switches, e.g. *gpc1: -fextended-pascal -ffield-widths -fno-clip-strings Note that `specs' does not want `--foo' but `-ffoo'. * All command-line `--foobar' flags now can be given as compiler directives. One example: (*$field-widths,NO-clip-strings,SetLimit=1024, AutoMake="-g -O3"*). This is case-insensitive except inside the " ... ". Language dialect switches like `extended-pascal' do not enable or disable keywords, so they do not *exactly* mean the same as if they were given in the command-line. For instance with (*$extended-pascal*), `uses' triggers a warning (but still works), whereas with `--extended-pascal' GPC does not know `uses' at all. * `For' control variables are checked now: With `--standard-pascal' etc. GPC warns about structured variables and variables not in the nearest enclosing declaration scope; with `--borland-pascal' etc. structured variables and global variables are okay, but local variables must still be declared in the nearest scope. Without a dialect switch, GPC only warns if we are `--pedantic'. * Bug fixed: A field width of zero does no longer suppress output (except for Strings where ISO requires it (which can be overridden with `--no-clip-strings' - see above)). * Bug fixed: Writing out Chars no more crashes on FreeBSD. * Bug fixed: Char operators, e.g. comparision, work now. * Bug fixed: RTL dump generation (with option `-dr'; for debugging purposed) works now. * Bug fixed: String value parameters, Conformant arrays (Standard Pascal) and open array parameters (Borland Pascal) are passed correctly now. (Now it is taken into account that their size isn't known.) * GPC now warns about usage of conformant arrays if invoked with `--standard-pascal-level-0', `--borland-pascal', or `--delphi'. * Bug fixed concerning Objects: The implicit `Self' parameter is passed correctly now when calling inherited methods. * Arrays can be initialized with not-absolutly-constant values now. * In ASM statements, tabs and newlines are now inserted automatically between different lines. It was not good that one had to write '... \n\t' in Pascal programs. (It's still allowed with (*$E+*), but you are not *required* to use it in ASM statements any more.) * Bug fixed: Input and output parameter specifications in ASM statements may consist of a single character now. * If statements and such now default to short-circuit operations. This can still be switched to complete evaluation using `--no-short-circuit', (*$B+*), or (*$no-short-circuit*). With `--standard-pascal' etc., the default becomes complete evaluation and can be switched to short circuit using `--short-circuit', (*$B-*), or (*$short-circuit*). (It is done this way because the cases where a program relies on complete evaluation of Boolean expressions are very rare; functions with side effects should not occur in such situations anyway because you cannot rely on the order of evaluation. OTOH, there are *many* programs which rely on short circuit evaluation.) * Bugs fixed: GPC now better distinguishes between Integer numbers and Boolean values and also knows about the difference between the pointer value `Nil' and the number `0'. * Bug fixed: Set comparision with `<' and '>' works now. * Arrays of Chars now can be initialized by String constants even without `packed'. With `--standard-pascal' etc., a warning is given. * Bug fixed: Types declared equivalent to `CString' now work like `CString'. In particular, String constants can be given to parameters of such a type. * Like in Borland Pascal, `PChar' is now implemented as an alternative to `CString' as a built-in identifier which can be redefined without warning (just like `CString'). This is switched off with `--standard-pascal' etc. * With (*$X+*) or when GPC is invoked with `--extended-syntax', `CString' (or `PChar') variables can be initialized with String constants, and they can be indexed like other Strings, but starting with 0 instead of 1. This is not affected by the dialect options since ISO Pascal does not define `CString' or `PChar', and Borland Pascal also requires (*$X+*) to allow the above. (And it makes not much sense to combine (*$X+*) with dialect options other than `--borland-pascal' anyway.) Extensions of this type must be explicitly switched on because they conflict with Pascal's type-checking rules, so don't expect the above to become GPC's default behaviour. (This is a different situation than the definition of the data type `CString' itself because `CString' is just a redefinable built-in name for "^Char", but it is a type conflict to index a pointer variable.) * When I wanted to implement an option to enable pointer arithmetics I encountered that it already worked by default due to a bug. :-) Now pointer arithmetics works only with (*$X+*) or `--extended-syntax'. (Like `CString' indexing, this is too dangerous to stay GPC's default behaviour, but it must be explicitly enabled.) * GPC now checks whether the `for' variable is of ordinal type. With (*$X+*) or `--extended-syntax', pointer variables are okay, too. * Set member iteration ("for i in [ 2, 3, 5, 7 ] do ...") is now implemented into GPC. The source - a diff against gpc-970401 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. I thank everybody who reported these bugs, in particular Phil Nelson, Frank Heckenbach, Stephen Lindholm, Abimbola A. Olowofoyeku, and Jan-Jaap van der Heijden. (Again I hope that I didn't forget your contribution.) Jan-Jaap furthermore contributed very useful ideas - besides his own work on GPC. I also thank everybody who took part in the discussion about GPC's default behaviour and helped to clarify what the standard specifications say and what they don't, what is reasonable behaviour of a compiler and what isn't. (* It seems that GPC will get more options than any other existing Pascal compiler ... :*) My special thank goes to Larry Carter for the donation of a licensed copy of Delphi, and to Nick Burrett who did not only report the bug about RTL dump generation, but also fixed it and sent me the patch. Ah - is somebody out there willing to document all this? I wrote several announcements of this type since gpc-2.0, and right now they are the only existing documentation for the new features in GPC. Thanks in advance for your help! 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

setting up gpc
by Alan Bailey 12 Apr '97

12 Apr '97

I've recently downloaded gpc (dos-djgpp) and tried running it. I used the sample hello world program included. I first tried doing this: gpc.exe hello.pas But it said it oculdn't open ld.exe or something "c:/djgpp/bin\ld.exe: cannot open -lgpc: No such file or directory (ENOENT)" Note the slashes ^ I'm assuming this is the executable you use, but I tried gpc1.exe: gpc1.exe hello.pas This worked fine, and the output was hello.s, an assembly file. that's the current situation, I have a djgpp dir and a gpc dir on my computer, both with the included binaries and documentations. So what's wrong, am I missing a parameter running gpc.exe, or do I need an assembler after gpc1.exe? Mail privately or to the list... -- Compliments of: _-_-_-_-_-_-_-_ Alan Bailey mailto:bailala@mw.sisna.com IRC: Abalone Web: http://www.mw.sisna.com/users/bailala/

2 1

Re: [BUG] GPC - a char killer?
by Peter Gerwinski 11 Apr '97

11 Apr '97

According to Sven Engelhardt: The compiled program "eats up" the first char if standard input is not a terminal. This is because when `Input' is `reset' at startup, the first char is read in to `Input's file buffer variable. If you would `read' the char rather than `getchar'ring it, you would get it. To work around, use the `eoln' function to check whether a char has been read in like this: > program test1(input,output); > > function getchar:integer; C; > > var k:integer; > > begin if not eoln ( Input ) then k:= ord ( Input^ ) else > k:=getchar; > while (k<>-1) do > begin > writeln(k); > k:=getchar; > end; > end. To fix this bug (?) it would be necessary to rewrite parts of the RTS, but I am not sure whether we should do that because I can imagine that GPC's behaviour is as the ISO Standard requires. (But I am not in the position to judge that. ;-) 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

Compiler switches (was: Configuration files)
by Peter Gerwinski 09 Apr '97

09 Apr '97

According to Frank Heckenbach: > Peter Gerwinski wrote: > > I am already doing this (in a portable way) for the AutoMake mechanism. > > There is an "internal" option `--amtmpfile=cc123456.gpc' which passes > > the name of a file containing the names of the `.o' files to be linked > > to the `gpc' driver program. > Sounds good! Is this a way to use compiler options (like -o, -l, .o files, > .c files) in the source? Yes, in principle. `.o' files *are* already passed that way. There might be some technical problems when generalizing this, but we will see ... 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: Configuration files (was: Standard compatibility)
by Frank Heckenbach 09 Apr '97

09 Apr '97

Peter Gerwinski wrote: > I am already doing this (in a portable way) for the AutoMake mechanism. > There is an "internal" option `--amtmpfile=cc123456.gpc' which passes > the name of a file containing the names of the `.o' files to be linked > to the `gpc' driver program. Sounds good! Is this a way to use compiler options (like -o, -l, .o files, .c files) in the source? > > If every option (except those like $R,$I,$S,$Q(?) that would be the same like > > BP's) would be at least 2 letters, this would avoid name clashes. > > Sounds reasonable. However I like the (*$W-*) ... (*$W+*) option as > a quick way to disable/enable warnings locally. (Sometimes one may > want to ignore a certain warning.) To have only (*$no-warnings*) > ... (*$warnings*) would be a little drawback ... No objections from me. BP doesn't have a $W option (except Windoze stack frame for Windoze platform, but I don't care very much about that), and $W for warnings sounds general enough to justify a one-letter switch. > > I'm not sure what this has got to do with it. Anyway, I think the biggest > > problem would be to collect all the options into one record (which might be > > quite hard if they're scattered among many modules now). Then, pushing and > > popping would reduce to storing/restoring this record to/from a (LIFO) stack. > > Please look at `toplev.c', `gpc-options.h', and `gpc-decl.c' to get an > overview. Seems like a lot of work... :-( -- 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

BP compatibility
by The African Chief 08 Apr '97

08 Apr '97

Hi all! Here are some more suggestions on Borland compatibility. The following code does not compile in GPC; Program Blah; type pChar = CString; { or ^Char} Procedure DoThis(aThis : pChar); Begin {blah, blah}; End; Begin DoThis ('This is the day!'); End. The compiler does not accept the parameter as being valid (you have to declare a pChar variable and all). This code would compile under Borland. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

GPC fails set comprare
by Jan-Jaap van der Heijden 08 Apr '97

08 Apr '97

Hello, Consider this little program: -------------------------------------------------------------- program main(input,output); var o, z: set of 1..15; begin o := [1]; z := []; if o < z then writeln('o < z'); if o <= z then writeln('o <= z'); if o = z then writeln('o = z'); if o <> z then writeln('o <> z'); if o >= z then writeln('o >= z'); if o > z then writeln('o > z'); if z < o then writeln('z < o'); if z <= o then writeln('z <= o'); if z = o then writeln('z = o'); if z <> o then writeln('z <> o'); if z >= o then writeln('z >= o'); if z > o then writeln('z > o'); if o < o then writeln('o < o'); if o <= o then writeln('o <= o'); if o = o then writeln('o = o'); if o <> o then writeln('o <> o'); if o >= o then writeln('o >= o'); if o > o then writeln('o > o'); if z < z then writeln('z < z'); if z <= z then writeln('z <= z'); if z = z then writeln('z = z'); if z <> z then writeln('z <> z'); if z >= z then writeln('z >= z'); if z > z then writeln('z > z'); end. -------------------------------------------------------------- GPC fails to compile this: t19.p: In function Program_Main': t19.p:7: invalid operands to binary < t19.p:17: invalid operands to binary > t19.p:19: invalid operands to binary < t19.p:29: invalid operands to binary > t19.p:31: invalid operands to binary < t19.p:41: invalid operands to binary > t19.p:43: invalid operands to binary < t19.p:53: invalid operands to binary > ISO 7185 sec. 6.7.1 suggests that this should work. The correct output should be: o <> z o >= z o > z z < o z <= o z <> o o <= o o = o o >= o z <= z z = z z >= z Greetings, JanJaap --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum

1 0

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

07 Apr '97

According to Frank Heckenbach: > > So, if it get this right, one needs a way to pass data (in this case, strings) > back from a child process to the parent process. I don't know very much about > the available means of process communication, but isn't there any (portable) > way to do so? Perhaps a temp file, or can it be done easier? I am already doing this (in a portable way) for the AutoMake mechanism. There is an "internal" option `--amtmpfile=cc123456.gpc' which passes the name of a file containing the names of the `.o' files to be linked to the `gpc' driver program. > If every option (except those like $R,$I,$S,$Q(?) that would be the same like > BP's) would be at least 2 letters, this would avoid name clashes. Sounds reasonable. However I like the (*$W-*) ... (*$W+*) option as a quick way to disable/enable warnings locally. (Sometimes one may want to ignore a certain warning.) To have only (*$no-warnings*) ... (*$warnings*) would be a little drawback ... At least I will make GPC warn about incompatible compiler switches when invoked with `--borland-pascal'. (It already does with `--pedantic.) > BTW: The first input file name sounds a bit strange to me. Rather, it should > be the main program, I think. But it's probably not so easy to implement. That's the reason. This is handled by the `gcc' driver program which does not read the source. But we might be able to solve this with the `--amtmpfile' mechanism ... > I don't know how field widths are handled, but I would suppose (and I think > that's how BP does it) that the compiler would pass the given field width, > or if omitted, the (current) default field width to the write routine. They are handled differently in gpc-970401, but I just wanted to change GPC to use the method above. > [...] > > Anyway, this was only an example, compiler options in the source and local > options would be a plus anyway. I agree. I will look at this. (* I should set up a list of things I wanted to look at. A *long* list. ;*) > I'm not sure what this has got to do with it. Anyway, I think the biggest > problem would be to collect all the options into one record (which might be > quite hard if they're scattered among many modules now). Then, pushing and > popping would reduce to storing/restoring this record to/from a (LIFO) stack. Please look at `toplev.c', `gpc-options.h', and `gpc-decl.c' to get an overview. 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: Binary files.
by Peter Gerwinski 07 Apr '97

07 Apr '97

According to Berend De Schouwer: > > 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? Yes. See below for an example program which I just tested to work - with the alpha version gpc-970401. > How big is a byte anyway? 8 bits. :-) > Looking at the examples and the info file, > I get confused. Is an integer 16bit or 32bit? 32. > What happens with > type byte=0..255; It will take 4 bytes. :-( Sorry - this is a known bug. > 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. See below for something which 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. The alpha version gpc-970401 has the following built-in types: Byte unsigned 8 bits ByteInt signed 8 bits ShortWord unsigned 16 bits ShortInt signed 16 bits Word unsigned 32 bits Integer signed 32 bits LongWord unsigned 64 bits LongInt signed 64 bits Single = ShortReal 32 Bits Double = Real 64 Bits Extended = LongReal 80 Bits on the PC, maybe 128 elsewhere However there is one known problem with these types: You cannot `write' or `writeln' them to text file. (Binary files are okay.) If you writeln ( a [ 7 ] ); with `a' being an array of bytes, you might get some very strange result because `writeln' outputs the integer consisting of `a [ 7 ]' and the following three bytes. To work around, cast these types to their base type: writeln ( Integer ( a [ 7 ] ) ); (The same holds for an `Extended' which you must cast to `Real' in order to `writeln' it.) > AND how to apply them properly to files ;) I hope the example below helps you. If you want to upgrade to gpc-970401, the URL is ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ 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] 8< ---- test.pas ------------------------------------------------------------- {OK} (* This program will read its own source and output 'OK'. *) Program Test; Type ByteInt = __byte__ Integer; Byte = __unsigned__ ByteInt; ByteFile = file of Byte; Var F: ByteFile; C: Char; Procedure Assign ( Var T: ByteFile; Name: String ); Var B: BindingType; begin (* Assign *) unbind ( T ); B:= binding ( T ); B.Name:= Name; bind ( T, B ); B:= binding ( T ); end (* Assign *); begin Assign ( F, 'test.pas' ); reset ( F ); read ( F, C ); read ( F, C ); write ( C ); read ( F, C ); writeln ( C ); close ( F ); end.

1 0

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

07 Apr '97

Peter Gerwinski wrote: > > 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. So, if it get this right, one needs a way to pass data (in this case, strings) back from a child process to the parent process. I don't know very much about the available means of process communication, but isn't there any (portable) way to do so? Perhaps a temp file, or can it be done easier? > > 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. I didn't expect them to be compatible. Of course, that wouldn't make much sense. But it might be better to avoid name clashes, so that ported BP programs woudln't accidentally acces gpc options (e.g. a BP program foo that declares an overlay {$O bar} should not be compiled to bar with gpc (if {$O ...} would be implemented). > 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 *). If every option (except those like $R,$I,$S,$Q(?) that would be the same like BP's) would be at least 2 letters, this would avoid name clashes. > Here I agree. BTW, EMX derives the name of the output file name from > that of the first input file name. Fine for EMX users... BTW: The first input file name sounds a bit strange to me. Rather, it should be the main program, I think. But it's probably not so easy to implement. > > 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 ... I don't know how field widths are handled, but I would suppose (and I think that's how BP does it) that the compiler would pass the given field width, or if omitted, the (current) default field width to the write routine. >From this, I would think that default fields widths don't need to be runtime variables, only internal variables of the compiler. > (* Why don't you want to compile your whole program with -O2? Because it's quite slow! Sorry to say that, but gpc is not so fast that I can neglect this issue completely, being a poor 486 user... > I would not release an unoptimized program as "production version". No, but I'm writing programs mostly for my own use, that I have to compile often (and therefore fast), and that have to run fast (but this always concerns only quite small portions os the code). In 5-10 years, this will not be an issue any more, but for now... Anyway, this was only an example, compiler options in the source and local options would be a plus anyway. > > This example also shows that it can be desirable to "push" and "pop" options. > > It would be better to write e.g. (tentative syntax): > > [...] > 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> ... I'm not sure what this has got to do with it. Anyway, I think the biggest problem would be to collect all the options into one record (which might be quite hard if they're scattered among many modules now). Then, pushing and popping would reduce to storing/restoring this record to/from a (LIFO) stack. > > 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 ... (?) Oh, I see, you mean the stubs. I thought you were talking about "real" symlinks, like e.g. symlinks with Linux' UMSDOS file system that don't really fit to DOS. -- 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

← Newer
1
...
4
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