Gpc

gpc@gnu.de

5400 discussions

GNU Pascal: pascal library
by Iron Helix 07 Nov '98

07 Nov '98

An interesting project...Well anyways, I'm a programmer that knows cross-processor asm, C, C++, VC++, VB, Basic (eww), Euphoria (the predecessor to C (and Pascal?)), and am learning Pascal. Anyways, I noticed how GNU Pascal is lacking a standard Pascallian library, and am interested in writing it. I would do so in DGJPP C (not C++: too hard to interface with pascal (i think)), NASM assembly, and possibly something else...however, I would need a few things first: 1) your approval 2) A standard (borland or watcom or something) Pascal library reference (or one of each type to write multiple libraries :), with descriptions of what each does etc. 3) A knowledge of how GNU Pascal calling convention works: (it should interface nicely with DJGPP-C type, right?), offsets that function paramaters are passed at (i.e. are 16-bit #'s passed as 32-bit #'s), etc. 4) A quick reference of GNU Pascal supported pointer types (far, near, huge), supported data types, how structures are setup 5) A reference of how the filetypes in the libraries are setup If given the above, I would write a full-featured library for use with GNU Pascal (or, at least, get pretty darn close :) that would be almost 100% compatible with normal Pascal libraries, and I would also maintain it, too :) Yes, I realize that this may be a huge task (how long did it take them to write the DJGPP2 libc? :), and that it would take a little while, but hey, it sounds interesting :) and you could take that little 'con' out of the cons section. In addition, non-C (but Pascal) programmers could use your compiler because you'd have a similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c reference :). NOTE: Just in case I wasn't clear, what I meant by writing a "standard Pascal lib" is writing the lib that is to Pascal as libc is to DJGPP :) Oh, and on the side, wouldn't it be an interesting thing to write a GNU Basic compiler that was _FAST_, had unsigned numbers, had more needed functions that aren't able to be made/used (i.e. an 'asm'-like command ;), used pointers, and some more stuff like being almost completely compatible with existing QBASIC programs and compiler-commands (i.e. '#include') and some more stuff? If you guys would want to do the lex. analyzer/compiler/etc. part, I'd write the library that would be the _FAST_ version of the normal BASIC lib...we could help BASIC programmers out there do alot better :) even tho it still wouldn't be as good as C... Anyways, thanx for your time. -Iron Helix ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: Automake
by Frank Heckenbach 06 Nov '98

06 Nov '98

Peter Gerwinski wrote: > > A library for gpi's would be nice? > > Any suggestion how this could be implemented? I suppose it could be done with `ar', just like with object libraries. However, I'm not sure if this will be really very important, once GPC has better automake and doesn't try to recompile unnecessarily. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

gpc-19980830 binary for DJGPP
by Frank Heckenbach 06 Nov '98

06 Nov '98

Hi, folks! A binary distribution of gpc-19980830 for DJGPP has been uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/gpc-19980830.i386-djgppv201.zip Greetings, Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Automake
by Thamm, Russell 06 Nov '98

06 Nov '98

I am having so much trouble with automake that I am considering abandoning GPC altogether. Everytime that I add a few more modules to my program, I have to spend several hours reorganizing units in order to get the program to compile. The only solution seems to be to combine all units into one giant unit. This is not really satisfactory. I keep running out of virtual memory on a machine with 256 MBytes of memory. My concern is that eventually my program will grow to a point where I won't be able to compile it at all. Or that compilation takes so long that development becomes impossible. Currently, the code only implements part of the GUI. Using a makefile is much better. I am not absolutely sure how to express the dependencies. Make seems to have no concept of a compilation producing more than one output file. I can get RHIDE to bypass automake by not specifying a primary file and adding all source files to the project. But Rhide apparently ignores the Uses clauses when determining dependencies and I ca't work out how to use user-defined dependencies with it. Does anyone know how I can use Rhide and avoid automake? Alternatively, is there some other solutions - A library for gpi's would be nice? Any options to indicate to automake that certain units don't need to be checked? I suspect that if automake kept track of the units not requiring compilation, things might improve.things. That is, the first time it checks grx20.pas, it should note that no recompilation is required rather than rechecking the same file many times. I'd be grateful for any advice. Russell Thamm

2 1

Another enumeration question
by Jo Dillon 05 Nov '98

05 Nov '98

Ok, I got it wrong with my previous question about enumerations, but what about this: (file babyunit2) unit babyunit2; interface type MyType = (a,b,c); implementation end. (file babyunit) unit babyunit; interface uses babyunit2; procedure printmytype(b : mytype); implementation procedure printmytype(b : mytype); begin writeln(ord(b)); end; end. (file baby) program baby; uses babyunit,babyunit2; var x : mytype; begin for x:=a to c do printmytype(x); end. [root@twentyfour aargh]# gpc -g -c -w babyunit2.pas [root@twentyfour aargh]# gpc -g -c -w babyunit.pas [root@twentyfour aargh]# gpc baby.pas babyunit2.o babyunit.o -o baby baby.pas: In function `program_Baby': baby.pas:19: incompatible type for argument 1 of `Printmytype' However, when I combine all three files like this: program baby; type MyType = (a,b,c); procedure printmytype(b : mytype); begin writeln(ord(b)); end; var x : mytype; begin for x:=a to c do printmytype(x); end. Everything works fine. Surely this has to be a compiler problem? -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

2 3

Re: Another enumeration question
by Frank Heckenbach 05 Nov '98

05 Nov '98

Jo Dillon wrote: > Ok, I got it wrong with my previous question about enumerations, > but what about this: > > (file babyunit2) > [...] Yes, this seems to be the same bug as in russell2.pas, but I added your program to the test suite, anyway. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Tests
by Miklos Cserzo 05 Nov '98

05 Nov '98

Hi Folks, I am testing the 0830 alpha distribution on different systems. The compilation is OK but the a number of sample codes in p/test are failed. Is there a system where ALL the tests are OK? Cheers, miklos

2 1

GPC enumerations bug?
by Jo Dillon 05 Nov '98

05 Nov '98

Hi, I have a small test program which doesn't compile: (file babyunit.pas) unit babyunit; interface type bug=(beetle, ant); procedure printbug(b : bug); implementation procedure printbug(b : bug); begin case b of beetle : writeln('beetle'); ant : writeln('ant') end end; end. (file baby.pas) program baby; uses babyunit; var lp : bug; type insect=(beetle, ant); begin {for lp:=bug(beetle) to bug(ant) do} { this compiles! } for lp:=beetle to ant do printbug(lp); end. Compiler error: gpc -g -c -w babyunit.pas gpc -g -c -w baby.pas baby.pas: In function `program_Baby': baby.pas:10: incompatible types in assignment It looks to be a problem with having the same identifier used in two enumerations; if those two enumerations are in the same unit a more informative error message results, such as: baby.pas:7: conflicting types for `Beetle' baby.pas:6: previous declaration of `Beetle' baby.pas:7: conflicting types for `Ant' baby.pas:6: previous declaration of `Ant' baby.pas: In function `program_Baby': baby.pas:11: incompatible types in assignment (when type foo=(beetle,ant); is added immediately after type insect in baby.pas). This is the most recent gpc beta snapshot compiled against the gcc 2.8.1 backend on intel/linux. Any ideas? Is this a compiler bug? -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

2 1

libgcc.a
by Thamm, Russell 05 Nov '98

05 Nov '98

I always wondered why the GPC distribution contained a different libgcc.a than the GCC distribution. I assumed that the GPC version had some extra stuff in it. However, it appears that the latest GPC version is incompatible with GNU C++. I've just spent all morning trying to make the GAWS package. Every time I tried to make any examples, I got heaps of linker errors. Eventually, in desparation, I replaced libgcc.a with the copy in GCC281b.ZIP. Suddenly all my linker errors dissappeared. I also note that the libgcc.a in the latest beta version of GPC is considerably shorter than the ones in previous versions. So what is the story with the GPC version of libgcc.a? thanks Russell BTW. I'm finally subscribed to this mailing list.

3 3

compiling grx20.pas
by Robert P. Ewing 04 Nov '98

04 Nov '98

Hi, all. I'm having trouble getting the grx20.pas unit to compile. If I just do a compile (gpc -g-c grx20.pas -o grx20.o), there are no errors. But when I attempt to Make it (this is in RHIDE), I see: compiling: c:\gpc\pascal\grx20.pas crt0.s: undefined reference to 'main' crt1.c: undefined reference to 'main' there were some errors Now I can't find any crt0.s or crt1.c files anywhere on the hard drive, so I don't think that's the problem... Is this a compiler bug, or can I get around it by changing some compiler flags or a few lines in the code? By the way, I'm using RHIDE 1.4, and the new beta gpc binary downloaded just a month ago. Any help would be appreciated. Toby Ewing ewing(a)iastate.edu

2 1

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