Take your time, this is a lengthy post. Before I jump in the matter, I want to go back a bit.
The magic of C64 Assembler
One of my first experiences with computer programming was on the C64. My dad bought my uncles C64…… Of course we played games at first, but at some point I started to look at all the books that my uncle had gaven with it. One of the first books I opened up and started playing with was called “Basic for Beginners”. I remember thinking, wow, so this is how you make games ? I started playing with existing programs and later on began writing my own, such brilliant programs as “My cassette collection” and “Adding Numbers”. But what I really wanted was to write my own games.
How come my C64 basic programs where always so slow ? Surely, there must be something I was doing wrong. With nobody around to teach me, or tell me anything about this machine, I dived in the pile of books that came with the computer once again. Two books took my interest. “C64 Programmers Reference Guide” and a home printed & binded book that had written on it “C64 Kernel listing”. I had two problems with these, being 1, my ability to read english and understanding the magic listings this book had. It took me a long, long time to grasp what these books where saying, but these 2 books, together with a dutch book on C64 programming, I slowly learned how to do 6510 assembly language for the C64.
This was the realm of pure magic. All of a sudden things went a lot faster. Moving a sprite along the screen could be done fast and smooth. But things where a lot more complicated. 6510 (or actually 6502, for the purists) asm, although especially now a days, quite simple, isn’t exactly humanly readable, nor was it clear to me how to structure full programs or games. I learned how to do a lot of tricks, like getting more then the 8 hardware supported sprites on screen at the same time (something then called multiplexing), playing sound while still having being able to do other things at the same time, getting sine waving color bars on screen and screen border, but I never managed to build a full game. What I learned about that was that interpreted basic was a lot slower then assembler and if you wanted to get real speed you’d have to target the platforms native code. Assembler wasn’t magic, it was just a better way to target the platform.
Back to current day.
I’ve been working with Flash for almost 9 years now. I dare to say I know quite a lot of Flash as a platform, and have been doing many projects and experimentation with it. Last year at MAX, when FlaCC or now, Alchemy was shown it looked like pure magic! Sure, I understood the basic principles, but running Quake in the Flash VM was nothing short of magic. Running Quake within the Flash VM using a port of the C code was quite an achievement, but the speed was more incredible. This was nothing short of pure magic, like turning lead into gold!
It’s an ironic name Adobe chose for FlaCC. Let’s look at the word and dabble into the occult. There’s a clear distinction between alchemy and science. Alchemy is most known for trying to create noble metals from otherwise less-valuable materials. Even Sir. Isaac Newton spent a lot of time in the field, surprisingly, even more time then he spent working on subjects such as optics and physics, for which he is most known. In a way, Alchemy is the forerunner for what now is chemistry. From the occult to exact sciences. So, with that name, is Adobe suggesting Alchemy is pure magic ? Turning lead into gold ?
Is it witchcraft ?
After the initial amazement I had with seeing Quake run within Flash, I started to question some things and started asking around with people who might know more of this witchcraft. Was this really Flash Player 9 running this ? From multiple sources I heard it was a slightly modified version of the Flash Player 9. Something to do with reserving a block of memory. Later on, after finding Scott Petersen his LLVM session on this subject, this was confirmed. In this session, Scott also shows an emulator running on top of the Flash VM. Having some experience in the FC64 (a commodore 64 emulator for flash) project, again, the speed was pure magic.
What I ended up finding most interesting about Alchemy, wasn’t the ability to take C code and compile it to Flash (although that’s an incredible achievement on itself), but the pure raw speed it seemed to harness. And with that, I also got a bit disappointed in Flash. It boils down to this.
The first magic bullet in Flash speed came in the form of the ActionScript Virtual Machine 2. With JIT compilation of ActionScriptByte code the platform just became a whole lot faster. With the coming of the AVM2, lot’s of things have changed. For me personally, one of the displays of the game changer was Papervision3D, in which I got involved quite early on. John Grden’s early demo using Papervision3D running on AS3 was an incredible testament to the speed of the AVM2. Now, that demo was built using ActionScript 3 as the language to be compiled down to ABC. ActionScript 3 is the language which was intended to run on top of this platform and one might thus derive that the language and it’s compiler is most optimized for the AVM2. So logically, one might asses that the best way to write code for the AVM2 is using ActionScript.
Heresy I say! Heresy! Burn the witch!
Alchemy is proof that this is not the case. Here’s a bit of pure heresy in the Adobe church : Alchemy is a testament to the underachievement of the ActionScript compiler. Ouch. Surely, this can’t be the case, right ? Well, yes and no.
Let’s start with the “no” part. That reference of a modified player running Quake was partially true. This was an early demo of Flash 10, in a way. As Nicolas Canasse points out in this blog post about Alchemy virtual memory opcodes, it seems like Alchemy is cheating a bit. Cheating ? While, yes. This part of the API is not available from within ActionScript itself. So, the platform (AVM2) now has features which are not supported by the language which is native to it ? Wow. I find this a very significant move by Adobe. Moving to a more flexible compiler makes total sense, but is this the first symptom caused by the EcmaScript4 draft debacle ?
To achieve the speed as displayed by Alchemy, I have thus have to move to using C code, or HaXe to compile for the AVM ? This is odd, to say the least. Nicolas his work on HaXe is nothing less then brilliant. The features this compiler has are those which would greatly help the development of a 3D engine, such as Papervision3D. I’ve always had a great deal of interest of porting Papervision3D to HaXe, purely to be able to implement things like inlining easily, which will safe us function calls and thus speed up the process of rendering 3D to the screen. The downside to that is, that the code base would have to change to HaXe, and thus become incompatible with the compilers of Flash and Flex. We (Papervision3D) could provide with a SWC built with HaXe, but in a way, I’m still a bit weary of that.
Now we come to the yes part, of my earlier “yes and no”. Next to the virtual memory opcodes that are currently unsupported from within the AS3 language, Branden Hall states something very disturbing on his blog about Alchemy, “Understanding Adobe Alchemy“.
“In fact, because LLVM does a lot of optimizations, whereas Flash and Flex have no optimization step built into their compilers, Alchemy code manages to overcome a lot of it is overhead just on its own.”
Ok, that is down right disturbing. The AVM2 was built with ActionScript in mind and visa versa. But compiling C using LLVM with ActionScript as a target produces better faster ActionScript (that’s actionscript, not bytecode) then the actual compiler built for the platform does ? Ouch. Now, moving to C development for the ActionScript platform to utilize this “magically” acquired speed seems somewhat illogical to me ? Joa Ebert already showed us some work he had done on the compiler, allowing for inline bytecode to be used. Nicolas shows us he can harnass the new Virtual Memory Opcodes, and his work on HaXe also shows us that inlining is very, very nice.
I’d love someone from adobe shedding some light on this issue. I love the Flash Platform, I love the work all the people at Adobe do, but this leaves me somewhat confused on how to develop for the platform I hold so dearly. If we have to let go of ActionScript to harness the pure speed Alchemy proofs is possible, then tell us. What is the future of our beloved language and our compilers for it ?