Am 20.12.2013 um 16:22 schrieb Anthony J. Bentley anth...@cathet.us:
On Fri, Dec 20, 2013 at 5:49 AM, Sylvain BERTRAND sylw...@legeek.net wrote:
There is also the question of finding a new C99 optimizing
compiler written properly in C of course.
tinycc is interesting. It would require just
On Fri, Dec 20, 2013 at 5:49 AM, Sylvain BERTRAND sylw...@legeek.net wrote:
There is also the question of finding a new C99 optimizing
compiler written properly in C of course.
tinycc is interesting. It would require just a few basic
optimization passes to make it a reasonable alternative to
On Fri, 20 Dec 2013 13:49:43 +0100
Sylvain BERTRAND sylw...@legeek.net wrote:
Is there any remaining good c++ compiler/runtime which can
boostrap using a C compiler/minimal runtime?
Since, it's near impossible to re-write/unroll all the
mandatory c++ components in C quickly (harfbuzz,
Tcc is actively maintained. Just check the mailing list or the git repo.
On 20 Dec 2013, at 16:35, Paul Onyschuk bl...@bojary.koba.pl wrote:
On Fri, 20 Dec 2013 13:49:43 +0100
Sylvain BERTRAND sylw...@legeek.net wrote:
Is there any remaining good c++ compiler/runtime which can
boostrap
On Fri, Dec 20, 2013 at 04:35:36PM +0100, Paul Onyschuk wrote:
On Fri, 20 Dec 2013 13:49:43 +0100
Sylvain BERTRAND sylw...@legeek.net wrote:
Is there any remaining good c++ compiler/runtime which can
boostrap using a C compiler/minimal runtime?
Since, it's near impossible to
Anthony J. Bentley wrote:
I’ve been curious about libfirm and cparser but haven't looked at them
closely yet.
I did work a bit with cparser/libfirm and found the following:
* It took about 2 times longer to compile than gcc
* There was no x64 support yet
* It is not developed very actively,
On Fri, Dec 20, 2013 at 08:22:03AM -0700, Anthony J. Bentley wrote:
On Fri, Dec 20, 2013 at 5:49 AM, Sylvain BERTRAND sylw...@legeek.net wrote:
There is also the question of finding a new C99 optimizing
compiler written properly in C of course.
tinycc is interesting. It would require just
Sylvain BERTRAND wrote:
Since its 4.8 version, gcc cannot bootstrap with a C
compiler/minimal runtime, it needs a c++ compiler and runtime.
Making gcc 4.7 series the last clean gcc.
I think it is amusing that you think that gcc 4.7 is clean and good,
because it is written in C. From my
On Fri, 20 Dec 2013 17:31:26 +0100
Sylvain BERTRAND sylw...@legeek.net wrote:
Oh! What openbsd uses for its man page terminal renderer? I'm
stuck with the buggy heirloom tools.
Mandoc aka mdocml [1].
ARM64 is on its way, which will require a backport in gcc 4.7.x.
We will see how it
(Wondering about the topic, no idea why one would want
to use C++ anyway… but… *shrug*)
Sylvain BERTRAND dixit:
This is valid question on other hand e.g. base OpenBSD is C++ free for
some time AFAIK (after the removal of groff). Idea of minimal set of
Same for MirBSD (removal of GNU groff in
On Fri, Dec 20, 2013 at 06:12:45PM +0100, Paul Onyschuk wrote:
On Fri, 20 Dec 2013 17:31:26 +0100
Sylvain BERTRAND sylw...@legeek.net wrote:
Oh! What openbsd uses for its man page terminal renderer? I'm
stuck with the buggy heirloom tools.
Mandoc aka mdocml [1].
Thanks. I'll see
On Fri, 20 Dec 2013 17:26:42 + (UTC)
Thorsten Glaser t...@mirbsd.de wrote:
Oh, they’re buggy? Damn. I had hoped for a ditroff
implementation eventually.
Here [1] you can find links/references to every existing *roff
implementation. Still that doesn't leave many options.
Troff from
Paul Onyschuk dixit:
(those can be copied from Heirloom or from older version of Groff -
Or my version from ATT nroff, which got bugfixes in the
else-part of GNU groff specifics. I’ve got them in CVS as
src/share/tmac/ (not /usr/lib/ but /usr/share/ as per the
standard modern-BSD filesystem
“Firm is a C-library that provides a graph-based intermediate
representation, optimizations, and assembly code generation suitable
for use in compilers.”
I don't know if this is useful for this topic, but I have written a
parser for C that can be used as the base for some project.
Regards,
14 matches
Mail list logo
