Version 1.2 is now available with its editor and inbuilt debugger. If you use this version I’d recommend you build it as a standalone application to get the best performances out of your code. It comes with a few samples of code to play with as well. If you write any code you’d like to share then sent it to me, then I’ll add it to the library of sample code to include with each build. Like wise if you make any changes to the editor then send those as well for me to distribute further. I’ve made the code for the text to ALE converter available to everyone as well, also my very simple XML code. The text to ALE converter code looks insanely complex but that’s only becuase it has to do an enourmous amount of syntax checking before calling the correct internal ALE method. Currently the only real limitation with the editor is that comments can only exist on a line by themselves. Also I haven’t implemented a way to change text size or colour in the editor, there is also no code sense or parameter highlighting, if someone else wants to work on that it’d be great.
Anyway the new version includes the following:
Engine simplification
Significant engine performance boast
Exception checking on stack reads and writes, your ALE program may crash if you do the wrong thing, the nature of assembly coding, but the editor shouldn’t.
Completely redesigned Code development program with integrated editor and debugger
New len, shr and shl instructions.
Reading characters off the stack into a string now requires a count of characters stored in ecx
Well, I’ve finished adding all the original X86 instructions into the 1.3 engine, and I’ve also added variable and label scope checking into the compiler, which can make your code so much more robust. I only have one thing left to add, which is resetting subroutine local variables back to default on exit, before I start to investigate the daunting, and very valid request from @Kem_Tekinay to get the engine running more than one program at a time. I don’t see this as too difficult, but I think retaining performance is something I’ll have to work on… No bare metal instruction calls though, I tried that and OSX got very upset with me… lol. I’m now very good friends with Kernal Panic… Just to clarify I was playing with a command line assembler not calling instructions from XOJO, was just messing around to see what I could do…
What I’m thinking to make this so much more useable, is to pass the pure assembly or compiled bit code you’ve fully tested in the editor directly to the engine and it will compile and run it. You’d store the assembly code in a constant or a string to load whenever you wish.
All you would need to type in Xojo would be something like the following:
RunCode(“ProgramName”, sourceCode, true)
The true meaning run immediately, and if false then the following:
RunCode(“ProgramName”)
You’d still have a number of wrappers to read and write to variables within the program but most everything else would be hidden. It’d be a lot simpler.
It is actually a wrapper for x86 assembly language instructions. The editor allows you to write pure assembly code then it generates the Xojo wrapper commands to execute it in a sandboxed engine.
While I was having a sleepless night and struggling to come up with an easy solution to reset subroutine variables back to default on exit, I remembered a little trick we used many years ago when writing an actual assembly compiler and linker.
So how do you reset subroutine variables back to default on subroutine exit? Well, rather strangely, the answer is you don’t, you don’t even bother.
What you do instead is incredibly simple, rather than stripping the variable’s definition from the compiled code as you normally would, you simply replace it with a mov instructions to reload the variable’s memory location with its default value. Too simple.
Now whenever the subroutine is called the variables are set back to their defaults as we wanted, and we haven’t had to create a complex subroutine map or add extra code to reset the variables when we detect a ret instruction.
I’m sorry but due to regrettable reasons mentioned in a different thread the Xojo version is no longer available. It also bares little to no resemblance to current ALS engine I’m working on for education, when I’ve completed the ALS project I’ll look at releasing a new version for Xojo which gives far better assembly language support and much greater performance.
