Gpc December 2002

gpc@gnu.de

35 participants
51 discussions

Re: Assignment from incompatible pointer
by Fredrik Ismyren 17 Dec '02

17 Dec '02

On Tue, 17 Dec 2002, Frank Heckenbach wrote: > No, they're two record types that look the same, > but are distinct types in Pascal. Just export the > types in the interface and don't declare them > again in the implementation. I see! Yes now it works. Thanks alot for this information. > PS: When you post sample code, please send > complete code. My compiler doesn't like `...', so > it's hard to test things. Yes I will Frank. Thanks again. // Fredrik - Sweden ____________________________________ Gratis epost med TJOHOOMAIL http://www.tjohoo.se

1 0

Assignment from incompatible pointer type
by Fredrik Ismyren 16 Dec '02

16 Dec '02

I'm using GPC 2.8.1 and I've got problems with the following manuever. Down in my procedure "DestroyPQueue" I try to assign the address from the left pointer to the local pointer pseg. I get: "Assignment from incompatible pointer type". They are created from the same type so I don't understand why this doesn't work. <---> module PriQueue interface; export PriQueue = ( PQueue, ... ); .. type ElementType = Integer; SegPek = ^TreeSeg; TreeSeg = record data : ElementType; left : SegPek; right : SegPek; end; PQueue = record root : SegPek; numberOfElements : Integer; end; .. procedure DestroyPQueue(var pq : PQueue); .. end. module PriQueue implementation; type ElementType = Integer; SegPek = ^TreeSeg; TreeSeg = record data : ElementType; left : SegPek; right : SegPek; end; .. procedure DestroyPQueue; var pseg : SegPek; begin pseg := pq.root^.left; { HERE'S THE PROBLEM } .. end; .. end. <---> ____________________________________ Gratis epost med TJOHOOMAIL http://www.tjohoo.se

2 1

Posting problems
by Fredrik Ismyren 16 Dec '02

16 Dec '02

Ping2! Why don't my bigger mails show up here? I signed on today. Do I have to wait for some days or what?

1 0

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, > > I have a problem with compiling my first Pascal program. This directly > after my Installation of GNU pascal. The problem is: > > I installed the latest version of GNU Pascal compiler on my PC with > windows XP Pro. I wrote my code in Emacs at the same PC. Then I used my > DOS-prompt and went to the route of the file that contained my code and > wrote the command: > > gpc <filename>.p and enter. > D:\DOCUME~1\ADMINI~1\Desktop\...\Pascal\INLUPP~1>gpc Inlupp1.p > > > > I got first some errors in compilation. I made necessary changes in the > code and run again. At this moment it should not give any fault and a > specific *.exe file should be created. > > Instead I got this Answer from the compiler: > > D:\Djgpp\bin/ld.exe: cannot open crt0.o: No such file or directory > (ENOENT) > > That was strange. As you know the Crt0.o is the standard run-time startup > routine (crt0.o). Now, I checked under the Djgpp\bin and I could find the > ld.exe file. I checked also the crt0.o file in Djgpp and exists in lib > directory: > > D:\Documents and Settings\Administrator\Desktop\...\Pascal\Djgpp\lib > > I checked the property of crt0.o file. It was not empty and it had > attribute archive. > > My question is when does this appear and what does it depend on ? > > Is it not that "\bin/ld.exe" should be "\bin\ld.exe" or that is not the > problem what can be the reason ? > > > > Best Regards /b > > > > _____ > > Do you Yahoo!? > Yahoo! Mail Plus > <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com> - Powerful. > Affordable. Sign up now > <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com>

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

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 assertion `!(TREE_CODE (index) == INTEGER_CST && TYPE_VALUES (TREE_TYPE (array)) && !int_fits_type_p (index, TYPE_VALUES (TREE_TYPE (array))))' crash.pas: In function `Baz': crash.pas:8: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. Exactly the same thing happens also with some other variants of the schema Foo definition: Bar (U: Cardinal) = array [0 .. U] of Char; Bar (L: Integer; U: Cardinal) = array [L .. U] of Char; GPC with 2.95.2 backend crashes hs well, in a slightly different place: [~/pascal]% gpc2 -v Reading specs from /usr/local/bin/../lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20021111, based on gcc-2.95.2 19991024 (release) [~/pascal]% gpc2 crash.pas /home/emil/dist/gpc-src/gcc-2.95.2/gcc/p/gpc-typeck.c:1860:build_array_ref: failed assertion `0' crash.pas: In function `Baz': crash.pas:8: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. Hope this helps. Emil

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 := 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

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 makefiles (Make-lang.in and Makefile.in) have been merged (also for gcc-3 integration) -- I don't know if anyone cares, but perhaps those who build GPC in special ways ... 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

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 (and write) data files that are compatible with other applications is important to me. I have a lot of packed records with carefully chosen sub-range types and packing bits in them to be able to match exactly specific data files written in other Pascals, other languages, etc. -- David James mailto:david@tcs01.demon.co.uk or mailto:david@djames.org.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

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