[M3devel] additional CVS repositories for additional gcc forks?

[Rodney M. Bates]

Jay K wrote:
>  >  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.

There is no way a debugger that has no Modula-3 awareness is going to provide
a Modula-3-like view.  The operators will have C spellings and C semantics,
and these do differ.  The syntax will be strictly C.  The display of values
will be C.  TEXT won't work in any reasonable way at all.  Demangling names
in the compiler's debug output would make them look nice, but then the Modula-3
type info would be lost, and output formats would lose.

Things that use  pointers at the machine level can never know whether the pointers
point to a single value or an array, and if the latter, with what bounds.  Display
of whole arrays is pretty much out of the question.

Probably the worst thing will be calls.  They just don't work without the debugger
having knowledge of a lot of stuff.  There are extra hidden parameters, method
calls, passing procedure-typed parameters with environments, calling the same,
the three modes of Modula-3, etc.  I consider calls in debugger commands very
valuable.

This could probably be improved a lot by switching to a better debug info format,
probably the latest Dwarf variant.  But that is a big job.

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