"Paolo Molaro" <[EMAIL PROTECTED]> wrote:
On 01/24/06 Jonathan Worthington wrote:
.NET has these managed reference thingies. They're basically like
They are called managed pointers.
Yes. And now I've misled Parrot folks into mis-naming them managed
references. D'oh.
pointers, but safe. What makes them safe is that only certain
instructions
can create them and the pointer value can't be set directly (we can do
that
fine - just have a PMC with an underlying struct that hold the pointer,
but
provide no PMC methods that set that pointer).
The value of the managed pointers can of course change (you can store
managed pointers to local variables...). This happens also when you
restrict your implementation to verifiable code.
Yes, I am restricting my implementation to verifiable code. When I said the
value of a managed pointer I meant the address where it points, not the
value it points at - of course the many stind operations change the value it
points at. But I can't see where in the spec where the address can be
changed in verifiable code - have I missed something?
Making them work on Parrot is no problem. Making them work without
comprimising the safety of the VM is harder. Amongst the things you can
I think you're approaching this from the wrong side. The IL bytecode is
checked for correctness and verifiability during translation and this is
completely independent on the VM that executes the translated code.
Assuming you don't introduce bugs in the translation and the VM works
correctly, after translation the code won't compromise the VM.
Translating .NET bytecode to Parrot bytecode isn't so cheap that you'd want
to do it "on the fly", so translation can be done ahead of time. This takes
in a .NET exe or dll and spits out a Parrot bytecode file. But my concern
isn't really code that has been through the translator, it's the potential
for malicious code to be able to use what exists to support managed pointers
to corrupt the state of Parrot. We don't really have any concept of
verification in Parrot, plus lack the knowledge to be able to do some kind
of static analysis (there's no distinct pointer type).
get a pointer to are parameters and local variables. Under .NET that
means
stack locations; with Parrot that means registers. So, imagine this.
Well, you'll need a stack in parrot, too, or performance will be
orrible.
How so? My translator maps the stack onto a set of registers, just like a
JIT compiler would. Only difference is they're software registers, not
hardware ones. As for parameters passing, Parrot uses CPS, though it does
build up a kinda "stack" of contexts. I'm translating calls so they use the
standard Parrot calling conventions though.
It's still not clear to me if your effort is supposed to build
a practical system or just a proof of concept, though. If you restrict
yourself to a subset of verifiable ops and don't care about speed, any
approach will work;-)
Well, at the moment the effort is to give me something to write a
dissertation about to submit for my degree. ;-) Long term I'd like to make
this usable and be able to run verifiable code. The point wouldn't really
be for anyone to use Parrot to run an entire .NET app on - they'd do much
better with Mono or the MS implementation. It's more along the lines of "I
have this library that's written in a .NET language, I'd like to use it from
my Perl 6 program" - where the point isn't so much performance any more, but
interoperability. Bytecode translation is only one way to achieve this, but
happens to be the one I chose to play with.
I think the only sane solution is to make sure that the integer
registers are at least pointer-sized and use them to store managed
pointers (not sure if this is possible with parrot: some time back there
was the policy of allowing to configure the size of int regs, so
making a build provide different semantics than another one...).
The only caveat is that you'll need to check those registers during GC.
Issue here is that there is no way to know which integer registers are
pointers and which are not, and therefore no way to restrict what can be
done to them. Much easier is making a managed pointer PMC which in turn
holds the pointer. This will get marked by GC already and we can control
what operations are allowed on them. No, the performance won't be amazing,
but see above.
BTW, from a quick look at your interesting blog:
"the arrays as supported by the VM are fixed length and can only contain
elements of a single type. One reading of the specification hints that
they are always object types, so a FixedPMCArray would do fine for any
array."
Arrays have an element type and all the elements will be of that type.
The element type can be almost any type, though, so not only objects,
but also bytes, integers etc.
Yes, I realized this later on - thanks for noting though. I am currently
using a ParrotIntegerArray and ParrotFloatArray for integer and floating
point types respectively, but can make that more efficient later. I suspect
Parrot will have PMCs for byte and short integer arrays respectively.
Also, if you care about the details: both arrays and strings must be
allocated in a single amount chunk of memory (but see above: with a
subset, non-pratical system you can ignore this).
I think this holds with the default Parrot implementations of strings and
arrays; if not I can always implement PMCs where the behaviour is like this.
Thanks very much for your input,
Jonathan
