I’ve been working on a module to provide assembly language support directly into the XOJO editor. I’ve been discussing this with the team at XOJO and they suggest that I announce it on the forum. Version 1.0 of the engine is complete and I’m currently working on updating it to the latest version of XOJO since just getting a new license. ALE uses no platform specific code so it should work equally well on all XOJO supported operating systems, not sure about IOS. I hope to have version 1.0 available for download in a week or so, and as soon as I find a place to host it. SourceForge? Not sure. Anyway the documentation for this version is complete so if you’d like to have a read before the engine is available then flick me an email.
Yes the assembly language does run in Xojo when executed. The assembly code is compiled and run within a custom sandboxed engine which can be accessed with Xojo wrappers to read and write data to and from the stack.
You can use the assembly code anywhere in your Xojo application you might use normal code, such as objects, functions and methods. Xojo code will still be required though for GUI and disk based operations as well as Xojo system type commands.
I’ve had some questions from friends not on the forum about the ALE engine performance so I’ll post my response. On my 2013 3.5Ghz i7 iMac I get on average about 10,000,000+ assembly language instructions per second, this is not taking into account the work which XOJO must be doing in the background. I am only counting the assembly language commands executed in the engine.
Now if we consider the following piece of assembly code which performs a loop of 5,500,000 it completes in exactly one second.
The loop_ command will look at the value held in ECX and automatically decrement it by one and if the value is still larger than 0 it will set the code execution point back to the label, now the label is actually a NOOP so the execution point drops straight back on the loop_ command, so it seems that we are really only executing one command repeatedly for a total of 5,500,000 assembly instructions per second, excluding the mov and lbl lines, just over half of my 10,000,000+. Why?
In reality the loop_ command is actually three instructions encapsulated into one. If we were to break the loop_ command out into its seperate steps then the code would look as follows.
So now in truth we need to multiply the 5,500,000 by three to get a total of 16,500,000 instructions per second, much better. Most ALE code I’ve written for testing executes so quickly that I’m not able to calculate timing. But truthfully the performance all depends on the code design and commands you’re executing.
The assembly code you type in the editor is actually XOJO code, or wrappers of each assembly command, which provides a bit compiled version of themselves to the assembly engine when executed.
As a little update I hope to release version 1 later this week. I’ve been mostly working on performance tweaks to the engine and now my one second loop test has been increase to 10,100,000 in a second when previously 5,500,000 would take a second, so almost twice the speed, and about 30,000,000 assembly language instructions per second. Strangely the major improvements have been achieved by replacing the code for many instructions with ALE code directly in the compiler, this has allowed me to strip an enormous amount of code out of the engine. I know it sounds weird, but it works.
For example, this is what the add instruction in the compiler looked like previously:
//Create a new code line object with the instruction bit
Dim NL As New ALE_Code(50)
//Add the param values onto the code line
addValCodeBit(nVal, NL)
addStringCodeBit(toMemLoc, NL)
//Add the compiled line onto the code array
addCodeLine(NL)
Actually the assembly functions you see in XOJO are compiled into bit code then executed in a sandboxed ASM engine, mainly because it is not possible in XOJO to create labels and subroutines within your methods like in assembler, which can then be randomly jumped around using the assembly Call, JMP, RET and conditional jump commands. Nor do you really have a stack or registers to directly address. Also I wanted to make sure you could not really break anything by directly writing to an inappropriate OS memory address.
In the old days you could just overwrite the address for the OS execution pointer and completely crash the system. Took one line of code actually.
Although the engine is sandboxed you can still read and write data to and from it using some additional wrapper for this purpose, so you can certainly use it for writing functions and methods. At the very least its great fun to play with…
If you wanted you could certainly use ALE to code your own functions and methods exactly as you would with XOJO code, you could use it as a learning tool, personally or at an educational institution, to examine assembly language concepts, or like me just for fun by recoding high level language functions in assembly just to see how they must really work underneath. I get a real buzz out of that.
In my early days of coding while lecturing at a University, I wrote a number of assembly language simulators so students could experience assembly language safely without the possibility of destroying or crashing the OS. ALE is just a much more advanced version of those.
I actually started my assembly coding journey pre your C64 on a VIC20. My first computer though was a Sinclair ZX80 with 1K of ram.
Hi Trig, what you are doing is fascinating and potentially very useful. I would appreciate a copy of the documentation you mention (gaines@ucalgary.ca).
Assembler was my primary language for many years starting with the Stantec Zebra in the 1950s, the Cambridge Titan, DEC PDP8, PDP9, PDP 11 and MINIC, an 8 bit micromputer I designed in the early 60s. I wrote systems for the London Stock Exchange, several hospitals, and instrumentation systems in the 1960s, all in assembler but in highly structured modular code, and added an interpreter in a Basic-like language with string processing capabilities modelled on Snobol and the Brooker-Morris compiler-compiler, to make IO, human-computer interaction, etc, making systems easier to set up and modify.
My last major use of assembler was in the 1980s when I purchased the source of a word processor (similar to FTC) from Gary Crandall written in Mac assembler, and modified it substially for my purposes (a groupware doc processor).
I have code now for logical inference and machine learning that could greatly benefit from recoding in assembler.
. Either way please be sure to post a link when you do!
