Systems architecture notes, not product copy
BitCal documents its vNext work as a technical whitepaper for advanced C++ readers: public model, algorithm organization, dispatch boundary, performance methodology, contract reference, and research context presented as one chain of evidence.
This site is for readers who want to answer six concrete questions before trusting a low-level library:
bit_block<Bits>, bit_view, const_bit_view, and free algorithms.<bitcal/bitcal.hpp> is the only stable include seam.Start with audience, verification path, and migration posture.
This is the shortest route to understanding how BitCal expects to be reviewed.
Follow the system architecture spine from public model to dispatch boundary.
This is where owner / view / algorithm, free-algorithm organization, and kernel boundaries are made explicit.
Read the retained benchmark baseline separately from the measurement methodology.
Numbers stay attached to reproduction commands, active backend context, and claim limits.
Confirm the public role model and algorithm contract after the architecture story is clear.
Reference pages explain what readers may rely on, not how every kernel happens to be written today.
Review citations, related systems, evolution notes, and design trade-offs.
This section exists to deepen technical judgment, not to add decorative academic tone.
End with release posture, support matrix, and documentation truth sources.
Status narrows every claim back down to what the repository can currently defend.
Not part of the stable user identity.
The home page does not attempt to replace the deeper sections. It gives a map:
BitCal prefers a narrower but more defensible story:
Grounds x86 SIMD discussion in an authoritative instruction-level source.
Useful when explaining why latency, throughput, and dispatch policy matter to low-level claims.
Provides a conceptual bridge between bit-level semantics and word-parallel implementation techniques.