>> Several people besides you have suggested that they might go the other
>> way round and try running Rotor on devices
There are two issues I would think would be of concern:
1. The size of the resulting Binary
2. The size of the EE and core libraries
The size of the Resulting binary is an issue since I would think the big
issue with
running Rotor on Embedded devices is going to be memory limitations as
opposed
to processor speed limitations.
With respect to MSIL binaries the issue is that MSIL uses 4 byte OPCODES as
opposed to the JVM and Squeak which use Single Byte Opcodes thus the
resulting
size of the binaries of these VM's have the potential of being much smaller,
of course
one could add a new JIT to Rotor and JIT to an internal Single Byte Opcode
format
with escape Opcodes if you run out of instructions.
I have read in a paper by John Gough, that the intermediate language
binaries of the
JVM and CLI are comparable in size, but he didn't expand on this very much,
I am
guessing this may have something to do with how MetaData is stored in a CLI
PE File.
The specs say that the storage of MetaData in a CLI PE file is optimized to
save space.
Considering that the JVM opcode size is 1/4 of the CLI, is the inefficiency
of the .CLASS
file comming from possibly how the JVM stores it's info in the constant pool
?
One thing I would love to see for Rotor is a .o format as the Managed C++
compiler
currently has, this way one could save even more space and get the benefits
of the
granularity of the .CLASS file with the chunk loading abilities of the PE
files !
Any comments here ?
The other space saver would be to build an interpreter since directly
interpreting or
Hybrid interpretation / compilation would make requirements of the app
itself smaller
then if one used only JIT compilation as currently in Rotor.
This design for small devices via an Interpretable type specific Instruction
Set and
"Super" or "Quick" Instructions is obvious in the JVM Instruction Set.
The size of the EE and core libraries would depend on the goals of the
problem.
>> It would take a fairly beefy device to run Rotor unmodified, since the
codebase
>> was designed for the PC form factor.
David could you comment on what you think it would take to say chop up the
Rotor
EE / core libraries to all but the most basic functionality needed say the
Kernel Profile ?
Is it feasible to get Rotor running in 32 Megs of RAM ?
Also what ramifications would this couse to the PAL, I am assuming that one
would
not need all the functionality provided by the full PAL in an embedded
device context.
>> or else with some substantial cutdown mods to the code.
Could you expand on this a bit.
>> It would be very cool to see a mindstorms port!!
Interestlying there is allready a Smalltalk port to the Lego MindStorms,
there was an article on it
in the Journal of Object Oriented Programming a Couple of Years Back.
Although I don't remember if it was Squeak or some other VM.
Yahya Mirza
Aurora Borealis Software
