Over time muvium is trending toward the java specification as more items move from the Not Implemented to the Whats Implemented list
Whats Implemented
- Garbage Collection
- Standard Data Types
- Objects
- Inheritance
- Interfaces
- Exception Handling
- Recursion
- Statics
- Multidimensional Arrays
- Some Standard Java Libraries
- Static Initialisers
- User definable Threads
- more ( todo )
Whats Not Implemented ( yet )
- Floating Point Types
- more (todo)
Differences and Gotcha's (
)
- 16 Bit Integer ( int is 16 bit, long is 32 bit )
- Limited Local Variables
- Local Variables Must Be Initialised
User Defined Threads
Threads are co-operative not pre-emptive which means a thread must yield or sleep for a thread switch to occur. The threading scheduler is round-robin.
16 Bit Integer
The Java specification sets the java integer as 32 bits. However, given that the JVM bytecode specification is highly integer centric, which means most types are cast to integers, then operated on and then cast back to their types. And given the resource limitations of the 8-bit processors muvium executes on and the nature of the applications it is intended for which rarely require the full 32 bit operations a 16 bit integer was chosen.
Why not make it a short? A very good arguement is to make the integer a short and stick to the java specification. This is probably the way it will be done, however, shorts are cast to integers for internal operations and then cast back to integers giving little advantage in terms of speed.
Future work is to track which operands are shorts and remove the casting operators to keep shorts as shorts internally and hence restore muvium to specification while maintaining performance. A short aware javac compiler would be very helpful for this task also.
Limited Local Variables
Muvium gains its performance from operating over static frames. These frames are limited in size however which restrict the number of local variables that are available in a frame. Local variables limitations is probably the biggest gotcha for developing muvium java code. However, good coding practice which breaks big methods up into smaller methods and local variable re-use makes it easy enough to work with. Nevertheless, the available local variable space is about to be parameterised as the current sizes were created for the 16F devices and the 18F devices have more resources available.
At present, the limitations for a method frame are 5 local object slots and 12 local literal slots. This includes the parameters of the method.
- All objects, and arrays use one slot each from the available object slots
- Non Static Methods uses 1 object slot for the this object
- All literals, integers, chars, shorts, booleans etc, use 2 slots each from the available literal slots
LocalVariableCalculationExamples - examples of how to calculate local variable useage
FieldsReplacingLocalVariablesExamples - examples of how to use fields in place of local variables as a work-around
Future work is to parameterise the frames to enable frames to specify their requirements and to extend muvium with non-static frames for very large frames and accept the performance hit in return for full conformance.
Local Variables must Be Initialised
You must initialise your variables for them to be recognised by the muvium local variable calculator. This is a bug, but the work-around is simple. Initialise your variables when they are created, which is standard practice anyhow.
NO DONT DO THIS
int foo(){
int total;
for( int i = 0; i < 10; i++){
total+=i;
}
YES DO THIS
int foo(){
int total = 0;
for( int i = 0; i < 10; i++){
total+=i;
}