Why Aztec - Powerful, Compact and Efficient
We found things to do in stormy weather...
Long may you run.
- Neil Young
This is the first of six "Why Aztec" pages. Individually, each of them describes a significant, positive benefit associated with the Aztec programming language, framework, environment or all three. As a collection, they tell a compelling story that the Aztec Engine offers a unique combination of features and technologies that are well thought out, consistent, well implemented, and worth considering for future development plans.
The entire Aztec Engine system is contained in a single executable file which is only 1.81 MB in size. This one small file contains the Aztec Compiler and Build System, Aztec Virtual Machine, the entire Aztec Class Framework, and a network based UI Display Server subsystem. The Aztec Engine software requires no special installation or setup. In an age where development environments and run-time class frameworks are huge and unwieldy, Aztec's compact yet powerful solution is refreshing, and can also make good business sense.
The following diagram provides a high level view of the separate Aztec Engine components and how they work together.
The complete set of Aztec Engine components as shown above provides a consise, compact and efficient programming solution with a high degree of cohesion between them. The individual components work very closely together in a variety of ways to provide a powerful and flexible programming environment.
Aztec Compiler and Build System
♦ Compiles source module(s) and creates a binary Aztec bytecode executable (-comp)
♦ Compiles source module(s) and immediately executes the code by sending the bytecode to the Virtual Machine (-exec)
♦ Compiles and executes source code dynamically at run-time on demand based on request from Class Framework and VM
♦ Integrates the new code at run-time into the Virtual Machine, Script Metadata and updates virtual method hierarchy tables
Aztec Virtual Machine
♦ Executes Aztec bytecode from a binary file previously created by the Aztec Compiler
♦ Executes Aztec bytecode from memory which was just created by the Aztec Compiler from Aztec source module(s)
♦ Manages execution of all Script Threads based on the bytecode and the definition of the Aztec VM Instruction set
♦ Manages Script Metadata with multi-threaded synchronization, and provides multi-threaded event handling infrastructure for Aztec Events
Aztec Class Framework
♦ Family of over 120 classes in many categories, including Primitive, Compiler, Script and Thread, Thead Synchronization, Metadata, Events and Exceptions, Collections, Steam I/O, Time and Date, Sockets, Sorting and User Interface.
♦ Majority of the class framework is written in C++ and uses Aztec Plug-In Framework Interface to communicate with Aztec Compiler and Aztec Virtual Machine
♦ Every method in the Primitive Class Framework is directly tied to a Virtual Machine Instruction to maximize the performance of using primitive classes
♦ UI class framework methods send messages directly to UI Display Server for local UI , and to remote UI Display Server via Sockets for remote UI
♦ Provides access to a remote message server using Aztec Sockets to receive Script messages from a remote Aztec Script
♦ Works together with serialization utilities to provide a simple mechanism for remote object transfer
Aztec Sockets Subsystem
♦ Provides TCP/IP socket functionality for the Socket family of classes in the Aztec Class Framework
♦ Provides server functionality and peer-peer client communications for Remote Messaging functionality
♦ Provides server functionality and peer-peer client communications for Remote UI Display Server functionality
Aztec UI Display Server
♦ Provides "Local" UI services for an Aztec Script running in the Virtual Machine within the same instance of the Aztec Engine
♦ Provides "Remote" UI services on one machine for an Aztec Script running on a separate machine (-display)
♦ UI Display Server underlying C++ code is implemented in two tiers, platform independent code and platform dependent code, to aid in porting to other systems
Aztec Engine System Menu
Aztec Interpret UI and the VM Ad-Hoc Thread
♦ Provides a UI to compile and execute ad-hoc Aztec Source Code within the context of an already executing Script (-interpret)
♦ The feature uses Aztec dynamic code generation to compile, integrate and execute the Aztec source code on the fly
♦ Ad-hoc source code can directly access objects and methods from within the executing Script if visibility settings allow it
♦ Useful debugging and unit test tool for running ad-hoc dynamic tests on a running Script
Aztec Console and Standard I/O
♦ Virtual Machine provides a Console Window to support Aztec Standard I/O read and write services for the framework (StdIO.Read(), StdIO.Write())
♦ If "-stdio" is used on Aztec Engine command line, Virtual Machine redirects StdIO.Read() and StdIO.Write() calls to automatically use Operating System standard I/O services
Aztec UI Display Server Statistics
♦ Dialog displays statistics about remote UI Display Server processing, which is available in the system menu when running in "-display Port" mode
♦ For each Display connection, it shows the name, IP Address, connection status, number of UI requests from Cient and number of UI events to the Client
Aztec Message Server Statistics
♦ Dialog displays statistics about remote Message Server processing, which is available in the system menu when Script.StartMessageServer() is called in VM
♦ For each Message connection, it shows the name, IP Address, port number, connection status and number of messages received
Aztec System Logs
♦ Dialog provides three separate Log File tabs - Initial Build Log, Run-Time Build Log and Virtual Machine Log
♦ Access to these logs is available to the Script using CompilerWriteLog() at compile-time, and Script.Log() at run-time
The Aztec Virtual Machine and corresponding VM Instruction Set are designed to optimize performance, and the Aztec Compiler works with the VM Instruction Set to help achieve that goal when creating the executable code. On a low end Dell Latitude laptop, the VM can execute more than 25 million instructions per second while sitting in a tight Aztec source code 'while' loop, resulting in approximately 3 million loops per second.
The Aztec Language syntax is also designed to be compact and clean, yet powerful.
♦ The number of Aztec Operators was minimized and some traditional operators were replaced with flexible and consistent primitive framework methods. This provides a nicer programmatic feel, more flexibility (due to the three types of primitive methods), and performs as well as if operators were used, since each primitive method is tied directly to a Virtual Machine Instruction.
♦ There are only four predefined primitive data types, simplifying the use of the language. When using an integer in an expression, there is never any concern about whether you have a 1, 2, 4 or 8 byte value, signed or unsigned, and what interaction you might have with the other integer in the expression. There is only one integer data type within the Aztec Compiler and Virtual Machine, and it is alwlays a signed, 8 byte value. As mentioned in other areas of the documentation, there are primitive methods to look within the 8 byte integer value using a 1, 2 or 4 byte integer, signed or unsigned, and the Stream I/O classes also support reading and writing integer values of any size, signed or unsigned. Bit level manipulation methods are also provided for the 8 byte integer.
♦ The 8 byte float also has similar mechanisms to exchange 4 byte floating point values with other systems via Stream I/O methods.
Future Directions
Porting the Aztec Engine to Linux is one of our highest priorities right now. This potentially opens up a variety of other directions for the Aztec Engine.
♦ Embedded software on sensors and machines, with simple communication amongst machines, and the ability to display control UI on a separate computer, such as a central monitoring system.
♦ Internet of Things - again, the small size and power make Aztec a great candidate for these type of applications.
♦ Cloud computing, Big data and other web technologies.
Aztec Engine as a Callable C++ Library
The entire Aztec Engine system is designed and implemented as a callable C++ library, and there are two separate C++ frameworks within the Aztec Engine that could be made available to 3rd party applications. The following diagram shows a modified version of the Aztec Engine Components diagram from above, but the Aztec Engine technology is now shown as a callable library.
This allows a 3rd party application to use the entire Aztec Engine system as a Scripting Language to serve the needs of that application.
There are two separate C++ frameworks in the Aztec Engine system that could be made available to 3rd parties.
♦ Aztec Plug-In Framework Interface
♦ Interface with the Compiler - Create foreign Aztec classes and methods backed by C++ functions
♦ Interface with the Virtual Machine - C++ function is invoked when Aztec "foreign method" is called. The API provides functionality to retrieve arguments from methods, set return values, query Aztec objects, etc.
♦ Aztec Foreign Interface
♦ Interface between 3rd Party Application and the Aztec Engine Message Dispatcher
♦ Some features that would be available to the 3rd party application
♦ Compile code (string or file) to binary - file or memory
♦ Compile code (string or file) and immediately execute the script
♦ Execute a binary Aztec script (file or memory)
♦ Setup a "foreign" C++ method in the application as an event handler to be automatically invoked based on events from the Aztec Script
♦ Query the value of members within an Aztec object and also set/manipulate them
♦ Access to Aztec Metadata
♦ Direct access to many of the Script class methods/features, including dynamic code generation
The compact size of the Aztec Engine, combined with the powerful features it brings to the table, make it a perfect candidate for an application scripting language.
