Sponsored Link •
While working on the Cat to MSIL compiler I ran into some very annoying security features.
The MSIL has some security features to try and prevent bad code from being executed. This has two problems: 1) it prevents language implementors from doing interesting things, 2) it can be circumvented. This reminds me of runnning up against a lot of the C++ features designed to prevent abuse.
The specific feature I am bellyaching about is the fact that a specific function can't manipulate the stack below its stack-frame, and can't manipulate the stack beyond its max-stack size. Furthermore a function can't create a non-deterministic (at compile-time) stack configuration with regards to the number and type of elements on the stack.
What this just means is that to translate from Cat to MSIL I have to emulate a more flexible stack. To try and leverage the efficiency of performing the MSIL byte-code operations, I am introducing a notion of a separate evaluation stack. In the old Cat model, everything occured on a single stack but in the next version the basic operations occur on an evaluation stack.
This however has lead to an interesting fact: all of the MSIL opcodes are going to be available directly from Cat. Apart from the usual operators, there is going to be two addtional operators:
msil_store. These operators copy to and from the main stack and the evaluation stack respectiviely. Now the entire set of MSIL operators will be exposed as follows:
msil.Add, msil.Add_Ovf, msil.Add_Ovf_Un, ...
|Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.|