December 2007 - Gpc

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

26 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

Assignment of cstrings passed to C routine
by Harmonious Botch 25 Dec '07

25 Dec '07

I'm trying to call a C routine from a pascal program, and pass string data back and forth. I can call it, I can pass integers back and forth ( thanks to Frank H ), but I can't pass strings. Attempts to assign data to a cstring either result in segmentation errors or garbage in the string. The following is the C routine: #include <stdio.h> char c_str[13]; void c_print_str() { printf ("Now in C routine called from Pascal code.\n"); printf ("string is %s.\n", c_str); fflush (stdout); /* So the text really appears now. */ } The following is the pascal program: program str_trans(input); (* This is an attempt to pass a string from a pascal program to a c function. The corresponding c code is in str_trans.c It is compiled with gpc --automake --unit-path=/home/x/pas str_trans.pas -o str_trans *) {$L str_trans.c} {$X+} procedure c_print_str; asmname 'c_print_str'; var char_ptr: ^char; c_str: cstring; asmname 'c_str'; external; begin new( char_ptr ); char_ptr^ := 'x'; writeln( char_ptr^ ); flush( output ); c_str := char_ptr; writeln( 'calling c function' ); c_print_str; end. As shown, it ends up with garbage in c_str. If I change the value of char_ptr^, the garbage changes. If I try simple assignment in the pascal program, such as c_str := 'x'; or c_str[3] := 'x'; or c_str^ := char_ptr^ it compiles ok, but generates run-time segmentation errors. So, the ideal help would be if someone could explain to me how to assign to c_str. If not, does anyone know how to pass string data between C and Pascal programs in some other manner? Thanks, and happy solstace to all! HB -- View this message in context: http://www.nabble.com/Assignment-of-cstrings-passed-to-C-routine-tp14472794… Sent from the Gpc mailing list archive at Nabble.com.

4 6

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

Re: dispose: bug or feature?
by Scott Moore 13 Dec '07

13 Dec '07

Scott Moore wrote: >> From: Russell Whitaker <russ(a)ashlandhome.net> >>> >>> On Mon, 10 Dec 2007, Scott Moore wrote: >>> >>> [..] >>>> What did you expect to happen? >>>> >>> I expected "dispose" to undo what "new" does. >>> Could not find a comment in gpc's source that states otherwise. >>> >>> At present, >>> >>> new(p) >>> 1. allocates a block of memory from the heap, the size is the size >>> that p wants to point to. >>> 2. returns the address of that memory block. >>> >>> dispose(p) >>> 1. marks the block of memory that p points to as free. >>> (I say "marks" because the block doesn't disapear) >>> >>> Thus, this works, but shouldn't: >>> >>> writeln( p^ ); >>> dispose( p ); >>> writeln( p^ ); >> >> ============================================= >> 6.5.4 Identified-variables >> An identified-variable shall denote the variable, if any, identified >> by the value of the pointer-variable >> of the identified-variable (see 6 .4 .4 and 6 .6 .5 .3) shall be >> accessible until the termination of the >> activation of the program-block or until the variable is made >> inaccessible (see the required procedure >> 28 >> ISO/IEC 7185 :1990(E) >> dispose, 6.6 .5 .3). >> NOTE | The accessibility of the variable also depends on the existence >> of a pointer-variable that has >> attributed to it the corresponding identifying-value. >> A pointer-variable shall be a variable-access that denotes a variable >> possessing a pointer-type . It shall >> be an error if the pointer-variable of an identified-variable either >> denotes a nil-value or is undefined. >> It shall be an error to remove from the set of values of the >> pointer-type the identifying-value of an >> identified-variable (see 6 .6 .5 .3) when a reference to the >> identified-variable exists. >> Examples: >> p1fi >> p1f .fatherf >> p1's .sibling's .father's >> 6.5 >> =========================================================== >> The statement "writeln( p^ );" after dispose is an "error", dispose >> left p undefined. >> >>> If you dig into gpc's heap.pas you will find code that is the >>> equivalent of: >>> >>> if p <> nil then >>> dispose(p); >>> >>> What I'd like to see is the equivalent of: >>> >>> if p <> nil then >>> begin >>> dispose(p); >>> p := nil; >>> end >>> else >>> writeln( stderr,"WARN: illegal use of dispose"); >>> >>> In places the specs are hard to follow, but I think the specs would >>> allow this. >>> >>> Russ >>> >> >> ====================================================== >> 6.6 .5.3 Dynamic allocation procedures >> >> ... >> >> dispose(q) >> >> shall remove the identifying-value denoted by the expression q from >> the pointer-type of q . It >> shall be an error if the identifying-value had been created using the >> form new(p,c l , . . .,cn). >> >> dispose(q,kl , . . .,km) >> >> shall remove the identifying-value denoted by the expression q from >> the pointer-type of q . The >> case-constants k 1, . . .,km shall be listed in order of increasing >> nesting of the variant-parts . It >> shall be an error unless the variable had been created using the form >> new(p,c 1 , . . .,cn ) and m is >> equal to n . It shall be an error if the variants in the variable >> identified by the pointer value of >> q are different from those specified by the values denoted by the >> case-constants k 1, . . .,km. >> >> NOTE | The removal of an identifying-value from the pointer-type to >> which it belongs renders the identifiedvariable >> inaccessible (see 6 .5.4) and makes undefined all variables and >> functions that have that value >> attributed (see 6 .6 .3 .2 and 6 .8 .2 .2). >> >> It shall be an error if q has a nil-value or is undefined. >> =================================================== >> >> So, again, it is an error (to pass nil to dispose). However, the >> standard leaves it up to the >> implementation when and if such errors are detected, so this is a >> "quality" issue: >> >> ================================================= >> 3.1 Error >> A violation by a program of the requirements of this International >> Standard that a processor is >> permitted to leave undetected. >> ================================================== >> >> I'll bet a nickel that the dispose nil behavior you saw was designed >> to compensate >> for disposals of zero length data. I had to solve that problem, but >> did it using a key address, >> i.e., new() returns a specific, predefined location that is the >> universal zero length pointer. >> >> Scott Moore >> > >

3 2

dispose: bug or feature?
by Russell Whitaker 11 Dec '07

11 Dec '07

Hi Given a pointer p, dispose(p) does not set p to nil. This program, program tst; type ptr = ^string; var p : ptr; begin p := new( ptr, 20 ); p^ := "abc"; writeln( p^ ); dispose( p ); p := nil; if p = nil then writeln("OK"); dispose( p ); writeln( p^ ); end. as is gives you abc OK segmentation fault The seg fault is from the last writeln. If you comment out the line "p := nil", the second "dispose" causes a core dump. If you comment out both "p := nil" and the second "dispose" you get abc abc and that's also an error. I do not know what side effects you might get if you caused "dispose" to set the pointer to nil. Russ

6 8

Re: dispose: bug or feature?
by Scott Moore 11 Dec '07

11 Dec '07

Peter N Lewis wrote: > It's not worth nit picking on the list further, but I wonder if...: > >> dispose(q) >> shall remove the identifying-value denoted by the expression q from the >> pointer-type of q . It shall be an error if the identifying-value had >> been created using the form new(p,c l , . . .,cn). >> >> ... >> >> NOTE -- The removal of an identifying-value from the pointer-type to >> which it belongs renders the identified-variable inaccessible (see >> 6.5.4) and makes undefined all variables and functions that have that >> value attributed (see 6.6.3.2 and 6.8.2.2). > > > "identified-variable" refers to the content, not p per se? > > Note how it makes the distinction of "identifying-value" (ie the > pointer?) and "identified-variable" (ie p^). > > Thus p^ is inaccessible. > > There is a reason I don't attempt to read standards! It says "makes undefined all variables and functions that have that value attributed", and the "value" the speaketh of is the "identifying-value". This is why I included the definition of: new(p) shall create a new variable that is totally-undefined, shall create a new identifying-value of the pointer-type associated with p, that identifies the new variable, and shall attribute this identifying-value to the variable denoted by the variable-access p Note "shall attribute this identifying-value to the variable denoted by the variable-access p" The double speak has a purpose, and the meaning covers several storage management schemes, including references and recycling. For reference systems, where the pointer contains not an address but a logical key to the actual variable, the "identifying-value" becomes undefined because its table entry becomes invalid. For recycling systems, the actual pointer may be set invalid. Its an important point, because it lets the implementor implement advanced storage handling. Scott Moore

1 0

German Book about GNU-Pascal needs contributors
by Eike 06 Dec '07

06 Dec '07

Hi Folks! There is a book in German language about GNU-Pascal available at Wikibooks. See http://de.wikibooks.org/wiki/GNU-Pascal_in_Beispielen There is a publishing company, who is going to sell this and some other books from wikibooks. The money will be donated to the wikimedia foundation. I do not have the time, to step through this book again and fix all those things, which might have changed or should be rewritten. If someone would like to take this job, feel free. Translators are also welcome. Without your help, this book becomes more and more outdated and not worth publishing. Yours Eike

3 4