Gpc

gpc@gnu.de

5400 discussions

ANN : JEDI-SDL now also compatible with Gnu Pascal & TMT Pascal compilers...
by Dominique Louis 25 Apr '03

25 Apr '03

Hi All, Just a quick note to say that I have just checked into CVS the last JEDI-SDL ( http://sourceforge.net/projects/jedi-sdl/ ) changes ( for now ) that has added compatability for the Gnu Pascal and TMT Pascal compilers. Thanks to Alexey "Clootie" Barkovoy for his help with TMT support. Thanks to Prof. Abimbola "The Chief" Olowofoyeku and Eike Lange for their help with Gnu Pascal support. Thanks to Mr "Que Pasha Pepe" Kroket for his help with better FreePascal support. These latest changes have been tested under Windows and the newly modified JEDISDL Aliens demo ( the benchmark for cross-compiler compatability ) has also been checked into CVS. These Pascal bindings and the demo now compile flawlessly under Delphi, FreePascal ( FPC ) 1.0.4, Gnu Pascal ( GPC ) Latest Alpha & TMT Pascal. The Aliens Demo runs flawlessly with Music and FX under Delphi, FPC and TMT. The GPC version has a screen refresh problem, while sound collision detection etc work flawlessly. The GPC issue, may be due to the Alpha status of the compiler or my lack of familiarity with the GPC compiler, as all compilers are essentially compiling the same code. Looking ahead, testing and bug fixing is under way to make sure the headers support Gnu Pascal on Linux and MacOS X ( yes MacOS, woo hoo ) and FreePascal under Linux. I hope this widens the appeal of JEDI-SDL. Dominique http://www.DelphiGamer.com := go on, write a game instead;

4 4

Importing a module several times
by Frank Heckenbach 23 Apr '03

23 Apr '03

Is this valid EP? module m; export m = all; const o = 'O'; k = 'K'; end; end. program p (Output); import m only (o); m only (k); begin WriteLn (o, k) end. The following might mean it isn't: : The occurrence of an interfaceÂidentifier in an importÂspecification shall : constitute the definingÂpoint of the identifier of the interfaceÂidentifier : as an importedÂinterfaceÂidentifier for the region that is the block, : moduleÂheading, or moduleÂblock closestÂcontaining the : importÂspecification. 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

1 0

Dynamic Linked Libraries under MacOS?
by Dominique Louis 23 Apr '03

23 Apr '03

How does one interface to DLLs ( or whatever they are called ) under MacOS? What are the steps required in order to achieve this? Thanks, Dominique http://www.DelphiGamer.com := go on, write a game instead;

2 1

Modules without implementation
by Frank Heckenbach 22 Apr '03

22 Apr '03

One of the listed bugs of GPC was "modules without implementation". However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part): : Each identifier having a definingÂpoint as a moduleÂidentifier in a : moduleÂheading of a moduleÂ declaration containing the interfaceÂdirective : interface shall have exactly one of its applied occurrences in a : moduleÂidentification of a moduleÂdeclaration containing the : implementationÂdirective implementation. In contrast, the following works in GPC (with an almost empty module-block): module fjf843m; export fjf843m = all; const OK = 'OK'; end; end. What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do): module fjf843m; export fjf843m = all; const OK = 'OK'; end. However, AFAICS, EP doesn't require to support `interface' modules without implementation. That's good because GPC has to know when compiling a module whether there will be an implementation part (because it has to create the initializer if (and only if) not). It also seems reasonable to me from the programmer's point of view. When you write a module interface, you know whether there has to be an implementation (namely, if there are any routines in the interface or an initializer or finalizer will be needed) or not (only constants, types and variables without need for initialization/finalization). So it makes sense to specify this explicitly (by writing `interface' or not). Can anyone confirm my interpretation? 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

5 11

-Wparentheses
by Frank Heckenbach 21 Apr '03

21 Apr '03

GCC supports `-Wparentheses' (warn about some constructs where parentheses are suggested for clarification, although not strictly syntactically necessary). The corresponding code is also there for GPC. I'm going to activate it now. The questions are: - Which constructs to warn about? So far, I've come up with the following ones: * `and' in an operand of `or', as in `a or b and c' which is equivalent to `a or (b and c)', but may confuse the reader. (Same for `and_then' instead of `and' etc., of course.) * logical operations (`and', `or', `not', etc.) in an operand of a relational operator (`=', etc., `in'). This would catch cases like the dreaded `if not a = b'. - What should be the default? I suggest off by default and on with `-Wall' (same as in GCC). (Of course, the issue is not as serious in Pascal than it is in C where the danger of confusion between `==' and `=' in a comparison almost requires such a warning, but I think it's also useful in Pascal.) 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

4 5

Progress of Mac OS X port
by Adriaan van Os 20 Apr '03

20 Apr '03

Yesterday, I wrote a small test program and linked it against Apple's "Carbon framework". To my surprise, it worked. So, against all expectations, the current compiler is able to link to Apple "dylibs" and Apple "frameworks". The compiler produces ".o" code and the Apple-"ld" linker takes care of the rest. This implies, that I am loosing interest in the Apple-patched GCC compiler. Apple writes "we're not even sure what all of them [the compiler changes] are, because the existing compiler has many undocumented changes inherited from 10 years of NeXT and Apple hacking, and nobody knows what some of them are for." This doesn't inspire confidence. Besides, important changes (like precompiled header support) are now getting integrated into mainline FSF. So, I am slowly considering it an advantage (rather than a disadvantage) that the current port is based on mainline FSF-GCC 3.2.1. And isn't it fun to read in officlal Apple docs for some compiler option "Not supported on Mac OS X" where the GPC compiler actually does .... As a further experiment, I compiled hello.pas into hello.o and tried to link it with "mwld", the command-line version of the MetroWerks CodeWarrior linker. Again, to my surprise, it worked. I added "hello.o" to a CodeWarrior Project and disassembled it there. It worked. So, maybe some day there will be a GNU Pascal compiler plug-in CodeWarrior (not a promise, just an idea) .... Regards, Adriaan van Os

6 13

gcc-2.95 with libefence
by Frank Heckenbach 20 Apr '03

20 Apr '03

I just build GPC with gcc-2.95.3 under Linux/IA32, linked with libefence and ran the test-suite. There was only one bug (7 instances: drf3a.pas, fjf639j7.pas, fjf669b.pas, goto7.pas, jj5.pas, sam11.pas, strindex.pas) which seems to be a backend bug. The bug seems relatively harmless -- only an invalid read access, and it might not even do any real harm in the worst circumstances (but I don't know enough about the backend data structures to tell for sure). So I won't add the fix to GPC's GCC patches (since GPC's support for gcc-2 will disappear "soon", anyway). If anyone wants to apply it, anyway, you can find it attached. 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

1 0

gpc-20030323 released (IMPORTANT NOTES ABOUT BACKWARD-INCOMPATIBILITY)
by Frank Heckenbach 18 Apr '03

18 Apr '03

I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ You will hate this release ... at least if you make heavy use of external declarations or other directives. We all knew that some backward-incompatible changes in this area would have to be made, now that's happened. PLEASE READ THE NOTES BELOW FOR DETAILS. Changes that affect building GPC: ================================= - Dwarf2 debug info (the default under Linux and many other systems with gcc-3) finally works. This means you can now build GPC with gcc-3 without `-g0' or `-gstabs'. - Building GPC no more requires gperf (those who maintain build dependencies please note this). - Besides the source distributions as before, there is now also a "minimal" distribution. This is compressed with bzip2 instead of gzip and does not contain any generated files. These files will be generated automatically when building GPC, but you need some additional tools installed: bzip2, bash, *GNU* sed, GNU awk, GNU m4, bison, flex, autoconf, help2man, makeinfo (at least version 4.1). Other changes: ============== - Forward referencing pointers generate proper debug info now. - Discriminant identifiers are allowed as variant record selectors. - `export Foo = all (...)' (fjf811*.pas) - Delphi-compatible `initialization', `finalization' (chief43*.pas) - Type-casts are BP compatible now, in particular, value type-casts between ordinal and real or complex types don't work anymore. - All non-ISO-7185 keywords can be used as identifiers (with two small exceptions). (fjf440.pas) - `pack-struct' does not imply bit-level packing anymore (only explicit `packed' records and arrays do). - New options `--[no-]ignore-packed' (`--ignore-packed' is the default in BP mode). (fjf796*.pas) - New option `--maximum-field-alignment=N' - `{$[no-]pack-struct}' as a compiler directive - New options `-W[no-]local-external' (implied by `-Wall') - New options `--vax-pascal', `--mac-pascal' - Mac Pascal directives `definec', `macro', `undefc', `ifc', `ifoptc', `elsec', `elifc', `endc', `errorc' - Units without `implementation' part - When passing a schema variable as an untyped argument, the whole schema, including the discriminants is passed. (fjf798.pas) - `TimeZone' in `TimeStamp' counts seconds *east* of UTC now (not west, as before). (datetimedemo.pas) - Some bug fixes related to operator overloading. - Variables declared in interfaces of modules are now initialized (capacity of strings etc.). (daj3.pas, sven14c.pas, nick1.pas) - Various other bug fixes. Directives and attributes: ========================== - `external name' works (BP compatible). So procedure Foo; external; asmname 'bar'; or (equivalent previously) procedure Foo; asmname 'bar'; can be changed to procedure Foo; external name 'bar'; GPC also accepts procedure Foo; external 'libname' name 'bar'; but ignores 'libname'. It could be supported via automake, but since automake is to be replaced by gp, anyway, it seems pointless to do it now. - `name' works as an attribute. - `attribute's with single parameters can be written with `=', so attribute (name ('foo')) and attribute (name = 'foo') are equivalent. - Linker names (whether by `external name' or as an `attribute') can be string constant expressions now (e.g., involving declared string constants and `+'). The same applies to module/unit file names specified with `in'. - `asmname' is deprecated (and will be dropped in a future version). * External `asmname' constructions can be changed as shown above. * In a unit interface, change procedure Foo; asmname 'bar'; to procedure Foo; external name 'bar'; *if* the routine is really external (e.g. implemented in a C file or library); otherwise to procedure Foo; attribute (name = 'bar'); (previously, GPC didn't care, but now you have to distinguish these cases). - `external' without an asmname (whether by `external name' or as an `attribute') defaults to all-lowercase linker names now. GPC will give a warning now (because of the change). This warning will disappear in the future (but the change will remain in effect, of course). Routines without `external' or asmname still use first-uppercase linker names, for those who care. But it's not recommended to rely on this. So change procedure Foo; external; to procedure Foo; external name 'Foo'; (or change the corresponding C code to `foo' if that's under your control). - All of the above applies to variables as well. - `c', `c_language' are also deprecated. Instead of procedure Foo; c; or procedure Foo; c_language; write procedure Foo; external; (if you don't mind the warning for now), or procedure Foo; external name 'foo'; (if you prefer to make the linker name more explicit). - `static', `volatile' and `register' for variables are no prefix directives anymore, but attributes. E.g. var Foo: static Integer; becomes var Foo: Integer; attribute (static); - Same for `inline' with routines. inline procedure Foo; becomes procedure Foo; attribute (inline); - A new attribute `const' for variables (really read-only -- unlike BP's "typed constants", and also applicable to external variables). - `attribute' for routines doesn't imply `forward' anymore, so you don't have to declare routines twice in a program or implementation part when setting the linker name or some other attribute. E.g. procedure Foo; attribute (noreturn); { forward; -- ignored here before } procedure Foo; begin Halt end; becomes: procedure Foo; attribute (noreturn); begin Halt end; A final example: procedure Foo; asmname 'bar'; attribute (noreturn); procedure Foo; begin Halt end; becomes: procedure Foo; attribute (noreturn, name = 'bar'); begin Halt end; 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

9 66

Re: Need units for delphi classes and forms
by Prof. A Olowofoyeku (The African Chief) 17 Apr '03

17 Apr '03

Brian Keener wrote: >I am playing around with porting an application from Visual C++ and >Delphi to GNU C++ and GNU GPC and I have a working GPC Compiler >(based on a compile of the Tests in GPC). While I am no where near >to having a working Makefile or truly compiled GNU GPC code for this >application I have gotten as far as being able to determine that I >need units for Delphi Classes and Forms. > >Does anyone know where I might locate these or get replacements that >will work with GPC or is there some other using I need instead. Unfortunately, you will not get very far without a tremendous amount of work. Units for Delphi classes and forms do not exist for use with GPC. Even with compilers that fully support the Delphi object model (e.g., Free Pascal and Virtual Pascal), it would be a herculean undertaking to compile the Delphi VCL or build anything like it. There are projects (e.g., Lazarus) that aim to produce something like the VCL, but they still have a very long way to go. With GPC, the compiler itself currently supports only the old BP object model - a different thing from the Delphi model. I have produced GPC units that begin to implement some things for Delphi compatibility (e.g., a Windows unit, and a rudimentary Sysutils unit) - but you will need far more than these. In effect, you would have to rewrite your programs (or at least the user interface parts thereof). How difficult this will be would depend on the kind of programs that you have written, and how much use they make of VCL visual objects. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

2 1

Need units for delphi classes and forms
by Brian Keener 17 Apr '03

17 Apr '03

I am playing around with porting an application from Visual C++ and Delphi to GNU C++ and GNU GPC and I have a working GPC Compiler (based on a compile of the Tests in GPC). While I am no where near to having a working Makefile or truly compiled GNU GPC code for this application I have gotten as far as being able to determine that I need units for Delphi Classes and Forms. Does anyone know where I might locate these or get replacements that will work with GPC or is there some other using I need instead. Brian Keener bkeener(a)thesoftwaresource.com

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