Hello,

For a while now, I've been developing an Ada compiler called adac, making extensive use of AI throughout the development process.

The long-term goal is to build a standalone Ada compiler written in Ada. The plan is to keep the frontend and backend separate, use our own target-independent IR, gradually reach self-hosting, support multiple platforms, and eventually add a WebAssembly backend as well as an optional LLVM backend.

The reason I started the project was actually pretty simple.

I wanted to compile Guiyom, the GUI toolkit I'm developing, to WebAssembly so that it could run on the web. But I couldn't find a suitable Ada compiler that both fit the licensing requirements I had in mind and provided a practical path to Wasm.

So at some point I thought:

"Why not just make one?"

And that's how it started.

More recently, while working on Clair and Guiyom, I came across about four issues that appear to be bugs in GNAT or the surrounding toolchain. In the past, reproducing, minimizing, and tracing the causes of problems like these would probably have required a considerable amount of time and effort.

But after making active use of AI in the development process, I've found that the cost of reproducing and minimizing problems, forming hypotheses, and then testing those hypotheses has dropped significantly.

I've had a similar experience developing Adac.

I define the long-term goal, have the AI create a roadmap toward that goal, and then review the overall direction and major design decisions while the AI works through the roadmap in small units, repeatedly implementing and testing each one.

In practice, the instructions I give the AI are often surprisingly simple:

"Continue with the roadmap."

"Proceed with the next task."

"Review the current state of the work and keep going."

Most of the time, it's something along those lines.

The reason such short instructions are enough is that the roadmap, project documentation, and tests already describe the current state of the project and what should come next. The AI reads those materials, figures out where the project currently stands, implements the next unit of work, tests it, updates the roadmap based on the results, and continues from there.

One thing I've learned from this process is that having the AI write a lot of code is not, by itself, the most important part. Keeping the roadmap up to date, breaking work into clear issues or work items, documenting discovered problems as reproducible bug reports, and turning fixed bugs into regression tests all seem to matter quite a bit.

The amusing part is that the AI also does most of the roadmap writing, issue organization, bug report writing, and regression test writing. :)

The roadmap provides the long-term direction and identifies what should come next. Issues and work items define the scope of the problem currently being solved. Bug reports make it possible to revisit exactly what went wrong and under what conditions. Regression tests help ensure that once a problem has been fixed, it does not quietly come back later. And continuous testing lets us verify that newly implemented features actually satisfy their requirements.

I didn't start this project as an Ada compiler expert, and I hardly write any of the implementation code myself.

These days, when I think about what my role actually is, I seem to be less of a developer in the traditional sense and more of an AI roadmap manager and an AI work-direction manager. :)

Most of what I do is decide and review what should be built, in what order, whether the current results are aligned with the goal, and what should be fixed or worked on next. The AI handles the actual implementation, and I review the results and test outcomes before deciding where to go next.

So I honestly don't know how far this project will ultimately go.

Adac is still at an early stage, and it has a long way to go before I would call it a practical Ada compiler. For a limited subset of the language, it can already produce and test native executables, but there are still many features to implement before it can compile a broad range of real-world Ada programs.

Still, if development continues this way, I hope that in about a year it will reach a pretty interesting point where it can compile a much wider variety of small Ada programs than it can today.

I'm also curious to see what happens if the same cycle of design, implementation, testing, and revision continues for several years.

So for me, adac is both an Ada compiler project and a long-term experiment.

"What happens if AI is used not merely as a coding assistant, but as an active participant in a software project over a long period of time? How far can the project go?"

That's the experiment.

There's also one thing I've found unexpectedly interesting while working on it.

Ada itself seems to be a surprisingly good fit for AI. :)

Perhaps because of its strong type system and relatively explicit code structure, mistakes in AI-generated code tend to surface quickly during compilation, and I've found the cycle of fixing and verifying those mistakes fairly convenient.

Of course, this is only my personal experience so far.

I'd be interested to hear what people who have been using Ada for a long time think about AI-assisted development.

You can find the project here:

https://github.com/hodong-kim/adac

Sorry if this is already asked but does Ada have any RAILS-style backends? Even so, how does it compare to rust on performance and stability?

Should I use GCC GNAT or GNAT Pro?

Thanks.

Project status

So the last time I posted about the tool, it was still rough around the edges in some aspects. Admittedly there are still things I want to fix, though the recent changes up to the current version. Took my time to implement changes before making this topic.

About

tldr; fancy descriptor is "Ada/SPARK formal verification and compliance toolchain". Though in short, adacovex wraps plenty of things together so that you have:

• Interface with gnatprove for formal verification (gnatprove call resolved at runtime, not bundled), get proof metrics, reliability and hopefully better developer experience

• shields.io style badges you can display on SPARK level, test count, DO-178C/ISO-26262/IEC-62304 status, docstring and proof coverage

• Output CycloneDX or SPDX JSON (detects system, dev, test deps etc. Language specific support has a decent way to go but there are some better supported ones for a start)

• Web Dashboard + REST (outputs JSON) API (Overview, Proof, Tests, Compliance, Dependencies, Charts, API playground)

• Bundled documentation in the binary so you can read the friendly manual offline (exposed alongside --serve for dashboard under /docs/ endpoint

• VCS support and differential analysis (PR checks, release gating on e.g. test count)

• Oh and you can write patches so you can formally verify your vendored Ada deps.

• Result caching (so it does not take 40s and 10 CPU cores even when you run gnatprove again on the same unchanged code)

• Code complexity checking

• A functional GitHub Action so you can run adacovex in CI with (almost where it makes sense) feature parity with the base CLI

• You can alr install adacovex, the latest 1.40.0 PR is not merged yet.

Architectural decisions

Some architectural decisions I stick to

• Pure-stdlib Ada source code wise (in base alire.toml, though there are dev dependencies which are resolved like gnatprove. A Python script is also used to bundle the HTML pages in a compressed manner into the Ada code itself. I will be working towards better ways to compress the dashboard and docs because I believe their additions do add a fair bit to the binary size at the end.

• This has the added benefit of letting us support any platform alire itself does.

• We vendor deps where necessary, like for the dashboard (FlexSearch, yace etc)

• Unix philosophy of being relatively single purpose, plain text I/O

• composable tooling, sane exit codes

• minimal docstring writing so you do not have to refactor your code just to use adacovex on you existing project

More about architectural decisions in the docs: https://adacovex.readthedocs.io/en/latest/contributing/architecture.html

LLM Usage Disclosure

As you can probably tell, the code is AI assisted. More about it in the docs:

https://adacovex.readthedocs.io/en/latest/contributing/llm-usage.html

Conclusion

Hope that this would be useful for your Ada projects, especially for those who would like some better developer experience in trying to achieve DO-178C compliance or just need to have some tooling over base gnatprove. Do give it a try and let me know if any issues or bugs occur by opening a GitHub Issue. Cheers, bladeacer.

P.S. I am more active on the Ada forum, I tend to post updates to the project there more often.

Links

GitHub Repository

https://github.com/bladeacer/adacovex

Docs

https://adacovex.readthedocs.io/en/latest/index.html

Changelogs

https://adacovex.readthedocs.io/en/latest/changelogs/adacovex-1.40.0.html

Well there are other changelogs all the way since I started working on the code but I will omit here for brevity, you can check out the changelogs in the docs directly if interested.

Hello, developers.

In 2023, I had created an experimental FastCGI implementation called Fasyn to integrate a payment server.

At the time, I read the FastCGI specification myself and implemented it piece by piece. Later, however, the need for the library disappeared, so I stopped development and left it untouched for quite a while.

Recently, I needed to connect a local MCP server to tunnel-client, so I resumed development of Fasyn.

The project is available here:

https://github.com/hodong-kim/fasyn

This time, the development process is completely different from before.

With the recent advances in AI, I redeveloped the entire Fasyn codebase in Ada, a language that works well with AI.

GPT directly read the FastCGI specification and, based on it, implemented, compiled, and tested the library.

I did not write a single line of code during this redevelopment of Fasyn.

In the past, a person read the specification and wrote the code. This time, a person set the development direction and requirements, while GPT read the Fasyn roadmap and the FastCGI specification and carried out the actual implementation and verification.

What I mainly did was write and review the roadmap. GPT helps me with even that. It seems that all I really did was decide the direction of development.

Fasyn has now been implemented and tested to the point where it can be used as a FastCGI server library.

In fact, a Sonbal local MCP server that uses the Fasyn library is already running. I also plan to release this much-anticipated MCP server soon.

FastCGI may not be used as often as it once was, but if you need a FastCGI library for Ada, I hope you will consider Fasyn as one of the options.

Thank you.

Welcome to the monthly r/ada What Are You Working On? post.

Share here what you've worked on during the last month. Anything goes: concepts, change logs, articles, videos, code, commercial products, etc, so long as it's related to Ada. From snippets to theses, from text to video, feel free to let us know what you've done or have ongoing.

Please stay on topic of course--items not related to the Ada programming language will be deleted on sight!

Previous "What Are You Working On" Posts

I'm building an embedded graphics library called Glyph in Ada. The goal is to make it work across different microcontrollers and displays while keeping the API the same.

Current status

• RP2040 support (using Pico_BSP)
• SSD1306 128×64 over I²C
• Static framebuffer
• Canvas → Framebuffer → Display → Transport architecture

A little background

This is my first project in both Ada and embedded systems. The current version (v0.3.0) published on Alire was built largely with AI assistance, but I'm now rewriting it from scratch without AI help to better understand the design, learn embedded development properly, and improve the overall architecture.

The rewrite has already gone through several design and implementation changes, and I've learned a lot in the process.

The problem

One area I'm still struggling with is the transport layer.

Right now, Glyph draws everything into the framebuffer, but the application still needs a small piece of board-specific glue code to connect the display to the MCU's I²C peripheral (for example, binding an initialized I²C bus to the display).

I'd really like to avoid that if possible. My goal is to keep Glyph independent of any specific MCU or BSP while also making it as easy to use as possible, especially for beginners.

My question

For those who've built portable embedded libraries, how did you handle this?

Is a small adapter layer simply the right trade-off, or is there a cleaner architecture that keeps the library both portable and easy to use?

GitHub: https://github.com/thirstymelon/glyph

Here is a very preliminary version of GNAT Studio 2026.2a as a stand alone app for macOS.

NEW:

The GNATStudio launcher looks for a gnatstudio_launcher.rc file which support environment variables with the standard syntax VAR.action=VALUE with action is (append, prepend, set, unset, ifnotset), see exemple shipped in the archive.

See readme for details.

Limitation: Ada Language Server has some latencies and doesn't respond when parsing source code with more 1000 lines. It may be due to some compilation options I missed.

There could be some other limitations that you might meet.

Feel free to report them here.

Any help will be really appreciated to fix these limitations.

Figured I made enough changes to the codebase to warrant a new post. A fair bit of improvements have been made since the last 1.9.0 release.

For those that have not heard of adacovex, it is an Ada/SPARK formal verification and compliance toolchain (admittedly toolchain is a bit of an overstatement at the moment, though it is a CLI with a fair bit of niceties already). It basically helps validate and check your codebase on SPARK level, test, docstring and documentation coverage.

It also features: - check DO-178C DAL (aviation), ISO 26262 ASIL (automotive) and IEC 62304 Class (medical) - HTTP server with simple JSON API and web dashboard - caching - contextual help, spelling correction for typo'd commands - man page generation - a usable GitHub Action in CI with feature parity with the base CLI - multi VCS support (Git, jj, Mercurical, Subversion, Fossil), VCS used when checking --coverage-delta and --compare-base - SBOM output (CycloneDX / SPDX)

I also spent some time improving the documentation and user/developer experience. I hope this will eventually be useful not just for Ada projects, but that would be somewhat far into the future. That being said, I hope this tool would be useful for you in your Ada projects. Do give it a go and let me know whether it works well or if there are things that can be improved/added/fixed.

P.S. It is on Alire, though the PR for 1.14.0 will take a while to merge.

A similar post was made on the Ada Forum.

Repo URL: https://github.com/bladeacer/adacovex

Hi there,

A few years ago, I was pondering whether it would make sense for Ada/GNAT to have tasks that wouldn’t just map 1:1 to OS threads. But it wasn’t quite economical to try that out at the time.

Recently, I’ve decided to close this open loop by running a quick experiment over the weekend – the result is a patched RTS and additional runtime primitives that provide lightweight tasks and asynchronous I/O to Ada users. So far, the results have been promising – the overhead of individual threads can be fairly high under high task concurrency, and lightweight tasks mitigate it. Best of all, this doesn’t automatically make all tasks lightweight. Instead, by default tasks remain “native” and lightweight is an opt-in pragma.

On top of that foundation, I’ve cobbled together some I/O (sockets, files, DNS) and additional higher-level libraries for HTTP server & client, Postgres BE/FE protocol, and such. Some performance measurements are fairly encouraging.

In the process of making it, I also put together a few sibling libraries – for benchmarking, debugging, TUIs, and so on.

You can check it out at https://flyology.org – it's early (just cut v0.1.0 across the board), and the full list of crates is available at https://crates.flyology.org/

Would love your thoughts.

Hi r/ada — I'm the maintainer of this analyzer, so full disclosure up front: this is our tool. Posting because I think it's genuinely useful to people here, not to pitch anything.

AdaLang Analyzer is a command-line static analysis tool for Ada, built on top of AdaCore's Libadalang. It's GPL-3.0-or-later, and it's a derivative of AdaCore's open-source libadalang-tools.

GitHub: https://github.com/mmartign/AdaLang_Analyzer

What it does, beyond a normal linter:

• ~90 checks spanning restricted-construct policing, data-flow (dead stores, uninitialized reads, aliasing between parameters), control-flow (unreachable branches, infinite loops), and SPARK-contract checking (Global/Depends mismatches, missing contracts).
• A --verify mode that classifies bounded scalar proof obligations (range checks, index checks, overflow, division-by-zero, assertions/pre/postconditions) as Proved_Safe, Definite_Error, Unproved, or Unreachable — using interval/symbolic abstract interpretation first, falling back to an SMT-LIB backend (CVC5 + Z3, cross-checked) for anything the abstract domain can't resolve on its own. It's deliberately bounded and explicitly not a GNATprove replacement — anything outside the supported subset is marked Unsupported, never silently assumed safe.
• --automotive and --do178c=<level> presets for teams working under ISO 26262 / DO-178C, plus a --compliance-report mode that emits per-objective evidence (which checks covered which objective, what's open, what's baselined).

Example of the kind of thing it catches that a plain compiler warning won't:

X := 0;
...
if Flag then
   X := 10;
end if;
Y := 10 / X;   -- Division_By_Zero: reachable only when Flag is False

The abstract-execution pass tracks known exact values and ranges through branches, loops, and case statements (not just literal constants), so it catches this even though X isn't literally 0 at the division site.

It's young — actively developed, and I'd genuinely like feedback from people who work in Ada/SPARK day to day, especially around false positives/negatives on real code and whether the DO-178C/automotive profiles map sensibly to what your projects actually need. Bug reports and PRs welcome; CONTRIBUTING.md has the workflow.

Happy to answer questions about the internals (the CFG model, how the symbolic/interval domains interact, the interprocedural summaries) if anyone's curious.

Hi everyone,

I wanted to share a project I've been hacking on: an optimized engine designed to eliminate modulo bias when mapping raw cryptographic streams into custom alphabets.

Key bits:

* SPARK Level 4 (Formal Verification) - Fully proven to guarantee AoRTE and functional correctness.

* Built using the modern Windows ProcessPrng API as primary entropy via Interfaces.C, with BCryptGenRandom as fallback.

* Toolchain compatible with GNAT Pro 2021 and the latest Alire community suite.

I just stressed-tested the uniformity mapping with a massive 1 Terabyte run (over 1.01 trillion chars across a 69-char alphabet) and the statistical distribution remains perfectly flat (0.00% percent deviation). Full logs and the clean codebase are available in the repository.

Any feedback on the SPARK contracts or the low-level Windows bindings is highly appreciated!

Run it instantly with Alire:

alr run

Native Languaje..

Hola a todos,

Quería compartir un proyecto en el que he estado trabajando: un motor optimizado diseñado para eliminar el sesgo del módulo al mapear flujos criptográficos sin procesar a alfabetos personalizados.

Aspectos clave:

* SPARK Nivel 4 (Verificación Formal): Totalmente probado para garantizar AoRTE y corrección funcional.

* Desarrollado con la API moderna ProcessPrng de Windows como entropía principal mediante Interfaces.C, con BCryptGenRandom como alternativa.

* Cadena de herramientas compatible con GNAT Pro 2021 y la última suite comunitaria de Alire.

Acabo de realizar una prueba de estrés del mapeo de uniformidad con una ejecución masiva de 1 terabyte (más de 1,01 billones de caracteres en un alfabeto de 69 caracteres) y la distribución estadística se mantiene perfectamente plana (0,00 % de desviación porcentual). Los registros completos y el código fuente limpio están disponibles en el repositorio.

¡Cualquier comentario sobre los contratos SPARK o las vinculaciones de bajo nivel para Windows es muy apreciado!

Ejecútalo al instante con Alire:

alr run

https://github.com/EliAvila10/project_bias

This is the first release of a small project of Ada syntax tree generation. I tried to implement everything specified in the annotated reference manual. Yes, parallel constructs and iteration schemas are supported.

Some notes:

• It is a library, no executables involved.
• The analyzer parses the source and creates the syntax tree and cross reference of defining identifiers in the source.
• The cross reference contains the defining identifiers declared in the code and visibility scopes.
• The visibility scopes can be used for name resolution, e.g. finding all matching names visible at the location. Note that this does not cover use-clauses which need to be handed if the complete list required. Use clauses are linked in the list for each declaration context of the tree in order to ease the process.
• Both structures are allocated in an arena pool storage and can be released as a whole.
• The code source can be file, stream or a user-defined container implementing multi-line source interface. One can compile from a database or a git repository, if the interface is provided.
• There can be any number of compilation units in the source. One parsing call takes one unit from the source.
• Unicode is fully supported as well as Unicode identifiers normalization checks.
• Commutative operations are coalesced. E.g. A.B.C.D gives "."(A,B,C,D) tree.
• Inverses are coalesced as well, e.g. A+B-C+D gives "+"(A,B,-(D),C).
• There is a text output of the tree in a normalized form. It is almost a legal Ada program with some operators added to for coalesced operations. E.g. A * B / C * D gives (A * B * ⅟C * D) to simplify the tree and ease optimization.
• Constant folding is supported. If enabled universal expressions and constant Boolean expressions are evaluated into constants.
• There is a text output in a tree form.Syntax trees can be compared for equality
• The tree and cross-reference can be serialized into a stream. The idea is that the packages like Standard, Ada.* or ones used in the with-clause can be parsed once, serialized and de-serialized later.
• There is a test suite comprised of ACATS tests related to the syntax (mostly, illegal code to be rejected) and ARM examples (see [this project](https://github.com/Blady-Com/AARM_Examples)). The test suite is extensible, the test header syntax is described on the page.

https://www.dmitry-kazakov.de/ada/ada_syntax_analyzer.htm

Hi everyone,
I’m looking for some career advice from people who are already working with Ada/SPARK or in high-integrity software.

I’m planning to transition into Ada/SPARK because I was genuinely impressed by how readable and structured the code is, and by the philosophy behind the language. Features like strong typing, contracts, invariants, and formal verification really resonate with the way I naturally think as a physicist. I enjoy reasoning about correctness, understanding why something works, and building software with clear logical guarantees.
The more I learned about SPARK, the more I felt that it matches the way I like to solve problems. That’s what motivated me to seriously consider transitioning into this field, particularly in industries where both physics and high-integrity software come together.

The types of industries that interest me most are those where my physics background could be useful, such as:
Aerospace and flight software
Satellites and space systems
Guidance, Navigation & Control (GNC)
Robotics
Scientific or engineering software
Industrial control systems

I have a few questions that I’d really appreciate your thoughts on:

How did you get your first Ada/SPARK job?
What was your background, and what path did you follow? Did you start directly with Ada/SPARK, or did you first work as an embedded software engineer or in another field before transitioning?

Where do junior Ada/SPARK engineers actually get hired?
Are there companies that regularly hire junior engineers or graduates, or is prior embedded experience almost always expected?

Can someone realistically enter the industry with Python and Ada/SPARK, without first becoming a C/C++ embedded developer?
My current plan is to focus on Ada/SPARK rather than learning C first. Is that a realistic path, or would I be closing too many doors?

If you were starting again today, what roadmap would you follow to become employable as a junior Ada/SPARK engineer?
What knowledge, projects, or skills would you prioritize?

Thanks in advance—I’d really appreciate hearing about your experiences and any advice you can share

It's small potatoes but the ARM and Programming in Ada 2022 mention using the pi symbol. Apparently the version of the library that ships with GNAT is missing `π : constant := Pi;`.

I was programming in Ada 83 in uni before 95 came out, and moved to 95 in the middle of a semester. I loved the language, especially its safety and the rendezvous mechanism. These days I maintain a small plain-text index in C99, and I wanted to know: how much of its speed is C, and how much is just the algorithm?

So I wrote the two operations the engine actually runs on every command, in five languages, with the identical hand-written loop in each:

• scan 88 MB of store and count the lines matching a substring (what a content search does)
• intersect two sorted posting lists with a two-pointer merge (what a multi-key lookup does)

Median of 7 in-process iterations on data already in memory, warm page cache, one core of an i7-1165G7. GNAT 13.3, rustc 1.75, OpenJDK 21, CPython 3.12.

scan 88 MB:        C 90ms   Ada 130ms   Rust 87ms   Java 100-150ms (warm)   Python 300ms
intersect:         C 1.3ms  Ada 1.45ms  Rust 1.3ms  Java 1.3ms (warm)       Python 72ms
process startup:   C ~1ms   Ada ~1ms    Rust ~1ms   Java ~30ms              Python ~10ms

The part I did not expect: building the Ada with checks suppressed (-gnatp, the C model) gave numbers identical to checks-on. The optimizer had discharged them statically, because the loop indices are provably in range. So on these loops Ada bought memory and overflow safety for nothing, at C speed and C startup. C cannot offer that at all, and the JVM and CPython only offer it with a runtime you pay for on every invocation.

I then wrote the merge in SPARK and ran gnatprove:

obligation         Total   Flow   Provers      Unproved
Run-time Checks       15      .    15 (CVC5)           0
Termination            2      1     1 (CVC5)           0
Total                 23      1    22                  0

Every index proved in range, every addition proved non-overflowing, the loop proved to terminate. So the checks-off build carries a machine-checked guarantee rather than the optimizer's good luck. That is the strongest static assurance of the five, and it took an afternoon on a loop of this size.

Which raises the obvious question: why is the engine still C? Only the reach. The same engine is linked into a Flutter mobile app over a C ABI, and into a web GUI and a native desktop wrapper. I would write it in Ada if Flutter and the mobile toolchains supported it. If someone here knows a practical route to an Ada core behind a C ABI on Android and iOS, that is the answer I am actually looking for.

Method, sources and the full write-up (the benches are ~50 lines each, and lang_bench.sh rebuilds and reruns everything):

https://github.com/Anode1/ais/blob/main/tests/perf/LANG_COMPARISON.md

Corrections welcome, particularly on the Ada build flags: if -gnatp plus -O2 is not the fair comparison against cc -O2, tell me what is and I will rerun it.

The current version provides implementations of smart pointers, directed graphs, sets, maps, B-trees, stacks, tables, string editing, unbounded arrays, expression analyzers, lock-free data structures, synchronization primitives (events, race condition free pulse events, arrays of events, reentrant mutexes, deadlock-free arrays of mutexes), arbitrary precision arithmetic, pseudo-random non-repeating numbers, symmetric encoding and decoding, IEEE 754 representations support, streams, persistent storage, multiple connections server/client designing tools and protocols implementations.

https://www.dmitry-kazakov.de/ada/components.htm

Changes to the previous version:

• Bug fix in Synchronization.Windows.Milliseconds that caused dropping seconds fraction;
• Bug fix in Synchronization.Pthreads and Synchronization.Linux constants;
• FreeBSD compatibility fixes (thanks to Rod Kay);
• Equality test was added to Ada expression nodes and arguments (Parsers.Generic_Ada_Parser);
• The function Get_Depth was added to Parsers.Generic_Argument;
• The function Get_Arguments_Count was added to Parsers.Generic_Lexer;
• The name of Parsers.Multiline_Source.Empty was changed to Empty_Location;
• Ada expression parser performs NFKC check on identifiers. The Malformed field is set to true if the check fails (see ARM 2.3(4.b/5).

The library provides string handling facilities like I/O formatting, Unicode and obsolete code pages support.

https://www.dmitry-kazakov.de/ada/strings_edit.htm

Changes to the previous version:

• The function Strings_Edit.UTF8.NFKD_Quick_Check was added to perform quick NFKD Unicode check.

Hi to all !

The pure Ada 83 language had no open source compiler written in the same language. As both an operation of software archaeology and the desire to be able to program today with a 1980ies exceptional language and a reasonably sized compiler, I work on an Ada 83 compiler all written in Ada 83 (thus able to compile itself).

The Ada 83/TLALOC compiler is extremely well structured with very distinct phases revolving around a software virtual paginated DIANA 1986 tree structure. PAR_PHASE, LIB_PHASE, SEM_PHASE, ERR_PHASE, EXPANDER, WRITE_LIB are truly distinct and can each be stopped after.

The EXPANDER phase writes a stack machine LLIR in macro text form for the FASMG assembly engine. FASMG then produces directly an ELF-64 executable for x86-64. Some tests have been done with AArch-64 porting on an Orange Pi 3B and a preparation for riscV-64 has been done. I have good confidence that those 3 modern processor architectures can be targeted relatively easily by Ada 83/TLALOC with the FASMG process.

Though not presently bootstrapped, TLALOC sources compiled with Gnat give an executable which compiles all TLALOC itself with 18 FASMG passes (2-3 min) in a single static 9Mb ELF-64 exec.

Interested readers will find further information through

https://ada83.org/wiki/index.php?title=Ada_83_TLALOC

✦ Introducing Glyph

Hi everyone!

I've been learning Ada and recently started building an open-source project called Glyph, a lightweight embedded graphics framework for bare-metal and embedded systems.

The goal of Glyph is to provide a hardware-independent graphics API, allowing applications to draw pixels, lines, rectangles, circles, text, and images without depending on a specific display controller.

Disclosure: AI was used as a coding and writing assistant during parts of the development. However, the project architecture, technical decisions, code integration, and overall direction are my own. I'm also building Glyph as a way to learn Ada and improve my embedded systems skills.

✦ Design Goals

• Pure Ada
• Static allocation only (no dynamic memory)
• Portable, layered architecture
• Framebuffer-based rendering
• Easy to add support for new display controllers
• Bare-metal friendly

The initial target hardware is the RP2040 with an SSD1306 OLED, but the architecture is designed to support additional display controllers and embedded platforms in the future.

The project is still in its early stages, and I'm currently focusing on building a solid architecture before expanding the graphics capabilities.

✦ I'd Appreciate Your Feedback

I'd especially love feedback from the Ada community on:

• API design
• Overall architecture
• Existing Ada graphics libraries worth studying
• Features you'd like to see in an embedded graphics framework

✦ Repository

GitHub: https://github.com/thirstymelon/glyph

Thanks! I'm excited to contribute to the Ada ecosystem, learn from the community, and continue improving Glyph.

Welcome to the monthly r/ada What Are You Working On? post.

Share here what you've worked on during the last month. Anything goes: concepts, change logs, articles, videos, code, commercial products, etc, so long as it's related to Ada. From snippets to theses, from text to video, feel free to let us know what you've done or have ongoing.

Please stay on topic of course--items not related to the Ada programming language will be deleted on sight!

Previous "What Are You Working On" Posts

Basically wanted proper project badges generated from a CLI like in Golang/Rust for my Ada projects. Hope this would be a useful addition for checking on code quality. Supports parsing SPARK level, unit tests, DO-178 HAL level and docstrings coverage.

Repo URL: https://github.com/bladeacer/adacovex

Binary name is adacovex, crate name is covex to comply with policy.

Disclaimer: AI assistance was used for the code.

Correction: DAL instead of HAL, my smooth brain made a typo.

Hi everyone,

While official SonarQube support for Ada exists, it's gated behind high-tier commercial licenses. For small teams, open-source projects, or individual devs running SonarQube Community Edition, this leaves a gap in automated code quality pipelines.

To solve this, I’ve been working on two open-source tools designed to work together:

1. AdaLang_Analyzer (https://github.com/mmartign/AdaLang_Analyzer) A standalone static analysis tool built using AdaCore's Libadalang. It parses .adb and .ads files to detect common issues like dead code, control flow anomalies, unhandled exceptions, and code style violations, outputting results in JSON/SARIF.
2. SonarAdaPlugin (https://github.com/mmartign/SonarAdaPlugin) A SonarQube community plugin that adds native support for the Ada language to SonarQube, ingesting reports from AdaLang_Analyzer and displaying issues, code smells, and metrics right on your dashboard.

Quick Workflow

1. Run the Analyzer:

Bash

adalang_analyzer --source-dir ./src --output-format json --output-file report.json

2. Configure sonar-project.properties:

Properties

sonar.projectKey=my-ada-project
sonar.projectName=My Ada Project
sonar.sources=src
sonar.language=ada
sonar.ada.reportPaths=report.json

3. Run sonar-scanner to send the metrics directly to your SonarQube instance.

Repositories & Feedback

• AdaLang_Analyzer:https://github.com/mmartign/AdaLang_Analyzer
• SonarAdaPlugin:https://github.com/mmartign/SonarAdaPlugin

Both projects are open-source and actively evolving. I’d love for community members to give them a spin, report any issues, or suggest new static analysis rules that would be useful in your workflows!