ALE Assembly Language Engine 1.2 now available

Hi Everyone,

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
  • Integrate help file
  • Bit Codes extensively re-profiled and reduced
  • Documentation Updates
  • Bug fixes

Enjoy :slight_smile:

Trig

4 Likes

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…

:slight_smile:

TC

3 Likes

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.

Just a thought…

TC

1 Like

Out of interest, is this a wrapper for xojoscript or have you essentially done a similar thing to xojoscript but for a different syntax?

Hi Julian,

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.

Regards

TC

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.

Sometimes it’s good to remember the old ways. :slight_smile:

TC

1 Like

that all sounds so great, can’t wait learning assembler …

1 Like

Thanks, you’re always welcome to ask me any questions…

TC

I loaded the “ALE Code Development Program.xojo_binary_project” project, run it and get 201 errors.

What was wrong with me ?

PS: version 1.2, of course.
With Xojo 2021r2.1.

HI Emile,

I would suspect that you haven’t imported the ALE module included in the ZIP file.

Regards

Trig

Done, now it works.

1 Like
Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.