feat: 16-bit Alien Engine layout (Bitpacked Trio)#65
feat: 16-bit Alien Engine layout (Bitpacked Trio)#65AdaWorldAPI wants to merge 1 commit intomainfrom
Conversation
Complete rewrite of bind_space.rs for AVX-512 alignment: - OPS: 0x00-0x0F (4K) - Built-in + 256 learned styles - FLUID: 0x10-0x3F (12K) - Crystal + working memory - EDGES: 0x40-0x7F (16K) - Relationships with Dn addressing - NODES: 0x80-0xBF (16K) - Dn tree topology (2^4 branches) - USER: 0xC0-0xFF (16K) - Sharding/overflow/extensions Key features: - EdgeTrio: [Source:u16, Target:u16, Verb:u16] = 48 bits - DnPath: Tree.Branch.Twig.Leaf (4.4.4.2 bits) - Sublanguage slot subdivision (SQL/CQL, Cypher/GQL, NARS/ACT-R) - Hamming distance = topological distance Mathematical requirement: u16 keeps Trio at 48 bits for AVX-512. Scaling via shards [Shard_ID:u16 | Local_Addr:u16], not wider pointers.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c9c548f75b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // NODES ZONE: 0x80-0xBF (64 prefixes × 256 = 16,384) | ||
| // Dn tree topology with bitpacked Hamming addressing | ||
| // ============================================================================= | ||
|
|
||
| pub const PREFIX_NODE_START: u8 = 0x80; | ||
| pub const PREFIX_NODE_END: u8 = 0xFF; | ||
| pub const NODE_PREFIXES: usize = 128; | ||
| pub const NODE_SIZE: usize = 32768; | ||
| pub const PREFIX_NODE_END: u8 = 0xBF; |
There was a problem hiding this comment.
Align node allocation logic with reduced node zone
This commit shrinks the node zone to 0x80–0xBF, but the allocator in src/cognitive/unified_stack.rs:678-680 still cycles across 128 prefixes (0x80 + ((len/256) % 128)), which will start emitting addresses in 0xC0–0xFF once the node count exceeds 16,384. At that point Addr::is_node() will return false and any code expecting node-zone semantics will misclassify or skip those entries. If the intent is to cap nodes at 16K, the allocator needs to respect PREFIX_NODE_END (or hard-limit), otherwise this change silently shifts excess nodes into the USER zone.
Useful? React with 👍 / 👎.
| #[inline] | ||
| pub const fn crystal(position: i8, slot: u8) -> Self { | ||
| let prefix = ((PREFIX_CRYSTAL_S_CURRENT as i8) + position) as u8; | ||
| Self::new(prefix, slot) |
There was a problem hiding this comment.
Guard crystal constructor against out-of-range positions
Addr::crystal previously clamped the temporal position to [-2, 2], but now it directly adds position and casts to u8. Any caller that passes an out-of-range value (e.g. a derived offset) will wrap into unrelated prefixes, producing an address that isn’t a crystal even though the API name and docstring imply it is. That can lead to incorrect crystal_position()/crystal_weight() behavior or storing “crystal” data in the wrong zone. Consider clamping or at least debug-asserting the allowed range to keep the API’s invariants intact.
Useful? React with 👍 / 👎.
The Bitpacked Trio Constraint
This layout is mathematically required for AVX-512 alignment:
[Source:u16, Target:u16, Verb:u16]= 48 bitsLayout
Key Features
Why 16-bit is NOT a limitation
[Shard_ID:u16 | Local_Addr:u16], not wider pointersBreaking Changes