Hello World Again!

Well, not too long ago I managed to get the first ‘Hello World’ ek9 application working on the Java JVM. I was very pleased. This work on generating the Intermediate Representation (IR) and the JVM bytecode has progresssed much further. It now included conditions (if/else/switch), and iteration (for, while, do/while) and exceptions (try, catch, finally). All progressing very nicely and also being ‘fuzzed’ by Claude Code so we now have many mutations and changes. This ‘fuzzing; has really paid off finding weird edge cases and some just pure ‘dumb bugs’.

So, why ‘Hello World Again!’, well the EK9 language has a common front-end, ‘middle-end’ (IR), but importantly it has a dual back-end. By this I mean there is the JVM implementation that is well underway as outlined above. But now the LLVM native back end is also well under way.

The llvm-native back end has been progressing in terms of design and development of a standard api that mirrors the standard api that has been completed in Java for the JVM run-time. By this I mean types like String, Float, Integer, List etc. In Java these are daily easy to implement because they compile down to JVM bytecode and so can just be used via the byte code the ek9 compiler generates for user developed ek9 source.

However, for native execution, there is much more to consider. How do you represent ‘objects’ for example, how does the memory management work? Not to mention the rich API’s and structures modern Java offers that can just be reused in the JVM implementation, but mist be coded in the native back end.

As a back graound taks I;ve been working on a separate branch structuring the native llvm back-end using pure C with mangled named functions, structs (as vtables) and specific memory management routines. The EK9 IR already produces memory management instructions using ‘ARC’ basically reference counting to manage the memory allocation and release.

While maybe not as sophisticated as the Rust ‘borrow checker’, it is probablu much easier for developers to use as it is more akin to ‘garbage collection’. But it frees memory on last reference removal - so not really a mark and sweep. Although there has to be an element of mark and sweep for ‘islands’ of linked data structures. By this i mean object that reference each other but are now ‘detatched’ from the main application logic. These too need to be identified and ‘freed’.

Anyway, today after another 6 months of background work, we finally had ‘Hello World’ but via ek9 → IR → llvm IR → native binary executable.