> The RCX is perhaps once of the most minimal devices around with a low
amount
> of CPU and memory space to work with, from what has been said so far
getting
> Rotor to work on it would mean stripping down Rotor to a large degree ?
Does the RCX even have a hard drive, I don't think it does, thus another
issue would
be the problems of not having virtual memory.
Note from publicly available info, Xbox doesn't have Virtual Memory but it
only has
64 megs of RAM, they use other techniques to reduce memory without loosing
speed,
like only having a single process, having static libraries, as well as
slimming the OS itself.
Thus Xbox images tend to be very static, they don't rely on tiny little
components that
get loaded and unloaded transparently all the time. Their OS or Runtime
(lack there of)
doesn't support that.
Additionally another issue is the Instruction Set of the Embedded Processor,
for
example some processors don't have all the instructions you need so then you
would have to emulate the core instructions you don't have, another reason
for having
a Threaded Code Interpreter or a hybrid system for low memory devices :)
What processor does the RCX have, I talked to the Lego guys a long time ago
at Siggraph
when they first demo'd the Brick, and I know that had their own Behavior
Description Language
to write the controllers of the Brick, but I also remember you could do some
coding using VC6,
I am not sure about this though.
Does the RCX use a Intel CPU ?
>> This is why I was wondering about the compact framework, work on porting
the CLI to
>> devices has been done so it makes perfect sense to me that such work is
rolled into
>> Rotor.
I think this might be an incorrect way to think abou this, I don't see
"code" from the compact framework being rolled into rotor, but some
of the implementation techniques they use in the Compact Framework
definitely could be applied to Rotor.
You have to remind yourself that interpretation isn't allways bad, JIT's
are cool, but a really modern high performance interpreter could potentially
do wonders with saving space.
For example their are several techniques in the VM community to make
interpreters fast "really fast" examples of these techniques or "Patterns"
are:
* Direct / Indirect / Call Threading
* Internal Opcodes ( Converting to a internal more optimized format)
* Super Instructions or Super Operators
* Selective Inlining
* JVM's Quick Instructions
* etc. etc. etc.
My personal favorite VM system BEFORE the CLI :) was Self and it's VM, they
created
an interesting object oriented langauge paradigm and then figured out how to
make it really
crank. I guess you could say they focussed quite a bit on Performance
patterns whereas
the Smalltalk community did that as well, but also did work on Memory
Reduction Hacks.
The Self language guys did tons of great stuff in the 80s and early 90's
that's been in hot
demand since JVM took off.
Interesting note is that the HotSpot JVM started as a bunch of techniques or
Patterns that
were learned form Self and applied to build a high performance Smalltalk
Virtual Machine.
When Java took off, they leveraged the techniques.
Some of these "Patterns" could be useful to a potenial Low memory version of
Rotor
one could pick and choose and apply these patterns to Rotor one at a time
to see which ones work well.
Additionaly the same could be said for object layouts, GC etc. etc Tradeoffs
matter
a ton, the tradeoffs that were used to get Rotor out were not the ones that
are
what you are interested in, thus the key question is:
What are the techniques that the Rotor implementation currently embodies and
what
are the tradeoffs of those design descisions to the problems of low memory
devices
like the RCX.
So when you think about CLI implementations, first ask your self what
problem
you are solving and then look at several implementations of different VM
based
languages and you'll start to see which solutions map well to which
problems.
As I said in my previous posts, I would think that memory is the big one,
and that
you would have to identify a ton of Memory Reducing Patterns that have been
applied before to implementation of the Virtual Machine itself in the early
80's that's
when all the really neat stuff was being invented and try applying them to
Rotor.
>>
Frank or other VM gurus, if you are reading this, are you utilizing Adaptive
Compilation
in the Compact framework, in the talk you gave at the MS Cambridge you
mentioned
Threaded Code. Does the Compact Framework JIT to an internal format part of
which gets
interpreterd to save space and part natively compiled depending on useage ?
Interestingly there are some elements of that in Rotor's JIT, you can see
there are some
instructions that are not CIL instructions, some of the these are
implemented using functions
as opposed to JITTing.
If the Rotor Jitter guys are reading, did Rotor JIT start out as a Threaded
Code Interpreter
thus these "internal instructions" I am seeing are the remnants of the once
aged Threaded Code
Interpreter now evolved into a native JIT ?
>>
Sorry for the long post :)
Yahya
