lion VS libcxx

I've been starting to dabble with digital logic design via Clash (https://clash-lang.org/), and there is a very cool-looking RISC-V SoC project done in that tool that looks fairly serious: https://github.com/standardsemiconductor/lion.

That’s fascinating about the M1. In retrospect it seems like kind of a no-brainer but I doubt I would have thought of it.

SPARC had different memory models at different ISA revs IIRC: it’s been like 20 years since I was dealing with SPARC so I might be misremembering the details. Alpha would have been a better example.

RISC-V is really interesting. I’ve been slowly working through this: https://github.com/standardsemiconductor/lion, highly recommend!

Interesting. Actually, you may be just the person to answer my question: Is it possible/plausible to run a Cardano node on Lion OS on a RISC-V machine? IMO, it would be great for the community if we could run all Cardano stake pools on end to end formally verified machines using open source core and hardware.

Lion: A formally verified, 5-stage pipeline RISC-V core\ (30 comments)

In addition, you can actually set the riscv-formal suite to verify correctness by k-induction: https://github.com/SymbioticEDA/riscv-formal/pull/28 https://symbiyosys.readthedocs.io/en/latest/quickstart.html#beyond-bounded-model-checks although I concur that by looking at https://github.com/standardsemiconductor/lion/blob/main/lion-formal/app/Main.hs the lion core is only verified with BMC.

If you are comparing hoops that library authors need to jump through in both languages, you can easily make the real-world comparison in the other direction, by comparing Rust's Option with C++'s std::optional (an exercise left for the reader): Rust std: https://github.com/rust-lang/rust/blob/master/library/core/src/option.rs libcxx: https://github.com/llvm-mirror/libcxx/blob/master/include/optional

My favorite prime number generator is the undocumented __next_prime():

https://github.com/llvm-mirror/libcxx/blob/78d6a7767ed57b501...

There is no good reason to use this one except in a code golf environment that includes all headers by default, which is where I learned about it.

I once read a Strousroup quote amounting to "If you understand std::vector, then you understand C++". I thought surely he couldn't have meant the interface but the implentation, googled that llvm's implementation is considered nice and clean, had a look, and noped straight out of there.

C++'s STL linked list for comparison (libcxx).

https://github.com/llvm-mirror/libcxx/blob/master/include/li...

> For example, accessing a std::span or a std::vector outside of its bounds would abort the program, and so would accessing an empty std::optional.

I don't really understand the difference with libc++, libstdc++ and msvc stl's respective debug modes, they already do exactly these checks :

- https://github.com/llvm-mirror/libcxx/blob/78d6a7767ed57b501...

- https://github.com/gcc-mirror/gcc/blob/966010b2eb4a4c52f139b...

I mean it's not hard to read the source for your platform. On Linux/x86_64/libc++ it's roughly:

- https://github.com/llvm-mirror/libcxx/blob/master/include/__...

- https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/...

I don't particularly care to comb through it to see if anything has changed, but historically it was a a little spin-CAS to make the non-contended path fast and then dropping into a https://en.wikipedia.org/wiki/Futex, which is about as good as it gets for staying mostly in userspace but still letting it be scheduler aware so you're not burning up a core busy-polling, which is what often happens when people try to roll their own shit.

Google wants a bit more latitude on the heuristics and degrees of freedom around read/write ownership, so they did it like this: https://github.com/abseil/abseil-cpp/blob/master/absl/synchr... which is quite a bit better commented/legible.

If anyone reading this can do better than the `abseil-cpp` folks, not only would Google take their PR, they'd probably offer them a job.