Skip to content

feat: 16-bit Alien Engine layout (Bitpacked Trio)#65

Open
AdaWorldAPI wants to merge 1 commit intomainfrom
feat/alien-engine-16bit-layout
Open

feat: 16-bit Alien Engine layout (Bitpacked Trio)#65
AdaWorldAPI wants to merge 1 commit intomainfrom
feat/alien-engine-16bit-layout

Conversation

@AdaWorldAPI
Copy link
Owner

The Bitpacked Trio Constraint

This layout is mathematically required for AVX-512 alignment:

  • Edge Trio = [Source:u16, Target:u16, Verb:u16] = 48 bits
  • AVX-512 processes 32 × u16 per instruction
  • Widening to u24 breaks alignment, bloats storage 50%, kills throughput

Layout

Zone Range Size Purpose
OPS 0x00-0x0F 4K Built-in methods + 256 learned styles
FLUID 0x10-0x3F 12K Crystal (±2 temporal) + working memory
EDGES 0x40-0x7F 16K Relationships, Dn addressing, Arrow-relative
NODES 0x80-0xBF 16K Dn tree: Tree.Branch.Twig.Leaf (4.4.4.2 bits)
USER 0xC0-0xFF 16K Sharding, overflow, user extensions

Key Features

  • EdgeTrio: 48-bit packed struct for AVX-512 batch processing
  • DnPath: Bitpacked tree addressing with 2^4 branches per level
  • Sublanguage: SQL/CQL, Cypher/GQL, NARS/ACT-R slot subdivision
  • Hamming distance = topological distance (XOR + popcount)

Why 16-bit is NOT a limitation

  • 32K nodes = active working set, not total storage
  • Cold storage (LanceDB) holds billions
  • Scale by shards [Shard_ID:u16 | Local_Addr:u16], not wider pointers

Breaking Changes

  • Removes Grammar Layer (NSM, Templates, Speech Acts) from 0x0C-0x0F
  • Those are now USER RESERVED
  • NODE zone reduced from 32K to 16K (0x80-0xBF instead of 0x80-0xFF)
  • New USER zone at 0xC0-0xFF

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.
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment on lines +174 to +179
// 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;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Comment on lines +286 to +289
#[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)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant