Rust Compiler Vitalis Now Self-Compiling with 1,333 Versions

I wrote a DSL compiler this week for ZeroClaw . Not because I had to because the alternative was worse , my AI agent (ZeroClaw) needed to control hardware on a Raspberry Pi. The naive loop is agent calling tool or need to Rust written tools, you cross-compile, copy the binary, run it. Each iteration takes approximate 2 minutes for an agent that wants to experiment with hardware, that's death. So I built a hardware description language and a compiler for it ( just to understand DSL compilers and because I already architected the HAL interphase I knew what was goin on underneath). Example of what ZeroClaw/developer writes : servo CLAW_LEFT { pin: PA1 pwm_channel: 1 range: 0..180 frequency_hz: 50 } Four stages, hand-written, no parser-combinator crates lexer (finite automaton) → recursive-descent parser → semantic analyzer (collects all errors, doesn't fail fast) → a code generator that emits Rust for either STM32 or Raspberry Pi Then I embedded the compiler inside the agent. No subprocess. No file I/O. The agent generates HAL, the compiler validates it in-process, rppal toggles the pin. 2 minutes → under 1 millisecond. Same task. Six orders of magnitude. The lesson: when your tooling is the bottleneck, build even better tooling. Even when "better tooling" means writing a compiler at 2am.😂 What did i made? Answer : I built a Hardware DSL (Domain Specific Language) and a Compiler called zeroclaw-halc. The DSL: A simple way to write "code" that describes hardware (like LEDs, buttons, or motors) in plain text. The Compiler: A tool that reads that text, checks it for mistakes (like using the wrong pin), and turns it into actual hardware actions. Who can use it? Answer : Developers: They can use it to quickly generate the complex boilerplate code needed to start a new hardware project on Raspberry Pi or STM32. The ZeroClaw AI Agent: This is the big one. The AI now has a "manual" it can write. When it wants to control a light or a motor, it writes a .hal description, and my compiler tells it exactly how to do it. How does it help ZeroClaw? Answer: Before this, ZeroClaw was mostly "software." Now, it has a direct, safe link to the physical world: Safety: The compiler acts as a "safety guard." If the AI tries to use a pin that doesn't exist or conflicts with another part, the compiler catches it before anything breaks or burns out. Instant Control: ZeroClaw doesn't have to wait for a human to write code. It can generate its own hardware configuration on the fly and execute it in milliseconds on a Raspberry Pi. Multi-Platform: It makes ZeroClaw "hardware-agnostic." Whether you are using a Raspberry Pi or an industrial STM32 chip, the AI uses the same language to talk to both. thank you Sundai for the event..! #Rust #Compilers #EmbeddedSystems #EdgeAI #ZeroClaw 🦀

𝗥𝘂𝘀𝘁'𝘀 𝗭𝗲𝗿𝗼-𝗖𝗼𝘀𝘁 𝗔𝗯𝘀𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻𝘀 Rust promises zero-cost abstractions. You write high-level code. The compiler produces fast machine code. It works as if you wrote low-level code by hand. Monomorphization is the secret. You write one generic function. The compiler writes many. It generates a concrete copy for every type you use. If you use a function with integers and floats, the compiler creates two versions. One for integers. One for floats. The CPU never sees a generic type. It does not use vtables or boxing. This is why iterator chains are fast. The compiler collapses the chain into one loop. This speed comes with a price. - Binary size. Every unique type creates a new copy. Large projects get bigger binaries. This matters for WebAssembly. - Compile time. The compiler does heavy work during code generation. This makes Rust slow to compile. - Cache pressure. More code in memory causes instruction cache misses. You have two choices for dispatch. Static dispatch uses generics. The compiler resolves the target. It is fast. Dynamic dispatch uses trait objects. Use dyn Trait. The compiler creates one function. It uses a vtable lookup at runtime. It is slower but saves space. Use generics for performance. Use dyn Trait for mixed collections or when binary size matters. You check this with tools. Install cargo-show-asm. Run it on your functions. You will see separate assembly for different types. Zero-cost does not mean free. You move the cost to the compiler. You trade build time for runtime speed. Source: https://lnkd.in/gUEFaE3c

[Backstage OCaml] Wasm_of_ocaml: What Changed Since 6.1: Wasm_of_ocaml compiles OCaml bytecode to WebAssembly, targeting WasmGC so that OCaml values are managed by the host garbage collector. This post covers the most relevant Wasm changes in versions 6.1 through 6.3, and three PRs that add WASI support, native effects via Stack Switching, and dynlink/toplevel support. The Background section at the end has a short recap of where the project fits alongside js_of_ocaml. What changed in 6.1-6.3 The full changelog covers all three releases in detail. Below are the changes most relevant to the Wasm backend. The compiler writes Wasm binaries directly now (6.1) Before 6.1, the compiler emitted WAT (WebAssembly text format) and then converted it to binary via Binaryen. Since 6.1, it writes .wasm binary modules directly, removing that conversion step. Binaryen is still a required system dependency. WAT output is still available for debugging and is also faster to generate now. Better Wasm code generation (6.1-6.3) Several changes across 6.1-6.3 improve the quality of the generated Wasm code: * Direct calls for known functions (6.1). When the compiler can determine the target of a function call at compile time, it emits a call_ref instruction. Having context on which functions are called where enables the Binaryen toolchain to better optimize the generated Wasm code. * Precise closure environment types (6.1). Closures carry refined WasmGC struct types for their captured variables instead of generic arrays. This gives the Wasm engine exact layout information. * Closure code pointer omission (6.2). When a closure is never called indirectly through a generic apply, the code pointer field is omitted from the closure struct entirely. * Number unboxing (6.3). The compiler tracks unboxed int/float values through chains of arithmetic operations and keeps them in Wasm locals instead of allocating heap boxes. This is the kind of optimization that makes tight numerical loops actually fast. * Reference unboxing (6.3). ref cells that don't escape a function become Wasm locals instead of heap-allocated mutable GC structs. * Specialized comparisons and bigarray ops (6.3). Instead of dispatching through caml_compare or generic bigarray accessors, the compiler emits type-specific Wasm instructions when it can resolve types statically. There are also shared compiler improvements (benefiting both js_of_ocaml and wasm_of_ocaml): the inlining pass was rewritten in 6.1 (#1935, #2018, #2027) with better tailcall optimization, deadcode elimination, and arity propagation between compilation units. Runtime additions (6.1-6.3) * Marshal now handles zstd-compressed values in the Wasm runtime (6.1, fix in 6.3). * Bigarray element access uses DataView get/set, which is faster than the typed array primitives that we used before (6.1). * Effect handler continuation resumption is more…

In Rust, this compiler performance tweak that merges functions has to be handled with caution! ⚠️ 🦀 You’ve probably heard this advice before: “Small functions are cheap—don’t worry about them.” That’s usually true… until you start chasing performance. Because under the hood, every function call still has a cost: ▪️ jumping to another location in memory ▪️ setting up a stack frame ▪️ returning back So what if you could just… remove that call entirely? 𝐖𝐡𝐚𝐭 𝐢𝐬 𝐢𝐧𝐥𝐢𝐧𝐢𝐧𝐠? Inlining means the compiler replaces a function call with the actual code of that function. Instead of: ▪️ jumping to another function ▪️ then coming back …the compiler just puts the function’s code directly where it’s used. This removes the cost of calling the function and helps the compiler optimize better. 𝐇𝐨𝐰 𝐭𝐨 𝐮𝐬𝐞 𝐢𝐧𝐥𝐢𝐧𝐢𝐧𝐠 𝐢𝐧 𝐑𝐮𝐬𝐭 #[inline] fn add(a: i32, b: i32) -> i32 { a + b } --------------- #[inline(always)] fn fast(x: i32) -> i32 { x * 2 } --------------- #[inline(never)] fn slow() { println!("Not important for performance"); } --------------- #[𝐢𝐧𝐥𝐢𝐧𝐞] → “you can inline this” #[𝐢𝐧𝐥𝐢𝐧𝐞(𝐚𝐥𝐰𝐚𝐲𝐬)] → “please always inline this” #[𝐢𝐧𝐥𝐢𝐧𝐞(𝐧𝐞𝐯𝐞𝐫)] → “don’t inline this” These are hints to the compiler. 𝐖𝐡𝐲 𝐢𝐬 𝐢𝐭 𝐟𝐚𝐬𝐭𝐞𝐫? Inlining helps because: ▪️ No function call overhead ▪️ The compiler can better optimize the code ▪️ It can simplify or remove unnecessary work That’s how Rust keeps abstractions fast. 𝐁𝐮𝐭 𝐝𝐨𝐧’𝐭 𝐨𝐯𝐞𝐫𝐝𝐨 𝐢𝐭 Inlining copies code everywhere. Too much of it: ▪️ makes your program bigger ▪️ hurts CPU cache usage (very bad!) ▪️ can actually slow things down 𝐀 𝐬𝐦𝐚𝐫𝐭𝐞𝐫 𝐚𝐩𝐩𝐫𝐨𝐚𝐜𝐡 Instead of inlining everything: ▪️ Inline small, important functions (hot path) ▪️ Keep bigger, less-used logic separate (cold path) This keeps performance high and avoids bloating your code. In other words, if the code is not part of a critical path, don't inline it! Inlining is powerful—but only when used carefully. Have you ever had issues with inlining? Share them below 👇 Source: Check Brian Pane's Seattle Rust talk to see a 𝐫𝐞𝐚𝐥 𝐮𝐬𝐞 𝐜𝐚𝐬𝐞 𝐬𝐜𝐞𝐧𝐚𝐫𝐢𝐨: https://lnkd.in/eA9iVwXC (19:00 to 22:00) Also check out: https://lnkd.in/et8zhp3E

"During one of my presentations at #OSSummit Japan 🇯🇵 the past year, I talked about a bug I found while addressing -Wflex-array-member-not-at-end issues in the Linux kernel. The warning reported by the compiler was the following. drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] See the related code below. 392 struct virtnet_info { ... 429 struct virtio_net_rss_config_trailer rss_trailer; 430 u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE]; 431 ... 496 }; According to the compiler, struct virtio_net_rss_config_trailer at line 429 above is a flexible structure; this is a structure that contains a flexible-array member (FAM), and the issue is that the FAM in this structure is not at the end of struct virtnet_info. Let’s remember that not-at-end FAMs are a compiler extension that may cause undefined behavior, and compilers do not handle the sizes of objects containing them consistently. For this reason, they are now deprecated: struct flex { int length; char data[]; }; struct mid_flex { int m; struct flex flex_data; int n; }; In the above, accessing a member of the array mid_flex.flex_data.data[] might have undefined behavior. Compilers do not handle such a case consistently. Any code relying on this case should be modified to ensure that flexible array members only end up at the ends of structures. flexible-array members and tail padding Now, let’s take a look at the internals of struct virtio_net_rss_config_trailer using the Poke a Hole (pahole) tool. pahole -C virtio_net_rss_config_trailer drivers/net/virtio_net.o struct virtio_net_rss_config_trailer { __le16 max_tx_vq; /* 0 2 */ __u8 hash_key_length; /* 2 1 */ __u8 hash_key_data[]; /* 3 0 */ /* size: 4, cachelines: 1, members: 3 */ /* padding: 1 */ /* last cacheline: 4 bytes */ }; As we can see above, the FAM hash_key_data[] is located at offset 3 and, of course, its size is 0 bytes. However, the size of the structure is 4 bytes, which means that between the end of the struct and the address of the FAM there is 1 byte of padding. As shown above, this is also displayed by pahole: /* padding: 1 */. This type of padding between the last member and the end of a structure is called tail padding, and it’s quite common. However, it can be problematic if people are not familiar with the nuances of flexible-array members. This is one of those subtle details developers should be acutely aware of when working with FAMs, in particular[...]" Read the full post on my blog: https://lnkd.in/eUEHcGM9 🐧 #Linux #linuxhardening #opensource

Handling of NULL Pointer after C++11: #include <iostream> using namespace std; void func(char* str) {   cout << "char* version" << endl; } void func(int i) {   cout << "int version" << endl; } int main() {   func(NULL);  // PROBLEM: Ambiguous or calls int version   //func(nullptr);   return 0; } Problem: func(NULL); // Which one runs? Function Overloading where the compiler gets confused. Before C++11, 0 and NULL had a "dual identity." They were used as both the number zero and a memory address.  This made it impossible for the compiler to know your true intent in overloaded functions. Before C++11, the "null" value didn't have its own type—it just borrowed the number 0. std::nullptr_t is the official,  dedicated type for the keyword nullptr. Solution:   func(nullptr); Enable and run the code and Disable //func(NULL);   If you pass nullptr: The compiler sees the type std::nullptr_t. It knows this type cannot be an integer, but it can be a pointer.   It immediately picks the pointer version of the function. What is an "Explicit Cast"? If you absolutely must turn nullptr into a number (though you almost never should), you have to "force" the compiler to do it using a cast. This is you telling the compiler, "I know this looks wrong, but I'm doing it on purpose." C++ // This will fail (Implicit): // int x = nullptr; // This will work (Explicit): int x = reinterpret_cast<intptr_t>(nullptr); What if there are TWO pointer types? void func(char* s); void func(int* i); func(nullptr); // ERROR: Ambiguous! Why? Because nullptr can convert to char* AND int* equally well. The compiler sees two perfect pointer matches and doesn't know which "flavor" of pointer you want. The Fix: You must tell the compiler which pointer type to use by casting: func(static_cast<char*>(nullptr)); static_cast: The operator name. <char*>: The Target Type. This is what you want the value to become. (nullptr): The Source Value. This is what you are starting with.

What is Lambda Syntax: [capture-list](parameters) -> return_type { body } When the compiler sees a lambda expression, it generates a unique, hidden Class (called a Closure Type). Lambdas: Are expressions, not declarations. They create a temporary "Closure" object. You can pass a lambda directly into another function It then creates a temporary Object of that class (the Closure). it is essentially a struct generated by the compiler. What is a "Closure" Object? The "Closure" is the physical manifestation of the lambda in memory. It is essentially a struct generated by the compiler. The Code: The lambda's body becomes the operator() (function call operator) of this hidden struct. A Functor is a struct that has been given the power to act like a function. In C++, you can overload almost any operator (+, -, *). When you overload the parentheses (), you are telling the compiler:  "If someone puts parentheses next to an instance of this struct, execute this code." When the C++ compiler encounters the syntax name(arguments), it follows a specific hierarchy to resolve what that means:   Is it a function? (No, is a variable/object).   Is it a function pointer? (No, it's a class type).   Does it have an operator()? (Yes! The compiler finds class::operator()). Once the compiler confirms that class has an overloaded (), it rewrites your high-level code into an explicit method call:   e.g. obj(65.5) Internal Translation: obj.operator()(65.5) The Data: Every variable you put in the Capture List [ ] becomes a member variable of this hidden struct. This is why a lambda with a Capture List [factor] cannot be converted to a raw C function pointer—a raw pointer has no place to store the factor.  In high-performance C++ and automotive systems (like ARM or x86_64 architectures), Registers are the fastest storage locations inside the CPU.  Using a register for the this pointer is a standard optimization called a Calling Convention. Here is why the compiler chooses a register instead of RAM for this pointer. ## 1. Speed (The Primary Reason) Registers sit directly on the CPU core. Accessing a value in a register takes less than 1 nanosecond (typically 1 clock cycle).   Registers: ~1 cycle   L1 Cache: ~4 cycles   Main RAM: ~100–300 cycles If the compiler used the Stack (RAM) to pass the this pointer: The caller would have to push the address onto the stack. The operator() would have to read it from the stack. This creates "traffic" on the memory bus. In automotive ECUs, where the CPU might be managing real-time engine timings or safety signals,  reducing unnecessary memory traffic prevents bottlenecks and ensures deterministic timing.

Can AI agents build software that comes with a mathematical proof that it works? At Basis Research Institute, we set four agents to build a verified compiler. Compilers are large, complex pieces of engineering, deep in the software stack. Anthropic recently showed that agents can build one from scratch. We wanted to ask the next question: can they build one that is verified correct? A verified compiler is one that comes with a machine-checked proof that it is mathematically correct. Most software is checked by running it on examples and checking its behaviour matches expectations. A proof guarantees it works on every example, including the ones no one ran. We tasked a team of agents to build a verified JS-to-WASM compiler in Lean. Over 14 days they wrote 93,000 lines of code and produced a compiler that ran. But they did not prove it correct. The agents built an interpreter, a target semantics, and the compiler between them. But the proofs never closed. They repeated broken strategies across sessions, forgot what had failed, and wrote the same lemma 122 times rather than abstracting it once. More capable models will help, but we think the bigger lever is verified program synthesis infrastructure designed around agents' capabilities and flaws. Full writeup: https://lnkd.in/er6mg4D4

In C++, both prefix (++obj) and postfix (obj++) have the same name: operator++. The compiler wouldn't know which one to call when it sees obj++.  Since C++ does not allow overloading based solely on the return type,  the language designers needed a way to change the "signature" of the function. To solve this, the C++ standard decided that:  Prefix (++obj): Takes no arguments.  Postfix (obj++): Takes a dummy int argument. When you write obj++, the compiler internally calls obj.operator++(0).  You never actually pass a number to it;  the compiler inserts a 0 automatically just to satisfy the function signature. the exact reason why postfix is slower than prefix: Overloading operator++(int) {   Overloading tmp;      // 1. Create a copy (Old state)   tmp.n = this->n;    // 2. Save current value   this->n = this->n + 1; // 3. Increment original   return tmp;      // 4. Return the OLD state by VALUE } Return by Value: Postfix must return by value because the tmp object is a local variable.  It will be destroyed when the function ends, so you cannot return a reference to it. In post-increment (obj++), the rule is: "Use the value first, then increment it." To achieve this in code: You create a local copy (Overloading tmp) to "remember" what the object . In C++, you cannot return a reference to a local variable. The tmp object is created on the Stack within the scope of the operator++ function. The moment the function reaches the return statement and exits,  the stack frame is destroyed and tmp ceases to exist. If you tried to return Overloading&, you would be returning a "Dangling Reference" to a memory location that has already been reclaimed. This would lead to non-deterministic crashes. #include <iostream> using namespace std; class Overloading {   private:   int d;   public: Overloading():d(10) {   //Parmetrized Constructor is invoked    cout <<"parmetrized Constructor is Invoked " << this->d << endl; } Overloading& operator ++() {   ++d;   return *this;    } Overloading operator++(int) {   Overloading temp;   temp = *this;   ++d;   return temp;   } ~Overloading() {   // Default Destructor to destroy the Object   cout <<"Default Destructor is Invoked " << endl;    }  friend ostream& operator<<(ostream& out, const Overloading& obj) {     out << obj.d; // We choose to print the value of 'd'     return out;  // Return the stream to allow chaining   } }; int main() {  Overloading obj1;  Overloading obj2;  obj2 = obj1++; //Post  cout <<"post Incre " << obj1 << endl;     cout <<"Post obj2 " << obj2<< endl;     obj2 = ++obj1; //Preincrement Operator Overloading  cout <<"Pre Incre" << obj1 << endl;     cout <<"Ptre incre obj2" << obj2 << endl;     return 0; } o/p: parmetrized Constructor is Invoked 10 parmetrized Constructor is Invoked 10 Default Destructor is Invoked  post Incre 11 Post obj2 10 Pre Incre12 Ptre incre obj212 Default Destructor is Invoked  Default Destructor is Invoked 

Day 13: if you wrote a destructor, the compiler has a question. Did you also write the other four? Here's the rule. If your class needs to manually manage a resource memory, a file handle, a socket and you write a destructor to clean it up, you've implicitly told the compiler that default behavior isn't good enough. And if default behavior isn't good enough for destruction, it almost certainly isn't good enough for copying or moving either. So you need all five. Destructor. Copy constructor. Copy assignment. Move constructor. Move assignment. Get any one of them wrong and you're looking at double-frees, shallow copies, or silently moved-from objects being used as if they're still valid. That's the Rule of Five. And it's a trap not because it's hard to understand, but because it's easy to forget half of. The Rule of Zero is the escape hatch. Design your class so it doesn't own raw resources directly. Use 𝒔𝒕𝒅::𝒖𝒏𝒊𝒒𝒖𝒆_𝒑𝒕𝒓, 𝒔𝒕𝒅::𝒔𝒕𝒓𝒊𝒏𝒈, 𝒔𝒕𝒅::𝒗𝒆𝒄𝒕𝒐𝒓 types that already implement the Rule of Five correctly. Let them do the work. Your class inherits correct behavior for free, and you write zero special member functions. 🧠 Key insight: writing less code is often the safer choice. Every custom destructor, copy constructor, or assignment operator is code that can have bugs. The Rule of Zero eliminates the entire category. If your class members manage themselves, your class manages itself. Worth knowing: = 𝒅𝒆𝒇𝒂𝒖𝒍𝒕 and = 𝒅𝒆𝒍𝒆𝒕𝒆 are your allies. Explicitly defaulting tells readers the compiler-generated version is intentional. Deleting prevents accidental copies on non-copyable types. · The moment you declare any of the five, the compiler stops generating some of the others automatically. The rules are subtle don't rely on implicit generation when resources are involved. · Rule of Zero isn't always possible low-level systems code, custom allocators, RAII wrappers for C APIs. In those cases, Rule of Five applies and deserves careful attention. Own the resource once. In one place. In one type. Everywhere else, just use it. Day 13 of my C++ deep-dive series. Missed Day 12? Go check out the 𝒔𝒕𝒅::𝒇𝒐𝒓𝒎𝒂𝒕 breakdown. Have you ever shipped a bug that traced back to a missing copy or move operator? What did it look like at the crash site? 👇 #cpp #cplusplus #programming #softwareengineering #cleancode