MES-replacement

I still have a small fee available from NLNet for the implementation of a RISC-V back-end for a compiler (more a transpiler) from a small stack language to assembly. I have already started the effort, but at this moment not the time to work on it. I am available for support. Back-ends to x86, x86_64 and arm64 are available and working. This is part of the MES-replacement project [1]. Let me know if you are interested (see email at the bottom of the website mentioned in my profile here or on GitHub.) [1] https://github.com/FransFaase/MES-replacement

I developed a similar language as an intermediate language for a C-compiler that I wrote. It uses reverse Polish notation instead of Polish notation [1], because it is easier to compile reverse Polish notation to machine code. I call the language Stack-C. See [2]. There are 32 bit and 64 bit compilers for x86 assembly and there is a memory safe interpreter for the language with a (rather limited) built-in debugger. [1] https://en.wikipedia.org/wiki/Polish_notation [2] https://github.com/FransFaase/MES-replacement/blob/main/Stac...

Here’s a link to the right directory at least: https://github.com/FransFaase/MES-replacement/tree/main/src

The code of TCC (0.9.26) is kind hard to compile, I have discovered in the past year, while developing a minimal C compiler to compile the TCC sources [1]. For that reason, I have concluded that TCC is its own test set. It uses the constant 0x80000000, which is an edge case for if you want to print it as a signed integer only using 32-bit operators. There is a switch statement with an post-increment operator in the switch expression. There are also switch statements with fall throughs and with goto statements in the cases. It uses the ## operator where the result is the name of a macro. Just to name a few. [1] https://github.com/FransFaase/MES-replacement

Interesting. I am currently in the process of writing an interpreter for a similar stack based language. I already wrote a compiler for this language to x86 assembly that can be compiled to an ELF. The language is used as an intermediate language for a C compiler that I am writing. It is maybe less Forth-like than your language. For more information see: https://github.com/FransFaase/MES-replacement For the interpreter have a look at: stack_c_interpreter.c At WHY2025, I gave a talk about the reasons why am working on this. See: https://www.youtube.com/watch?v=akzyyO5wvm0

Is there any hard evidence that using AI agents significantly improve the productivity in software development, excluding website development? I have been developing C(++) software for more than 30 years and I am still discovering things about the language that I had not fully grasped before, especially now that I am developing a C-compiler [1] myself. What I want to say is that developing quality software, a deep understanding of programming languages, is required. Good software engineering is not about produce lots of code, but keeping you code base lean/agile, avoiding technical depth, such that you velocity does not decrease over time. I am not convinced that that can be achieved with current day AI agents that only have a shallow understanding of software and that I doubt are able to have a deep understanding of large code base. So,

I am currently implementing a stack based language as an intermediate language for a C compiler that I am developing. I have developed a relatively straight forward compiler for the stack language to the M1 assembler from live-bootstrap. This stack language has local variables. It actually makes use of two stacks: One in the traditional sense and one for the local variables (and the return address for calls). It reads as a kind of very primitive post-fix C kind of language. See: https://github.com/FransFaase/MES-replacement and https://www.iwriteiam.nl/D2506.html#2b

Social media, YouTube, TV, visiting exhibitions, maintaining website, developing a C compiler for compiling TCC (https://github.com/FransFaase/MES-replacement), walking/biking.