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.
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
