Gpc

gpc@gnu.de

5400 discussions

How important is GPC for you?
by Peter Gerwinski 17 Aug '10

17 Aug '10

Hello, everyone! Some of you might still remember me. From about 1995 to 2001 I was the main GPC developer who implemented BP-style units, objects, and other things. I am still hosting the GPC web pages, this mailing list, etc. In 1998 I started my own company (G-N-U GmbH, http://www.g-n-u.de) doing business on free software. Our product range includes professional service for GNU Pascal, developing and customizing free software, and other services. For a while, GNU Pascal was a very important tool for my company, which justified that I invested a lot of time and money into it. However, over the years more and more customers addressed me with other needs. Meanwhile, GNU Pascal has reached a point where it needs full-time attention by an experienced GPC developer for several months. 1. The GCC backend is drifting away. Even if we just want to keep the existing language alive, without aiming at extensions, we need to transplant it onto a new, long-time stable backend. 2. It is very difficult for GPC enthusiasts to join the development team, since GPC is written in C rather than Pascal. Realistically, only Waldek, Frank, and/or myself can replace the GPC backend or rewrite the GPC frontend in Pascal without breaking the compiler. However all three of us face the necessity to make a living and thus cannot afford to do that large amount of work just for fun. It needs to be funded. I suggest to concentrate our forces on problem 2 and to rewrite the GPC frontend in Pascal without any backend. This gives you, Pascal programmers using GPC, the opportunity to watch the emerging new compiler and to become a GPC developer. Once this step is completed and the new compiler can represent a Pascal program in memory, the (hopefully enlarged) GPC development team has a free choice which backend(s?) to implement. If GNU Pascal is important for you, please consider to invest into its future by funding our work on GPC. You can contact me either on this list or in private email. Encrypted mail is welcome. Please find my public key at: http://www.peter.gerwinski.de/peter-gerwinski.public-key.asc Greetings, Peter -- Dr. rer. nat. Peter Gerwinski - http://www.peter.gerwinski.de G-N-U GmbH - First Class IT Services - http://www.g-n-u.de German pages for GNU & free software - http://www.gnu.de GNU Pascal - http://www.gnu-pascal.de

10 30

Re: Quo vadis, GPC?
by Steven D'Aprano 14 Aug '10

14 Aug '10

On Sat, 14 Aug 2010 04:17:58 pm Rugxulo wrote: > Hi, > > On 8/13/10, Steven D'Aprano <steve(a)pearwood.info> wrote: > > But we're not discussing what "should be", but what *is*, > > Even if we cared enough to find out (and apparently none of us do, or > don't know who to ask), the way it *is* could change yet again by the > time we finish GPC 2015. Yes. So what? You have to consider the laws as they are *now*, not how they might be some time in the indefinite future. > Besides, like I said, what if your country > doesn't approve of such laws? Then you won't be infringing your own country's laws, and you have nothing to worry about so long as you don't distribute the software in countries where it is infringing. [...] > > and the legal > > reality is that works like P5, even without a copyright notice, > > *are* copyrighted and will remain so for the foreseeable future. > > P5 is Scott's (heavy) modification. I don't know if it's enough to > constitute a whole "new" work or just another derivative. It's a derivative. > He says his work is PD. If he is infringing the P4 copyright, he doesn't have the right to write P5 in the first place, let alone to put it into the public domain. I don't equate copyright infringement with theft, but the analogy sometimes is useful. If you steal a diamond, and put it into a ring, and then give that ring away, the recipient is still receiving stolen goods. The excuse "But Scott said I could have it" is worthless. (The excuse "but I didn't know it was stolen" *might* help, but that's not always a given, and regardless, you don't get to keep the ring.) > And > Pemberton publishes his book online for free now (though he didn't > write P4 himself, right??). That should tell you something, even if > it's not legally airtight. No, it doesn't tell you anything. "You can download this book for free" is not the same as "You can write derivative works from this" or "you can re-distribute it". These are separate rights. > (Scott says several commercial compilers > used P4 as a basis. So apparently they didn't mind!!) Scott has no credibility in my mind. The legal theories he has been promoting in this thread are beyond ridiculous, e.g. the theory that works enter the public domain if you *know about* (not even approve of, or give permission to, but merely *know*) somebody -- anybody -- giving away copies for free. > > That means > > that using such a work puts you in legal jeopardy unless you get an > > explicit licence to use it. > > Right, but who to ask? I assume Pemberton, he should know better than > any of us. But if even he didn't write it, how can we be sure who > did? Ask the author if he is the copyright holder, and if so, what rights is he willing to give. -- Steven D'Aprano

3 2

Fwd: Quo vadis, GPC?
by Rugxulo 14 Aug '10

14 Aug '10

Argh, did it again, sent to wrong address. ---------- Forwarded message ---------- Hi, On 8/13/10, Steven D'Aprano <steve_AT_pearwood_DOT_info> wrote: > > But we're not discussing what "should be", but what *is*, Even if we cared enough to find out (and apparently none of us do, or don't know who to ask), the way it *is* could change yet again by the time we finish GPC 2015. Besides, like I said, what if your country doesn't approve of such laws? It really pains me to hear that such and such is illegal (only) now or such and such a country doesn't follow this or that the U.S. is more strict, etc. Sure, if you think "all the world's U.S./Europe", it simplifies things, but it doesn't truly solve it. > and the legal > reality is that works like P5, even without a copyright notice, *are* > copyrighted and will remain so for the foreseeable future. P5 is Scott's (heavy) modification. I don't know if it's enough to constitute a whole "new" work or just another derivative. He says his work is PD. So we'd only have to worry about the "old" P4 bits. And Pemberton publishes his book online for free now (though he didn't write P4 himself, right??). That should tell you something, even if it's not legally airtight. (Scott says several commercial compilers used P4 as a basis. So apparently they didn't mind!!) > That means > that using such a work puts you in legal jeopardy unless you get an > explicit licence to use it. Right, but who to ask? I assume Pemberton, he should know better than any of us. But if even he didn't write it, how can we be sure who did? > If you, or somebody else, chooses to take that risk, then by all means > do so. Just do so with full understanding that you *are* infringing > copyright, and even if the author is happy to turn a blind eye, the > copyright holder might not be. I have no intention of screwing over anybody. But we're talking about something very small and old. Doesn't mean legal wars haven't been waged on similarly old or small stuff, but still ... it doesn't seem like it's THAT big a deal! > As for the rest of the debate... well, it's too long, too rambling, the > analogies you make are strange, and none of it really matters. Okay, so I ramble, and my analogies suck. Sue me. (Oh wait, that's not illegal.) ;-) > We're > not designing our perfect copyright law, nor are we documenting all the > crazy things people do. We're trying to help Frank decide what the > future of gpc should be. Clearly Scott (who is clearly intelligent) thinks P5 is worthwhile. Frank (also intelligent) would prefer to go another direction. That's his right. The point is that if we want a (classic / standard) Pascal written in Pascal, P5 would probably be a good starting point. Otherwise it might be better just to modify FPC to add an ISO 10206 mode.

1 0

Fwd: Quo vadis, GPC?
by Rugxulo 13 Aug '10

13 Aug '10

Bah, silly reply sent only via private mail (Gmail's fault). I'm not egotistical to expect this post to be worth anything, but here ya go anyways .... ---------- Forwarded message ---------- From: Rugxulo <rugxulo(a)gmail.com> Date: Thu, 12 Aug 2010 23:55:07 -0500 Subject: Re: Quo vadis, GPC? To: Steven D'Aprano <steve(a)pearwood.info> Hi, On 8/12/10, Steven D'Aprano <steve(a)pearwood.info> wrote: > On Fri, 13 Aug 2010 02:26:41 am Rugxulo wrote: > >> It may be true that now all work is by default copyrighted. I'm not >> even sure you can PD software in some countries (ugh). But most >> important is the original author(s)' intent. > > That is possibly the LEAST important factor. What the original author > wants doesn't matter. What matters is what the current copyright holder > thinks, and what the law says. You're right, good point, BUT copyright was never meant to be extended indefinitely. And there are a lot of crazy laws. You can't please everybody, even if you try. It's a minefield. I'm not saying you shouldn't try, but pretending that a law (standard) matters over what most people think (Borland) is naive at best. Some people support the law just because it's the law. Others follow what's good and decent. (Yes, I have an unrelated grudge, heh, stupid law changed much to my disadvantage in an extremely arbitrary way.) For example, I personally disagree that anybody but Terry Welch should've ever had the LZW patent, esp. since it was milked for twenty years AFTER he died!! Somebody please tell me how that's fair. (BTW, I hate software patents, just giving a lame example. If it doesn't help the guy who invented it, what good is it?) >> If they don't care, >> nobody else will. It's not worth arguing over their "rights" when >> they don't care anymore (or never did). > > That's simply not true. What happens when the author dies, and his heirs > inherit ownership of the copyrighted work? What happens when the compiler for the copyrighted work is no longer available? What happens when the OS it ran on is no longer available? What happens when it's no longer available for sale? What happens when the cpu it runs on is no longer mass produced? (See, I can worry too!) What happens if nobody remembers how to use it? What happens if everybody is too busy arguing legalities to appreciate the gift horse (and his mouth or whatever)? > What guarantee do you have > that they will be as easy-going with regard to copyright as the > original owner? Without a licence from the original author, this > becomes a clear and obvious case of infringement. I agree that a clear statement would be best. But if you can't get one, don't worry! No reason to assume the worst if you make a best effort to find out. BTW, many people have rescinded licenses for various things without any good reason. And they scream and yell how they are allowed to push people around. It's disgusting. "Oops, sorry, end users, we don't care about you." Big surprise. It's not the first time nor the last. > What happens if the work was written under the auspices of a university, > which in 1972 was quite happy to let the author publish without a > copyright notice, but in 2010 discover that under the terms of their > employment contract at the time, they actually own the copyright, not > the author? Gross incompetence at best, flagrant misuse of copyright at worst. Lucky for them it wasn't written in some extinct language! (How many existing, popular Pascal compilers can build P4 out-of-the-box? If it's only GPC, then I would find that highly ironic.) > Or what happens if responsibility for enforcing copyright is separate > from the creative act? You can have a situation where the left hand is > explicitly encouraging people to use copyrighted material, while the > right hand is threatening those same people for infringement. Probably a good reason that companies shouldn't get exclusive rights to all their workers' efforts. (How that's even legal is beyond me. What they do in their free time should never be owned by anyone else.) > A recent > case, where the Discovery Channel's marketing department provided > promotional material to a fan website, and the legal department then > threatened them with a lawsuit and forced the owner to hand over > ownership of the domain: Trust me, I know of plenty of similarly crazy cases. I try not to infuriate myself with too much of that. People are crazy and will do crazy things whether it makes sense or not, legal or illegal, etc. The world is broken. > Don't imagine for one second that this is unique. I've even seen cases > where the marketing department of a record label uploaded videos to > YouTube, and the legal department then made DMCA claims and had their > own videos removed. (I can't find the link right now, sorry.) I've seen lots of crazy things too. Yes, big companies are crazy, and the crazy laws that cater to them are just as bad. > I note that you made a quip: > > You know what they say about "assume". > > and then immediately go on to advise us to assume that the absence of an > explicit prohibition against copying a work is the same as permission > to copy. That's terribly irresponsible. Under copyright law, it works > the other way: in the absence of explicit permission, you are legally > required to assume the prohibition stands. Like I said, it's moot here since nobody here (except Scott) is using P4 or P5 for a compiler. BUT, if we were, I would definitely ask Steve P. (and whoever else) for some kind of reassurance. If that failed to get any response, I would not worry and proceed as normal. It's kinda funny that this comes up today. I've had a certain book in my possession for months now because the person I returned it to (so they could return it to their mother, who loaned it to me) accidentally returned it back to me (!) and yet refused to retrieve it! Am I legally bound to return what I already returned, even at my own inconvenience? If so, how fast should I send it? I already told them twice about it, and they gave me the runaround. I finally just said, "Forget it, I'll mail it directly." Had to do it myself, they weren't responsible enough to do it! (Note that this book was only $15 new, which is very small claims at best. How much is a compiler [or more specifically, P4] worth to you??) I also had some really old baseball cards I assumed for YEARS belonged to a distant family member, but that person never stayed in contact with me. (I am much younger.) I never could even confirm whose they were, much less what to do with them. I finally shipped them off to the "nearest" other relative I could find. Legally, I have no idea what I would be required to do, but I did my best to be fair (even if it took like twenty years, and note that I'm only 31, heh). So yes, I do indeed care, but often times it's worrying over nothing. If nobody complains about something you ALREADY have in your possession, why would they complain once you do something with it? (Did Pemberton's publisher care to get the original authors' explicit permission? If they didn't care, why should we? For laughs???)

3 2

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

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