Gpc August 2007

gpc@gnu.de

7 participants
13 discussions

Inefficiency of `mod'
by Emil Jerabek 25 Oct '10

25 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

New (gpc-20060325)
by Waldek Hebisch 08 Dec '09

08 Dec '09

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 Main change is preliminary gcc-4.0.x support. The other changes are rather small. Note that for "production use" 3.4.x and 3.3.x backend are prefered. Also, using 2.8.1, 2.95.3 and 3.2.3 backend should work, but is depreciated. For more detail see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20060325 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20060325 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

7 44

compiling static library + gpc runtime without _statvfs on Mac OS X for Intel
by Glenn Howes 20 Apr '08

20 Apr '08

Hello, After months of being distracted by another portion of my application, I'm back to creating a universal binary version of the Pascal based library we are linking into our C++ based application. The problem is the application will not launch under PPC on Mac OS X 10.3 (Panther). The console registers an undefined symbol: _statvfs expected to be defined in /usr/lib/libSystem.B.dylib After some research, I found this call is being used by the StatFS routine implemented in rts.c (line 1510) /** Get information about a file system. */ GLOBAL (Boolean _p_StatFS (char *Path UNUSED, StatFSBuffer *Buf)) { int Result; #ifdef HAVE_STATVFS struct statvfs b; errno = 0; Result = statvfs (Path, &b); Buf->BlockSize = (long long int) b.f_frsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_favail; #elif defined (HAVE_STATFS) struct statfs b; errno = 0; Result = statfs (Path, &b); Buf->BlockSize = (long long int) b.f_bsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_ffree; #else Result = -1; errno = ENOSYS; #endif if (Result == 0) return True; Buf->BlockSize = 0; Buf->BlocksTotal = 0; Buf->BlocksFree = 0; Buf->FilesTotal = 0; Buf->FilesFree = 0; return False; } It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files, which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library). Also, if I build my environment/library on a PowerPC using the build-on- powerPC-10.3.command, I end up with a different set of link problems involving the long double version of pow(). Besides which, I'd prefer to do my development on OS X for Intel going forward. I have tried hand editing the above routine and rebuilding my Pascal development environment, and pulling the statvfs.h file from my OS X SDK, and yet when my application links, it still has an unresolved reference to _statvfs. I'm not a build engineer, as my previous missives to this mailing list make clear, and I'm at a loss as to how to proceed. Just to be clear, I link in two static libraries: a universal version of the libgpc.a for the runtime, and a universal version of the library I've created. Neither of them contain the symbol _statvfs (at least I can't find that text in them). I link that with my application. The application now references _statvfs (I can now see the text in it's executable). I can't launch on 10.3. I comment out the calls to the Pascal library and recompile+relink, and the application no longer has the symbol and I can launch under 10.3. So something in either of the gpc associated libraries must be calling something which calls statvfs, making the linker (ld) mark statvfs as an unresolved symbol to be loaded in at runtime. At least that is my impression. So, I'd appreciate some suggestions. --glenn

4 8

Memory layout of array of variable size.
by Bastiaan Veelo 24 Dec '07

24 Dec '07

Hi, In an attempt to hook up to GTK+, I am trying to pass a Pascal array of varible size to C. Static arrays are fine, but these arrays carry some additional information like capacity and size, and I gues they could be received as a struct on the C-side. However, I cannot figure out the structure that the struc should have. I do like this in Pascal: procedure YGTK_init(var argc : CInteger; argv : array of CString); external name 'YGTK_init'; procedure Y_init; var argc : CInteger; argv : array[0..ParamCount] of CString; Counter : integer; begin argc := ParamCount+1; for Counter := 0 to ParamCount do begin argv[Counter] := NewCString(ParamStr(Counter)); end; YGTK_init(argc, argv); end; And like this in C: struct t_argv { int end; void *argv; }; void YGTK_init( int *argc, struct t_argv argv ) { printf("In ygtk.c:YGTK_init.\n"); printf("argv.end: %d\n", argv2.argc); printf("argv.argv address: %p\n", argv2.argv); printf("argv.argv int: %d\n", argv2.argv); printf("argv.argv string: %s\n", argv2.argv); printf("number of arguments: %d\n", *argc); } So I figured out that the first element in the struct is an integer containing the length-1 of the array, but what it should look like for the rest I do not know yet. Do you have an idea? Thanks, Bastiaan.

5 9

indirect jmp redux (Mac OS on Intel)
by Frederick Karl Kepner DuPuy 04 Sep '07

04 Sep '07

Hi. Regarding gpc for Mac OS X on Intel, I found a thread in the archives (see below) from October 2006 concerning an error message a user (Nestor Aguilera) got in compiling even the simplest programs. Unless I'm misreading the thread, no final conclusion was reached. Is anything further known now? Here's the thread: http://www.gnu-pascal.de/crystal/gpc/en/mail13854.html And the gist of the error messages: indirect jmp without `*' I'm having the same issue he had: programs which used to compile and execute happily with the gpc for PPC compiler are less happy with the gpc for Intel compiler--- they're still compiling, but issuing this error message repeatedly as they do so. I believe the output executes OK; but you can see why this is unsettling. So: is this a problem, or just an annoyance to be lived with? And is it happening to everybody trying to use gpc for Mac on Intel? (If so I'm curious as to why it hasn't been discussed since October.) (Please pardon my near-complete ignorance, by the way.) Thanks a lot, Rick DuPuy

3 5

linux test results for gpc based on GCC-4.1.2
by Matthias Klose 30 Aug '07

30 Aug '07

please find attach test results for gpc based on GCC-4.1.2 built on Ubuntu gutsy development. Listing for each architecture the results for the build based on 4.1.2 and then for the build based on 3.4.6. The packages (gpc-2.1-3.4 and gpc-4.1) are available in the Ubuntu archives. Looks like there are some regressions, or I'm missing some patches. Matthias ----- i486-linux-gnu ----------------------------------------------- Running target any FAIL: agettext2test.pas FAIL: asmtest.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: fjf998r.pas FAIL: nicola4c.pas === gpc Summary === # of tests 5070 # of expected passes 5051 # of unexpected failures 18 # of unsupported tests 1 3.4.6: Running target any FAIL: agettext2test.pas FAIL: fjf998r.pas === gpc Summary === # of tests 5057 # of expected passes 5054 # of unexpected failures 2 # of unsupported tests 1 ----- i686-linux-gnu ----------------------------------------------- Running target any FAIL: asmtest.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: nicola4c.pas === gpc Summary === # of tests 5070 # of expected passes 5053 # of unexpected failures 16 # of unsupported tests 1 3.4.6: Running target any === gpc Summary === # of tests 5057 # of expected passes 5056 # of unsupported tests 1 ----- amd64-linux-gnu ---------------------------------------------- Running target any FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: nicola4c.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5070 # of expected passes 5043 # of unexpected failures 25 # of unsupported tests 2 3.4.6: Running target any FAIL: chief40.pas FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf327.pas FAIL: fjf526a.pas FAIL: fjf526b.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: shl.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5057 # of expected passes 5040 # of unexpected failures 15 # of unsupported tests 2 ----- powerpc-linux-gnu -------------------------------------------- Running target any FAIL: agettext2test.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf998r.pas FAIL: nicola4c.pas FAIL: prep2p.pas === gpc Summary === # of tests 5070 # of expected passes 5052 # of unexpected failures 15 # of unsupported tests 3 3.4.6: Running target any FAIL: agettext2test.pas FAIL: fjf998r.pas FAIL: prep2p.pas === gpc Summary === # of tests 5057 # of expected passes 5051 # of unexpected failures 3 # of unsupported tests 3 ----- sparc-linux-gnu ---------------------------------------------- Running target any FAIL: agettext2test.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf746.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf967e.pas FAIL: fjf998r.pas FAIL: nicola4c.pas === gpc Summary === # of tests 5070 # of expected passes 5052 # of unexpected failures 16 # of unsupported tests 2 3.4.6: Running target any FAIL: agettext2test.pas FAIL: fjf980a.pas FAIL: fjf980b.pas FAIL: fjf998r.pas === gpc Summary === # of tests 5057 # of expected passes 5050 # of unexpected failures 4 # of unsupported tests 3 ----- ia64-linux-gnu ----------------------------------------------- Running target any FAIL: chief35b.pas FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: nicola4c.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5070 # of expected passes 5042 # of unexpected failures 26 # of unsupported tests 2 3.4.6: Running target any FAIL: chief40.pas FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf327.pas FAIL: fjf526a.pas FAIL: fjf526b.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: shl.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5057 # of expected passes 5040 # of unexpected failures 15 # of unsupported tests 2

1 0

Re: AKFAvatar
by M. Uhle sen. 18 Aug '07

18 Aug '07

This seems to me to be another version of a very academic discussion about our "new" students, who all know how to "click"......Sorry, they are as the are. Trying to teach "programming" to undergraduate students for years now, I do see the problem from a different point of view. It is NOT a question of IDE's, debugging-Systems, sophisticated tools, not even languages. To me it seems to be a problem of missing applications. What I mean? Student: To program my first "hallo world" is simply boaring, I am not interested to print a simple sin-table.. and the like. What on earth all this programming is to be used for? Some years ago Iswitched to: A simple editor, a plain compiler, and a textbased console and AN INTERESTING JOB to do. Say: simulate an atomobile on a 10 km long road with traffic lights. Answer the question: does it make sense to ignore speed limits or does it not? So jump, dive, and swim.. And the advice to our beginners is: Start with a small program saying 'Program Speed Simulation Start' 'Program Speed Simulation Stop' If that works, you know: I can use the editor, it worked I can use the compiler, it worked I wrote my first program, it worked. I save it as version 0, copy ist to version 1, and I will expand it now to version n+1. Output will be written to screen and (later) redirected to a file from where it can be plotted by eg. xmgrace or so. We all in the teaching business should think about interesting 'real life' examples, it seems there are just a few! The sophisticated tools should NOT be used. To be honest: even the above example is - in my opinion - not real enough! What I mean? try to use "Kdevelop" (or any of the like) with beginners. Even the "hallo world" project creates "thousands" of files in the associated directories, no beginner will understand that not to talk about keeping track. I dropped it completely (for beginners, not for later real work). If I am allowed to add one thing: my students are still using GPC 2004.12.18 Why? There is no newer binary available on "www.gnu-pascal.de", and beginners are NOT able to compile GPC from scratch. And: most Pascal users are not experts for c! Mathias Uhle -- Univ.-Prof. Dr.-Ing. Mathias Uhle, Messtechnik, Universitaet Dortmund Leonhard Euler Str. 5, D-44221 Dortmund Tel: +49.231.755.3257 Fax: +49.231.755.2631 email: uhle(a)mt.mb.uni-dortmund.de http://www.mt.mb.uni-dortmund.de

3 3

[Fwd: Re: AKFAvatar]
by Adriaan van Os 17 Aug '07

17 Aug '07

-------- Original Message -------- Subject: Re: AKFAvatar Date: Thu, 16 Aug 2007 22:53:46 +0200 From: marcov(a)stack.nl (Marco van de Voort) To: Adriaan van Os <gpc(a)microbizz.nl> References: <20070814101911.GA5425(a)castrophe.akfoerster.de> <46C3FF48.50100(a)microbizz.nl> In gmane.comp.compilers.gpc, you wrote: >> your program to use my library. (The program may not use the CRT unit or >> any other nonstandard output facility) > > The same mistake was made in teaching mathematics the-modern-way, with > much graphics and much less exact reasoning nor proofs-of-correctness. > Well, indeed in a democratic society the Pythogorean Theorem > <http://en.wikipedia.org/wiki/Pythagorean_theorem> should no longer be > proofed, which is dictatorial, or even be thought about, which is > elitarian, but decided on by voting .... > > This is all bullsh..., I mean nonsense. Programming, like mathematics, > *is* about exact reasoning and it *is* about abstract thinking. The task > of teachers is to lead pupils into this new world and to bring young > people to spiritual maturity. It is *not* the task of teachers to succumb > to the first shallow prejuduce, like whether something yet unknown is > "boring" or not. I talked a bit with teachers on the FPC booth at Systems 2005, and I got a different feeling; Teachers have had a love for the consoles tools because their simplicity somewhat put a brake on the time being spent in e.g. form designers making blinkenlightes with buttons and the like. (and because they are generally too lazy to re-setup their courses) However slowly that is becoming a problem because current students seem to miss any feel for the textconsole at all, having never used Dos. It is simply not a common skill anymore. And yes, that is not a really hard skill to teach, but every course day lost also detracts from the real objective of the course. The consensus seemed to be that a simple IDE maybe integrated with a lib to do some minimal work (few textfields/memo's input, a few output ones) would be the best. IOW one should separate "old and simple" and the real issue "can't be abused" here. Anyway, TP is probably still too free for a CS practicum, though the skills to exploit it may have decreased in new students A cut down compiler,IDE and lib that can't do anything communicating with the outside world except this special lib would be best. So one of the open source compilers, cut down and an IDE (Bloodshed?). Main problem probably: the debugger.

1 0

AKFAvatar
by Andreas K. Foerster 17 Aug '07

17 Aug '07

Hello, you know the problem? You want to teach somebody how to program in Pascal, so you start with simple line oriented programs. And then you get the answer "Pascal is boring, because you can only write old DOS programs with it" (Yes, some even call them "DOS programs", although they run under GNU/Linux). So for those who want to teach Pascal my project AKFAvatar might be a solution. You can take any Pascal program, which uses only the standard input/output and compile it into a funny graphical program with no extra effort (apart from the first installation). Yes, there is no need to make any changes to the program, just use a wrapper-script to compile your program to use my library. (The program may not use the CRT unit or any other nonstandard output facility) If you want to make use of more features, you can leave the script away and include the unit with "uses avatar;". There are some funny additional procedures to use. For example you can show image files, or play audio files... So programming with it is fun, but still easy enough for beginners. Please have a look at it: http://akfoerster.de/akfavatar/ It is still alpha and almost only tested under GNU/Linux so far. Please tell me what you think about it. -- AKFoerster

2 2

Re: Newbie Q: Porting TObject to gpc?
by Alexander von Below 10 Aug '07

10 Aug '07

Thanks! To be very honest, all I care about is that it compiles on a Mac, so FreePascal is good enough! Alex Am 10.08.2007 um 12:00 schrieb Marco van de Voort: >> You are absolutely correct, sorry for not adding a code snippet: > > This is Delphi code, not Turbo Pascal. > > Note that I only monitor the GPC list for certain interfacing with FPC > purposes (which will compile this flawlessly), so I can't really > comment on > the GPC status. > > Best to post that code (and the Delphi observation) to the list too. >

1 0

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