Gpc

gpc@gnu.de

5400 discussions

Re: Two GNU Pascal ideas
by Frank Heckenbach 13 May '99

13 May '99

Dr A A Olowofoyeku wrote: > Peter Gerwinski <peter(a)gerwinski.de> wrote: > > > > Sounds mostly okay - except that with Win32, a DLL does not need to > > > have the extension '.dll' (for example, Win32 device drivers are just > > > DLLs with the same interface, and with the extension '.drv' ). A > > > Win32 DLL can have any extension, or no extension at all. Thus it > > > might be that the extension will need to be specified. On the other > > > hand, I suppose that perhaps GPC can presume the extension '.dll' > > > unless another extension is suppled. However, how do you then deal > > > with a case where someone has written a DLL but does not want to give > > > it any extension? > > > > Let GPC first search for the name 'foo' as given, second for > > 'foo.dll' or 'libfoo.so' (depending on the OS) and last for > > 'libfoo.a'. > > Perhaps we are talking at cross-purposes here! The Win32 problem > will occur not a compile or link time, but at runtime, when the > program is trying to link to the DLL. I am not sure whose job it is > to search for the DLL at this point - whether it is the compiler's > job or the OS (I suspect that it is the job of the OS which should > then raise an exception if it cannot find the DLL). Indeed, it's not the compiler that searches for the libraries, but the (static or dynamic) linker. As it is now, `{$L filename.ext}' will: - pass `filename.ext' to the linker, if `.ext' is a known linker extension, currently `.o', `.a', `.so', `.lnk', - pass `-l filename' to the linker if `.ext' is missing. The linker will then search for a (static or dynamic) library called `filename' with the appropriate extension (i.e., `.a' for static and `.so' for dynamic libraries -- I suppose the windoze linker will search for `.dll' rather than `.so'), - pass a filename with any other extension to the compiler (with automake). The most common case here is `.c' to compile and link C code. So, this mechanism currently does not allow arbitrary linker extensions. We could turn it around, so that only known source extensions (`.pas', `.p', `.c', `.cc', `.i', `.S', perhaps `.f' (Fortran?) etc.) are passed to the compiler, and all other extensions to the linker. This would then only prevent a linker file with a source extension (but who would want to give a binary such an extension ;-), and without an extension (because that's reserved for `-l'). If the latter is a real issue, we might have to change the syntax for the second case (`{$L foo}' -> `-l foo'), which I'd consider unfortunate, since it's the most common one besides `{$L foo.c}'. BTW, using `-l foo' (or `{$L foo}' or later "external 'foo'") is preferable over `foo.a' (or `{$L foo.a}', or "external 'foo.dll'", etc.) for several reasons: `-l' will search the library path (`-L'), will find static or dynamic libraries, taking into account the `-static' switch, and can use the appropriate extensions (e.g. `.so' or `.dll'). Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Two GNU Pascal ideas
by Frank Heckenbach 13 May '99

13 May '99

Dr A A Olowofoyeku wrote: > > Instead of "Foobar" for an identifier `FooBar' declared in a > > unit/module `Baz', we could probably use `baz.foobar' (or > > `baz$foobar'), all lower-case, without risking name clashes with the > > libc. > > Since such routines should be calleable from programs with the > declaration "baz.foobar", it might be that the dot notation would be > preferable to the "$" notation (but of course, it might not make any > difference to the compiler which notation is used internally). Indeed, these two things are not bound to each other. In Pascal, it will be calleable as `baz.foobar' in any case (required by Extended Pascal and Borland Pascal, and the only reasonable thing, anyway, since `$' already has a different meaning in BP and GPC). > > For the external declarations, my suggestions is: > > Procedure Foo; external; (* extern void foo ( void ); *) > > > > (I.e., `external' will convert the name to lower-case, without the > > module name prefix.) > > > > Procedure FooBar; external name 'FooBar'; (* extern void FooBar ( void ); *) > > > > I've heard Delphi has something like this (`external' and `name'). > > Is it the same syntax, or what does it look like in Delphi? > > Delphi has the same notation, with the same syntax as above, used in > the context of *importing* routines from dynamic link libraries > (DLLs). Normally the DLL's name will be in-between "external" and > "name" -e.g., > > Procedure FooBar; external 'barfoo.dll' name 'FooBar'; I think we could do the same, with the 'barfoo.dll' being optional (is it optional in Delphi as well?). If it's omitted, the compiler will assume the library or object file which contains the routine to be linked by other means (e.g., other `external' statements, `{$L barfoo}' directives, or on the command line). Furthermore, I think we should drop the `.dll', i.e. just have external 'barfoo', to link `barfoo.dll' on Win32, and `barfoo.so' on Unix, or `barfoo.a' on any system. IOW, it's equivalent to `{$L barfoo}'. Also, we should allow "external 'foo.o'" to link an object file,', "external 'foo.c'" for C files etc. (which is also completely equivalent to the `{$L}' directive). > A slightly similar notation also exists for *exporting* routines from > DLLs, in which case it has to be used in a separate "EXPORTS" section > at the end of the DLL source (instead of the point where the function > is declared) - e.g., > > Library barfoo; > > Procedure foobar; > Begin > // blah, blah > End; > > Function foofoo : integer; > Begin > Result := -22; > End; > > EXPORTS > foobar name 'FooBar', > foofoo index 1 name 'FooFOO'; // index is optional > > Begin > End. > > I am not sure if (and if so, how) these should be supported by GPC. I think there should be some way to declare libraries in GPC, but we haven't made any design plans for them yet. Also I suppose they'll not be implemented too soon, since there are more urgent things to do, and it's possible (already now) to build libraries with a little bit of extra work, i.e. declare the public routines with `asmname' (later perhaps `name') directives, compile them with `-c', and build a library of them (with `ar' for static libraries and `gpc -shared' for dynamic ones). The problem I see with the syntax above is that the external name declaration is at the end. I doubt whether GPC can could with that well since AFAIK it expects to know the external name when it compiles a routine. Perhaps it could use a temporary name while compiling the routine, and declare the real external name as an alias of that temporary name later, but I'm not too sure if that's possible. If that's not possible, then perhaps a GPC library could look somewhat like a unit, i.e. library foo; interface procedure foobar; name 'FooBar'; implementation procedure foobar; begin end; end. This would not be so much different from what we have already, and therefore probably be easier to realize. > Note: > Identifiers exported in this way are case-sensitive when you want > to import the DLL functions with the "name" declaration. This is not > a Delphi thing but a Win32 thing, so GPC does not need to (and > probably should not) seek to copy that behaviour. `asmname' currently is case-sensitive, and so will `name' be. In order to interface to C code, we don't actually have another choice, because C identifiers are case-sensitive. > In any case, AFAIK, > DLLs are only relevant to OS/2 and Win32, so this may not be an issue > of serious concern. They're only called "DLL" on OS/2 and Win32, but dynamic libraries exist on any platform I know except DJGPP (and perhaps EMX for Dos?). Besides, I don't think we should make a distinction between static and dynamic libraries as far as the program directives are concerned, i.e. let "external 'foobar'" link foobar.dll, foobar.so or foobar.a, whichever is appropriate for the target system and exists (see above). In fact, one can (already now) use the `-static' switch to link the static versions of all libraries rather than the dynamic ones, without changing anything in the source. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 4

Linking problems
by Peter Gerwinski 13 May '99

13 May '99

Hi, folks! Any linker experts out there? When I `ar' together a bulk of `.o' files compiled with GPC, I get lots of undefined references between the `.o's in the `.a'. The same compilation with `--autobuild' works. Any ideas what I am doing wrong? Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 1

Re: integration of GPC into EGCS
by David Edelsohn 13 May '99

13 May '99

>>>>> Peter Gerwinski writes: Peter> This task involves changes to the EGCS backend which must Peter> be coordinated with the other EGCS developers. In earlier Peter> cases our very small suggestions were not accepted, so I do Peter> not really expect our major requirements to make it into the Peter> EGCS main line. The issue is whether something you need changed is the right way to accomodate that feature. We are trying to support all languages and compromise will be necessary. Given the broad, portable use of the compiler and common backend, changes need to be general where appropriate and consistent with maintainability. I have not seen all of the GPC changes, so I am not implying anything about their quality or correctness, just commenting on the broader goals that need to be achieved as part of incorporating GPC. David

1 0

Re: integration of GPC into EGCS
by Peter Gerwinski 13 May '99

13 May '99

Alexander V. Voinov wrote: > Are there any plans to *fully* integrate GNU Pascal into the main EGCS > source tree as is done for G77? Yes. > I.e. I mean to have GPC as a true proper > subtree of egcs as g77 is, and to find it by default in all stable and > experimental versions of egcs. For example, that moment one has > egcs-1.1.2 as a standard version, adopted by RedHat et al., but GPC is > compatible only with the 1.1.1. Of course, but this also means some work - to get GPC integrated into EGCS, (This task involves changes to the EGCS backend which must be coordinated with the other EGCS developers. In earlier cases our very small suggestions were not accepted, so I do not really expect our major requirements to make it into the EGCS main line.) - to keep track with EGCS development, - not to lose support for stable releases (gcc-2.8.1, egcs-1.1.x). Due to a big lack of human resources we currently do not feel able to perform this task - although it is on our schedule. Help welcome! Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

1 0

integration of GPC into EGCS
by Alexander V. Voinov 12 May '99

12 May '99

Dear Colleagues, Are there any plans to *fully* integrate GNU Pascal into the main EGCS source tree as is done for G77? I.e. I mean to have GPC as a true proper subtree of egcs as g77 is, and to find it by default in all stable and experimental versions of egcs. For example, that moment one has egcs-1.1.2 as a standard version, adopted by RedHat et al., but GPC is compatible only with the 1.1.1. Thank you in advance Alexander

1 0

Learning Pascal
by J Horacio MG 12 May '99

12 May '99

Greetings, I'd like to learn programming, and been asking around for recommendations. A vast majority suggested to learn C and then C++, but I've also been strongly suggested starting with a "well structured language" like Pascal before anything else. I don't fully understand the meaning of this, and would like some guidance for starting with Pascal. Actually this sounds as if C was about programming, and Pascal just a step towards it. I've tried to look for documentation both online/downloadable and books, and though I've found loads for C/C++, almost nothing for Pascal. All I have is a small course (with Borland programs) in windoze for Turbo Pascal, which means I've been forced to install windoze while my OS is Debian. I'm concerned that this Turbo Pascal course may not help me with learning Pascal with GPC... may be it can help me learning the basics? I would appreciate any suggestions, tips, pointers to docs and books,... and comments to the above. Thank You in Advanced, Horacio.

2 1

Re: Two GNU Pascal ideas
by Frank Heckenbach 12 May '99

12 May '99

Peter Gerwinski wrote: > > 3. Have some extension to indicate C linkage (like C++ and > > some C compilers do). Maybe an extension or alternative > > to the EXTERNAL keyword. > > This already exists. See `info -f gpc -n "Other languages"'. > > Procedure Foo; C; (* extern void foo ( void ); *) > > Procedure FooBar; asmname 'FooBar'; (* extern void FooBar ( void ); *) I should mention that we're thinking about changing the syntax of external declarations and the internal names of Pascal identifiers soon. In order to allow the same identifier in different units/modules (which is required by both the Standard and Borland Pascal and which GPC currently doesn't support), we need to change the "name mangling", anyway. Instead of "Foobar" for an identifier `FooBar' declared in a unit/module `Baz', we could probably use `baz.foobar' (or `baz$foobar'), all lower-case, without risking name clashes with the libc. For the external declarations, my suggestions is: Procedure Foo; external; (* extern void foo ( void ); *) (I.e., `external' will convert the name to lower-case, without the module name prefix.) Procedure FooBar; external name 'FooBar'; (* extern void FooBar ( void ); *) I've heard Delphi has something like this (`external' and `name'). Is it the same syntax, or what does it look like in Delphi? BTW, we could then also have: Procedure FooBar; name 'FooBar'; begin end; to declare a Pascal procedure with a given internal name, instead of the "strange" form that is now necessary: Procedure FooBar; asmname 'FooBar'; Procedure FooBar; begin end; These are just ideas right now. Any comments? Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Interested about GNU Pascal development
by GrimReaperX 12 May '99

12 May '99

Hi, I am a 19 years old college student. I study programming. I like Linux/Unix* alot because of the open-source concept and also because these OS are highly configurable and customizable. I run RedHat 5.2 on a i386 machine (Pentium 166MhZ, 48MB ram) and If you need to traduct english-to-french or french-to-english feel free to ask me :) I can also do alpha/beta testings. This far, my teachers only showed us the basics of Pascal (Console..) and some C. But as my studies advances I will get better. In fact, I am willing to do whatever I can to help Linux/Unix*/GNU to grow. (Little anger toward microsoft....well let's rather say some hatred ;) reboot-reboot reboot) I live in Quebec, Canada. Cya soon! Pierre-Luc Vincent a.k.a. GrimReaperX grimreaperx(a)usa.net

3 3

Re: prior parameter's size depends on `foo'
by Frank Heckenbach 12 May '99

12 May '99

David James wrote: > There may well already be a provided routine to do this (return the > last i characters of a string), and if there is, I'd be grateful for > a pointer to it, but even so I think I'd still like to be able to > write similar procedures/functions. The functions `Copy' and `SubStr', when called with 2 parameters s and i, return all the characters of s starting from the i'th. The difference is that `SubStr' causes a runtime error when i < 1 or i > Length (s), while `Copy' returns the empty string then. So, to get the last i characters of s, you can use `Copy (s, Length (s) - i + 1)', or if you want to accept i > Length (s) here and get the whole string then, you could do `Copy (s, Max (1, Length (s) - i + 1))'. Peter Gerwinski wrote: > * In this example we are mixing Extended Pascal modules with > UCSD (Borland) Pascal units. EP wants `import' instead of > `uses'. > > While GPC accepts all this, it is maybe better to stick to one > flavour of modularized Pascal programming which means either > EP-style modules or UCSD-style unit, but not a mixture. He did `uses gpc;' which is correct since gpc.pas is indeed a unit (and is not available as a module). So I think it's alright to mix this unit with modules. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

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