generating c code

[leblancmeneses]

Hi

My goal is to create something similar to:
http://students.ceid.upatras.gr/~sxanth/lwc/Tutorial1.txt

where IL is used instead of c++.

The goal is to abstract using OOP design and then generate c code of
my structures and controller class libraries.  Since it will be for
low end devices i know I need to implement System.Net and other .net
classes .. I understand this but initially the goal is just for code
generation to c of my oop design.

I'm choosing c because for low end devices there exists a c compiler
for all of them.

[quote source=http://www.mono-project.com/Mono:Runtime]
Tree Pattern Matching
The new JIT engines uses three intermediate representations: the
source is the CIL which is transformed into a forest of trees; This is
fed into a BURS instruction selector that generates the final low-
level intermediate representation.

There are a couple of books that deal with this technique: "A
Retargetable C Compiler" and "Advanced Compiler Design and
Implementation" are good references.
[/quote]


Please critique the principal .. i may be going about this the wrong
way...

Is anyone using cecil to retarget to other architectures/languages?




--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[Keith-104]

Hello! Correct me if I'm wrong: You have written some code in C# (or
other .NET language), compiled it to an assembly, and you want to
convert the assembly from IL into C so that it can be recompiled for
low-end devices. Yes?

One caveat with this approach is that IL assumes a garbage collector,
so the code has no information in it about freeing objects that you no
longer need. But you will (almost certainly) need this information in
a C-language version. You'll need to write some kind of dummy Free()
function which does nothing in C#, but which frees structures in C.

It will also be much easier to convert from a parse tree (or CodeDOM)
than from IL. There must be some IL-to-CodeDOM out there (Reflector
must use such a thing); does anyone know of one available for Cecil?
--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[leblancmeneses]

>assembly from IL into C so that it can be recompiled for
>low-end devices. Yes?

Yes.



>One caveat with this approach is that IL assumes a garbage collector,
good point.  The goal though is to be able to take ANY c# assembly and
convert to c.
I will need to build a garbage collector system as part of the
framework.
Thanks for the heads up.



>It will also be much easier to convert from a parse tree (or CodeDOM)
than from IL.

I've used code dom for simple C# interpreter in code generation
templates.
The problem with this approach is it is specific to language .. on
msdn it says ( it provides concrete compilers for: C#,  JScript, and
Visual Basic.)
What about other languages?
By using IL (i support all .net languages: IronPython, Php, ..ect) I
just need an ILReader.


I'm debating actually on whether to use Cecil, PostSharp ILReader, ms
published ilreader on codeplex, or creating my own IL AST...



--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[Daniel Grunwald]

leblancmeneses wrote:
>> One caveat with this approach is that IL assumes a garbage collector,
>>    
> good point.  The goal though is to be able to take ANY c# assembly and
> convert to c.
> I will need to build a garbage collector system as part of the
> framework.
> Thanks for the heads up.

Not only a garbage collector.
If you really want to take ANY C# assembly, you need to also rebuild all
other features of the .NET runtime.
Generics, Reflection, all the native methods that the BCL calls into, etc.
Essentially, you'll be writing your own version of .NET on top of a C
compiler (which isn't really a good basis for that job).
I think it would be much easier to port Mono to your target platform.
Or, you need to scale down your goals dramatically (leave out most .NET
features).

Daniel

--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[leblancmeneses]

> I think it would be much easier to port Mono to your target platform.
My first post does mention i am aware of .net classes needing
implementation.

I was planning a partial support of items that would need porting
like:

System.IO
File, Ports (Serial)

System.Net
TcpClient, UdpClient

those namespaces that are hardware dependent


I believe
System.Generic.Collections
would be handled by custom compiler itself that will extract from
mscorlib.dll


I want to keep the micro under 5 bucks.
I haven't seen any 8 bit controllers running mono ?

Is there a place listing all the microcontroller mono has been ported
to... what 32 bit controllers of freescale/arm ect?


--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[leblancmeneses]

http://go-mono.com/forums/#nabble-td21214297

i may just forget about trying to get it to run on microchip and
purchase better microcontrollers... (save myself the effort)

still debating though since it reduces profit per item.
--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[Dykam]

This looks closely to impossible... the most close you can get easily is Vala[http://live.gnome.org/Vala], though you mis GC and the BCL.

On Sun, Aug 16, 2009 at 5:30 AM, leblancmeneses <leblancmeneses@...> wrote:

http://go-mono.com/forums/#nabble-td21214297

i may just forget about trying to get it to run on microchip and
purchase better microcontrollers... (save myself the effort)

still debating though since it reduces profit per item.

--
Mark

--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[Steve Wagner]

Hi, why do you dont use the .Net Micro Framework? This is designed to
run on this low cost hardware. The other option it to use the mono
toolset and build a minimal version of you program as single executable
which contains only this what you need and is fully compiled generated
at compile time (This is what they did to run Mono apps and the IPhone).

-Steve

leblancmeneses schrieb:

>
>> I think it would be much easier to port Mono to your target platform.
> My first post does mention i am aware of .net classes needing
> implementation.
>
> I was planning a partial support of items that would need porting
> like:
>
> System.IO
> File, Ports (Serial)
>
> System.Net
> TcpClient, UdpClient
>
> those namespaces that are hardware dependent
>
>
> I believe
> System.Generic.Collections
> would be handled by custom compiler itself that will extract from
> mscorlib.dll
>
>
> I want to keep the micro under 5 bucks.
> I haven't seen any 8 bit controllers running mono ?
>
> Is there a place listing all the microcontroller mono has been ported
> to... what 32 bit controllers of freescale/arm ect?
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[leblancmeneses]

> Mark de Bruijn
thanks for the link!!

just got some basic stuff working. this is definitely the idea.

this would actually work if i could strip and minimize the glib
library for my specific embedded scenario. (hopefully it can be
optimized out when i compile using vendors compiler)

Example: cat glib.h shows a lot of includes i wouldn't need.

this definitely has potential and without any additional work.

thanks!


>Steve
> why do you dont use the .Net Micro Framework?

I wouldn't mind trying it (looks like a couple of people might be
trying it already):
http://www.microchip.com/forums/tm.aspx?m=304148&mpage=1&key=FatFs%2cUSB%2cframework񊐔
but then i'll be relying on microsoft to extend supported devices.
Currently they have targeted microcontrollers used in multimedia
applications (probably due to surface technology).  So anything <32
bit controllers are probably outside their target market.


in this case i rather go with mono if i plan extending it to other low
architectures.
miguel has some ideas on accomplishing using linker tools .. although
i currently wouldn't know how to start this yet.  Anyone?
http://www.desktoplinux.com/articles/AT7746284247.html


Although using the glib and vala i'm not sure where i'll end up in
size.
The benefit i see is it wouldn't be interpreted anymore.


--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---

[leblancmeneses]

for now i'm going halt my efforts on this, since, i see small only a
small return.
I'll stick to what i've been doing programming straight c on these low
end devices.

maybe after i see cash flow from other projects I might revisit this.

thanks for everyone's thoughts.
--~--~---------~--~----~------------~-------~--~----~
--
mono-cecil
-~----------~----~----~----~------~----~------~--~---