Thursday, February 5th, 2009
Opera isn’t sitting on their heels as the other browser vendors get snappy (even if other claim so!)
We have focused our efforts to improve upon our previous engine in three main areas:
The last couple of generations of Opera’s ECMAScript engine have used a stack-based bytecode instruction set. This type of instruction set is based around a stack of values, where most instructions “pop” input operands from the value stack, process them, and “push” the result back onto the value stack. Some instructions simply push values onto the value stack, and others rearrange the values on the stack. This gives compact bytecode programs and is easy to generate bytecode for.
In the new engine, we’ve instead opted for a register-based bytecode instruction set. In a register-based machine, instead of a dynamically sized stack of values, there’s a fixed size block of them, called “registers”. Instead of only looking at the values at the top of the stack, each instruction can access any register. Since there is no need to copy values to and from the top of the stack to work on them, fewer instructions need to be executed, and less data needs to be copied.
Native code generation
Although our new engine’s bytecode instruction set permits the implementation of a significantly faster bytecode execution engine, there is still significant overhead involved in executing simple ECMAScript code, such as loops performing integer arithmetics, in a bytecode interpreter. To get rid of this overhead we are implementing compilation of whole or parts of ECMAScript programs and functions into native code.
This native code compilation is based on static type analysis (with an internal type system that is richer than ECMAScript’s ordinary one) to eliminte unnecessary type-checks, speculative specialization (with regards to statically indeterminate types) where appropriate, and a relatively ambitious register allocator that allows generation of compact native code with as few unnecessary inter-register moves and memory accesses as possible.
Automatic object classification
Another area of major improvement over our current engine is in the representation of ECMAScript objects. In the new engine, each object is assigned a class that collects various information about the object, such as its prototype and the order and names of some or all of its properties. Class assignment is naturally very dynamic, since ECMAScript is a very dynamic language, but it is organized such that objects with the same prototype and the same set of properties are assigned the same class.
Nice to see, and interesting that the browsers aren’t (or aren’t able too?) share their VM work. Each browser has a new VM implementation going. Wouldn’t it be nice if they could share effort?
Then we have Vega a vector graphics library that Opera uses to power SVG, Canvas, and more.
Vega was created shortly after we started working on SVG support.
When we added SVG support in Opera we needed a vector graphics
library. We looked into what what available to use and met our
requirements (fast, low memory usage and works on platforms
ranging from phones to TVs and desktop computers). We did not
find and good match for our needs, so we decided to write our
Shortly after we created Vega we added <canvas> support, which
also uses Vega.
The most recent addition to Vega is the ability to use a
hardware accelerated back-end. The back-ends we are using at the
moment are OpenGL and Direct3D.
A busy day for Opera!
Posted by Dion Almaer at 12:01 am