Gpc July 2010

gpc@gnu.de

27 participants
11 discussions

Inefficiency of `mod'
by Emil Jerabek 25 Oct '10

25 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

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

Quo vadis, GPC?
by Frank Heckenbach 06 Aug '10

06 Aug '10

Hi everybody, 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 As I write there, I don't see much future in the current way of developing GPC, but also alternative development models will not be a task for a single person. In other words, without some new contributors, there is probably no chance for GPC development to continue. I don't really know how many of you currently use GPC, and to what extent and in which ways, e.g., do you use it just to maintain some legacy code, or are you actively writing new applications? So in order to tell whether continuing GPC development is worthwhile, I'd like to know who of you would actually care about major new features in GPC (as opposed to just preserving the status quo), and who would be interested not only in using GPC, but also supporting its continued development, either by actively contributing to it, or -- perhaps in the case of companies that use GPC -- by paying for continued development. If it turns out there is no sufficient amount of interest, I'm afraid to say it's probably better to put an end to it now rather than further dragging along. (Of course, the existing GPC versions will continue to be available, and anyone who wants to can use and modify them, which the GPL already guarantees, but without prospects for the future, I would then retire from GPC development and start to rewrite my own Pascal programs in other languages.) 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

26 98

Re: Quo vadis, GPC? (Community Survey)
by Prince Riley 02 Aug '10

02 Aug '10

Hello everyone, Frank's excellent post raises several issues about GPC that have been nagging at me for quite some time. As I read his post I began to understand several of the issues from the development/maintainers standpoint. There broad range of issue and concerns surrounding the future direction of GPC needs to have some refinement to provide the user community a clearer idea of the priorities and to help summarize their ideas for the maintainers. Perhaps a well structured online survey would both encourage greater response by the user community and make those ideas and opinions more accessible. I'm willing to take on the task of designing a draft user community survey, and making it accessible. Comments on this idea would be most appreciated. Prince Riley >

2 1

Rép : Ada (was: D (was: Quo vadis,
by Pascal 31 Jul '10

31 Jul '10

Hello. My background came deeply from Pascal language before I discovered Ada which provides last modern object programming with last standard Ada 2005. Just as you mentioned them, Ada provides Pascal like range checking, exceptions, generic and more: native tasking model and much more, see http://en.wikibooks.org/wiki/Ada_Programming With my huge legacy Mac Pascal code, I got involved in Pascal to Ada translator P2Ada: http://sourceforge.net/projects/p2ada It comes with some explanations: http://p2ada.sourceforge.net/ pascada.htm It comes with ISO and Borland TurboPascal translation on NewP2Ada branch (pretty stable release http://p2ada.svn.sourceforge.net/viewvc/ p2ada/newp2ada). It comes also with Object-Pascal translation mainly coming from Delphi and FPC on ObjP2Ada branch (alpha release http:// p2ada.svn.sourceforge.net/viewvc/p2ada/objp2ada/). For translating all macro of Pascal Mac interfaces I used GPC pre- processor. At the beginning of the century I was very happy to get a Pascal compiler on Mac new OS X. Thanks to all that make GPC possible. Nowadays, as mentioned, Ada tool chain GNAT is available with GPL (http://libre.adacore.com/libre) thus I switched without forgotten why. Regards, Pascal. http://blady.pagesperso-orange.fr Le 31 juil. 10 à 06:54, gpc-owner(a)gnu.de a écrit : > De : Frank Heckenbach <ih8mj(a)fjf.gnu.de> > Date : 31 juillet 2010 06:01:17 HAEC > À : gpc(a)gnu.de > Objet : Rép : Ada (was: D (was: Quo vadis, > > > J. David Bryan wrote: > >> This raises a point of interest to me. When GPC development >> stalled, I had >> to decide whether to continue with GPC as it was, switch to >> another Pascal >> compiler, or switch languages. I have programmed in Pascal for >> thirty >> years; it was my fifth language, after BASIC, Algol 60, FORTRAN >> IV, and >> SNOBOL, and of those, it is the only one in which I have continued to >> develop new programs. This was due primarily to the existance of >> GPC, and >> especially its good support for ISO 10206. >> >> For a number of reasons, I elected to switch to Ada, as >> implemented by the >> GNU Ada compiler (GNAT). I had studied the language shortly after >> it was >> introduced in 1983 but did not use it seriously until a GCC >> version became >> available. I found the transition from Pascal to Ada to be quite >> easy, >> because many of the implementation concepts are similar. For several >> years, I've done all of my new work in Ada instead of Pascal. >> >> I would think that translating from Pascal to Ada would have some >> advantages over C++. For example, Ada inherently supports scalar >> subrange >> types and range checking. I'm not that familiar with C++, but I >> don't >> believe that subranges are supported. > > No, not directly. However, range-checks are a rather minor issue -- > for comparison, it took me a few days to implement them in GPC, > while the object models took weeks or months (I'm not sure exactly > how much work Peter and Waldek spent on them), exceptions > implemented from scratch would take weeks, and templates probably > much longer. So it's these "big things" that matter most. You might > think checked subranges are more important because they're more > fundamental (which they are), but they're just not so difficult to > implement. For the 3 big things I mentioned, I know C++ has them > already. I don't know if Ada does, perhaps you can give us some > information here, e.g., is its object model comparable to those GPC > supports or that of C++; does Ada supported exception handling and > how; does it support something like templates (IOW, how can one > implement, say, a generic list, applicable to any given type, with > strong type-checking). >

1 0

Re: OS wars (was: Quo vadis, GPC?)
by samiam＠moorecad.com 31 Jul '10

31 Jul '10

1 0

Re: Quo vadis GRX?
by twixt＠cstone.net 30 Jul '10

30 Jul '10

| At some point in time I have to wonder when people will go to use free | pascal at http://www.freepascal.org/ | | They are Delphi and turbo pascal compliant How is free pascal an improvement over gpc in terms of graphics output? I searched both the programmer's guide and the language reference guide for "graphics." I found nothing. | And lets face it, here in the states pascal usage has dropped | significantly since the the infestation of java... Perhaps your intent was to post in the "Quo vadis GPC" thread? I plea for discussions of GPC that have nothing to do with GRX be taken to that thread. Thanks. | | | | | | -----Original Message----- | From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of | twixt(a)cstone.net | Sent: Thursday, July 29, 2010 11:51 AM | To: gpc(a)gnu.de | Subject: Quo vadis GRX? | | | | I would like to use Pascal to generate images in high resolution and at | least 24 bit color depth. There are links to a GRX library, which | provides | 2d graphics, but the user manual there was last updated in 2007, which | suggests they are further behind than GPC. I don't find any grx library | in | my Debian (Lenny) list of available packages, using the search feature | within aptitude. Apparently I would have to compile GRX and then somehow | get it to work with Pascal. As a barely capable programmer, I do not | look | forward to this with glee. (BTW I am not asking for help, just making a | point.) In all the discussion about the future of GPC, I am a bit | surprised that no one seems to talk about graphics output. Did I miss | something? I do that a lot. | | How about incorporating graphics | output directly in Pascal? Is there much interest in this? It seems to | me | that it would make Pascal more attractive. It would be "like POVray | but even more powerful" as any general purpose programming language | naturally would be. Thanks for your time. | | | | | PRIVILEGED AND CONFIDENTIAL | This email transmission contains privileged and confidential information | intended only for the use of the individual or entity named above. If the | reader of the email is not the intended recipient or the employee or agent | responsible for delivering it to the intended recipient, you are hereby | notified that any use, dissemination or copying of this email transmission | is strictly prohibited by the sender. If you have received this | transmission in error, please delete the email and immediately notify the | sender via the email return address or mailto:postmaster@argushealth.com. | Thank you. | | | | |

2 1

Quo vadis GRX?
by twixt＠cstone.net 30 Jul '10

30 Jul '10

I would like to use Pascal to generate images in high resolution and at least 24 bit color depth. There are links to a GRX library, which provides 2d graphics, but the user manual there was last updated in 2007, which suggests they are further behind than GPC. I don't find any grx library in my Debian (Lenny) list of available packages, using the search feature within aptitude. Apparently I would have to compile GRX and then somehow get it to work with Pascal. As a barely capable programmer, I do not look forward to this with glee. (BTW I am not asking for help, just making a point.) In all the discussion about the future of GPC, I am a bit surprised that no one seems to talk about graphics output. Did I miss something? I do that a lot. How about incorporating graphics output directly in Pascal? Is there much interest in this? It seems to me that it would make Pascal more attractive. It would be "like POVray but even more powerful" as any general purpose programming language naturally would be. Thanks for your time.

2 1

Re: Quo vadis, GPC?
by samiam＠moorecad.com 28 Jul '10

28 Jul '10

Frank, Some brief notes on your presentation "Quo vadis, GPC" (Where is GPC going). I'd of sent it direct, but I note your email is not working. First, I also considered, and was strongly suggested, to use GCC as a backend for my compiler. I rejected this idea because, primarily, of the very tight coupling between the front and back ends of GCC. This is in contrast to the well developed intermediate code coupled systems outside of GCC. The other issue is the, frankly, hostile attitude of the GCC folks towards Pascal. Fortran and other compilers are distributed with GCC and get better support from the GCC group. I can't help but think that this comes from the C group perception of Pascal as a rival, which it used to be but is no longer. As for making GPC a front end for another compiler, I can't think of a better way to insure that GPC dies quietly. Virtually all of the "cascade" compilers, including Cfront, had severe difficulties, including becoming unnaturally coupled to one particular backend, and angering users by giving errors from the underlying compiler that the front end didn't catch. C++ became a success because Stroustrup moved quickly away from Cfront and onto a true compiler for C++. GPC started out with a big advantage due to having a high quality back end with wide implementation. However, you detail well the unseen costs of that, including a moving target back end specification, inability to write the compiler in its own language, etc. Pascal scores low as a common implementation language, but as you detail, most of this is because of a movement to interpreters and away from true compilers. Although this is stated to be "because of ease of development", I believe in large part this is a reaction to the difficulties of C/C++ development, which is directly traceable to the complexity of the language and the difficulties with debugging a language totally lacking in basic type security. I think nothing underlines this more than Anders' move to Microsoft and C#: Anders went from taking a language designed around type security (Pascal) and tearing away its type security, to taking a language designed around a lack of type security (and proud of it) C, and adding type security to that. I completely agree with your diatribe on automatic destructors. I choose automatic (and anonymous) constructors and destructors for the language Pascaline (a highly extended version of Pascal) because I believed it was necessary for the compiler to both control when, and in what order, the constructors and destructors are called. I also believe (as shown in Java and C#) that classes should be treated as code structuring constructs and NOT as "extended records", and that both static and dynamic objects have their uses. In Pascaline, classes are expressed as modules which can be instantiated, and fit within modules in program structure (programs are a series of modules which may contain classes). For more on that, I invite you to look over the Pascaline specification: http://www.standardpascal.org/standards.html I looked at templates for Pascaline, and I used your exact example to evaluate it, that is, general handlers for list structures. However, I came to the conclusion that this was also the paramount example for classes, and in fact classes are an example of a highly structured system of typing that reduces the need for the highly unstructured method offered by templates (which by the way, Wirth is on record as saying was not such a hot idea). Although I am not sure I see the sense of your basic argument (interest in GPC is falling off, so lets rewrite it). I would say it makes equal sense to simply start moving parts of GPC into its own language and away from C. If you were to write a code generator to replace the back end, in Pascal, you would both be independent of GCC and much farther along on your goal of a GPC rewritten in its own language. Cheers, Scott Moore

2 1

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