The paper is about a Dynamic code generation system known as VCODE, which the
author claims to be retargetable Extensible and fast. The paper says that
dynamic code generation is not a new concept but the existing systems are
non-portable, inefficient and slow. The author says that one of the most
important features of VCODE that makes it fast is it does not use any
intermediate data structure. This feature also makes it extensible. The paper
lays down the guidelines of a dynamic code generation system as portability
functionality and speed. The author also claims that for wide availability
Vcode neither requires any changes to the existing compilers nor does it
requires its own sophisticated compiler. The low level Vcode interface and
instruction set makes it easier for the clients to write portable Vcode. As
Vcode generates code in place it becomes easier to extend its instruction set.
The paper also talks about other dynamic code generation systems as spark, dcg
and finds that Vcode is much faster than them.
The paper says that because Vcode is a manual code generation system it does
not require complex compiler support as is required by other automatic run time
code generation systems. The author has used the term complex compiler support
at several places but never bothered to explain it. The paper explains in
detail theVcode instruction set architecture and the client interface. The
paper points out that in spite of a lot of difference between their
architectures there is no performance loss when Vcode is mapped with x86. I
think this factor contributes to the wider usability of Vcode, as x86 is the
most widely used processor. The author tested Vcode as a compiler as well as a
dynamic compiler and found the results to be positive. The paper finally talks
about extensibility and limitations of Vcode giving 3-4 points of Vcode’s
limitation. I feel that the author was more or less successful in proving Vcode
to be a retargetable fast and extensible dynamic code generation system.
The paper on the VCODE gives a good overview of the concept of the Dynamic Code Generation and VCODE system which impelments this feature.Dynamic Code generation is the creation of the executable code during run time.In the begining of the paper the author points out the problems of portability and functionality barriers which limits the use of the dynamic code generation and explains how VCODE overcomes these problems.VCODE has the machine-independent interface to generate the machine code from the client specifications.Also VCODE generates the code in place.In section 2 the author describes the various dynamic code generation implemetations apart from VCODE.The system overview is been describes by the author in a convinsing way.VCODE has set of C macros and support functions which allows the programmers to protably and efficiently generate the code.Author outlines the various advantages of the low level interface used in VCODE.Such as code to be generated without the any compiler. According to the author the instruction set of the VCODE has been built up on the base operations such as sub,mul etc.Using the Client/VCODE interface the client program can be written.VCODE assumes that the Global optimizations are responsibility of the Client.Retargetting VCODE is well defined in the paper which includes the macros to generate the exe code.VCODE implements RISC.So it may be a problem if the hardware is different.In sec 4 the author gives the three implementation of three systems using the VCODE.Paper poitns out the four challenges for the in-place code generation and gives the some what adhoc solutions to them.The authors explain very well how to voilate the VCODE abstraction to improve the performance and control.The VCODE prepocessing specifications can add new instructions to it, as VCODE eleminates the imtermediate data structure.The drawbacks of the ODE are that it doesn't have a debugger,it has limited registers. In short the authors very well explains the VCODE for dynamic complation.
This system shares many of its goals with the "Fast, Effective, Dynamic Compilation" paper. However, after reading it, I'm less convinced that this one has achieved those goals. The idea of performing dynamic compilation at this low level is certainly interesting, but the paper provided very little proof that it is efficent in practical systems. In fact, the paper only spoke of how this was faster than other dynamic compilation systems, but never discussed its speed in relation to a static system. I find this troubling. Beyond the efficency issue, the technique in vcode was interesting in how it achieved portability. Most people don't associate low level code with portable systems, but this paper seemed to do just that. To that end, I would say that the portability idea presented is probably more interesting than the system as a whole.
VCODE is a tool for writing code in an idealistic RISC model to be jit compiled. A key point of the paper at the time it was written was that general optimizations were not the responsibility of the dynamic compiler, but rather left to the programmer and/or compiler. While direct compiler support is possible, the author sticks with allowing the programmer to write his dynamic sections in VCODE 'assembly language'. The VCODE project - which seems to have been done in ~96 around the beginnings of Java seems to be a foundation for a portable virtual machine. Unlike Java, VCODE does not appear to provide any hardware abstractions to the programmer (ie. graphics/console/networking etc) as does java, but is otherwise stated to be generally portable as soon as the VCODE system itself is ported to the target architecture. Because of the lack of hardware/os abstractions, porting VCODE to a new risc architecture is stated to take only 1-4 days. It seemed to me that since VCODE is largely macro based and that there isn't a linked vcode library per se, that source must be available at compile time. Perhaps I misinterpreted. In this case it seems that VCODE is generally not much more portable than the original source. Another advantage he givesis that dynamically compiled code can make use of runtime information to perform certain optimizations- a topic covered in much greater depth in the other paper. However, because VCODE is essentially responsible only for transliteration of VCODE symbols and not to optimization, such optimizations are left to hand coding by the programmer.
VCODE consists of a set of macros which mimic RISC instructions. These macros generate code at run time, by expanding into their platform-specific counterparts. The system works at this virtual-instruction level, so it can take advantage of existing compiler optimizations, and it's easy to port, because all they need to do is update the definitions of the most basic instructions. The system appears relatively simple and the authors assert its speed and usefulness. This combination seems like a winning product, but it made a dull paper. Invariably, interesting problems, like needing to know the size of the activation record (5.2), were solved in effective but clumsy ways.
VCODE is a system for generation of executable code at runtime. The main idea in this paper is this notion of machine-independent, idealized-RISC pseudo operations which are automatically converted into platform-specific instructions at runtime. This is done by specifying a mapping for each architecture from RISC pseudo ops to multiple (they claim 6-10) platform ops. In many respects this is reminiscent of EEL (which was published only a year before this paper), except that VCODE is targeted for dynamic code generation while EEL is designed for platform-independent instrumentation. VCODE seems to have several drawbacks, however. First is that dynamic code must be represented in VCODE-ops. This must then require a high-level language VCODE compiler. While not a major drawback, this dependency was not fully explored in the paper (it was only mentioned in the section on tcc, a 'C compiler). The next drawback is the various overheads, which although seemingly necessary, are still unsightly. These overheads come from VCODE->native translation (6-10x expansion) and register saving. Lastly is the inability to optimize leaf procedures without programmer annotations (and even then, it may not be possible to optimize the procedures, since the VCODE instructions themselves may map to function calls (e.g. MUL, DIV).
For the purposes of this review, the alternate dynamic compilation/code generation scheme described in the Auslander et al. paper entitled "Fast, Effective Dynamic Compilation" will be referred to as the "other scheme." VCODE is concerned primarily with solving two problems related to dynamic code generation. First, VCODE is designed to be retargetable. Second, VCODE is designed to output code without any intermediate representation. Extensibility is a low cost side effect of the latter. Generality - that is, avoiding language-specific dependencies - is a common theme between both VCODE and the other scheme. Attempting to solve retargetability, VCODE specifies its own embedded virtual machine. The "native" instruction set of this VM is an interesting cross between high-level language functionality and assembly language. As the authors repeatedly point out, VCODE allows you to program with paradigms that are just not possible in traditional languages such as C, although the current widespread use of inline assembly might slightly weaken this argument. Additionally, even though the VM is designed with RISC architectures, in practice, the CISC x86 architecture works, too, which is important for widespread acceptance. As far as retargetability is concerned, I don't think the other scheme is at a particular disadvantage. Switching between platforms in the other scheme would at most require updating the stitcher for each target platform. I see some potential pitfalls with this approach. Most importantly, due to the design decision to forego intermediate representation, this scheme does not perform any global optimizations. This places an incredible burden on the programmer. The programmer must be intimately familiar with run-time optimization techniques to obtain any real benefit from VCODE. Also, as the authors themselves mention, symbolic debugging is not currently possible with the current implementation of VCODE, but this might not be a real issue due to the VCODE's intended audience. However, this approach can also be extremely useful in specific circumstances and I believe the authors implicitly concede that VCODE is a very special-purpose system. The authors provide decent, systems-related examples of where the highly manual approach of VCODE shines compared to more automated schemes. In systems-level environments, such as an OS kernel, performance is extremely critical and generic global optimizations and intermediate representation could produce latency problems and other bottlenecks that are difficult to locate. A final nitpick: the authors twice mention that porting VCODE to another RISC architecture requires between one to four days. Such metrics are misleading and do not belong in such a paper. This is the realm of software engineering, not dynamic code generation.
The aim of VCODE system is to generate code efficiently and fleetly. To achieve this goal, it defines the low level interface, a set of C micros, which fit for RISC architecture. This interface allow user to do the expensive code generation operations and global optimizations, leaving VCODE focus on translating instruction sets into machine code. Since the instruction sets defined by VCODE are machine independent, simple and regular, it lets code to be generated quickly without support of compiler. Although there are drawbacks of VCODE system, which may limit the usage, it still is a practical dynamic code generation systems. Also it is the first general purpose dynamic generation system that could generate code in place. The interface VCODE provided allow client specifying which part need to be generated dynamically in the application and is easy to be extended.
The aim of VCODE system is to generate code efficiently and fleetly. To achieve this goal, it defines the low level interface, a set of C micros, which fit for RISC architecture. This interface allow user to do the expensive code generation operations and global optimizations, leaving VCODE focus on translating instruction sets into machine code. Since the instruction sets defined by VCODE are machine independent, simple and regular, it lets code to be generated quickly without support of compiler. Although there are drawbacks of VCODE system, which may limit the usage, it still is a practical dynamic code generation systems. Also it is the first general purpose dynamic generation system that could generate code in place. The interface VCODE provided allow client specifying which part need to be generated dynamically in the application and is easy to be extended.
Generated: Thu Mar 6 15:39:24 EST 2003 by mwh