Idaes behind Amber VM
Technical documentation
01/18/2009
Definition of Goals¶
I think it is time to formulate the concepts behind Amber VM before starting to develop in a multitude of directions and getting away from what Amber VM was intended to be.
To simplify matter I have formulated a few simple to put goals that I will explain later on.
- Security
- Multilingualism
- Language Conformity
- Speed
This goals are ordered by priority, meaning the higher rated goals overule the later ones if there is no way to combine or satisfies them all. Of cause all of this goals are important, and in a ideal case all should be fulfilled. They were with the aim of Amber VM in mind.
Security¶
Amber is intended to be used in environments where code executed on it is not coming from verified sources. This the higest priority is that in default settings Amber VM should act in a way that no code executed in it can harm the system it runs on.
That includes:
- Restricting access to data on the system
- Restricting access to functionality on the system
- Restricting the CPU footprint
- Restricting the memry footprint
Currently Amber VM implements the access restrictions by requiring the developer to explicitly publish functions or variables to Amber VM before they can be used in scripts.
Protection against runaway scripts is implemented by allowing to limit the runtime of a script.
Protection against huge memory use is not yet implemented!
This goal has the highest priority up to the point where it should not even considered to cut down on it in favor of any other goal.
Multilingualism¶
One of the very fundamental ideas behind Amber was that it should be possible to mix code from different languages. This still is important.
This does snot mean that it has to be possible to write one file with different languages or switch the used language within a function (while that certainly would be cool) but that if a library is written in language X it should be accessible from library Y without too much of work, functions should be able to be called variables read and so on.
This means that very language specific constructs (in the way of the VM backend not out of the view of the language!) might not be usable and have to be described more complex by the compiler, thus creating them out of the building blocks the VM provides.
Language Conformity¶
This is simple to explain, languages implemented in Amber VM should be as close as possible to the 'defautl' implementation - if possible be entirely conform with it.
Speed¶
Another simple goal, once all other goals are accomplished the interpretation should be as fast as possible - of cause.