Gpc August 2010

gpc@gnu.de

32 participants
32 discussions

Quo vadis, GPC?
by Objective Modula-2 13 Aug '10

13 Aug '10

Frank Heckenbach wrote: > since GPC development has mostly stalled, I've thought about if and > how its development could be continued. Here are my current thoughts > about it. Since the text is quite long, I put it on the web: > http://fjf.gnu.de/gpc-future.html Although I no longer use Pascal, I would like to make a plea for GNU Pascal to be sustained. Generating C (or even C++) as an alternative target is certainly a useful feature for any compiler to have but if GPC was to lose its interface to the GCC back-end, I wonder if it would still be GNU Pascal. I believe most people associate GCC back-end support with any compiler that carries the GNU moniker. Don't get me wrong, I am not a GNU fanboy nor a GCC zealot. I know that developing for the GCC back-end can be painful. Nevertheless, I believe it would be a loss for the Algol/Pascal family of languages and their users to see Pascal disappear from the list of supported languages in the GCC toolbox. It is correct that the existing code will remain available but without maintenance, GNU Pascal would eventually cease to work with the latest GCC distribution. GNU Modula-2 is now very close to its 1.0 release at which point it is expected to become part of the main GCC distribution. It would be sad to see Pascal leave the GCC party just as Modula-2 joins. It is not uncommon that a project maintainer burns out after a decade. Nobody can blame you for that. Perhaps somebody else can be found to take over the project and continue it. As for retargeting GNU Pascal, I personally would consider that a new project. How much sense it would make to reuse the GNU Pascal front end for a new compiler project to target a different back-end I am unable to say. However, I can comment on targeting the LLVM compiler infrastructure. First, some clarification. Some posters appear to be confused about what LLVM is. For example, I saw one commenter writing "I am not interested in programming in ... LLVM". The LLVM compiler infrastructure is not a programming language you would write programs in. Instead, it is a compiler-back end library that compiler developers can use to plug their compilers into thereby saving themselves the effort to write their own target specific back-ends and optimisers. Compared to using the GCC back-end, LLVM is far more straightforward. There are two ways to interface to it. You can either use the C or C++ bindings and generate your LLVM AST directly from within your own parser, or you could write a back-end for LLVM pseudo-assembly code which is actually far cleaner than C or C++. It is a typed virtual assembly language that has atomic intrinsics and trampolines and a lot of other useful things. I am currently involved in a Modula-2 compiler project that targets C and LLVM (via the LLVM pseudo-assembly language). We are using a template approach for code generation and for each AST node a corresponding C or LLVM template is populated with the details from the AST node. So far code generation has only been in an experimental stage but I can already tell you from this experimental experience that targeting LLVM is certainly far more straight forward than targeting the GCC back-end. It would certainly be nice to see a Pascal compiler targeting LLVM but as I said, this should probably be considered a new project and no longer GNU Pascal. Even with an LLVM Pascal compiler available, I still believe it would be beneficial to sustain GNU Pascal (as a Pascal compiler targeting the GCC back-end). Anyway, good luck to you and the GNU Pascal community -- Projects mentioned in this post: GNU Modula-2 (http://www.nongnu.org/gm2) LLVM Compiler Infrastructure (http://llvm.org) Objective Modula-2 (http://objective.modula2.net) Modula-2 R10 (http://www.ohloh.net/p/m2r10)

8 25

Re: D (was: Quo vadis, GPC?)
by Frank Heckenbach 13 Aug '10

13 Aug '10

Bastiaan Veelo wrote: > We have an extensive code base of Extended Pascal that is in active use > commercially, and we will continue development in many years to come. We > are using the Prospero compiler, which is still serving our needs. But, > as Prospero is Windows-only, gpc has always appeared as the most > promising escape route to portability, should we need it. Therefore I am > hoping that gpc will find its way into the future. > > I have a small contribution to the discussion. Regarding the suggestion > of turning gpc into a translator to some other language, I would suggest > considering the D programming language as the target language, instead > of C++. I have been following the development of D for many years, and > have always seen similarities between Extended Pascal and D. Off the top > of my head there are nested functions, modules, function argument > storage classes, better type safety than C++, dynamic arrays with size > information, and fast compilation (especially compared to C++). There > may be more similarities. D's template design is also much better than > C++'s, as is its approach to const-correctness and its alternative to > multiple-inheritance. D is designed to be a better language than C++, > and I think it is. I think that of modern languages D is most compatible > to the way Pascal programmers like to think (pardon the generalization) > and although its syntax is C++-inspired, D might be a good candidate to > "take over" from Pascal. If gpc would do a good job at generating > readable D code, Pascal programmers could choose to continue writing > Pascal or make the switch to D completely and be happy with it. > > Some pointers: > http://en.wikipedia.org/wiki/D_%28programming_language%29 > http://www.digitalmars.com/d/ As for the main features as listed in the Wikipedia article: - some are mainly library issues or can be addressed as such, including associative and dynamic arrays (e.g. map and vector in STL) or array slicing (not sure if STL currently provides this, but it could), - some of the mentioned improvements actually exist in C++ such as inner classes and the previously mentioned STL types, - some things will be addressed in the planned C++0x standard (http://en.wikipedia.org/wiki/C%2B%2B0x), e.g. foreach-like loops, better metaprogamming including compile-time function execution, and anonymous functions, including nested ones and closures, - some things I don't necessarily see as advantages for our purposes, e.g. automatic gargabe collection (on a (Pascal) language level, I think we should leave the choice to the user), or limited multiple inheritance (though I hardly need the full version myself, but if we choose to implement just the limited form, we can do it equally well in C++ and D, since it's a strict subset of the full version; but if we, now or later, decide we want the full form in some object model, C++ has it), - for some things the description there is too vague, e.g. "reengineered template syntax" (the example doesn't tell me much -- however, if it's only about syntax, it doesn't matter much for a target language anyway) or the inline assembler (g++ has one, I have no idea if D's is better or worse -- mostly likely it won't be (CPU-)portable (quite hard for assembler code ;-), and apart from that, I see no major drawbacks in the g++ inline assembler (same as that in gcc and gpc), except maybe from syntax (irrelevant, see above); in particular it cooperates well with the optimizer which is not true of many other inline assemblers I've seen, in particular BP's, even for that tiny bit of optimization that BP has), - so only a few things are left that are clearly advantages in my view, e.g. true modules and first class arrays. (Though modules are not such a big issue for a compiler-converter either; converting to C++ style "compilation units" and headers is not much more difficult, and the more tricky part -- processing modules in the correct order WRT dependencies -- has to be done in the frontend anyway; this is what "gp" currently does which could partly be reused as well.) But most importantly of all (IMHO), D doesn't seem very widespread. Maybe this will change. However, since one root of our problems is really that Pascal isn't so widespread (anymore), I'm reluctant to base its renewal on another language whose long-time future is also in doubt AFAICS. Honestly, if I had to bet on the futue of D vs. C++0x, I'd take the latter, even if it's still in the standardization process, just because of the mass of existing C++ code and compilers. (And even if C++0x fails, the fallback to the existing C++ standard is soft, whereas a failure of D a few years from now when we have based our new compiler on it would be fatal.) Of course, for manually (or semi-automatically) converting your Pascal programs to another language if GPC has no future, D might be a good choice. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

13 48

Backspace on a Mac with GPC doesn't work - why?
by Tom Schneider 13 Aug '10

13 Aug '10

Here's a puzzle in the from of a program. Regards to all! Tom program inout (input,output); (* version = 1.01 of inout.p 2010 Aug 12 2010 Aug 12, 1.01: testing on Sun 2010 Aug 12, 1.00: origin on mac Thomas D. Schneider, Ph.D. National Institutes of Health Gene Regulation and Chromosome Biology Laboratory schneidt(a)mail.nih.gov http://alum.mit.edu/www/toms (permanent) Test input string in GPC. The program reads one character from the user at a time. If the user types the wrong character and wishes to correct it, then they should be able to type control-H (^H) or delete and correct the input. This works with GPC on a Sun computer, but on a Mac OSX (10.6.2) one instead sees '^H' and no backspace occurs. What can be done at compile time to make backspace work on the Mac? ******************************************************************************** On a Sun computer: % inout h the character was h u the character was u b the character was b z the character was z a the character was a b the character was b q the character was q Backspace (control-H) and delete work as expected. On a Mac: % inout a the character was a abcd the character was a abcd^H^H^H^H^H^H^H^H control H or delete gives same^H^H^H the character was a q the character was q Backspace (control-H) and delete do not work. *) var n: char; (* a character from the user *) begin n := ' '; while (n <> 'q') do begin readln(input, n); writeln(output, 'the character was ',n); end; end.

2 3

Pascal for Python extensions
by Andrew Gregory 13 Aug '10

13 Aug '10

I've been following the debate with some interest - although I'm no expert on compilers. My work involves a lot of data processing, for which I use Python scripts from which I can call functions coded in Pascal (and other languages). The interfacing works as follows: Pascal modules are linked statically to some C interface code (which converts Python objects to/ from C types). The C interface code is compiled to Python compatible DLLs, which can be imported directly into Python. I'm sure there are other ways to achieve the same end (and it would be nicer to be able to do the conversion to/from Python objects in Pascal) - but it works. I use the MinGW compiler to compile my code. The extensions work with the standard (MSVC) Python distribution. As long as there is a straightforward means of creating Python binary extensions from Pascal source code I'll be happy - but since Python is written in C the C++ solution sounds more promising, so I will vote for that. Andrew. http://www.npl.co.uk/materials/ http://www.npl.co.uk/electromagnetic/ ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY -------------------------------------------------------------------

3 3

Re: "hello world" causes Linux assember errors
by Morton, John 12 Aug '10

12 Aug '10

First, everything in this message occurred while logged in as "root". I think I've installed the compiler properly but the assembler always reports errors for "push" and "pop". Sample messages and the results when compiling with the -v option can be found below. The platform is a HP xw8200 (Xeon) machine running 64 bit Red Hat Enterprise Linux Desktop, probably release 5.2. On this system "uname -a" produces: Linux lxstn08 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux gcc was not installed on this system when gpc was loaded. Using the web page instructions for binaries at http://www.gnu-pascal.de/binary/ I installed the "gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz" file into the standard location. After gpc was installed "man gpc" worked and "gpc -v" says: gpc version 2.1 (20020510), based on 2.95.2 19991024 (release). So far so good. Now the problem: Compiling the absolute minimum version of "hello.pas" (1 writeln statement) produced ~15 assember error messages, a mixture of: Error: suffix or operands invalid for "push" (and/or) Error: suffix or operands invalid for "pop" messages with about 4 times more "push" than "pop" messages. Any ideas about how to fix this problem? BTW, Although a 64 bit executable would be much preferred a 32 bit target that can run under 64 bit RHEL would also work for us. ----- BACKGROUND INFO For safety, security, and configuration control reasons changing the RHEL components is not allowed. But installing applications (e.g. gpc, vnc, Open Office) that do not affect the O/S is OK. "man as" says that binutils contains the portable Gnu assember. My first thought was a 64/32 bit word length mismatch in a library, the compiler or the assembler. The "yum" results are at the end of this message. Using the "-v" option produces (with <CR>s inserted for clarity): # gpc -v hello.pas Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 2.1 (20020510), based on 2.95.2 19991024 (release) /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpcpp -lang-pascal -v -famtmpfile=/tmp/ccL8ikKt -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2.1 -D__GPC_RELEASE__=20020510 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ hello.p /tmp/cc3waT7h.i GNU Pascal Compiler PreProcessor version 2.1 (20020510), based on gcc-2.95.2 19991024 (release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/i686-pc-linux-gnu/include /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include /usr/include End of search list. /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 /tmp/cc3waT7h.i -quiet -dumpbase hello.pas -version -famtmpfile=/tmp/ccL8ikKt -o /tmp/cc3waT7h.s GNU Pascal version 2.95.2 19991024 (release) (i686-pc-linux-gnu) compiled by GNU C version 3.3.3. GNU Pascal version is actually 2.1 (20020510), based on gcc-2.95.2 19991024 (release) as -V -Qy -o /tmp/cc3waT7h1.o /tmp/cc3waT7h.s GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020 /tmp/cc3waT7h.s: Assembler messages: /tmp/cc3waT7h.s:14: Error: suffix or operands invalid for `push' /tmp/cc3waT7h.s:18: Error: suffix or operands invalid for `push' ... (about ~14 more "pop" and "push" error messages) --- The man page for "as(1)" does not list the options -V or -Qy (used above). Also odd is that the "/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2" folder contains "collect2" instead of "collect" - and that the file "/lib/crt[01n].o" does not exist on this system (or is the "gpc" man page out of date?). I have downloaded but not installed the "gcc-core-2.95.2.tar.gz" compiler (from http://www.gnu-pascal.de/stable/). As suggested by the mailing list archives I have also downloaded a newer version of gpc and gcc from http://alignment.hep.brandeis.edu/Software/Pascal/Index.html (by using the "Linux binary", "GCC 3.4.6" and "GPC 20070904" links on that page). I then untarred gcc 3.4.6 into it's normal location (but "man gcc" and "gcc" still do not work). I have not yet tried installing the newer version of gpc. yum reports the following packages as installed: binutils.x86_64 2.17.50.0.06-12.el5 (missing i386 version?) glibc.i686 2.5-42 (instead of i386 version?) glibc.x86_64 2.5-42 glibc-common.x86_64 2.5-42 libgcc.i386 4.1.2-46.el5 (i686 version needed?) libgcc.x86_64 4.1.2-46.el5 <EOM>

1 0

Re: Vector arithmetic
by Contestcen＠aol.com 11 Aug '10

11 Aug '10

When I first started using FPC, I went through the manuals looking for useful features. I came across both open arrays and dynamic arrays, and thought that they might be valuable. But nowhere could I find any notation for the second, third ... dimension of the array. Without that, open and dynamic arrays were little more than curiosities, possibly useful for 1-dimensional array, but not beyond. Now I see from your email that the notation for the second dimension of an array is Length(xarray[i]) where i is any valid index value (and hence can always be 0). By extension, the third dimension presumably would be Length(xarray[0,0]), and so forth. Never, ever, would I have guessed that would work. It makes sense mathematically, but notationally I would have expected something like Length(xarray,2) for the second dimension. If I had thought of Length(xarray[0]), I would have deemed it so implausible that I never would have tried it. But simply because this is feasible does not mean that one should use it. For one thing, I would like the compiler to generate warning messages if I try to add two matrices of incompatible sizes. I don't want to discover this hours into a computation. That type of checking is one of the main virtues of Pascal. For another, it requires that I code a SetLength statement for every array. That means the array information becomes decentralized. I can't just read down the VAR section of my procedure and learn what I need about the variables, I must consult two sections. Of course I wouldn't have to make every array open, but then I would have a mixture of two kinds of array declarations. This creates an extra maintenance task, making some arrays open, when needed, and restoring them to fixed size when they no longer need to be open. The problem could become fierce when the same declarations are shared by several different procedures. Which one should set the length? How can I be sure the length is set before I reach MyProc? So, once again, I throw my support towards adding vector operations to the compiler. Frank Rubin In a message dated 8/6/2010 12:23:25 P.M. Eastern Daylight Time, harley(a)umich.edu writes: Dear Frank Rubin, "Except that you have to code every single case separately, 2x6, 3x10, 4x4x4, etc. You need to write a separate routine for every shape of array you want to use." Not so: Use open arrays (always 0-based): type Matrix = array of array of TRing; Youu can write code, roughly: operator * (const A, B: Matrix): Matrix; var RowA, ColA, RowB, ColB, I, J, K: Integer; T: TRing; begin RowA := Length(A); ... ColB := Length(B[0]); if ColA <> RowB then ... SetLength(Result, RowA); for J := 0 to RowA - 1 do SetLength(Result[J], ColB); for I := 0 to RowA - 1 do for K := 0 to ColB - 1 do begin T := Zero; // prefer just 0 for J := 0 to ColA - 1 do T := T + A[I, J]*B[J, K]; Result[I, K] := T; end; end; once and for all, covering all sizes of matrices. The problem I do not yet know how to solve: to do it for all TRing. So I need a type TRing that can include any structure that has + and * operators, and a 0 element: Integers, Floats, Rationals, Gaussian Integers, Polynomials with xxx coefficients,... any possible data type I can define with overloaded +, *, etc. Note that 0 is a problem in itself -- one really needs to overload it too! Frank Heckenbach's first reply to me may contain the answer. I haven't completely digested it yet. Cheers, Harley

3 4

Re: Vector arithmetic
by Contestcen＠aol.com 10 Aug '10

10 Aug '10

> Do not built things into the compiler (or ask for them) that can be > done outside of it. Building in things is many times as much work. > Maybe I haven't stressed this enough so far because it's so obvious > to me, but not to those who haven't worked in the compiler. I understand, but the balance changes when 10 people, or 100 or 1000 people need to do the same thing. Which is more work, a compiler writer making a hard change, or 100 people each writing a set of relatively straightforward code? That's why we try to identify features that will be widely used, such as vector arithmetic. FPC already supports assignments of vectors and arrays, so why not addition and subtraction? It builds on a capability that the compiler already has. Frank Rubin

3 2

Re: Vector arithmetic
by Contestcen＠aol.com 09 Aug '10

09 Aug '10

(Oops, I hit Send before I hit the control that removes the HTML tags. Please excuse the error. Here is the cleansed message.) I see. How would that work? Can you give me an example of a routine that would, for example, add arrays of long integers and could handle the 3 cases that I mentioned? Would it also handle arrays of bytes? arrays of words? arrays of reals? Would I need to repeat the same for multiplication? for xor? for string concatenation? for modular arithmetic? for 96-bit arithmetic? for quaternions? for division rings? A general vector facility would be a great work saver, even if it did nothing regarding parallel execution. In a message dated 8/6/2010 3:16:27 A.M. Eastern Daylight Time, felipemonteiro.carvalho(a)gmail.com writes: On Fri, Aug 6, 2010 at 8:35 AM, <Contestcen(a)aol.com> wrote: > Except that you have to code every single case separately, 2x6, 3x10, > 4x4x4, etc. You need to write a separate routine for every shape of array you > want to use. Or you could use dynamic arrays instead of static ones. Then you can write only one case. -- Felipe Monteiro de Carvalho

1 0

Re: Vector arithmetic
by Contestcen＠aol.com 09 Aug '10

09 Aug '10

I see. How would that work? Can you give me an example of a routine that would, for example, add arrays of long integers and could handle the 3 cases that I mentioned? Would it also handle arrays of bytes? arrays of words? arrays of reals? Would I need to repeat the same for multiplication? for xor? for string concatenation? for modular arithmetic? for 96-bit arithmetic? for quaternions? for division rings? A general vector facility would be a great work saver, even if it did nothing regarding parallel execution. In a message dated 8/6/2010 3:16:27 A.M. Eastern Daylight Time, felipemonteiro.carvalho(a)gmail.com writes: On Fri, Aug 6, 2010 at 8:35 AM, <Contestcen(a)aol.com> wrote: > Except that you have to code every single case separately, 2x6, 3x10, > 4x4x4, etc. You need to write a separate routine for every shape of array you > want to use. Or you could use dynamic arrays instead of static ones. Then you can write only one case. -- Felipe Monteiro de Carvalho

1 0

Vector arithmetic
by Contestcen＠aol.com 08 Aug '10

08 Aug '10

> For your information: that already exists in FPC. It's called operator overloading: > > http://www.freepascal.org/docs-html/ref/refch12.html#x161-16800012 > > -- > Felipe Monteiro de Carvalho Except that you have to code every single case separately, 2x6, 3x10, 4x4x4, etc. You need to write a separate routine for every shape of array you want to use. Frank Rubin

4 3

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 August 2010