February 2002 - Gpc

Re: pointers (was: gcc-3+)
by da Silva, Joe 19 Feb '02

19 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Markus Gerwinski [SMTP:markus@gerwinski.de] > Sent: Tuesday, February 19, 2002 6:10 AM > To: da Silva, Joe > Cc: 'gpc(a)gnu.de' > Subject: Re: gcc-3+ > > Hi folks, > > da Silva, Joe wrote: > > FWIW, I see the "store pointer" being what you are describing > > here as the "other pointer" (I think). It points to the real data, > > and the "reference pointers" just point to it (the "store pointer"). > > That was my idea, yes... but after re-thinking, I now found an > unintentional > side effect: This would cause the reference pointer to _always_ point to > the > data of the store pointer, even if you dispose and re-new the store; the > command sequence > > new ( store ); > ... > reference:= store; (* set reference^ to store^ *) > ... > dispose ( store ); (* set reference to nil *) > ... > new ( store ); (* set reference^ to store^ ... without a command > *) > [Joe da Silva] No, the last statement cannot result in a new assignment for the reference pointer. That's just unacceptable. That's why Frank was saying you needed "double pointers", so that you could specifically set the reference pointer to "nil" when you disposed it's corresponding store pointer. So, the subsequent "new" statement would not re-assign the reference pointer - if that's what you (ie. the programmer) want, you assign it explicitly after the "new" statement. You could also search the reference pointers when disposing a store pointer, to find out which of these are affected, but that would be inefficient (like GC;-). > > would then contain a new trap to tangle up the logic of the program. The > implicit handling of a store/reference concept doing exactly what it is > supposed to do (hooking the reference to the _data_, not to its store) > would, as Frank said, really be more complicated, I fear. > > Bye > > Markus

2 1

Re: gcc-3+
by da Silva, Joe 18 Feb '02

18 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, February 12, 2002 7:16 PM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > Russell Whitaker wrote: > > > found this at http://gcc.gnu.org/projects/ > > > > Miscellaneous ideas: > > > > Chill should use garbage collection. > > > > Convert the Chill front end to use garbage collection instead of > > obstacks, so that it can work again with current GCC. > > > > Suspect this should apply to gpc as well. > > Indeed. That's one of the main issues when moving GPC to gcc-3. > Other issues are a numer of changed interfaces, though this will > probably mostly be "mechanical" work. > [Joe da Silva] Well, the pragmatist in me says GCC-3 compatibility is more important than ideological misgivings about garbage collection. <G> > > Any guess how much time > > and effort it would take to make the change? > > According to a talk with Peter, it will be on the order of several > days to a few weeks. If several people will work on it, it will be > easier on everyone, of course. Are you interested in helping? > > da Silva, Joe wrote: > > > IMHO, garbage collection is a kludge to fix memory leakage > > problems, which are a particularly common affliction with C, > > with it's particularly heavy reliance on pointers ... <BG> > > Excuse me, but I think that's more of a prejudice here. What the > compiler does internally relies heavily on tree structures. These > require pointers in *any* language -- though some languages hide the > fact. Pascal doesn't hide it, so the tree handling code and the > resulting memory management problems would be exactly the same if > GPC was written in Pascal. > > Other typical usages of pointers in C, such as for strings, are > relatively few in GCC/GPC, and are not the problem. > [Joe da Silva] My comments were general and relate to the excessive reliance of C on pointers, whereas Pascal often avoids them with safer alternatives, such as "var" parameters, etc. Of course, pointers are important and necessary in many situations (but I still consider garbage collection is a kludge for bad housekeeping - note also the <BG> ;-) My knowledge of the internal workings of GPC (compilers in general, actually) is next to zero, although I hope that one day this will improve. BTW, I do realize GPC is itself written in C, thereby taking advantage of the wide platform support of GCC (every cloud has a silver lining!;-). If this inter-dependence with GCC also means that garbage collection is a requirement, then "so be it" ... > The "obstacks" were something like a "half-hearted" garbage > collector and cause(d) many problems, so it's good to get rid of > them, anyway, even if gcc-3 would not require it. > > Of course, there are other alternatives to GC, such as reference > counting. But that's not without cost either: it requires traversing > all structures to get rid of, which costs runtime and is even a > little tricky in the presence of recursive structures. And it costs > memory to store the reference counters while GC has no significant > memory costs AFAIK (only runtime costs). > > So, from the programmer's perspective, GC is probably the easiest to > live with, and also at runtime, it might not be worse than the > alternatives. > > Or am I missing the perfect solution? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

6 13

Re: gcc-3+
by Maurice Lombardi 18 Feb '02

18 Feb '02

Markus Gerwinski <markus(a)gerwinski.de> a dit : > Hi folks, > > Frank Heckenbach wrote: > > Though I'm not sure why the distinction between store and reference > > pointers is necessary. Why not make all pointers the same, and when > > one pointer to an object is disposed of, all the other ones are > > invalidated? > > This is usually not, what you do... is it? If the pointer p1 is the one used > to allocate p1^, and it is also referenced by p2..pn, you normally take care > to use p1 again to deallocate, don't you? > > If so, you _are_ implicitly working with "store" and "reference" pointers. > Making this an explicit naming within the programming language would IMO > make the language more "speaking". It would enforce "clear responsibilities" > within the program: Only the pointer that created a piece of memory may > destroy it. > > If the restrictions are like this: > - store pointers may _only_ "new" or "dispose", but never be set to the > value of another pointer. Trying to "new" an already set store pointer > causes a runtime error. > - reference pointers may _only_ be set to the value of another pointer, but > never be "new"ed or "dispose"d. > ... then memory leaks are made impossible (you just _can't_ allocate a > pointer and then set somewhere else), and accidentally disposing of some > data still needed by a bunch of other pointers becomes at least less likely > (reference p42 just isn't able to dispose of p1). Gosh. How do you do with linked lists, a quite common situation I believe. If you append records only at the end of the list, you can use the last "next" pointer as a store pointer. But what do you do if you want to insert a new record in the middle of the list. Usually either: you keep the address of the next record in a temporary pointer and allocate the new record with the "next" pointer of the previous: invalid because you try to new an undisposed pointer. you allocate the new record with a "temporary" pointer (no problem up to that point, it will be a store pointer) and then insert it, playing with two "next" pointers: but the previous "next" goes from store to reference status. And you need to keep somewhere all "temporary" pointers which served you to allocate the elements ... Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

New versions of the sysutils and objects units
by Prof. A Olowofoyeku (The African Chief) 18 Feb '02

18 Feb '02

Hi all Updated versions of the sysutils and objects units have been released, and are now on agnes: ftp://agnes.dida.physik.uni-essen.de/home/chief/ Enjoy ... Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

4 3

Re: Compiling inline assembly code
by da Silva, Joe 18 Feb '02

18 Feb '02

There are two possible reasons for using inline assembler code : 1. For speed-critical portions of code. 2. For very low-level, machine-specific parts of the code. So, if it's reason #2, then you can't merely translate the code, either to Pascal, or to your new target machine language, Sparc. For example, suppose the inline assembly code is an interrupt service routine for INT4 (COM1: serial port interrupt). You can't just translate this to another platform, because INT4 (if there is such a thing) will be unrelated, the serial port I/O addresses will be different, the serial port UART probably has different registers and modes, the CPU will definitely have different registers, etc., etc. Good luck, you'll need it! Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, February 18, 2002 4:51 PM > To: gpc(a)gnu.de > Subject: Re: Compiling inline assembly code > > Anuradha wrote: > > > We have been trying to compile in-line assembler code in our pascal > > programs using gpc-20010623 .We are porting the sources from windows to > > sparc-sunsolaris 2.6 and we have some problems with compiling the asm > > code.The gas says that it is not able to recognise the opcodes > > "push","pop","cld".. > > Erm, well, different processors use different kinds of assembler > code. That's why assembler is considered low-level compared to > Pascal. > > Basically, you'll have to rewrite all your assembler code for any > new processor. Or you translate it to Pascal, then you need only one > version. (Since GPC is a Pascal compiler, I think I might mention > this option ... ;-) > > > The link to Mr.Brennan's site given in the FAQ has a ~ and we are not > > able to reach the site. > > Thanks for the hint. In the DJGPP FAQ, I found a new URL: > http://www.delorie.com/djgpp/doc/brennan/brennan_att_inline_djgpp.html > > BTW, I was misspelled (the `_djgpp' part was missing) or has moved > -- at least since v2.30 of the FAQ which I have here (in case any of > the DJGPP people are reading this, and it hasn't been fixed > already). > > > Can you kindly tell us where we can get some help on compiling asm on > > sparc-sun-solaris. > > No, I haven't had the need to program any asm on the Sparc. Have you > searched the net? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 2

Re: gcc-3+
by da Silva, Joe 18 Feb '02

18 Feb '02

Am I the only one missing the previous message from CBF? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Friday, February 15, 2002 10:47 PM > To: gpc(a)gnu.de; cbfalconer(a)worldnet.att.net > Subject: Re: gcc-3+ > > CBFalconer wrote: > > > I never heard of an 'obstack'. > > I guess not. It's a GNU invention, and I haven't seen it used > anywhere but in GCC itself (prior to version 3). Actually, now that > you mention it, they're not much different from Mark/Release except > that they support several independent instances. > > > P4 did most of this with mark/release, which sufficed, but is > > usually incompatible with new/dispose (another subject). > > FWIW, in GPC(*) they are compatible, but in a rather inefficient way > (i.e., Release just does a series of Dispose calls internally). > > (*) Here I mean for GPC programs, not in GPC internally, of course. > > > Are we talking about the same things? > > I think so, and after dealing with some of the more nasty problems > caused by obstacks and leading to compiler crashed that are hard to > debug (like many MM related problems, because the symptoms ofter > occur much later than the problem), I really like to get rid of > them. > > 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

Compiling inline assembly code
by Anuradha 18 Feb '02

18 Feb '02

Hello, We have been trying to compile in-line assembler code in our pascal programs using gpc-20010623 .We are porting the sources from windows to sparc-sunsolaris 2.6 and we have some problems with compiling the asm code.The gas says that it is not able to recognise the opcodes "push","pop","cld".. The link to Mr.Brennan's site given in the FAQ has a ~ and we are not able to reach the site. Can you kindly tell us where we can get some help on compiling asm on sparc-sun-solaris. Thanks and Regards, Anuradha -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

Re: gcc-3+
by Frank Heckenbach 15 Feb '02

15 Feb '02

CBFalconer wrote: > I never heard of an 'obstack'. I guess not. It's a GNU invention, and I haven't seen it used anywhere but in GCC itself (prior to version 3). Actually, now that you mention it, they're not much different from Mark/Release except that they support several independent instances. > P4 did most of this with mark/release, which sufficed, but is > usually incompatible with new/dispose (another subject). FWIW, in GPC(*) they are compatible, but in a rather inefficient way (i.e., Release just does a series of Dispose calls internally). (*) Here I mean for GPC programs, not in GPC internally, of course. > Are we talking about the same things? I think so, and after dealing with some of the more nasty problems caused by obstacks and leading to compiler crashed that are hard to debug (like many MM related problems, because the symptoms ofter occur much later than the problem), I really like to get rid of them. 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

Multiple definition of procedures.
by HARIKRISHNA Kocheralkota 15 Feb '02

15 Feb '02

Hello, Is multiple definition of procedure like the following not allowed in GPC? =================================================== program myprg; uses mycase; begin x; end. =================================================== unit Mycase; interface uses Myunit; procedure x; implementation procedure X; begin writeln('i am in Mycase'); end; end. ================================================ unit myunit; interface procedure x; implementation procedure x; begin writeln(' i am in myuint'); end; end. ==================================================== This works fine in BP. Thanks and Regards, Hari

2 1

Re: gcc-3+
by Frank Heckenbach 15 Feb '02

15 Feb '02

CBFalconer wrote: > Frank Heckenbach wrote: > > > > Obviously, you need pointers to represent such structures. Creating > > them is not a problem, but how to clean up properly? You can > > traverse all pointers in the object and clean up the objects they > > point to recursively. But that's wrong because those objects might > > be referred to from elsewhere. Also, with cyclic references, you'd > > run into an endless loop. > > > > This is not to say it's impossible (I mentioned reference counting, > > and there are ways to avoid the endless loop), but is this much > > simpler than GC? In fact, if you consider the whole memory as a > > large tree(*), the resulting algorithm wouldn't look much > > differently from a GC algorithm ... > > > > (*) It's not really so, but in fact most of it is consumed by tree > > nodes, and whether you consider cleaning up one of several trees > > or cutting a branch from the only tree doesn't make a big > > difference. > > > > > If this > > > inter-dependence with GCC also means that garbage > > > collection is a requirement, then "so be it" ... > > > > Practically, it does. But if you know a better solution, even if > > only in theory, I'd be interested, just for curiosity. > > How about in practice. I wrote the attached package for precisely > this sort of problem. It is not completely tested yet, but I have > found very few problems, and the whole package represents about a > kilobyte of object code. > > So far the best usage example is the 'markov' program, which uses > two inter-related data bases. There is no need to keep track of > individual items, only the data base itself. The inner workings > are hidden. Read the header file, which provides the complete > abstraction. > > I envision each scope opening a new data base, and scope exit > releasing it. Access is fast, generally requiring about 1.5 > probes for finding, 2 for insertion. The package statistics > include the cost of reorganization, which is more efficient than > insertion, makes the database size irrelevant, and is again hidden > from view. There is no problem including usage counts, possibly > in a master spellings table, and interconnecting such with table > construction/destruction (see the dupe/undupe functions). > > For large numbers of items the only practical difficulty is the > slow operation of free() in some C systems. This becomes > noticeable in DJGPP by about 10,000 items, and is an O(N*N) > effect, related to merging of freed storage blocks. Yes, it seems to happen only with strong fragmentation as in the following test program (without fragmentation it's quite linear). #include <stdlib.h> #include <stdio.h> #include <sys/time.h> void *p [200000]; int main () { int i, j; clock_t c = clock (), c2; for (i = 1; i <= 20; i++) { for (j = 0; j < 10000 * i; j++) p[j] = malloc (42); for (j = 0; j < 10000 * i; j += 2) free (p[j]); for (j = 1; j < 10000 * i; j += 2) free (p[j]); c2 = clock (); printf ("%i ", (int) (c2 - c)); fflush (stdout); c = c2; } return 0; } > This probably > will not affect compiler use, since 10,000 items per scope is a > rare occurence IMNSHO. Probably. OTOH, I've just fixed some other O(n^2) problems (in the code that deals with unit/module) interfaces. The Chief had reported (long time ago) that the compilation of Windows API interfaces was very slow, and that might have been due to these problems (as soon as the next RC is release, he'll certainly test it, I guess). I don't know how many items there actually are, but I wouldn't be surprised if it actually reaches this order of magnitude (taking into account that e.g., each function parameter, its type and its name, use distinct nodes internally). > I am attaching the hashlib (preliminary) package only to you, > since it is preliminary and until I have finished with testing I > want to keep control of it, and the newlist should not be burdened > with a fairly large attachment. Feel free to pass it on to other > workers in the Pascal pits, and/or to forward this message to the > newslist. ... which I'm doing now. Since I'm quite busy I haven't had the time yet to look at it thoroughly. But at first sight, if I understand it correctly, one would start a new "block" for each Pascal routine (roughly), do all local allocations within it, and release it as a whole in the end. (Perhaps this understanding is completely wrong, then ignore the rest. ;-) Well, this is almost exactly the obstack idea. (Except that they kind of "buffer" the allocation and allocate and free larger blocks from the system MM, so the slowness of free() on DJGPP probably doesn't matter so much.) But problems occur when the usage pattern of the tree nodes is not strictly "scoped". This starts with parameters (which are declared within a function, but needed when calling it -- though perhaps you can just put them in the outer scope), goes on with inline routines (whose code is kept in an intermediary form ("RTX") while most of the tree nodes can be freed, but not all, since, e.g. some type information is still needed), and the most difficult (or ugly) problems are often seemingly little details. E.g., a node that represents a type contains a list of its "variants" (i.e., the same type but, e.g., a protected and/or restricted version). Perhaps that's only for efficiency (so that when `protected foo' appears in several places, only one node for the restricted type needs to be created). But for this to work, a new variant of a type is always placed on the same obstack (in this case), otherwise a pointer would dangle when another obstack is removed. These were just some examples (and perhaps not well described). The main point is that the more optimization and special features come into play, the more often one gets in conflict with the strict scoping that the obstacks imply by default. I suppose that's the reason why they were finally thrown out in gcc-3.0. 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