[M3devel] C generating back end

[Daniel Alejandro Benavides D.]

Hi all:
Olivetti had the the original development environment written with a C generating backend written in C for different operating system machines, they intended to realease it fully (probably it was) but performance showed was inferior to that of SRC environment at the time 2.x (Modula-3 to C written in Modula-3), which led to include Olivetti front end part as a library front end being part of the SRC distribution, later to deploy Network Objects high level intermediate code network logical layer.
Having a C backend this days wouldn't make sense if it was actually developed at some point, and up to a Professor remembers RMS wanted this to be donated to FSF so it could led to some sort to GPLed system, but there wasn't such a donation or haven't been done yet and it probably was related to the performance comparison (in the time of Olivetti and SRC 2.x systems) reason mentioned by Mick Jordan (see http://compilers.iecc.com/comparch/article/90-08-046 ) and later to M3CG (due SRC Modula-2+ system low level intermediate code) interface which has proven to be a good compromise between portability and performance.
If we could prove that Olivetti backend could be a plus in terms of M3 performance and portability to get it back and compare its actual performance with nowadays M3CG backend performance then this would have a point

Hope it helps, thanks in advance 
 

--- El vie, 1/1/10, Tony Hosking <hosking at cs.purdue.edu> escribió:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] C generating back end
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: viernes, 1 de enero, 2010 18:42
> On 1 Jan
> 2010, at 18:05, Jay K
> wrote:
> Fyi I finally
> looked at the 2.x implementation and the outputing of
> C was implemented fairly directly at the m3front layer.
> There wasn't the "M3CG" stuff.
> 
> 
> Thus, the "easiest" way to get back such
> functionality would
> probably be to "interleave" the old code and the
> new code within m3front.
> 
> I'd like to avoid that sort of
> interleaving.
> The
> "cleaner" way is probably to implement a new M3CG
> though and
> leave m3front unchanged.
> 
> This is a much better plan.
> I still think
> generating portable C a great way to achieve portability.
> Better yet maybe, generate C++ and use its exception
> handling feature.
> (ok, maybe generate both, in case some systems lack C++
> support)
> 
> We can use the gcc-backend exception handling
> support if anyone was prepared to work on it.
>  realize
> there are several ways to view this though.
> 
>   gcc backend provides enough portability 
>      imagine IA64_NT though. or Plan9.
> or even OpenBSD 
>       or Darwin where there are
> long standing forks 
>       (The OpenBSD patches are
> small and we carry/apply them.
>       The Apple changes I think
> are mainly in the frontends
>       which I think is how we get
> by.) 
> 
>      For efficient exception handling
> we should be able to use libunwind on most targets. 
> 
>   llvm would provide good portability and maybe other
> benefits like perf 
>      less reach than gcc but hits the
> major platforms 
>      difficult for me to get started
> with sorry 
> 
>   integrated backend could/should be ported around and
> is fast 
>      a lot of work 
>      I think the first steps here are
> to learn about mach-o and elf file formats
>        as part of ports for
> other x86 targets. I've started a macho-dumper. 
> 
>   burg or others 
> 
>  - Jay
> 
> 
>