cv5005 (u/cv5005) - Readit News

cv5005 commented on The Lobster Programming Language strlen.com/lobster/... · Posted by u/keyle

Novel programming languages have still educational value for those building them and, yes, we still need programming languages. I dont see any reason we would not need them. Even if Ai is going to write the code for you; how is it going to write it with no programming language? With raw binary? Absolutly not.

cv5005 · 5 days ago

Eventually it wont need to write any code at all. The end goal for AI is "The Final Software" - no more software needs to be written, you just tell the AI what you actually want done and it does it, no need for it to generate a program.

cv5005 commented on Best performance of a C++ singleton andreasfertig.com/blog/20... · Posted by u/jandeboevrie

halayli · 5 days ago

The performance observation is real but the two approaches are not equivalent, and the article doesn't mention what you're actually trading away, which is the part that matters.

The C++11 threadsafety guarantee on static initialization is explicitly scoped to block local statics. That's not an implementation detail, that's the guarantee.

The __cxa_guard_acquire/release machinery in the assembly is the standard fulfilling that contract. Move to a private static data member and you're outside that guarantee entirely. You've quietly handed that responsibility back to yourself.

Then there's the static initialization order fiasco, which is the whole reason the meyers singleton with a local static became canonical. Block local static initializes on first use, lazily, deterministically, thread safely. A static data member initializes at startup in an order that is undefined across translation units. If anything touches Instance() during its own static initialization from a different TU, you're in UB territory. The article doesn't mention this.

Real world singleton designs also need: deferred/configuration-driven initialization, optional instantiation, state recycling, controlled teardown. A block local static keeps those doors open. A static data member initializes unconditionally at startup, you've lost lazy-init, you've lost the option to not initialize it, and configuration based instantiation becomes awkward by design.

Honestly, if you're bottlenecking on singleton access, that's design smell worth addressing, not the guard variable.

cv5005 · 5 days ago

>Then there's the static initialization order fiasco

One of the reasons I hate constructors and destructors.

Explicit init()/deinit() functions are much better.

cv5005 commented on Zig – io_uring and Grand Central Dispatch std.Io implementations landed ziglang.org/devlog/2026/#... · Posted by u/Retro_Dev

junon · a month ago

> Rust will also never replace C or C++ in any meaningful way

Not only do I disagree it never will, I think it's already well on its way to doing exactly that.

cv5005 · a month ago

Is it? rust has to ditch llvm to be able to replace c++ - or rewrite llvm in rust.

cv5005 commented on How many registers does an x86-64 CPU have? (2020) blog.yossarian.net/2020/1... · Posted by u/tosh

Joker_vD · a month ago

So, let's take a function with 40 alive temporaries at a point where it needs to call a helper function of, say, two arguments.

On a 16 register machine with 9 call-clobbered registers and 7 call-invariant ones (one of which is the stack pointer) we put 6 temporaries into call-invariant registers (so there are 6 spills in the prologue of this big function), another 9 into the call-clobbered registers; 2 of those 9 are the helper function's arguments, but 7 other temporaries have to be spilled to survive the call. And the rest 25 temporaries live on the stack in the first place.

If we instead take a machine with 31 registers, 19 being call-clobbered and 12 call-invariant ones (one of which is a stack pointer), we can put 11 temporaries into call-invariant registers (so there are 11 spills in the prologue of this big function), and another 19 into the call-clobbered registers; 2 of those 19 are the helper function's arguments, so 17 other temporaries have to be spilled to survive the call. And the rest of 10 temporaries live on the stack in the first place.

So, there seems to be more spilling/reloading whether you count pre-emptive spills or the on-demand-at-the-call-site spills, at least to me.

cv5005 · a month ago

A good compiler will only do that if the register spilling is more efficient than using more stack varibles, so I don't really see the problem.

cv5005 commented on LLMs could be, but shouldn't be compilers alperenkeles.com/posts/ll... · Posted by u/alpaylan

CGMthrowaway · a month ago

>LLMs are not deterministic, so they are not compilers.

"Deterministic" is not the the right constraint to introduce here. Plenty of software is non-deterministic (such as LLMs! But also, consensus protocols, request routing architecture, GPU kernels, etc) so why not compilers?

What a compiler needs is not determinism, but semantic closure. A system is semantically closed if the meanings of its outputs are fully defined within the system, correctness can be evaluated internally and errors are decidable. LLMs are semantically open. A semantically closed compiler will never output nonsense, even if its output is nondeterministic. But two runs of a (semantically closed) nondeterministic compiler may produce two correct programs, one being faster on one CPU and the other faster on another. Or such a compiler can be useful for enhancing security, e.g. programs behave identically, resist fingerprinting.

Nondeterminism simply means the compiler selects any element of an equivalence class. Semantic closure ensures the equivalence class is well‑defined.

cv5005 · a month ago

Bitwise identical output from a compiler is important for verification to protect against tampering, supply chain attacks, etc.

cv5005 commented on We tasked Opus 4.6 using agent teams to build a C Compiler anthropic.com/engineering... · Posted by u/modeless

falcor84 · a month ago

> literally a text book task

Generating a 99% compliant C compiler is not a textbook task in any university I've ever heard of. There's a vast difference between a toy compiler and one that can actually compile Linux and Doom.

From a bit of research now, there are only three other compilers that can compile an unmodified Linux kernel: GCC, Clang/LLVM and Intel's oneAPI. I can't find any other compiler implementation that came close.

cv5005 · a month ago

That's because you need to implement a bunch of gcc-specific behavior that linux relies on. A 100% standards compliant c23 compiler can't compile linux.

cv5005 commented on Advancing AI Benchmarking with Game Arena blog.google/innovation-an... · Posted by u/salkahfi

cv5005 · a month ago

My personal threshold for AGI is when an AI can 'sit down' - it doesn't need to have robotic hands, but it needs to only use visual and audio inputs to make its moves - and complete a modern RPG or FPS single player game that it hasn't pre-trained on (it can train on older games).

cv5005 commented on Aliasing xania.org/202512/15-alias... · Posted by u/ibobev

newpavlov · 3 months ago

For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust.

Aliasing issues is just yet another instance of C/C++ inferiority holding the industry back. C could've learnt from Fortran, but we ended up with the language we have...

cv5005 · 3 months ago

For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:

    void foo(void *a, void *b, int n) {
        assume_aligned(a, 16);
        assume_stride(a, 16);
        assume_distinct(a, b);
        ... go and vectorize!
    }

cv5005 commented on Data breach at major Swedish software supplier impacts 1.5M bleepingcomputer.com/news... · Posted by u/fleahunter

cv5005 · 4 months ago

This data is publically available to anyone in Sweden:

Your salary (well, last years taxable income), debts/credit rating, criminal history, address, phone number, which vehicles and properties you own and which company boards you're on.

One of organized criminals biggest income these days are scamming rich old folks because it's so trivial to get all details needed (and who to target) to be a pretty convincing bankman, IRS type agent/etc.

Some of it you have to kind of manually request at various places, but it's all available.

So data breaches aren't really that big of a deal when everything is already public.

cv5005 commented on Fil-C: A memory-safe C implementation lwn.net/SubscriberLink/10... · Posted by u/chmaynard

TuxSH · 4 months ago

Also this is _de facto_ limited to userspace application for the mainstream OSes if my understanding is correct.

Reading Fil-C website's "InvisiCaps by example" page, I see that "Laundering Integers As Pointers" is disallowed. This essentially disqualifies Fil-C for low-level work, which makes for a substantial part of C programs.

(int2ptr for MMIO/pre-allocated memory is in theory UB, in practice just fine as long as you don't otherwise break aliasing rules (and lifetime rules in C++) - as the compiler will fail to track provenance at least once).

But that isn't really what Fil-C is aimed at - the value is, as you implied, in hardening userspace applications.

cv5005 · 4 months ago

You don't have to do int2ptr for mmio or absolute addresses, you can punt that to the linker.

    extern struct uart UART0;

Then place that symbol at address X in your linker script.