[Mono-list] Re: C# -> Binary .. MCS to C++ cross compiler

[Ben Cooley]

> > >I really liked what I read on this language from a syntax/semantic
> > >point of view.  Is there plan support to have this language generate
> > >binary instead of CLI code?
> >
> > I don't know if there existing at the moment plans for this, but the
> > eminent feature of C#/.net is the .net-platform itself. If you create
> > native-code, the code is neither platform-independent nor creates its a
> > bridge for different languages. So the nicest featues of C#/.net are
lost.
> >
> > Btw: I think, that there was in any place here in the internet a side by
> > IBM, where IBM compares different Java-platforms/compilers/etc. And
> > Java-Bianary-Code programs runs on the IBM-JVM - according to IBM -
faster
> > then the same programs compiled with gcj in native-code.
>
> It depends what you mean by nicest feature of C#/CLI... I'm not interested
for
> my software to run on many platform without re-compilation.  But I am
> interested in the
>
> - - includeless feature of C#
> - - EventHandler
> - - implicit conversion of int to object
> - - all type has a base object class
> - - better keyword such as internal, readonly.
> - - notion of safe/unsafe code for section using pointer
> - - {0}, {1} when printing instead of %s ... (which probably resume in
better
> class library)
> - - Garbage Collector
> - - By default exception support
> - - Jagged arrays
>
> And others I forgot.
>
> Those interest me as they seems to make the code more comprehensive and
remove
> annoyances.  If the whole CLI stuff is needed for all those features to
work
> then you're kind of right that it won't matter between a pre-compiled and
a
> version compiled by the jit and cached.
>
> I have not gone through the CLI ECMA doc yet so I wasn't able to know by

I was working on a mcs mono to C++ compiler.  This would allow mono to be
compiled to C++ (not C) code that would be practically indistinguishable to
a source debugger, and would allow mono to seamlessly integrate with extant
C++ code.

I got as far as the mono/C++ integration so that C++ and mono would
recognize and work with eachother, and had a rudimentary C++ source
generator module added into mcs.

Unfortunately, time and intense work problems have overwhelmed my project,
and I haven't been able to continue on it.

The problem with a CLI implementation on many platforms is simply speed.
You can say what you want about the performance of IBM's JIT on x86, but for
deployment on memory limited and performance limited embedded systems, a JIT
simply isn't a good idea.

There is an especially large performance hit when you are talking about game
platforms like the Playstation 2 or Gamecube, where the slower speed of the
host processor and the lack of vectorization and other C and C++ compiler
complex static optimization techniques really does make a big difference.

Likewise, it is simply not practical to re-engineer all of the static
optimization techniques for every possible target processor into the JIT
system.  It will never be any more than a "good" solution for most embedded
systems, and the fact that it is required to dynamically compile at load
time is also another problem.

A standard C# to C and C++ cross compiler is really needed in these
instances, as static optimization and static binaries are critical in these
applications.

I just wish I had the time to finish my project. :(

If anyone is interested in helping to continue this project or interested in
the current working binaries on x86.. drop me a line.