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
