external-cannbot-ops-ascendc-regbase-best-practice

Ascend C RegBase Development

This capability addresses four categories of problems under the RegBase route: API constraint confirmation, implementation structure reference, common pitfall troubleshooting, and real reference operator selection.

reference-ops The subtree is a lightweight reference asset. A match on operator name or base type only indicates a "candidate reference worth examining"; it cannot prove that the target task can directly reuse, fuse, or copy that implementation. Whether to reuse it must be re-evaluated through a RegBase-specific design decision.

When to Use

Use this capability when any of the following conditions is met:

• The Architect considers RegBase as a candidate route during solution decision-making.
• RegBase / RegTensor / asc_vf_call / simd_vf and other signals appear explicitly in the user input, DESIGN.md, or the code.
• The Developer or Reviewer needs to confirm RegBase-specific APIs, implementation structure, pitfalls, or reference implementations.

Do not treat this capability as a general substitute for the default operator development path. When the technical route is undecided, the Architect completes the solution decision between SIMD/MemBase and RegBase.

Reading Entry Points

• End-to-end development mainline:references/regbase_development_guide.md
• API constraints and signatures:references/api/index.md
• Pitfalls and precision risks:references/pitfalls/index.md
• Engineering experience and route judgment:references/dev-experience/index.md
• Real reference implementations:references/reference-ops/open_source_operator_table.md

Select by Stage

• Solution decision:references/regbase_development_guide.md、references/dev-experience/index.md
• Design:references/regbase_development_guide.md、references/api/index.md
• Implementation:references/api/index.md、references/dev-experience/regbase_programming_notes.md、references/reference-ops/open_source_operator_table.md
• Review:references/pitfalls/index.md、references/dev-experience/index.md
• Fixing and debugging:references/pitfalls/symptom_to_cause.md、references/dev-experience/index.md

After entering api/、pitfalls/ or dev-experience/ , first read that directory's index.md, then open the leaf documents. For a single sub-problem, expand at most 5 leaf documents; if that is still not enough, split the problem rather than loading the entire subtree at once.

Constraints

• Before referencing an API, you must check the API whitelist, API reference, or official documentation; do not guess based on function names.
• Design pseudocode cannot be directly treated as compilable implementation; when writing code, you must return to the real engineering template and API signatures.
• Before writing a new RegBase operator, you must use open_source_operator_table.md to locate candidate directories, and read at least one real implementation confirmed to contain RegBase evidence.
• When you see keywords such as RegTensor / MaskReg / asc_vf_call / __simd_vf__ , prioritize checking the API layer and pitfalls layer.
• Architectural judgments must be stated explicitly. If a piece of experience comes from a compatibility path rather than the main path DAV_3510 / RegBase, this needs to be made clear.