[M3devel] additional CVS repositories for additional gcc forks?

[Jay K]

 >  better code quality

Use the native C++ exception handling. Not more calling setjmp all over the place.
Inlining. Currnetly disabled in 4.5.1 because it breaks things.
LTO/LTCG -- which we could get today, on gcc platforms, if we are willing to import even more code.
 (link time optimization, link time code gen). e.g. cross module inlining.
see also PGO -- profile guided optimization.
i.e. whatever the full C/C++ toolset is, you can use it.


 > better debugging
 

Existing debuggers would work and work well.
Notice today that NT386 has only line numbers.
That there are systems that don't support stabs -- e.g. HP-UX.
That other -g switches to cm3cg crash.


> > Basically all platforms would just work.
>
> I doubt that very much.

It's only a slight exaggeration.
We'd still need our #ifdef'ing of the C code. Possibly guided by autoconf.
And there are still the threading/gc issues.
But for example, we should work on any processor for any operating system
for which we already work -- NT, Linux, NetBSD, FreeBSD, Solaris, OSF -- on any processors.
And AIX, Irix, VMS would work or be closer to working.
(IA64 might need an #ifdef)

Anyway, I'll try to work on it.

> And it would be an order of magnitude slower.

It would be slower. I'm not sure by how much.

 - Jay


----------------------------------------
> Date: Thu, 26 Aug 2010 14:10:22 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] additional CVS repositories for additional gcc forks?
>
> Quoting Jay K :
>
> > > No. I would see a C backend as a variant (option) too, but probably not
> > > use it on platforms were I can compile without it.
> >
> > I would like to see a C backend at least replace the gcc backend.
> > We could maybe then slowly iterate on the integrated backend. Or LLVM.
> > It would provide more obvious correctness, better debugging, better
> > code quality.
>
> I don't really see that yet.
>
> > Imagine -- basically all platforms would get stack walkers.
> > By generating C++ for most platforms, or using C exception
> > handling in NT/VMS/Tru64.
> > Basically all platforms would just work.
>
> I doubt that very much.
>
> > Stock debuggers would work, gdb and others.
> > Basically no more porting.
> > Basically all optimizations could be enabled.
> > (Aside: I think the generated C would be sure to store
> > gc roots in volatile locals, but not otherwise use said volatiles.)
>
> As I said: it has been tried before.
>
> > And in more recent developments, it would enregister some records
> > passed by value.
> > It would, in a sense, shrink the code base (cheating sort of).
>
> And it would be an order of magnitude slower.
>
> > I'm not holding my breath on any of this.
> > But I'm going to start trying to do more and talk less about it.
>
> I will let you convince me ;-)
> I've got no problem with trying that. If it's really better, we will
> use it. If not, we may want to use it for special situations (e.g. porting).
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>