Gpc

gpc@gnu.de

5400 discussions

VB: EFLIB
by Johan Larsson 01 Aug '97

01 Aug '97

Hi, I have written a program for Borland Pascal. I am currently looking for porters for the GNU Pascal environment. It will be released under a modified GNU Library GPL license. Check EFLIB at http://www.ts.umu.se/EFLIB/. Best Regards, Johan Larsson jola(a)ts.umu.se Also, REMEMBER to check out http://www.ts.umu.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED.

1 0

Re: pointer-compatibile integers
by Peter Gerwinski 01 Aug '97

01 Aug '97

According to Frank Heckenbach: > > Can there be any problems with signedness, or is it guaranteed that > ptrdiff_t is always signed and of the same size as a pointer? (I should > think so, but after all I've heard in the last time about such things, > I'm getting very careful...) If this is portable, there's no need to > predefine this type. Of course, this is *not* guaranteed. > What about size_t? > [...] > So perhaps only one more integer type (for now)... :-) GNU C has two special types here: SIZE_TYPE and PTR_DIFF_TYPE. Both are machine-dependent. To be compatible, maybe we must provide both? Following the notations for required identifiers in the Extended Pascal standard, we should not use underscores for predefined types. So what about `SizeType' and `PtrDiffType'? Since both are *not* guaranteed to have the same size as a pointer, the other thing, `Ptr[Int|Card|Word]', would be useful, too. This means five more integer types. More suggestions? 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: pointer-compatibile integers (was: gpi-hash.c segfaults)
by Frank Heckenbach 01 Aug '97

01 Aug '97

Peter Gerwinski wrote: > According to Frank Heckenbach: > > > > While we're at it: would it be possible to have predefined Pascal types > > as size_t and ptrdiff_t (and maybe other types?) so that such > > calculations can be done in Pascal? > > Not enough integer types yet? ;-) :-) (But, fortunately, they're not really new types, just the same types with different names...) > This can be be implemented with > > Type > PtrInt = Integer ( BitSizeOf ( Pointer ) ); > > Is this sufficient? Can there be any problems with signedness, or is it guaranteed that ptrdiff_t is always signed and of the same size as a pointer? (I should think so, but after all I've heard in the last time about such things, I'm getting very careful...) If this is portable, there's no need to predefine this type. What about size_t? In BP, I've always used "Word" for memory sizes, and at least for DJGPP and Linux, this would work in gpc, too. But also on other machines (Alpha)? If not, I don't see a way to define size_t in Pascal, so it might have to be predefined... So perhaps only one more integer type (for now)... :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: gpi-hash.c segfaults
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Bill Currie: > > I'VE FIXED IT!! The problem was caused by a negative index into the > hash table. Congratulations and thank you! > To fix it change the line (gci-hash.c:122): > > (((((char *)(NODE))-(char *)0) >> 2) % MAX_HASH_TABLE) > > to: > > (((((unsigned long)(NODE))-(unsigned long)0) >> 2) % MAX_HASH_TABLE) Since pointers and `long' integers don't have the same size on some sytems (I know it for the Alpha), I think this should be changed to something like `(unsigned size_t)'. > [...] > Well, anyway, maybe now this bug can be laid to rest... I hope so, too. Having this, it's realistic to have the next beta release within the next days ... Yours, 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

3 2

pointer-compatibile integers (was: gpi-hash.c segfaults)
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Frank Heckenbach: > > While we're at it: would it be possible to have predefined Pascal types > as size_t and ptrdiff_t (and maybe other types?) so that such > calculations can be done in Pascal? Not enough integer types yet? ;-) This can be be implemented with Type PtrInt = Integer ( BitSizeOf ( Pointer ) ); Is this sufficient? Since GPC fully supports pointer arithmetics, I don't see too much applications for this. If not ... what about `PtrInt', `PtrCard', and `PtrWord'? Greetings, Peter (* For those who have not followed the recent discussion about integer types in GPC, here is some background: Besides `Integer' (signed), GPC supports `Cardinal' (unsigned) and `Word' (don't care about signedness, in fact unsigned). These types exist in several sizes which guarantee compatibility to GNU C and introduce some portability to other Pascal compilers: GNU Pascal GNU C ByteInt signed char ShortInt short int Integer int MedInt long int LongInt long long int There are also `*Card' and `*Word' versions of these, yielding a total of fifteen basic integer types. Besides this, GPC supports a synonym `LongestInt' for `LongInt' which guarantees the longest possible integer type (for the case that GNU C introduces `long long long int' which we would implement as `LongLongInt'); same with `LongestCard' and `LongestWord'. Eighteen. Compatibility to Borland Pascal and Delphi requires `Comp' (same as `LongInt' and `SmallInt' (same as `ShortInt' in GPC). Twenty. Okay? Good. Now it *really* begins. Like all Pascal compilers, GPC supports subranges like `1..42'. This adds 2 * sqr ( 2 pow 64 ) more possible integer types to our zoo. The `2' comes from signed and unsigned variants ... let's speak of "20 + two classes" of integer types. As an extension, GPC allows these subranges to be `packed' (i.e. allocate only one byte for `packed 1..42'; the default of allocating four bytes results in faster code) which leaves us with 20 + four classes of integer types. In low-level programming you often have the situation that you want to know exactly how many bits a variable occupies. While this could be done with packed subranges, it is more comfortable to have an extended syntax for `Integer'. In GPC, `Integer ( 42 )' yields a 42-bit integer. Depending on the machine (which might not have 42-bit registers) this will probably be stored in a 64-bit word, except in packed records; however on those machines where you need, say, `Integer ( 8 )' for your low-level stuff, you can be sure that the hardware supports it. Having this for `Cardinal' and `Word' as well yields 20 + 7 classes. Adding `Ptr[Int|Card|Word]' as suggested above would make it 23 + 7 classes of integer types. Well, no big deal. I know this is a great source of confusion, but the discussion convinced me that all these integer types have their place where they are important. 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: gpi-hash.c segfaults
by Frank Heckenbach 31 Jul '97

31 Jul '97

Jukka Virtanen wrote: > In ANSI C the result of (ptr - ptr) is of type ptrdiff_t, > which in the alpha is (signed long). > Using cast (unsigned size_t) might not be a good idea, at least > I do not know if Ansi C quarantees that size_t always > is as large as ptrdiff_t. While we're at it: would it be possible to have predefined Pascal types as size_t and ptrdiff_t (and maybe other types?) so that such calculations can be done in Pascal?

1 0

Re: More crashing in gpc (970727)
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Bill Currie: > > Sigh, got gpi-hash fixed and now this :( > > At least it's easy to reproduce, I just have absolutly no > understanding of what's going on. > > Just compile with `gpc -O2 -c system.pas'. Reproducible. :-) > A warning is given (doesn't make sense to me yet) You commented out the definition of `LongInt' to be `Integer' (32 bits), so GPC used its built-in `LongInt' (64 bits), whereas pointers on iX86 processors only have 32 bits. > and then the call > to `convert' in `build_c_cast' (line 5316 in gpc-typeck.c) goes > bananas (infinite(?) recursion). This happens in fillchar (line 178) > [...] Fixed. :-) Patch for `gpc-typeck.c' below. > There's also a strange bug where an untytped constant that's declared > in one unit that's used by onother and both of those are used by a > third gets lost to the third unit if the second unit is `used' after > the first. Unfortunatly, I have yet to reproduce this in small > files. And unfortunately, I cannot reproduce it by myself. :-( But I don't expect this to be as weird as the "hashing" bug you just fixed. :-) 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125] 8< ---- gpc-typeck.c.diff ---------------------------------------------------- @@ -5303,7 +5308,9 @@ pedwarn ("constant out of range - truncated"); } - if (TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) + if (TREE_CODE (type) != POINTER_TYPE + && TREE_CODE (TREE_TYPE (value)) != POINTER_TYPE + && TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) && TYPE_PRECISION (type) != TYPE_PRECISION (TREE_TYPE (value))) { /* Do the conversion in two stages, e.g.

1 0

Re: Linking error
by Peter Gerwinski 30 Jul '97

30 Jul '97

According to Joao Miguel: > > I'm trying to compile the system.pas unit (contained in bpcompat.zip) with > my program. The compiler gives the error: > > "system.o: Undefined symbol `__fmode' referenced from text segment" > > I'm using Free-BSD 2.1. [...] I am afraid this system Unit is not {yet} very portable. It is known to run under DJGPP (DOS), but to make it usable for FreeBSD, probably some work will be necessary. AFAIK, `FMode' is responsible for write access when `reset'ting a file; to get the same functionality without this variable you can use `update' instead of `reset'. 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Pascal Compiler
by Peter Gerwinski 30 Jul '97

30 Jul '97

According to Tsee Lee: > > I saw on the web site that there is a version for Win95, but can't find > it on the ftp server. Is ther really such a version? Thanks. Yes: Look out for the `cygwin32' binaries. You will probably need more CygWin32 stuff for program development under Windows 95 with GNU Pascal. You can look for it at ftp://ftp.cygnus.com, but somebody else on this list can probably tell you more about 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 [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Linking error
by Joao Miguel 30 Jul '97

30 Jul '97

Hi, I'm trying to compile the system.pas unit (contained in bpcompat.zip) with my program. The compiler gives the error: "system.o: Undefined symbol `__fmode' referenced from text segment" I'm using Free-BSD 2.1. Can anyone tell me what is the name in BSD of the symbol referenced in the source: "FMode : AsmName '_fmode' integer;" Best regards Joao Domingos

1 0

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