Note: Aged discussions surrounding the topic are stored in Scripted Compiler Discussions. This page contains distilled information and fresh discussions (See the section at the end).
To incite some discussion and controversy.
Basic question: With machines getting faster and memory cheaper, would it make sense to write compilers which only have bits and pieces written in C, Ada, ..., and their main components (like complex manipulation of whatever data structures are needed to represent and optimize code) are actually written in a scripting language, like Tcl, Python, ... ?
And secondary, if we have such a compiler for, for example, the C language, does make it sense to package it up as an extension for the scripting language the majority of it is written in, for example, Tcl ?
Have fun thinking about this -- AK :)
Note that this is not so much about taking an existing compiler and making it scriptable, and thus allowing others to change its behaviour, but more about making use of highlevel data structures available in scripting languages to make the implementation of algorithms for data-flow analysis and such more ... understandable and/or maintainable.
Also note that this not about configuration files, but about implementing parsers, etc. for system languages like C. In a wider sense such are also useful in tools like Source Navigator which extract x-ref information out of sources.
Sub projects to think of ...
Related pages in this Wiki:
Other references
Note the obvious connection to Starkit's.
In the context of using a scripted compiler to extend the interpreter of a scripting language there are three main components:
Compiler results:
Reasoning and scenarios behind the above:
The above are the scenarios I thought of when I wrote up the lists of required packages and compiler results. For a new scenario I thought of recently see below.
AK: It is not clear if the gain to be had by using higher optimized machine code is outweighed by having to load a large native binary library. The research regarding slim binaries suggests that this is not so. At least for shortly running processes, IMHO. For long-running processes the initial overhead could easily be matched by the gains in speed we get. The problem is to determine the break-even point, i.e. the point where it makes sense to switch from one to the other.
I should note that the researchers in the area of slim binaries also research the field of optimizing the machine code of highly used procedures at runtime, in parallel to the actual application, using spare cycles in a low-priority thread. The above scenario could be seen as an evolution of this where the optimization results are written to disk for sharing with future instances of any application using the same procedures.
jcw: Thoughts... Maybe components 1+2 and result 3 are sufficient as first step? Also: binary code would be a great way to secure part of an app, which in turn could then supply keys for decoding the rest. With slim binaries, it gets even better because the same "code" runs cross-platform.
AK: 1+2/3 is essentially Critcl without an external compiler, and as such a logical first-step. But note that for result 3 we might need result 2 as source.
The relationship between a scripted compiler and Critcl.
Comments, notes, and discussion
DKF: How would you go about debugging such a beast? Without debugging... Well, let's just say that's highly scary, shall we?
AK: Testsuites for the components, trace log (package require log), data structure dumps (tree's, graph's) fed into visualization tools, symbolic debuggers, like in TclPro.
TP I find tcc interesting. It might be small enough for a self-contained Tcl extension C compiler that wouldn't require exec'ing gcc. Current downside is tcc generates x86 only.
TP Another cool project to keep in mind for a Tcl compiler backend, LLVM http://llvm.cs.uiuc.edu/
RC I am currently using Python to implement a C-to-VHDL optimizing compiler for FPGAs. I definitely recommend using "scripting" languages, at a minimum, as the glue languages between different algorithms, although the built-in data structures of scripting languages (Python has lists, tuples, and dicts) certainly make some of the hairier optimization routines much easier to understand. (For more info, you can see [L5 ]).
TJC compiler is a compiler for the TclJava project. It is written in Tcl and produces Java from Tcl. -TP
tclc compiles a Tcl script to a Tcl extension.
Zarutian adds a link to the online book The Art Of Assembly Language [L6 ]. Comments on the book appear here [L7 ].
Common to most MMORPGs, [L8 ] is a means of quickly gaining
experience and getting your character to the higher levels in a very short span of time. In World
of Warcraft there are many techniques that can help you to reach your leveling goals. The few that
are listed here work great and if you get into the habit of using them over time you will begin to
level very quickly.
One of the easiest ways to level your character is to get in with a group of higher level players.
You will receive more experience as they will be fighting higher level monsters than you would be
able to handle on your own. Simply befriend a player who is at a higher level than you and get
invited into their group. This is one of the easiest and most common ways of leveling up quickly.
Sometimes a balanced group of two or three is much more efficient than soloing. This is
particularly true when a Quest requires killing a certain number of monsters. Simply quest with
groups when you feel it is necessary and fight solo whenever you feel you may be held back or
hindered by them. In other words, use your intuitive sense to decide which is most efficient for
you at any given time.
There is some confusion as to whether questing or grinding is best for [L9 ]. I feel that this is a matter of personal preference. Some people actually enjoy the mindless tedium of spending countless hours grinding away at mobs of monsters for experience. While others prefer to mix things up with the excitement of faster leveling and story telling that comes with Questing. You will earn more experience and level quicker in a shorter amount of gameplay time through Questing. It all depends upon how you like spending your time while playing World of Warcraft. However, if you are wanting to Power Level then Questing is the definitely the quicker route.
Never be afraid to drop Quests that are overly long. Quests that require a ridiculous amount of
traveling or time to complete are useless to players that are trying to
[L10 ]. If you are taking
Quests in order to level up more quickly the last thing you will want to do is waste a ridiculous
amount of time on an overly long and complicated Quest. There are quite literally thousands of
Quests to choose from in World of Warcraft so move on to those that are finished quickly and
require little traveling.
[L11 ] is an excellent way of
preventing yourself from becoming stuck in the middle levels as many players tend to do later on
in World of Warcraft. Getting stuck like this can cause the game to become monotonous and boring
for some. For players who want to avoid this problem, [L12 ] is
the obvious choice. If you require more information or help, there are many online resources
available that can provide you with more detailed strategies concerning [L13 ] in World of Warcraft. Miles Tyler is an avid gamer and World of Warcraft enthusiast. He enjoys WoW and also loves helping others to enhance their WoW gaming experience.