ALE Version 1.1 is now available. For a point release this version contains an enormous number of changes and fixes. In my mind this is what version 1.0 should have been. I recommend this as a required upgrade for all users.
Major changes include:
Simplified and profiled engine design
Extensible language and macro support
Addition of string and numeric variable datatypes
Additions and improvement of all XOJO wrappers
Memory reduction by duplicate constants detection
Addition of constants, variables and strings data table
Improved bounds update to include constant and variable data
Clean up and reordering of bit codes after extensive profiling
Improved documentation with numerous updates
Lots of sample code
The code development program has also been heavily updated. It now contains commented examples of using all core instructions, examples of calling ALE programs remotely from a label, using ALE code in your own functions, extending the ALE instructions with your own commands or macros and finally examples of using every XOJO wrapper.
As always send me any issues or questions you have. If you can’t get a piece of code to run then send that to me as well and I’ll gladly troubleshoot it for you.
I’ll stop spamming you all for a while now, I really need a rest, and I’m not sure at the moment what changes to makes for the next version.
Sorry, I just re-released Version 1.1 because I found an error which I hadn’t noticed from the very beginning. It all had to do with certain label NOOP’s not being created in the complied code, so jumping to that label could mean you miss a real line which needed to be executed.
The only reason I found the error was because of the new code viewer and debugger I’m including in version 1.2. Amongst other things 1.2 has a much simplified and faster code engine. Here’s a picture to show you what’s coming, in a few weeks probably.
I not sure what you mean? The license agreement says you can use the ALE engine in your commercial apps and if you do a donation is welcome. It’s only the development program you can’t distribute for profit.
… may be I missed something. Neiter the word “business” nor “commercial” is anywhere in your PDF. The only part I found is:
License Fee.
ALE is licensed as donation ware. If you use it personally, for fun, education or distribute it compiled within your own applications or maybe even as a learning tool at an educational institution, then a donation to help with development would be greatly appreciated. You can make a donation into Trig’s PayPal account using the email address trig.charters@icloud.com.
This does not tell me anything about delivering my code to someone and get money for it - this is where I live from
So may be you mentioned it somewhere else? Thanks a lot,
Michael
If you click the license agreement button, on the dialog that shows the license fee, you get the complete license agreement.
License Agreement.
The ALE module which encapsulates the Assembly Language Engine for XOJO is CLOSED SOURCE. It is completely and wholly designed and maintained by Trig Charters and Trig Charters retains copyright and all intellectual property rights to the design and code held within. You may not attempt to decrypt this module nor attempt to reverse engineer its code or functionality. You may not distribute it to any third party except when included in your own compiled application.
The ALE Code Development Program, is OPEN SOURCE. You are free to modify this application to assist with the development of your own ALE code. You may not however distribute compiled or built versions of this application to a third party for profit. You may distribute uncompiled versions with your changes to other members of the XOJO and ALE development communities. Compiled versions may only be used locally for code performance testing.
You as the user accept all responsibility for any damages that may occur from your use of the ALE module or the ALE Code Development Program. Though every effort has been made to sandbox the assembly language engine from any external access the developer, Trig Charters, cannot be held responsible for any issues which may occur from its use.
Any changes or suggestion of changes to be made to ALE are approved or denied solely at the discretion of the developer Trig Charters. Any changes approved and included in the Assembly Language Engine are copyright Trig Charters and Trig Charters retains all intellectual property rights to any changes made.
If you wish I’ll update it with your business or commercial applications.
The New agreement, I’ll update the doco and app in the next version:
License Agreement.
The ALE module which encapsulates the Assembly Language Engine for XOJO is CLOSED SOURCE. It is completely and wholly designed and maintained by Trig Charters and Trig Charters retains copyright and all intellectual property rights to the design and code held within. You may not attempt to decrypt this module nor attempt to reverse engineer its code or functionality. You may not distribute it to any third party for profit except when included in your own compiled business or commercial application.
The ALE Code Development Program, is OPEN SOURCE. You are free to modify this application to assist with the development of your own ALE code. You may not however distribute compiled or built versions of this application to a third party for profit. You may distribute uncompiled versions with your changes to other members of the XOJO and ALE development communities. Compiled versions may only be used locally for code performance testing.
You as the user accept all responsibility for any damages that may occur from your use of the ALE module or the ALE Code Development Program. Though every effort has been made to sandbox the assembly language engine from any external access the developer, Trig Charters, cannot be held responsible for any issues which may occur from its use.
Any changes or suggestion of changes to be made to ALE are approved or denied solely at the discretion of the developer Trig Charters. Any changes approved and included in the Assembly Language Engine are copyright Trig Charters and Trig Charters retains all intellectual property rights to any changes made.
License Fee.
ALE is licensed as donation ware. If you use it personally, for fun, education or distribute it for profit compiled within your own business or commercial applications or maybe even as a learning tool at an educational institution, then a donation to help with development would be greatly appreciated. You can make a donation into Trig’s PayPal account using the email address trig.charters@icloud.com.
I wish I could peak behind the curtain, but since I can only see what you expose, please correct me where I’m wrong.
It seems that the engine compiles and executes on demand. For example, in your uppercaseString method, it looks like to compiles the code, then provides data for the “inString” variable, then runs it, and it looks like this happens every time the Xojo function is called. Is that right?
Assuming it is, would this make more sense as a class where the encapsulated code could be compiled once and called many times?
(Keeping in mind that I know next to nothing about assembly so the question itself might not make sense.)
For the purposes of the uppercase string example in 1.1 yes you are correct, the engine is reset and code recompiled and run each time, though you don’t have to do this. You could very well load a whole library of different functions or methods into the engine at the start of your XOJO application then call them individually at any point by just calling their label name, then no recompiling is ever required, so the upper case string function could now look like:
Let’s say I want to distribute code based on ALE and I use the steps you outline above. A user imports my code alongside his own that also uses ALE in the way you describe. Wouldn’t one clobber the other?
I’m not quite sure what you mean? When you distribute the ALE engine it must be compiled into your built application, so in this case the other user wouldn’t have access to write ALE code so your’s wouldn’t be clobbered.
However if the other user is also a XOJO developer using ALE, then yes if they import their own ALE code then your’s would be clobbered, as the engine can only have one compiled ALE program within it at any time. There is nothing to stop them from adding their functions or methods to your ALE library, or alternatively they could just reload your library again when they needed it. Compilation is extremely fast so there wouldn’t be a noticeable delay.
I hope this answers the question or have I completely misunderstood.
To do that I would have to create a class which encapsulates a seperate stack, codeStack, variableStack, stringStack, execution stack, registers and everything else I’ve forgotten which goes along with a compiled ALE program and the simplest simulation of a CPU. Then I’d have to have an array of these classes so you could have as many programs loaded as you wish.
Although this sounds like a great idea, while not impossible, it would add a great deal of complexity to the engine and classes themselves are very slow. I’ve improved the speed of ALE hugely by dereferencing everything I can from the class object and now a simple loop to a million takes just 0.05 seconds compared to 2.2 seconds at the beginning when I was referring to the existing class object.
As compiling a ALE program is so fast it seems a better option to just switch between the appropriate libraries when you need them, rather than to add extra overhead to the engine. Though I do like the idea and if I could maintain the same level of performance I’d certainly look at it.
I’m not sure why you’d need to maintain an array. As a consumer of your module, it would be up to me to store or discard that as needed.
Given your current API, you might be able to do something like this:
(Pseudo-code)
ALE.StartCode
// Add instructions
var code as ALE.VMData = ALE.FetchAndReset
code.SetVariable a, b
ALE.Execute code
Internally, Reset would create a new copy of the ALE.VMData class to store the encapsulated data. StartCode is needed to keep two Threads from clobbering each other. The engine would use the class arrays/MemoryBlocks/whatever directly. To facilitate this, you could create a local Class Interface that would allow you to fetch that data. Most of the methods and functions would stay in the module but the actual vm would reside within the class.
My M_Crypto module implements, among other things, AES and Bcrypt. I’ve made both reasonably fast but have hit the wall with what I can do in pure Xojo code. Your module would potentially let me break through that wall by rewriting some parts in assembly.
Legalities aside, my usage of ALE would clobber ALE usage elsewhere in whatever project it’s dropped into, especially if others have the same idea. Encapsulating the code would (should) 1) speed it up as it would only have to be compiled once, and 2) allow my code to coexist in a project.
This may never come to pass, but it’s this use case that has prompted my comments.
By plan I designed ALE as a single threaded original 8086 simulator, like the original 8086 it was never designed to run more than one program or instruction at any one time, to allow this I would need each program to have its own dedicated memory pool for code, stacks and registers which none of the other programs could clobber. I may be able to, with some work, implement an original time slicing method in the current engine but it would never be truely multi-threaded. That would require a complete rethink and redesign.
I’ve written quite a few programs using ALE now, and using code libraries or just compiling on the fly I’ve so far never needed to run more than one program in the engine at a time. That may be just me as I come from a procedural coding background.
Currently I’m working on an editor for 1.2 in which you can write your ALE code and fully test and debug it before copying the generated code into your XOJO application. This is beneficial as you can run your code in a fully built version of the engine so you get to see your code running at full performance. You also don’t need to start and stop your own program to write code and then try to figure out what’s wrong.
Just quickly your suggestions have prompted me to add one feature I never considered. Your can now set and read a loaded program name from the engine, so you can quickly use this to check if your required library is loaded or if you need to reload it.
//This resets the ALE Engine for a new program
reset_ALE
//This sets the program name identifer in the engine for your code
setCodeName_ALE("UpperCaseString")
//Program Start Label
lbl "_start:"
Is there any way to actually retrieve the code as, say, a Base64-encoded string that could then be easily loaded into the engine to restore it? If so, one could write the code, save that result to a constant, then load it when needed within the app.
It wouldn’t be too hard to return the compiled code, but where the problem lays is you’d also need to return the stacks and memory state so when reloaded the memory and stacks are in exactly the same state for the program to continue.
This actually happens on a real CPU when time slicing multiple processes on a single thread, even on current generation multicore CPU’s, the register states needs to be saved and then reloaded into the CPU the next time an instruction from the application is executed.
I 'm not sure if anyone realises just how quickly an ALE program is compiled and loaded into the engine, and I use the word compiler in a very loose sense. The commands you type into XOJO are actually just wrappers for each of the assembly commands. The XOJO editor has already done most of the syntax checking by making sure you are calling the correct overloaded method with the right parameter types. These wrappers are then compiled into native code when you build your application so when called they execute incredibly quickly. The only thing that needs to be done after all the code is sent is to make sure that all the variables and labels have been defined. Another very quick process.
The compiler, if you wish to call it that, is a line compiler and takes no consideration of program flow when the instructions are being sent, so there is even less checking to be done.
With the new editor I’m working on you can create your ALE code for XOJO in as quick a fashion as possible, and the inbuilt debugger helps even more, its actually help me find bugs in the engine. It generates the code for XOJO with all the correct input and output functions defined and ready to go.
