[om-list] Dynamic Code Generation

Tom and other Packers TomP at Burgoyne.Com
Thu Jan 31 14:37:23 EST 2002


Mark

    I haven't read all of this article yet, nor have I read the following
email.  I'll get to it all after I "bite the dust", and "go the way of all
the earth".  But what I skimmed through was very interesting to me.

    Do you think this reflection emit can be used for both of the following
issues I have found while planning MTShell:

    (1) You suggest I find a sneaky way to make a compiler.  I want to
efficiently come up with some compilation pathway, a path which starts at my
language, MTL, and which may terminate on at least two platforms: Windows
and Linux.  If there's an intermediate language out there that I could use,
and an accompanying translator for various OSes, that might work.  (2)
MTShell, and the subsequent 4C-Informatica, will be very general-purpose,
and I would like to find a means of optimising-by-specialising: that is, I'd
like to generate faster, specialised code at run-time for a particular user,
based on that user's pattern of use, leaving the original code effectively
generally-applicable.

    Comments?

    I don't know much about anything except C/C++, so I'm a little nervous
making a big decision, like adopting a whole new language like C#, and .NET,
and systems I don't understand yet.  I have no problem in adopting something
completely new, as long as I know it will work well for me in the long run.
I just don't know enough yet to know what to start learning.

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






More information about the om-list mailing list