[om-list] Dynamic Code Generation

[Mark Butler]

Tom,

  Usign a set of C++ programs with a standard Unix would be the easiest way to start.

  Beyond that, I think you should make an MTL interpreter long before you think about any form of a compiler.

C# is nice, provided you can afford Visual Studio.NET or wait until the Mono C# tools stabilize.  C++ is far more portable, so you should probably stick with that for now.

- Mark

Tom and other Packers wrote:
> 
> Mark
> 
>     Would you suggest writing everything in C#, such as the shell, the
> utilities, ... what else is there?  I have too many questions, I don't know
> where to begin.
> 
>     Let's see if I have anything straight, yet.  You suggest I write some of
> the utilities first, as separate executables, which I can run in an existing
> shell, like bash.  Then you suggest I write my own shell, which interprets
> my written commands, like any other shell.  Then, do you suggest two more
> steps: (1) I should use C# Reflection.Emit in the shell to somehow convert
> my MTL into CLR byte code, and use whatever library or DLL that comes with
> C# and is compiled into my MTShell to run this new byte code at run-time.
> (2) I should write a compiler for my MTL.
> 
>     I'm guessing that step two would be a long way off, if I ever get to it.
> And even if I do, I think I will still want to be able to type commands into
> MTShell and run them immediately, without much hassle -- as though it were
> still like any other shell.
> 
>     Am I close?  The things you've shown me sound very interesting.  I just
> don't understand them well enough yet.  Should I start writing everything in
> C#?  Or should still write the utilities in C++ and compile them for both
> windows and Linux?  Is it easier or harder to port C# than C++?  Which is
> faster at run-time?  When you say that CLR modules start slower the first
> time, but speed up after that, does that assume you are running them in
> quick succession, such as when running one shell script.  Or does this
> happen even after closing the program, or re-booting the computer?
> 
> tomp
> 
> ----- Original Message -----
> From: "Mark Butler" <butlerm at middle.net>
> To: "One Model List" <om-list at onemodel.org>
> Cc: "Ping Wang" <pingwang at home.com>
> Sent: Friday, 23 November, 2001 12:50
> Subject: [om-list] Dynamic Code Generation
> 
> Tom,
> 
>   If you are interested in implemented your own language with a matching
> compiler, I thought you might find the following article very interesting:
> 
> http://www.oreillynet.com/pub/a/dotnet/excerpt/prog_csharp_ch18/index.html
> 
> It turns out that C# has capability known as "Reflection.Emit" that allows
> you to generate CLR byte code at run time and then invoke it directly.  This
> is not nearly as transparent as LISP, because CLR byte code is based on a
> FORTH style stack machine, but it is a great improvement over the more
> conventional technique of translating to source code, calling a compiler to
> build a library, and and loading, binding, and calling the compiled
> function.
> 
> The latter really isn't such a bad idea - you can still do it in C#, as
> described in the article.  The  big problem doing this with C++ is that
> there are no available functions to support C++ function lookup or name
> mangling, which makes the source generation / compiling technique limited to
> C functions or C++ functions with C wrappers.  Application plug-ins (e.g.
> Flash, Shockwave, Acrobat Reader, ODBC drivers, etc.) are generally all
> loaded and bound to a common C interface this way, excepting being compiled
> in advance, of course.
> 
> Java has a class loader which eliminates this binding problem, and C# goes
> one step further by providing libraries that allow you to generate CLR
> (common language runtime) byte code directly. CLR assemblies (an analog to
> Java class files) can be interpreted, but Microsoft's policy is always to
> compile and cache the whole assembly on demand, rather than use just-in-time
> compilation techniques to compile the detected hot spots while a program is
> being interpreted.  That means that CLR modules start slower the first time,
> but generally start and run very fast after that.
> 
> So in short, if you want to build an efficient language without building a
> full optimizing native code generator from scratch, writing a front end in
> C# and using the Reflection.Emit capabilities would be a good place to
> start.  Regardless, it would be advisable to implement all the basic
> operations of your language in a class framework long before you get around
> to writing parsers and code generators.
> 
> - Mark
> 
> More C# advocacy, from an open source perspective:
> 
>  http://www.oreillynet.com/pub/a/dotnet/2001/07/09/icaza.html
> 
> _______________________________________________
> om-list mailing list
> om-list at onemodel.org
> http://www.pairlist.net/mailman/listinfo/om-list
m