On 01/24/06 Jonathan Worthington wrote: > .NET has these managed reference thingies. They're basically like
They are called managed pointers. > 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. > 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. > 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. 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;-) > 1) A two part solution. > > a) Make set an MMD operation. This way, a .NET managed reference PMC knows [...] > b) Add a v-table flag saying "returning me is forbidden" and checking that [...] > 2) Add a new Reference register type. We have INSP, so we'd also have R [...] > Maybe someone has an idea for a better way. Anyhow, that's the problem and > the ideas so far. Comments and suggestions very welcome. 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. 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. 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). lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
