←back to thread

124 points akktor | 5 comments | | HN request time: 1.149s | source

This question's for all those cool projects or skills you're secretly fascinated by, but haven't quite jumped into. Maybe you feel like you just don't have the right "brain" for it, or you're not smart enough to figure it out, or even worse, you simply have no clue how or where to even start.

The idea here is to shine a light on these hidden interests and the little (or big!) mental blocks that come with them. If you're already rocking in those specific areas – or you've been there and figured out how to get past similar hurdles – please chime in! Share some helpful resources, dish out general advice, or just give a nudge of encouragement on how to take that intimidating first step.

Let's help each other get unstuck!

1. addaon ◴[] No.44240443[source]
I've wanted for years to take the research paper "Coq: The World's Best Macro Assembler" through several of its more and less obvious next steps, including re-implementing it on top of a formal specification of ARM (or RISC-V) machine code, and introducing a concept of virtual registers on top of a (light weight) register allocator. I really feel like there's a path here to a system in which low-level non-portable code can be written comfortably (if perhaps at a somewhat slower pace than C), with arbitrary correctness properties proven on it; but the learning curve to get there (through Coq, etc) has been a struggle. Every few years I set myself the goal of a proven-correct implementation of a min/max heap in assembly built on this approach, and every few years I give up.
replies(1): >>44242213 #
2. ecesena ◴[] No.44242213[source]
Not in Coq, but you might find this interesting from AWS: https://github.com/awslabs/s2n-bignum?tab=readme-ov-file#tes...
replies(1): >>44242751 #
3. addaon ◴[] No.44242751[source]
I've just taken a quick glance at this, and will explore further -- but at first, it seems like it's really a good application of ad-hoc proofs to assembly code; which is a subset of what I'm interested in, but for me the more interesting thing about the paper was the structured safety proofs for things like memory safety, no read-before-write, no overflow, etc., and thinking about how this can be expanded and generalized. While for something like a bignum library (or a heap) the actual conformance to the behavioral contract will be somewhat ad-hoc, having a lot of safety contracts also proved along the way "for free" (or at slightly reduced cost, anyway) is what really draws my attention. I can see spending 2x the time writing the code, and 10x the time proving things about it, in exchange for not having to spend the 100x (DAL B) or 1000x (DAL A) time testing it.
replies(1): >>44254048 #
4. ecesena ◴[] No.44254048{3}[source]
Yeah, I hear you. Many things are simplified in this crypto code, for example there’s no dynamic allocation. At the same time it’s incredibly difficult to get a realistic model of the hardware instructions because they all have side effects. And it gets incredibly more difficult if you try to prove real world, hand optimized code (vs academic proof of concept code).

With all this said, I think this could be a good inspiration and look forward to seeing advancements!

replies(1): >>44265444 #
5. addaon ◴[] No.44265444{4}[source]
> Many things are simplified in this crypto code, for example there’s no dynamic allocation.

That's okay, I haven't worked on code bases with dynamic allocation professionally in years, and even my hobby projects usually avoid it.