[om-list] Dynamic Code Generation

[Tom and other Packers]

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