The Chaga compiler now generates IF-THEN-ELSE statements in x86 assembler. I'm testing the functionality now. Once testing is finished, I'll release the next Chaga compiler.
Adding IF-THEN-ELSE statements to the Chaga programming language is actually somewhat difficult. What makes it difficult is deciding the best approach to generating assembler code. I've tried different approaches but wasn't happy with the results. I've finally decided to integrate the assembler code within the Abstract Syntax Tree (AST). It makes a lot of sense to do so. Each statement is already optimized for intermediate code generation in the AST. I'm implementing the x86 assembler statements in several stages. The first stage is stubbed-in x86 assembler code for each type of statement. On the second pass I'll fill in the finer details such as generating branch labels to navigate statement blocks for IF-THEN-ELSE, WHILE, DO-WHILE, types of statements. The IF-THEN-ELSE statement is the most complex because it requires a forward label from the IF statement to the ELSE statement block, depending on the outcome of the expression evaluated on the IF statement. Sharing this brief update on my Blog in case anyone is really curious as to what I've been up to. The next iteration of the Chaga compiler will have significant infrastructure changes. The hint that this is happening already are the many releases of LibChaga and the run-time expression engine. Hope I can wrap this all up soon. Ok, back to work.
I am tantilizingly close to having IF-THEN-ELSE statements working in the Chaga compiler. I'm generating most of the x86 assembler code now. What stops me - what I'm working on now - is resolving when I'm inside a statement block for an IF-THEN statement or inside a statement block for an ELSE statement block. Once I have this resolved, it will be trivially easy to also apply the same idea to WHILE statements, FOR statements, and DO-WHILE statements. The run-time expression engine is working flawlessly. I've been testing it in the next release candidate of the Chaga compiler. Why is it important to know when I'm inside a statement block for, say, an IF-THEN or ELSE statement? Simply put, I need to use labels in x86 assembly with branch statements depending on if a statement block should be entered or not because of a Boolean expression. The solution I've devised is to include a count for the number of left and right curly braces for each statement in the Abstract Syntax Tree. Once I know I'm entering a statement block after an IF-THEN statement, I can the count for the number of left curly braces (and right curly braces). I can also decipher when I'm leaving a statement block based on the number of left and right curly braces (when entering an IF-THEN statement block versus when I leave the IF-THEN statement block). First of all, the number of left curly braces should remain the same while the number of right curly braces will be increased by one (when leaving an IF-THEN statement). Once I know the boundaries of statement blocks, I can then craft x86 assembler code with labels to branch to when I encounter an IF-THEN-ELSE statement.
An additional note: I already use curly brace counting to determine scope for variables within functions and procedures. I'm not new to curly brace counting. I use it extensively when creating the symbol table (and scope of variables as noted before). What is new is utilzing curly brace counts for each statement. That's a new idea.
UPDATED: I've released LibChaga version 0.5.9. Fixed output error in boolean_display function: Removed a "\n" from being output when a boolean value is NULL.
I've released LibChaga version 0.5.8. This is a minor update. When a packed_string_integer or a packed_string_float variable is NULL but the user attempts to display the contents, it currently displays nothing. I modified packed_string_integer_display() and packed_string_float_display() to display "UNDEFINED;" when a NULL value is passed in to be displayed.
I've released LibChaga version 0.5.7. This is a minor update. I added a new subroutine: boolean_release_memory() as a wrapper for free() function. I did this for consistency with other libraries in LibChaga application programmers interface (API). I've also updated all test routines to call boolean_release_memory() instead of free() when applicable.
I've released LibChaga version 0.5.6. Not too much has changed in this version other than infrastructure for the run-time expression library. For consistency, I'm passing return values for Boolean datatypes as pointers now (instead of an unsigned char). Yes, pointers require more stack space (8 bytes for a 64-bit pointer) compared to one byte (for an unsigned char). In my defense, I chose to use pointer values as I could differentiate when a Boolean variable was defined or not (i.e. if the pointer to the variable is NULL, it is undefined). I also updated the test library to be even more rigorous in case NULL is returned on any run-time evaluation.
Having released a milestone version of LibChaga (0.5.5), I'm focused once again on the Chaga compiler. I'm integrating the new run-time expression evaluator into the compiler. It is a very different way of evaluating expressions compared to the current method the Chaga compiler uses. I'll continue working away on Chaga compiler and hope to have a new version of Chaga compiler out that utilizes the new run-timme expression engine. The run-time expression engine is quite powerful in that it will appropriately convert mixed datatypes. I see wonderful benefits to this infrastructure upgrade in the future. Stay tuned. Gotta get some sleep now (it's 12:26am as I post this message).
I've released LibChaga version 0.5.5. This version fixes additional bugs in the Chaga string arithmetic library. It also features a run-time expression engine. Lastly, I've created an extensive testing library to validate the results from the Chaga string arithmetic library.
I have thus far written 392 dedicated testing subroutines that create a dynamic postfix expression in run-time then call the compute function to evaluate the result. Each subroutine also has pre-computed the correct answer (which I hand-code). I then compare the correct result with the result returned from the dynamic evaluation. If the two results don't match, the testing stops with a failure error, otherwise the tests continue. This has been a highly effective method to determine if my run-time postfix expression evaluator is rock-solid (translation bug-free). These testing routines will be included in the libChaga version 0.5.5 release.
I had an epiphany concerning run-time expression evaluation: in the future, I could search for common factors in complex run-time expressions involving division (i.e. numerator and denominator having common factors that can be cancelled out). This could save significant run-time evaluaton. It is an interesting idea. It's not a priority to implement right now but is certainly an intriguing idea.
I've been writing an extensive testing library to evaluate the robustness of LibChaga (also known as the Chaga string arithmetic library). Specifically, I'm working on a 0.5.5 release candidate for LibChaga which will feature a dynamic expression evaluator. The dynamic expression evaluator is a big infrastructure change. The compiler currently builds the assembly instructions to evaluate complex expression at compile time along with the stack (for temporary storage of intermediate values). With the dynamic expression evaluator, the compiler simply converts infix expressions into postfix then sends the postfix based expression to a run-time library for real-time evaluation. This simplifies the compilation process but complicates the run-time process. Building a run-time expression evaluator means converting datatypes on-the-fly during runtime (when necessary) to evaluate an expression. For example, one could enter the expression 12 + FALSE. Of course this is a mixture of an integer constant and a Boolean FALSE. In this situation, the Boolean FALSE is converted to integer zero while the constant twelve is converted to an integer twelve value. The result is evaluated as: 12 + 0 = 12. What makes this incredibly complicated are the many possible datatype combinations which require conversion to a common-datatype. The testing routines are designed to test all possible combinations of mixed and like-datatypes to find defects. The real-time expression evaluator can evaluate numerical expressions (which return an integer or real result), Boolean expressions (which return a TRUE or FALSE result), or a hybrid Boolean-numerical expression which involves both numerical and Boolean expressions. Hybrid Boolean-numerical expressions will return either a Boolean value or numerical value depending on context. Specifically, an assignment statment target variable will determine if the expression must be converted to Boolean (e.g. target variable holds a Boolean result) or numerical datatype (if target variable is an integer or float datatype). Furthermore, if the expression is embedded within an IF-THEN-ELSE statement, WHILE statement, or DO-UNTIL statement, the hybrid Boolean-numerical expression evaluator will return a Boolean result. Once the run-time expression evaluator is finished, I will integrate it into IF-THEN-ELSE statements. I see a bright future with this expansion. Unfortunately, it takes a lot of patience and time to implement correctly and in a robust, predictable manner (translation: bug-free). That's the current state of the Chaga development.
I will be teaching one class in Fall 2026 at Sonoma State University: CS-210 (Introduction to Unix). The first day of class is Tuesday. August 25, 2026. My goal is to complete the run-time expression library by that time and, hopefully, get IF-THEN-ELSE statements working in the Chaga compiler as well. I still have lots of work to complete but I know how to get there. Since I'm only teaching one class this Fall, I will be devoting some time to the Chaga compiler as well during the Fall semester.
Released libchaga-0.5.4. Notes about changes since previous version are noted in the file "version_history.txt" (included in each each release of libchaga).
Two version of LibChaga released in one day?! Yes! I've been quite productive.
Released libchaga-0.5.3 Added even more new subroutines as infrastructure for the compiler during run-time.
Released libchaga-0.5.2. Fixed one bug in packed_string_float_subtract library. Added lots of new subroutines as infrastructure for the compiler during run-time.
When writing a compiler or interpreter that supports a variety of datatypes, inevitably a program will contain an expression involving different datatypes. I accept such situations in the Chaga programming language by performing datatype conversions. I do my best to preserve floating-point values during the expression evaluation process (if applicable and possible). For example, if a sub-expression (within a much larger expression) involves multiplying an integer datatype with a float datatype, I convert the integer datatype to a float (which is easy with string arithmetic by the way) then perform the multiply operation. I continue in this way until I hit hard limits such as a float datatype ANDed with a Boolean datatype. When this situation arises, I test if the float datatype is greater than zero. If so, I convert the float datatype to Boolean TRUE otherwise I convert the float datatype to Boolean FALSE. I plan to write detailed documentation containing all the rules for datatype conversion in Chapter 2 of the Chaga programming language documentation.
Working on evaluating Boolean and Boolean-numerical expressions in IF-THEN-ELSE statements for the Chaga Programming Language. I'd worked on this extensively last year while adding the Boolean datatype. Once Boolean datatypes were supported, I went on to develop the string-based float datatypes (which of course took a while). Now, revisiting IF-THEN-ELSE. I've already got the x86 assembly worked out. I know how to retrieve variables from the stack frame. Really all that is left is to ensure I have enough temporary variables to evaluate the Boolean expression (which could have numerical expressions that ultimately evaluate to Boolean). Concrete syntax tree (CST) and Abstract syntax tree (AST) already work on the parsing of Boolean and combo-Boolean/numerical expressions. My ASTs even place the Boolean or Boolean/numerical expressions in postfix order. Yes, I use Dijkstra's Shunting Yard algorithm. Therefore, once I get the rest of this logic finished for IF-THEN and IF-THEN-ELSE statements, I can recycle the Boolean expression logic to evaluate DO-WHILE and WHILE statements. Next Chaga release will have IF-THEN and IF-THEN-ELSE supported for INT, BOOLEAN, and FLOAT datatypes. I like to release Chaga versions often because each version is then officially backed-up, off-site and represents a development milestone. I'm confident I'll have IF-THEN and IF-THEN-ELSE finished in under two weeks (if not sooner). A lot of the work is already finished.
Chaga compiler version 0.5.4 is officially released. This version includes support for floating-point numbers. The Chaga compiler now requires installation of libchaga-0.5.1 (the Chaga string arithmetic library). The Chaga compiler links compiled Chaga applications with the LibChaga. LibChaga is an open soure library too (GPL v3) and available for download.
I've finally found a way to manage Chaga attributes at run-time. I've developed an application called the Chaga Attributes Manager. It is a statically linked library that is automatically linked to compiled Chaga applications. The Chaga Attributes Manager is a run-time database which keeps track of all integers and float datatypes. It is still in the early testing stages but so far looks promising. I've also added support to read attributes for functions or procedures. My goal is to set the scale attribute for a floating point number at run-time to, say, 20 digits right of the decimal then compute a division on a non-terminating repeating fraction.
While adding the float datatype to the Chaga compiler, I realized I must finally begin implementing Chaga attributes (also known as "metadata attributes"). Why? Because the Chaga string arithmetic library passes parameters back in certain situations such as dividing by zero (flagged as "DIVIDE BY ZERO") or dividing by a number containing factors other than two and/or five (flagged as "TERMINATING NON-REPEATING") to indicate the decimal remainder was truncated by a user-defined number of digits of precision. The user-defined number of digits of precision is also a settable run-time attribute for floating point datatypes. Implementing attributes is a big leap forward but nonetheless must be done.
Chapter 2 of the Chaga Programming Language documentation is devoted to attributes (there are many). Attributes are available to Chaga programs during run-time. The attributes are in some ways like a run-time based symbol table. One can even query an identifier itself for specific attribute information in a process called "reflection". Attributes are one area where the Chaga Programming Language differs from the hugely influential C programming language.
Another Chaga attribute is scope. I want to query scope of an identifier at run-time. The identifier can be the name of a procedure, the name of a function, or the name of a datatype. Things will get really wild when I implement my memory management functionality. I plan to use automatic garbage collection. One technique is to allow users to automatically de-allocate portions of memory beneath a certain scope threshold.
After much development and testing, I have released the first public version (0.5.0) of the Chaga string arithmetic library today. It is licensed under GPL version 3. If you download and build the library, it will generate a shared object (Dynamic Linked Library), a static object (for static linking), and build a test application which demonstrates most of the Chaga string arithmetic library features. Build and installation instructions are included in the application. This library will install to /usr/local/lib.
The Chaga string arithmetic library is an essential part of the Chaga programming language. The next release of the Chaga programming language compiler will build Chaga applications that are either statically-linked to the chaga string arithmetic library or dynamically linked to it.
The full source code for the Chaga string arithmetic library is available on the Download webpage.
I've been experimenting with 64-bit integer number blocks in the Chaga string arithmetic library. The performance improvement is substantial: I can perform subtraction on two 10,000,000 digit integers (using 64-bit number blocks) in 0.044090 seconds. Yes, it is very fast and accurate. I've been checking my results against other large calculators.
Integrated the Toom-Cook with three-partitions (aka Toom-3) into the packed_string_integer_multiply function. The packed_string_integer_multiply function is the main function one calls when performing any sort of string-based multiplication on two binary-coded (base-10) decimal digits. Inside that function, I check if the two input numbers are greater than a threshold constant (currently set as 1000-digits). If both numbers exceed 1000-digits, then compute the product with Toom-3 otherwise use the traditional multiplication method one learns in elementary school. This gives a terrific performance boost with larger numbers.
I rewrote my integer division function (packed_string_integer_divide) with substantially faster throughput as well.
Lastly, I wrote a new function to compute the nth root of a number using Newton-Raphson method. My version of Newton-Raphson calls my nth root bisection method function to get an approximation for the nth root (with about 10 digits of accuracy right of decimal). Newton's method indeed converges much faster than bisection method for finding the nth root.
I'm writing a function to convert base-10 to base-2. This will allow me to convert my native, base-10 representation internally into 64-bit number chunks in base-2. This prepares me for future work using Number Theoretic Transforms (NTT) which are a type of Fast-Fourier Transform that operates on discrete numbers (integers). This also allows me to experiment with hardware accelerated base-2 integer math operations within the CPU.I begin work again on the Chaga compiler in about one week. The next step is incorporating floating-point datatypes into the Chaga language.
I've extensively been testing, bug-fixing, and refactoring the Chaga string arithmetic library. I'm in the final testing stages now. The next new feature to add to the Chaga compiler is adding support for floating-point datatypes. I will likely begin development on Chaga compiler again in about a week or two from today.
Added a new function in the Chaga string arithmetic library to convert decimal notation to scientific notation (e.g. 1234567.0 becomes 1.234567E6). I did this to decrease storage requirements and increase computation efficiency. Note: I store the exponent as a separate string. I wrote out the E notation for display purposes only. No internal "E" is stored in the string library. Computation efficiency is improved in division of two big numbers. I can subtract the denominator exponent from the numerator exponent right away. This saves computation time. In multiplication, I can add the exponent values together. With addition or subtraction, I can shift the decimal location on the mantissa to make the exponents the same (e.g. 1.0E6 + 1.0E5 = 10.0E5+1.0E5 = 11.0E5 = 1.1E6). Win-win!
I've expanded the Chaga string arithmetic library to support both a PACKED (2 BCD digits per byte) mode and an unpacked (one BCD digit per byte) mode. Internal math functions work on both packed and unpacked BCD representations of digits; however, there's a time-space trade-off. I plan to run performance tests on internal functions to measure the speed differences in computation (packed BCD versus unpacked BCD computation). I've strategically chosen to use 8-bit registers and unsigned bytes instead of 64-bit registers and unsigned long long integer data structures to be as hardware agnostic as possible (i.e. avoid proprietary hardware acceleration). Instead, I'm focused on optimizations in algorithms and data structures to subtly improve computation performance. Up to this point, I've released the Chaga string arithmetic library inside the Chaga compiler as I always felt it was internal infrastructure. However, the Chaga string arithmetic library has enough utility to become a standalone product. Documentation on Chaga string arithmetic library is under the developer's page at the moment (see bottom of page for all the Chaga string arithmetic library functions). My development approach on the Chaga compiler and string arithmetic library are very much intertwined. My modus operandi is to complete my infrastructure for datatype manipulation and representation before proceeding with the implementation of new Chaga language commands.
I've finished string-based, floating point division in the Chaga string arithmetic library today. This means the Chaga string arithmetic library now supports string-based floating point division, multiplication, subtraction, and addition. The latest version of the Chaga numerical string library will be included in the next Chaga compiler release, tentatively scheduled for late June 2026.
Since I have this week off from school for Spring break, I've been working on the Chaga string arithmetic library for floating point numbers. Specifically, I've implemented floating point multiplication. It will be released in the next version of Chaga (to be determined). Now to start work on Chaga floating point division. I already have floating point addition and subtraction completed in the Chaga string arithmetic library.
Finalized the data structure to hold floating-point numbers as strings in the Chaga string arithmetic library. I've conducted many tests before reaching this stage. The data structure I use is more complex than string integers as string floats have a whole part (left of the decimal) and a fractional part (right of the decimal). With minor adjustments, the floating-point data structure will also be used (recycled) for complex and imaginary numbers.
I've also added string addition for floating-point numbers to the Chaga string arithmetic library. I'm testing that software now to ensure all is well before moving on to floating-point string subtraction, floating-point string multiplication, and floating-point string division.
I'm hoping I can compute several million digits of PI in the Chaga programming language on March 14, 2027 (PI day).
Just released Chaga programming language compiler version 0.5.3. Fixed a bug in the string arithmetic modulo function. Specifically, if numerator and denominator are identical, I was returning one (quotient) rather than zero (remainder). This has been fixed. You may download version 0.5.3 from the Download page.
Released Chaga programming language compiler version 0.5.2. Added support for Boolean datatype (bool). You may download the gzipped tar archive from the downloads page.
Just released Chaga programming language compiler version 0.5.1. Added support for string integer division and string integer modulo (remainder). You may download the gzipped tar archive from the downloads page.
The first public release of the Chaga programming language compiler (version 0.5) is now available for download and testing. I'm releasing it under the GNU Public License 3.0 (GPL3). I've included full source code for the compiler with Makefile. You will need a 64-bit GNU/Linux operating system, gcc, and the GNU assembler. I've also included sample programs in the Chaga programming language for you to compile. You may download the gzipped tar archive from the downloads page.
I've computed 10000! (ten-thousand factorial) using the Chaga numerical string library. Ten-thousand factorial is 35,660 digits long. I've also created a factorial table for the first one-thousand numbers.
Computed the first ten million terms of the Fibonacci series (with first two terms being zero and one). The ten millionth term of the Fibonancci series contains 2,089,876 digits. I computed this number using the Chaga numerical string library which is a software library written for the Chaga programming language.
Spent time yesterday extensively re-writing the documentation for the Chaga Programming Language. Previously I had one continuous long HTML page. Now documentation is formatted much more like an online book divided into seven chapters thus far. I'm pleased with the new documentation layout in book style. One area I'm still debating in the Chaga programming language is how to manage memory from the heap. I will very likely use some sort of automatic garbage collection. The Rust style of checking-in and checking-out memory is very intriguing. Another thought is to create a metadata attribute for pointers which could denote when the memory will be released or under what circumstances the memory will be released. I don't see an easy solution yet. Perhaps setting a scope threshold is one option. Memory is released once it goes below a given scope threshold. I keep track of scope already with metadata attributes. Every procedure or function has a non-negative scope value. The scope threshold would set a time-to-release for pointer memory and could be one means of garbage collection.
The Chaga programming language features metadata attributes for each datatype in the programming language. Most of these attributes are read-only as they are infrastructure related to the programming language itself. The protect attribute is modifiable by the end-user (the programmer). This attribute can be set for read-only, write-only, or read-write. Changes to the protect attribute can only be implemented in the same scope the variable was declared. Setting the attribute to read-only on a given variable will enable me to pass that variable's address (e.g. a large string datatype) to a function or procedure without the worry the function or procedure will modify the original string.
Using my math string library, I computed the first million terms in the Fibonacci series. The millionth Fibonacci term is 208,989 digits long.
I'm partially finished with writing a math string library to support math operations using strings to represent numbers. My math string library supports addition thus far and works fine. I tested it by computing the first 50,000 terms in the Fibonacci sequence. 50,000th Fibonacci_term and the Fibonacci sequence for the first 50,000 terms.
Introducing the Chaga Programming Language. I began developing this language in November 2023 when I was initially hired to teach Programming Languages in the Computer Science Department at Sonoma State University. The Chaga programming language began as a derivative of the C programming language. Although I primarily use this language as a teaching tool, my goal is to develop a low-level systems-oriented programming language.
I've designed a "C-like" programming language. I've used this language in my classes for three semesters now. The BNF grammar is quite extensive and the language has some subtle differences - improvements - from C. The programming language has a name (to be revealed at a future date). I've proposed the development of this language as an open-source collaboration hosted (and developed) in the CS department at Sonoma State University. I felt this would be an effective way to merge my own interests in compiler development and language construction with open-source. Not sure if this will take off or flop but thought I'd give it a go. Stay tuned. Language features I'd tentatively like to include: native support for coroutines, threads, pipes, sockets, and shared memory; functions that return one or more return values. This language may target robotics, IoT, and embedded systems development. This is NOT meant to be a beginner programming language. This is a systems-oriented programming language.
Copyright © 2025, 2026 Robert James Bruce.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is available at https://www.gnu.org/licenses/fdl-1.3.html