I always wondered why gcc never fleshed out the feature set for C++. Sine it’s
all a volunteer operation at Sourceforge/GNU, I never questioned it, but
perhaps LLVM/Clang may turn out to be an influence on the C++ standard.
Perhaps it’s time that some of the GNU people started taking part in the
ISO/IEC JTC1/SC22/WG21. After all, in point of fact, gcc users probably
outnumber users of commercial compilers, and all that experience could help the
standards committees.
James K Beard
From: Ruben Van Boxem [mailto:[email protected]]
Sent: Sunday, April 10, 2011 2:34 PM
To: [email protected]
Cc: [email protected]
Subject: RE: [Mingw-w64-public] mingw-w64 Decimal Floating Point math
Op 10 apr. 2011 19:05 schreef "James K Beard" <[email protected]> het
volgende:
>
> Philosophies about how compilers should be build has gone through fads and
> phases. Originally, of course, compilers were built using macro assemblers,
> and such large programs in macro assembler almost inevitably have dependency
> and side-effect bugs that are almost impossible to find and fix without
> causing other subtle bugs, and of course macro assembly code of any size is
> notoriously difficult to maintain. At one point the ideal was to build all
> compilers in Pascal code, because of all the computer science built into the
> Pascal language, but in practice it didn’t work out because things like
> garbage collection and stack/heap management weren’t easily done in Pascal.
> Sometime in the early 1990’s most newer compilers were built in C, and these
> tended to be successful. But there is still a contingent of computer
> scientists that believe that the best compilers are written in their own
> language.
>
>
>
> The obvious advantage of building a compiler in its own language is that
> compiling itself is likely to test every single feature of that language.
> This cannot be as thorough as a well-developed test suite, and you must
> accept the limitations of each language in the building of its own compiler,
> e.g. stack/heap management in a Pascal compiler – and large Pascal programs
> are known to be particularly prolific stack and heap users and abusers. But,
> for a language such as C (or, C++?) it does seem a natural thing to do for a
> number of reasons.
>
>
>
> I would want to be careful about using C++ as the compiler language for two
> reasons, the higher cost of maintenance of C++ code and the fact that it’s
> not at all obvious what C++ brings to the table for compiler code.
I believe you haven't met the phenomenon called LLVM/Clang. This is
full-fledged C++, used for just about anything from JIT to C/C++ compilation.
Note that I'm not saying a compiler has to be written in C++, I never did. But
it's not as daunting as you make believe. I was simply pointing out to Kai that
GCC is preparing for a limited transition to allow a shallow subset of C++
(which is very strange and shows of little understanding of what C++ is in my
eyes; it's not an add-on to C, and sucks if you were to use it that way, but
that's my opinion on the matter), and completely aside from that, allow
bootstrapping the C++ parts of the compiler as well. No philosophical argument
in intended.
Ruben
>
>
>
> James K Beard
>
>
>
> From: Ruben Van Boxem [mailto:[email protected]]
> Sent: Sunday, April 10, 2011 8:54 AM
> To: [email protected]
> Cc: [email protected]; James K Beard
>
> Subject: Re: [Mingw-w64-public] mingw-w64 Decimal Floating Point math
>
>
>
> Op 10 apr. 2011 08:49 schreef "Kai Tietz" <[email protected]> het
> volgende:
>
> >
> > 2011/4/10 James K Beard <[email protected]>:
> > > JonY - well, mine is in Fortran 95 structured format, with layers of
> > > classes
> > > and derived data types. An experienced programmer could port it to C++
> > > fairly quickly, giving you a a C++ class with overloaded arithmetic and
> > > casting/data conversion operations. But I'm not a C++ programmer and
> > > don't
> > > want to become one; I'm not in software or computer science and have other
> > > plans for my time than gaining expertise in C++. But I would be happy to
> > > support other people to do the conversion to C++.
> >
> > Well, C++ is a good language, but nevertheless for a C runtime-library
> > something not really usable. At least not for gcc, where we end then
> > in egg/chicken situation, as initial bootstrap provides C compiler,
> > but C++ isn't present completely. So if we include a dfp library into
> > runtime, it needs to be written in C language. But well, to
> > transscript C++ to C isn't a hard thing. So as startup version a C++
> > variant might be good enought here.
>
> GCC has been working toward having itself compiled by a C++ compiler,
> partially brought on by ppl/cloog dependencies. It can be enabled as an
> experimental feature already. Also; a full in-tree build of GCC with c++
> dependencies (ppl/cloog) is already possible (using host libstdc++) and works
> at least on Linux. Bootstrapping C++ isn't as impossible as it seems with GCC.
>
> >
> > > The Numerical Recopies core utilities are extended-precision fixed-point
> > > arithmetic without extensions (I do the extensions myself), an algorithm
> > > to
> > > compute pi to arbitrary precision, and an algorithm to do multiplication
> > > using an FFT to convolve polynomials of integers that are the extended
> > > precision mantissas broken up into bytes. The multiplication and division
> > > algorithms are non-trivial and the computer science in them is very much
> > > key
> > > to acceptable speeds in multiplication. If you guys are at all serious
> > > about this I will approach the NR people about how to proceed. My
> > > tentative
> > > thinking has been to put out what I have under the GPL, MIT, BSD or
> > > whatever
> > > license and note the NR modules needed to complete the package and leave
> > > it
> > > at that. For something to become a package in another language, I need a
> > > release into the MIT or BSD license. That's not at all very different
> > > from
> > > what they offer in the books and CD, so I think that it might be
> > > forthcoming, particularly if a plug for NR is included, but at this late
> > > date even that might not be required.
> > >
> > > My package has an initialization routine that sets up all the
> > > transcendental
> > > functions in arbitrary precision - log, exp, sine, cosine, tangent, arc
> > > sine, arc cosine, arc tangent - one and two argument - and a couple of
> > > others like the log gamma function. All of that is mine and free for me
> > > to
> > > release in any license.
> > >
> > > James K Beard
> >
> > Well, the interesting part here would be to support 128-bit binary
> > floats, which need to be emulated by software for x86/x64 anyway. By
> > this the support of dfp 128 should be then much easier. So I
> > wondering, if it wouldn't be in general a better solution to provide
> > first 128-bit binary float, and then use it for dfp 128. For dfp 64
> > and 32 bit, the 80-bit precission we support already, is for sure
> > precise enough. Only thing is the rounding after complex calculations.
> >
> > Regards,
> > Kai
> >
> > ------------------------------------------------------------------------------
> > Xperia(TM) PLAY
> > It's a major breakthrough. An authentic gaming
> > smartphone on the nation's most reliable network.
> > And it wants your games.
> > http://p.sf.net/sfu/verizon-sfdev
> > _______________________________________________
> > Mingw-w64-public mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
