Gpc

gpc@gnu.de

5400 discussions

unit dependencies (about GPC compiler internals)
by Igor Marnat 22 Jul '05

22 Jul '05

Hello list! I try to build big enough project (~170 units) with --autobuild option. It was built successfully before but from some time it stopped to be built. It seems to me that the problem is in a branchy dependencies between units which goes more and more complicated. Build process stops with the message 'error: module/unit `mainvar.pas' could not be compiled'. I investigated GPC sources a bit (particularly, module.c unit). As far as I got, the problem is: when it try to build mainvar.pas, it stores file name (mainvar.pas) in temporary file with label #compiling. Then the compiler goes to compile units from mainvar.pas "uses" section, some of these units in their turn uses unit mainvar (indirectly, may be). So the compiler tries to compile mainvar.pas once again a bit later and add its name (mainvar.pas) to temporary file again with #compiling label. Before every attempt it checks that the file is mentioned in the temporary file less then 2 times (by call "find_automake_tempfile_entry ("#compiling: ", fn, 2)"). When it tries to add mainvar.pas to a temporary file in a third time, it find that this file name has been already added twice to temporary file and stops building process with error mentioned above. There are the comments in compile_module function in module.c file: /* File is being compiled => avoid a cycle. This also avoids compiling one source file twice with `--autobuild'. */ /* @@@@@@ Kludge. Allow two simultaneous compilations of the same module (fjf40[57].pas), but not infinitely many (sven18[a-c].pas). The number 2 is arbitrary. */ Is it really true that number 2 is arbitrary? Should I review module dependencies or there is some other soluton (may be, change 2 to 3 :-))? May be I missed something? GPC version: "gpc version 20040516, based on gcc-3.3.2". Regards, Igor Marnat mailto:marny@rambler.ru

2 1

gcc-3.4.4
by Russell Whitaker 22 Jul '05

22 Jul '05

Hi Now that gcc-3.4.4 is out, thought I'd try it with gcc-20050331. Using gcc-3.4.3.diff, got these rejects: gcc.c.rej varasm.c.rej version.c.rej That last one I needed to patch version.c manualy so gcc would compile. After I did it, wondered if it might be beter to patch gpc instead? Since have 2 cpu's, tried "make -j3 bootstrap". The c part ran ok, it quit in the rts with an error message. "make bootstrap" & installed with no problem: Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-languages=c,c++,pascal Thread model: posix gpc version 20050331, based on gcc-3.4.4 Ran gpc's test using gcc-3.3.5 and then gcc-3.4.4, got one new fail: avo7.pas And ran the tests with "time make": gcc-3.3.5 gcc-3.4.4 ---------- ---------- real 22m24.452s 20m49.896s user 11m40.872s 10m52.583s system 10m25.648s 9m41.803s And that's it Russ

3 4

Packing strings ()
by Contestcen＠aol.com 22 Jul '05

22 Jul '05

>> In any case, we are getting off the subject, > > Finally, a word of wisdom... > >> which was how to store a set of >> varying-length strings with minimal wasted space. > > ... except that the subject of this mailing list is not "how to store > something somewhere", but "the GNU Pascal Compiler", in case you > didn't notice. Discussion of the Pascal Macro Compiler belongs to the > Pascal Macro Compiler mailing list. > > Another thing which you apparently didn't notice, although three > people already asked you to do so: please, turn off HTML in your mail. > > Emil Jerabek The subject of this thread in the GPC mailing list is how to store character strings without wasted space. Notive that the subject of this thread is "Packing strings ()" That was the subject of the original posting that started the thread. I have mentioned the Pascal Macro Compiler because it comes with macros that have the ability to pack strings without wasted space. That is the original question, and this is an appropriate answer to the question. I have not discussed the Pascal Macro Compiler in any other context except to answer the question in this thread. I have gone to great lengths to avoid creating any HTML in my postings to this mailing list. To avoid HTML-style quoting, I am copying the postings myself, and inserting all of those greater-than signs by hand. I have avoided putting in any links because I have not found a way to suppress the anchor tags. I have not done any form of text emphasis other than using caps, used no colors, inserted no pictures or backgrounds, and given no email links. I don't see what I am doing that makes you see HTML in my posts. I can't see any signs of HTML in these emails, other than line breaks, which are already in the emails when I receive them from the mailing list. If I manually removed the line breaks, then the gt-signs would no longer be along the left edge, but interspersed in the text. I don't think that would be desirable. I have tried to stick to the subject, but other people have been attacking my postings for all sorts of reasons that I believe are tangential at best, such as the use of text compression, hashing, trees and linked lists. I have tried to point out that these are separate issues, but I get attacked again when I do that. I am starting to wonder if this isn't some kind of hazing for the new guy, and if I want to join this fraternity then I have to undergo this ritual. Or maybe you are just testing me to see if I am worthy to be in this august company. Frank Rubin

6 5

Re: New as function
by Peter N Lewis 22 Jul '05

22 Jul '05

> > If I want to allocate memory, but handle it gracefully if it fails, > > what are the recommended approaches? > >You could call GetMemPtr directly (with all the drawbacks of using >GetMem vs. New, as you know), or install your own allocator >(wrapper) which returns `UndocumentedReturnNil' (as, e.g. BPGetMem >in the System unit does). As the name indicates, this was really a >quick kludge, added to support this BP compatibility unit ... Sounds ugly. Does this mean the compiler actually does cope with New returning nil? Ie, it wont call Initialize? >I don't think we have a really nice way to do it ATM. Is there (or perhaps should there be) a way to disable the run time error temporarily and manage to return New with a nil value? If the compiler already copes with New potentially returning nil, then presumably all it would need would be a flag to heap.pas to return nil without a runtime error? It looks like heap.pas would need to be a little more careful with how it copes with nil (for example, currently AddToMarkList and AddHeapRange would be called if GetMemPtr^ was allowed to return nil without generating a runtime error. New( s, 10 ); if s <> nil then is much cleaner than s := GetMemPtr^( SizeOf(String(10)) ); if s <> nil then begin Initialize(s^); I presume the two sequences of code would be equivalent if the runtime error in New was avoided and returned nil instead. I'm happy to add support for a flag in heap.pas if that is desired, assuming that it wont have any affect on the compiler and the compiler already does handle the New returning nil case. Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

Mac OS X Pascal Interfaces
by Adriaan van Os 21 Jul '05

21 Jul '05

The latest version of the Mac OS X Pascal Interfaces <http://www.microbizz.nl/GPCInterfacesF.tar.gz> can be downloaded from <http://www.microbizz.nl/gpc.html>. Detailed release notes are included with the package, a summary is given below. Most important news is that compatible interfaces for FPC have been added. I have to thank Peter N. Lewis and Gale Paeper for the effort they put in this new release and Olle Raab for his help in creating the FPC interfaces. Regards, Adriaan van Os

1 0

Strings and Char Arrays
by Contestcen＠aol.com 21 Jul '05

21 Jul '05

> This SHOULD NOT work in BP or any flavor of Pascal, any more than the > following should work: > > const Digit: array[0..255] of 0..9 = 123456789101112; > > A string is a different data type than an array of char, with a lot of > different methods. > > I am surprised tht BP identifies short arrays of char with short strings. > > Would (and should) this work? > > program foo; > > var ch1, ch2, ch3: array[1..100] of char; > > begin > ch1 := '123'; > ch2 := '456'; > ch3 := ch1+ch2; (* or ch3 := Concat(ch1, ch2); *) >Writeln(ch3, ' ', Length(ch3)); > end. > > I say absolutely not. HF I tried this, and it does not compile. The Borland compiler will not allow ch1 := '123'; Assigning a string value to a character array is a shortcut for initializing character arrays so that you don't have to write Const ch: array[1..100] of char = ('H', 'e', 'l', 'l', 'o'); Instead you can write Const ch: array[1..100] of char = 'Hello'; However this works only in Const clauses, and only when the size of the array elements is less than 256 characters. If you need to initialize a character array greater than 255 chars in BP, you can resort to using absolute. For example Const ch1: array[1..5,1..100] of char = ('First 100 chars', 'Second 100 chars', ..., 'Last 100 chars'); Var ch: array[1..500] of char absolute ch1; Frank Rubin

3 2

Packing strings ()
by Contestcen＠aol.com 20 Jul '05

20 Jul '05

>> Making a perfect hash requires 7 additional tables, 3 independent hashes of >> the string, 3 tables to convert the hash values into summands, and one table to >> convert the sums into pointers to the strings. (There is a trick that can >> reduce this to 5 tables, but it makes the first hashing round slower.) > > Any references for these claims? > > gperf needs only one additional table. It doesn't need several > "hashing rounds", only one very short hash function. Did you > actually look at it (or comparable programs)? First, let me clarify some terms. There are two properties of hash functions involved here. The first is that every keyword hashes to a different value. This is called "collision-free" hashing, or "single-probe" hashing. The second property is that hash function for the N keywords is into a set of N things (such as N pointers, or the integers from 0 to N-1). This is called "minimal" hashing. If the hash function is both collision-free and minimal, then it is called "perfect." Apparently, perfect hashing is so hard to achieve in practice that the terms have become debased, and people are now calling a hash "perfect" if it possesses only the first of the two properties. When I made my statement about 5 or 7 tables, I had in mind my own implementation of perfect hashing (in the stricter sense). I invented this many years ago, possibly as early as 1980, but immediately (the next day, in fact) discovered that I was 2 or 3 years too late. It had already been published, I think in CACM. However, I do not have the reference. It is the only method I know to achieve (true) perfect hashing with large and diffcult keyword sets. I looked up the gperf program, and found that it satisfies the first property most of the time, except for large sets of keywords, and the second property rarely, only for small keyword sets. So, from my perspective, it does not achieve perfect hashing. Also, it appears to use 3 tables, not 1. In any case, we are getting off the subject, which was how to store a set of varying-length strings with minimal wasted space. The method that I suggested, using the Pascal Macro Compiler, uses no wasted space at all. I mentioned that an additional advantage is that its pointer table or index table could be arranged to provide O(log N) time searching without using any additional tables or space. The fact that this is not the fastest search method is beyond the scope of this discussion. If a practical method for searching the table in minimal time is required, then a self-expanding hash function would be a more suitable solution, since these can be built during runtime in linear time, with moderate wasted space. Frank Rubin

4 4

Re: Packed strings
by Frank Heckenbach 20 Jul '05

20 Jul '05

Contestcen(a)aol.com wrote: > Yes, it is getting boring repeating that storage management and data access > are independent issues. No, they aren't. > I can't think of any standard access method where the > choice of any standard storage management technique adds more than a single > table reference to the process of retrieving a string. Which is already one thing that you may or may not save. I mentioned alignment several times. > I am starting to think that there is some problem in terminology that is > keeping us from agreeing on this point. Maybe, if you can give me an example of a > standard access method, and two different storage management methods that > have a large difference in how long it takes to retrieve a keyword, then that > might reveal some difference in our language or in our assumptions. ad 1, you might want to string in a tree structure, or a pointer. That's one access and a pointer more to store. ad 2, if the string is unaligned, you have to copy it before you can use it, which I think is a substantial difference, both in time and in (code) size. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Re: Array elements as control variables
by Frank Heckenbach 20 Jul '05

20 Jul '05

Contestcen(a)aol.com wrote: > >> Using array elements as control variables is very useful when you want the > >> ability to stop a deeply nested loop, checkpoint the program, and then > resume > >> the execution from the same point later. I would not like to see this > >> capability removed. > > > > As first glance, since only constant indices are allowed, it would > > seem to be equivalent to using a1, a2, ... instead of a[1], a[2], or > > am I missing something? > > > > Can you give an example for the situation you describe? > > The essential difference between using a1, a2, ... and a[1], a[2], ... is > that I can write loops that do something useful with the a[i] elements. For > example, suppose that I have the statements > > if KeyPressed > then begin > CheckPoint (depth); > exit; > end; > > located at various places in a deeply nested loop. Here depth indicates how > deep in the nest the checkpoint was taken. Now I can put the following inside > the CheckPoint procedure. > > for n := 1 to depth do > writeln (checkfile, a[n]); > > This will write out all of the known control variable values. The restart > procedure can do this > > depth := 0; > while not eof(checkfile) do begin > depth := depth + 1; > readln (checkfile, start[depth]); > end; > for n := depth+1 to maxdepth do > start[n] := 1; {or whatever the lower value is} > > Then in each loop in the nest the control variable can be tested like this > > for a[10] := 1 to max[10] do begin > eq := true; > for n := 1 to 9 do > if a[n] <> start[n] > then eq := false; > if eq and (a[10] < start[10]) > then continue; > ... > end; > > If you did not have the ability to use array elements as control variables, > then the previous code would have to be the verbose > > for a10 := 1 to max10 do begin > if (a1 = start[1]) and (a2 = start[2]) and (a3 = start[3]) and (a4 = > start[4]) and (a5 = start[5]) and (a6 = start[6]) > and (a7 = start[7]) and (a8 = start[8]) and (a9 = start[9]) and (a10 < > start[10]) > then continue; > end; > > Yes, it can be done, but I much prefer the loop version to the last version. Can't you use a macro processor to generate the verbose code? ;-) Anyway, I see that this is an example, at least in theory. However, I'd probably do it differently in practice. I think this is more efficient, since you don't need any comparisons, and in particular no extra code in the innermost loop which is the most time-critical. If you need the original start values afterwards, copy the array before the first loop, of course. for a1 := start[1] to max[1] do begin for a2 := start[2] to max[2] do begin for a3 := start[3] to max[3] do begin ... end; start[3] := 1 end; start[2] := 1 end; Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Packing strings ()
by Contestcen＠aol.com 20 Jul '05

20 Jul '05

>>> This assumes that you know precisely what the compiler is doing with >>> your macros, and that compiler optimisations do not achieve better >>> results than what you have hand-coded. [The Chief] >> >> This may be true for executable code generated by the Pascal Macro Compiler, >> but it is not true for the data declarations that are generated for the packed >> strings. There is no executable code involved, so the compiler has nothing >> to optimize. [Rubin] > > Yes -- if you only store the data and never access them. > > Most people actually want to use the data they store. And the layout > of the data can easily affect the code necessary to access it, both > in speed and size. [Hockenbach] The Pascal Macro Compiler could certainly generate code for accessing the strings, however the Keyword String macros do not generate access code; they generate data structures. These structures are well-suited for access by hash functions, hash trees, binary trees, heap search, or binary search. The normal code and tables for these methods will work with minimal, or no, complications. In the last two cases, no extra storage or structures are needed. Frank Rubin

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc