I recently discovered GPC and am attempting to install it on Windows NT, but
cannot get it to run. So far I have done the following:
* downloaded the MinGW 1.1 distribution from SourceForge.net
* added C:\mingw\bin to my PATH per the MinGW 1.1 instructions at SourceForge
* downloaded the gpc-19990118.i386-pc-mingw32 distribution
* extracted the files to the C:\mingw folder (the GPC binary is in the same bin
folder as the GCC, g77, etc. binaries)
Now, working in a Command Prompt window from a …
[View More]different folder (i.e. my
"working directory"), I get the following behavior:
* Type "gpc" - works ok (I get the copyright message and a list of more details,
command line options, and a command to view the online documentation)
* Type "gpc --verbose" (as described in the above output) - I get a couple of
lines of messages, with the last line reading "ld: cannot open crt1.o: No such
file or directory", but this file is located in my "C:\mingw\lib" folder.
* Type "info -f gpc invoking" (as described in the above output) - I get the
standard Microsoft error message "The name specified is not recognized as an
internal or external command, operable program or batch file."
* Type "gpc test.pas" (test.pas is a file in my current working directory, which
runs correctly under Turbo Pascal 5.5) - I get an error message "gpc:
installation problem, cannot exec 'gpc-cpp': No such file or directory"
There is a file "gpc-cpp.exe" located in
"c:\MinGW\lib\gcc-lib\i386-mingw32\2.8.1", so I added this folder to my PATH.
Now I get the following behavior:
* Type "gpc test.pas" (same as above) - I get a different error message "ld:
cannot open crt1.o: No such file or directory", but this file is located in my
"C:\mingw\lib" folder.
Can anyone help me get this installation to work?
Also, it would be great to use either the PENG or RHIDE IDEs described on the
GPC web page, but I noticed that both of these only work with DJGPP. Will DJGPP
work under Windows NT? If so, (other than the obvious of getting the DJGPP
versions of GCC, binutils, GPC etc.), are there any tricks necessary to getting
the DJGPP version of GPC operable and getting PENG or RHIDE working as well?
Thanks.
Andrew Kelly
andrew.kelly(a)us.abb.com
[View Less]
Again, fragmentation is a different issue. Garbage collection
involves the removal of garbage - which means blocks of
memory that are no longer referenced by a pointer, but which
due to neglect, have not been de-allocated (ie. memory
leakage).
Joe.
> -----Original Message-----
> From: Russell Whitaker [SMTP:russ@ashlandhome.net]
> Sent: Thursday, February 14, 2002 2:47 PM
> To: cbfalconer(a)worldnet.att.net
> Cc: gpc(a)gnu.de
> Subject: Re: gcc-3+
>
>
>
> On …
[View More]Wed, 13 Feb 2002, CBFalconer wrote:
>
> > ... Pascal should not have garbage collection.
>
> 1. Does the program fragment memory?
> 2. If yes, what are the acceptable limits of that fragmentation?
> 3. Will the program terminate before those limits are reached?
>
> One size doesn't fit all.
>
> Russ
>
>
[View Less]
Please see below ...
Joe.
> -----Original Message-----
> From: Russell Whitaker [SMTP:russ@ashlandhome.net]
> Sent: Wednesday, February 13, 2002 3:51 PM
> To: gpc(a)gnu.de
> Subject: Re: gcc-3+
>
>
>
> On Tue, 12 Feb 2002, Markus Gerwinski wrote:
>
> > Hi folks,
> >
> > Frank Heckenbach wrote (in reply to da Silva, Joe):
> > > Obviously, you need pointers to represent such structures. Creating
> > > them is not a problem, …
[View More]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.
>
[Joe da Silva]
Yes, I seem to recall this matter being discussed in
Pemberton and Martin, wrt. the P4 compiler, although
I can't recall the details ( I'm trying to learn this stuff,
but it's "heavy going" and spare time is scarce :-/ ).
> > >
> > > 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 ...
> > > > 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.
> >
> > I'm currently working on a framework including an object type named
> > "tReferenceManager". It is intended to exactly solve this problem, at
> least
> > for synchronization of collections (lists, hashtables etc.): For every
> > pointer, you can subscribe _one_ collection it is stored in, plus an
> > arbitrary number of reference collections. When the pointer is removed
> from
> > the store collection, it is automatically disposed, and all of the
> > references are removed from the reference collections.
> >
> > I hope to complete the respective unit of this framework within a few
> weeks.
> > If anyone thinks he/she can use it, I'll announce it after this unit is
> > ready. (Frank: The framework contains also the exception handling unit
> we
> > already talked about.)
> >
> > Personally, I _really_ dislike garbage collection since I had to deal
> with
> > it in an optimization problem in Java. ;-/ IMO, providing a language
> with
> > GC is just a way to encourage programmers to give up control. An
> alternative
> > feature I'd like to see in a language would be to split pointers into
> two
> > separate data types: "store" pointers and "reference" pointers.
> Allocating
> > and deallocating may only be done on a store pointer; setting a pointer
> to
> > an already existing address may only be done with a reference pointer.
> When
> > disposing of a store pointer, itself and all of its references are
> > automatically set to nil, so you can always check whether the pointer is
> > pointing to valid data. (It's the same principle I'm using in my
> > tReferenceManager, and up to now I didn't find any disadvantages in it.
> > Except that you are forced to think before you code.;-)
>
[Joe da Silva]
An interesting idea - I like your approach.
> >
> Perhaps I'm missing something. I thought the purpose of GC was to maintain
> a list of free memory. Thus GC doesn't care how you access a block, it
> cares only if it is free or not. A simple GC would recognize adjacent free
> blocks and combine them into a larger single block.
>
[Joe da Silva]
Well, I though that's what "new" and "dispose" do. As I
understand it, GC's purpose is to de-allocate memory
blocks that no longer are referenced by pointers but
that the programmer has forgotten to de-allocate himself
(or herself). For example,
new(apointertosomething);
..... {no dispose}
new(apointertosomething);
> A more complex scheme
> could move already allocated blocks to make a large free block when one is
> needed. This last might be implemented by adding a transparent level of
> indirection. Programmer thinks his pointer p is pointing to something when
> in reality it is pointing to an internal pointer pointing to the
> something. Thus when the block gets moved only one pointer needs to be
> changed.
>
> Along with GC you have the problem of do you allocate first fit or best
> fit? Each has its pros and cons.
>
> And just how is gcc doing GC and friends? (was lazy and didn't do much
> digging thru the code.)
>
> Just some thoughts,
> Russ
>
[View Less]
Please see below ...
Joe.
> -----Original Message-----
> From: Frank Heckenbach [SMTP:frank@g-n-u.de]
> Sent: Tuesday, February 12, 2002 9:29 PM
> To: gpc(a)gnu.de
> Subject: Re: gcc-3+
>
> da Silva, Joe wrote:
>
> > > 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
> > …
[View More]> 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.
>
> As much as I share your dislike of C in general, let's try to keep
> to the point. The use of explicit pointers instead of `var'
> parameters does not affect the memory management situation (if used
> properly, but I think GCC does so). Memory management is used with
> malloc() in C or New in Pascal, and those routines yield explicit
> pointers, anyway.
>
[Joe da Silva]
Yes, you are right. Sorry for straying a bit off-topic
(no pun intended;-). Of course, memory leakage
and stray pointers are two separate problems.
------ snip ------
[View Less]
Frank Heckenbach <frank(a)g-n-u.de> a dit :
> Besides, as I noted, Emil evaluates the series only in a certain
> interval (|u| < 1/3, i.e. z < 1/9), so the number of terms needed to
> get the required accuracy is bounded by a constant (the size of the
> coefficients array). When you say "too high", do you mean this
> constant is too big?
Bigger than that of a Tchebiceff polynomial of same accuracy over same range.
> Also, as I said, I can't see why there should
…
[View More]> be large rounding errors.
Mmm. I may have spoken too fast. Rounding errors are a plague in large degree
polynomials of alternating signs, if terms (coeff * x^n) are of same order of
magnitude. This should not occur for an absolutely convergent series, where
the higher degree terms are small, if summed from higher to lower degree.
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
[View Less]
Hi
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. Any guess how much time
and effort it would take to make the change?
Russ
You're right! Problem solved, silly mistake on my part - I forgot
that the "asmname" stuff was case sensitive. <G>
Joe.
> -----Original Message-----
> From: Frank Heckenbach [SMTP:frank@g-n-u.de]
> Sent: Monday, February 11, 2002 3:16 PM
> To: gpc(a)gnu.de
> Subject: Re: Complex_Arctan
>
> da Silva, Joe wrote:
>
> > Hmmm ... Maybe I'm doing something wrong, but my installation of
> > GPC (DJGPP) doesn't know what "Log1P" is, nor can I find it in …
[View More]the
> > source code of the GPC unit, etc. Anyway, that's my problem, so I'll
> > look into that further when I can.
>
> Emil posted a Pascal version of Log1P recently. And if the libc
> contains it (DJGPP's does), an external declaration will do.
>
------ snip ------
[View Less]
Frank Heckenbach <frank(a)g-n-u.de> a dit :
> da Silva, Joe wrote:
> > As for my comment about "tweaked" coefficients (for platforms which
> > don't already provide the function), the general rule is that if you
> > truncate
> > an infinite series, you need to "tweak" the coefficient values to provide
> > optimum accuracy for the number of terms you are using. Simply
> > truncating a series may produce inaccurate results, regardless of how
> > …
[View More]many terms you apply. That is the general rule, and I remember it was
> > certainly true with trigonometric functions. However, perhaps this effect
> > is not so prevalent with the "log1p" coefficients?
>
> As I said, I'm no expert on numerics, and I haven't heard of this
> tweaking.
I suppose that what Joe has in mind is the replacement of a Taylor series by
a Tchebychev polynomial. The drawback of a Taylor series is that to have a
given accuracy you need only one term at the origin, but a number of terms
which increases when you go farther away from the origin of the development.
To have the accuracy you need at the farthest point of the development you
need a polynomial of too high a degree, and you get in addition problems of
roundoff errors when evaluating this polynomial. A Tchebycheff polynomial have
a constant accuracy over the whole range of validity, and for a given accuracy
over a given range it is of lower degree than any Taylor series based
polynomial in the same range. Even better is the use of a rational function
(ratio of two polynomials) as is used in the CEPHES library, for the log1p
function in particular.
However the degree and coefficients of this best polynomial depends both on
the interval sought and on the accuracy needed. It is different e.g. for
single, double, long double, and you cannot simply truncate a given series to
different orders. The situation is even worse for a general purpose compiler
like gpc which is aimed to work with different word sizes: 64 bits for real or
double for most systems, but may be 128 bits for some. Checks would be needed
to select the polynomial to use. It is probably better to let this done when
possible by a libc library (or an other specialized library like CEPHES) which
knows the particular system for which it is built and selects the order and
coefficients of the polynomial accordingly. Gpc should give only a less
optimized but the most generally valid solution.
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
[View Less]