3 ms·

Try to implement the flash AVM2 virtual machine: http://mahmud.arablug.org/avm2-opcodes-complete.txt http://mahmud.arablug.org/avm2-opcodes-complete.txt I sta

by mahmud 16y ago

Try to implement the flash AVM2 virtual machine: http://mahmud.arablug.org/avm2-opcodes-complete.txt http://mahmud.arablug.org/avm2-opcodes-complete.txt I started work on it in Lisp and made some minor progress when Adobe decided to cockblock and released Tamarin under the GPL. Bit more stuff: http://mahmud.arablug.org/avm2-undocumented-opcodes.txt http://mahmud.arablug.org/avm2-undocumented-opcodes.txt Feel free to pick my brains on the flash platform, if you want your toy to support multimedia. I got a gut-full of it with absolutely no possible use :-/ [Edit: Should you go the flash route, I should be able to pull some IRC logs of interesting discussions as well.]

aarongough 16y ago
Thanks Mahmud! I'm not really interested in re-implementing another language at the moment (though I probably will in the future), but it's really good to read the documentation/opcodes for other VMs. Others I've had a look at so far are YARV, Parrot and Lua. I definitely need to check out the docs for the JVM at some point too...
mahmud 16y ago
Let me add that language design != language implementation. Try to prototype your language design in a very high-level language, preferably one with macros. So you can iron out the kinks rapidly without being bogged down by machine limitations. Also, try to use a homoiconic syntax for easy parsing, so you're not stressing over lexical analysis and other string manipulation crap. Once you have the high-level semantics ironed out, you can choose a suitable intermediate representation, one that can handle several phases of optimization. Register or graph based IR, like SSA, will allow you to capture code and data flow, and it presents an underlying "machine" architecture with abundant resources (cheap infinite registers for starters.) Stack-based IRs are compact and excellent for virtual interpretation, they also capture lexical scope and procedure call very well, but you will have to expend a bit more effort should you want to compile them for a native processor. The easiest language to implement would probably be a block-structured Algol dialect (say, Oberon or Pascal) but without runtime heap allocation. That way you're not messing with garbage collection. You can allocate your application memory at startup or compile time and it will sit and stay in there. See Chapter 10 of this: http://homepages.cwi.nl/~steven/pascal/book/pascalimplementation.html http://homepages.cwi.nl/~steven/pascal/book/pascalimplementa... If you want first-class environments and closures you will need GC and a heap. You will also need a heap if you want first class objects or dynamic exception handling. The language design stuff is boring, and you can be inspired by various designs out there. It's the runtime implementation that's funny, but very exciting. Good luck.
- aarongough 16y ago
  I like the idea of prototyping the language syntax in a high-level language, it reflects nicely what I'm currently doing with the VM. I'll definitely look into that. Clearly I still have a lot more reading/learning to do! Should be fun :-p

by mahmud 16y ago

aarongough 16y ago

Thanks Mahmud! I'm not really interested in re-implementing another language at the moment (though I probably will in the future), but it's really good to read the documentation/opcodes for other VMs. Others I've had a look at so far are YARV, Parrot and Lua. I definitely need to check out the docs for the JVM at some point too...

mahmud 16y ago

Let me add that language design != language implementation. Try to prototype your language design in a very high-level language, preferably one with macros. So you can iron out the kinks rapidly without being bogged down by machine limitations. Also, try to use a homoiconic syntax for easy parsing, so you're not stressing over lexical analysis and other string manipulation crap. Once you have the high-level semantics ironed out, you can choose a suitable intermediate representation, one that can handle several phases of optimization. Register or graph based IR, like SSA, will allow you to capture code and data flow, and it presents an underlying "machine" architecture with abundant resources (cheap infinite registers for starters.) Stack-based IRs are compact and excellent for virtual interpretation, they also capture lexical scope and procedure call very well, but you will have to expend a bit more effort should you want to compile them for a native processor. The easiest language to implement would probably be a block-structured Algol dialect (say, Oberon or Pascal) but without runtime heap allocation. That way you're not messing with garbage collection. You can allocate your application memory at startup or compile time and it will sit and stay in there. See Chapter 10 of this: http://homepages.cwi.nl/~steven/pascal/book/pascalimplementation.html http://homepages.cwi.nl/~steven/pascal/book/pascalimplementa... If you want first-class environments and closures you will need GC and a heap. You will also need a heap if you want first class objects or dynamic exception handling. The language design stuff is boring, and you can be inspired by various designs out there. It's the runtime implementation that's funny, but very exciting. Good luck.

aarongough 16y ago
I like the idea of prototyping the language syntax in a high-level language, it reflects nicely what I'm currently doing with the VM. I'll definitely look into that. Clearly I still have a lot more reading/learning to do! Should be fun :-p