Gpc

gpc@gnu.de

5400 discussions

Start a nNew thread

Ping!
by Fredrik Ismyren 16 Dec '02

16 Dec '02

Ping ping .. don't answer on this one.

1 0

Re: Crt0.o
by da Silva, Joe 16 Dec '02

16 Dec '02

You might like to look at my instructions for installing GPC for DOS : http://jds-freeware.hypermart.net/pascal/how2gpc.dos.txt Installing for XP should be similar, I expect. Note that the above document predates the availability of GPC to match GCC 3.X.X, but is otherwise fairly up-to-date. Joe. > -----Original Message----- > From: b b [SMTP:babakjohn2002@yahoo.com] > Sent: Sunday, December 15, 2002 9:36 AM > To: gpc(a)gnu.de > Subject: Crt0.o > > Hi guys, > > … [View More]

1 0

The preprocessor
by Frank Heckenbach 15 Dec '02

15 Dec '02

Hi, GPC currently uses a stand-alone preprocessor (gpcpp) that is derived from the C preprocessor and shares many of its features. I plan to integrate it into the compiler which would follow gcc's example (not so important, though), maybe make it a little faster (not very much, I guess, since preprocessing in general doesn't take very long), solve some problems (e.g., the `--needed-option' ugliness, mostly on MIPS) and allow for further improvements. In the same process, I'd like to change … [View More]some of the more obscure aspects, thereby hopefully making the code much simpler and even more powerful. This will not affect the BPish features of the preprocessor (`{$ifdef}', `{$ifopt}' and `{$i ...}' (include)), and the Pascal standards don't have a preprocessor, anyway, so I think there are no compatibility concerns (except for backward-compatibility to existing GPC versions). I think most the features discussed below are known to few people at all and not used much. If you want to know about the dirty details of the C preprocessor, please read the info files `cpp' and `cppinternals'. Note that the C preprocessor does a lot of micro-optimizations. I think in Pascal we can get away without them since the preprocessor (in particular macros and complicated includes) are *much* less often used here than in C. (And again, I think preprocessing is quite fast compared to compilation that I doubt how much effect these optimizations have at all.) The C preprocessor takes some effort to prevent recursive macro calls, so, e.g., in `#define foo foo(x)', the macro foo will not call itself. This might be useful sometimes (e.g., when overriding a previously defined thing), but at the same time it limits the expressiveness of macros. (In the above example recursion would be pointless since it would be inifinite, but using parameters etc., useful cases can be constructed.) So I suggest the following: Allow recursive macro calls in general, but provide a way to suppress it explicitly, e.g. by prefixing the name with `\' (similar to how shells can prevent alias expansion). This could also work outside of macros: {$define foo bar} foo { yields `bar' } \foo { yields `foo' } \bar { yields `bar' } The latter should give a warning (or an error?). This leaves it standard-compliant. Since the stnandard doesn't have macros, each occurrence of `\' would be of the latter kind and therefore wrong (according to the standard which doesn't have `\' at all). Another obvious improvement would be to allow compiler directives within macros which is not possible in C. E.g., `{$define foo {$define bar baz}}' (with `--nested-comments') or `{$define foo (*$define bar baz*)}' (with `--mixed-comments') would define a macro that defines another macro when used. So, e.g., the following macro could compute a factorial (of a constant) at compile time: {$define FACTORIAL(N) {$if N < 0} {$error Negative argument of FACTORIAL} {$elif N <= 1} 1 {$else} (N * FACTORIAL (N - 1)) {$endif} } Or an automatic counter (similar to enum types -- those should be preferred when possible, of course, but in some situations it's not so easy): {$define DEF_REC(X, S, N) {$if N <= 0} {$define X S} {$else} DEF_REC (X, S + 1, N - 1) {$endif} } {$define COUNTER 0} {$define DEFCOUNTED(X) {$redefine \COUNTER COUNTER + 1} DEF_REC(X, 0, COUNTER) } DEFCOUNTED (a) { => 1 } DEFCOUNTED (b) { => 2 } DEFCOUNTED (c) { => 3 } Two other difficult areas in C (especially because they have different syntax in traditional (K&R) and ANSI C) are token concatenation and stringification. K&R: foo/**/bar "foo" This is clearly not suitable for Pascal since in Pascal a comment is clearly equivalent to whitespace, and for the second case (if `foo' is a macro argument, it would yield a string containing the contents of foo, not the 3 letters `f', `o', `o'), in Pascal, strings are clearly literal (whether delimited by "" in C, or '' in Pascal is a side-issue here). ANSI: foo##bar #foo These forms look quite artifical to me (and the latter one is also close, though maybe not directly conflicting, to the BP-style char constant syntax). I think it would be better (also easier to handle) to have some built-in "magic macros" with these effects (which is what in C is typically defined in a header to overcome the K&R vs. ANSI differences). The macros could be given sufficiently long names (e.g., `MACRO_CONCAT' and `MACRO_STRINGIFY') to avoid most conflicts or, if deemed necessary, be activated only within macro bodies (outside of them they're not very interesting, anyway). Since in standard and BP modes macros are disabled at all, they have no effect there, either. Similarly, one could have, e.g., `MACRO_EVAL' within a macro definition to substitute {$define FOO 1} {$define BAR FOO} {$define BAZ MACRO_EVAL(FOO)} {$redefine FOO 2} BAR { => 2 } BAZ { => 1 } This would, e.g., simplify the automatic counter from above: {$define COUNTER 0} {$define DEFCOUNTED(X) {$redefine \COUNTER COUNTER + 1} {$define X MACRO_EVAL(COUNTER)} } Again, I think this behaviour will actuall be simpler to implement than the C compatible behaviour (and much simpler than the current implementation which is overly complex for questionable optimizations (and consists of rather old code) ... Then, I don't like the `{$include <...>}' syntax (mostly because `<' and `>' have very unusual meanings there). In C, there might be a point in distinguishing between system and application headers (though I haven't seem many cases very it was really important, even in C), whereas in Pascal you don't have system headers (and typically few, if any) application headers. So one include mechanism should be enough, namely `{$include STRING}' (where STRING can be any regular string constant). (And, for compatibility's sake, the BP form `{$I foo}' which appends `.pas' automatically if necessary.) Going a step further, I'm also thinking about dropping the C syntax for compiler directives (`#foo'), in favour of the (also already existing) BP-compatible syntax (`{$foo}'). I suppose there will be some objections, but I thought I'd just ask, anyway ... The special meaning of `\'-newline also seems to be needed for `#' directives (since `{$}' directives can be multi-line naturally), so this could also be dropped then. And, finally, perhaps also dropping C operators in conditional expressions (`{$if foo && bar}' -> `{$if foo and bar}') ... 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 [View Less]

2 4

a compiler crash
by Emil Jerabek 15 Dec '02

15 Dec '02

Hi, the following code program Foo; type Bar (U: Cardinal) = array [-1 .. U] of Char; function Baz (F: Bar): Char; begin Baz := F[-1] end; begin end. crashes the compiler: [~/pascal]% gpc -v Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.1.1/specs Configured with: ../gcc-3.1.1/configure --enable-languages=pascal Thread model: single gpc version 20021128, based on gcc-3.1.1 [~/pascal]% gpc crash.pas ../../gcc-3.1.1/gcc/p/gpc-typeck.c:1613:build_array_ref: failed … [View More]

2 2

A little benchmark
by Waldek Hebisch 15 Dec '02

15 Dec '02

Recently Frank wrote that subranges are stored as integer to get better performance. So I decided to run a little silly benchmark to verify my suspitions. I used variations of the following program: program p1; type foo = record a : 0..127; b : -2000..2000; end; var t : array [1..1000000] of foo; i, j, s, sum : integer; begin {writeln(Sizeof(foo));} for i:=1 to 1000000 do begin t[i].a := 20; t[i].b := 1000; end; sum := 0; for j:=1 to 100 do begin s := … [View More]0; for i:=1 to 1000000 do begin s := s + t[i].b; end; sum := sum + s div 13678; end; writeln(sum) end . I decided to compare gpc (latest alpha with gcc-3.2.1, options -O3), p2c (with gcc-3.2.1, options -O3) and fpc-1.0.6 (options -Sd -O3 -Op3). All timings are real time on otherwise idle Duron-650. 'x' in fpc column means that fpc rejected the program. gpc p2c fpc p1 3.116s 1.802s 2.550s p2 2.178s 1.802s x p3 2.953s 2.073s 2.888s p4 2.959s 2.072s x p5 3.116s 2.852s 3.365s p11 1.239s 0.467s 1.652s p12 1.394s 0.467s x p13 2.165s 0.930s 2.397s p14 2.165s 0.930s x p15 1.239s 0.897s 1.720s p21 0.469s 0.467s 1.084s p22 0.623s 0.467s x p23 1.703s 1.007s 1.932s p24 1.702s 1.007s x p25 0.470s 0.916s 1.026s p1 is the program above, p2 has packed subranges as components of the record, p3 uses packed record, p4 uses packed record with packed subranges, in p5 the record has integer components. The series p11 to p15 uses array of 1000 elements so it entirely fits into the level 1 cache. Series p21 to p25 has inner for loop replaced by equivalent repeat until loop (otherwise identical to p11 .. p15) Now, some concusions: 1) When working set does not fit into cache smaller records give significantly better speed, 2) Other compilers give fastest code just when using subranges. 3) When working in the cache aligned subword acces seem to be as fast as fullword acces, while unaligned acces or bitfild acces (used by p2c for packed records) are slower. 4) gcc backend is doing something weird to the loops: C for loops gives good (IMHO not optimal) code, but it fails to optimize Pascal for loop (that way I timed variant with repeat until loop). You may say that this is only a single benchmark on a single machine. But I think that many programs spent a lot of time in similar loops, so it is representative. I admit that I wrote the benchmark to show my point, but I based it on properties shared (IMHO) but most modern machines (especially cheaper ones): main memory much slower then the CPU, slow unaligned acces, fast subword acces. Also, it does not measure performance of using subranges as indices and similar -- I belive that reading from memory is crucial as stores are much less frequent then loads and the compiler can use integer in computations anyway, just loads and stores are done differntly. Coming to gpc: it is probably too late to change the method to store subranges, but I think it is fair to say that the decision was made in the past and we are stuck with it rather then claim that it gives faster code. Also, the loop behavior is rather embarassing (well, I can guess why it works that way, but fixing it may be harder). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl [View Less]

2 1

New alpha
by Frank Heckenbach 14 Dec '02

14 Dec '02

Hi, I've uploaded a new alpha version. Most importantly, thanks to Waldek stabs debugging should now work (at least under Linux, haven't tested on other platforms yet). Also, coff debugging (DJGPP) might work ... Furthermore, the license of the documentation has changed to the GNU Free Documentation License (the counterpart of the GPL for manuals etc.). Thanks to Eike for doing the formalities. Besides, some changes according to recent bug reports and more cleanups have been made. The two … [View More]

6 15

Re: Bug? Identifier Integer sometimes fails
by david＠tcs01.demon.co.uk 13 Dec '02

13 Dec '02

In message <3DF8B460.10793.179D5AF@localhost> "Prof. A Olowofoyeku (The African Chief)" writes: > > This is fine. But please let us retain the ability to specify sizes > for data types. People often have to read files created by other > applications and sometimes require data structures of specific sizes, > and it should be possible to create a data structure of that size > without too many contortions. Can I add a 'me too' to that comment. The ability to read … [View More]

2 1

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 … [View More]

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 --… [View More]

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 … [View More]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! [View Less]

4 7

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