[Code Health] Add typed orchestration scalar helpers to hide uint64 ABI details

[lyfne123]

Category

Technical Debt (cleanup, refactor)

Component

Orchestration

Description

The orchestration scalar API currently exposes low-level ABI details to callers. PTOParam::add_scalar() only accepts uint64_t, so orchestration code must manually encode non-integer scalar values into raw bit patterns before submission.

A concrete example is the AICPU vector example, where kernel_add_scalar expects a float scalar but the orchestration layer has to call float_to_u64(1.0f) / float_to_u64(2.0f) before passing the value. This makes orchestration code aware of the kernel argument binary representation instead of expressing the intended scalar type directly.

This is not a correctness bug today, but it is an abstraction leak that makes orchestration code harder to read, easier to misuse, and less uniform with the read side APIs that already provide typed helpers such as OrchArg::value_as<T>().

Location

• src/a2a3/runtime/aicpu_build_graph/runtime/pto_types.h
• src/a2a3/runtime/tensormap_and_ringbuffer/runtime/pto_types.h
• examples/a2a3/aicpu_build_graph/vector_example/kernels/orchestration/orchestration.cpp
• examples/a2a3/tensormap_and_ringbuffer/vector_example/kernels/orchestration/example_orchestration.cpp
• examples/a2a3/aicpu_build_graph/vector_example/kernels/aiv/kernel_add_scalar.cpp

Proposed Fix

Keep the underlying scalar ABI unchanged if desired, but add typed helper APIs at the orchestration layer, for example:

• add_scalar_f32(float) / add_scalar_f64(double)
• add_scalar_i32(int32_t) / add_scalar_u32(uint32_t)
• or a generic helper such as add_scalar_as<T>(T value) / AddScalarBits<T>(T value) that bit-casts into the existing uint64_t slot.

The goal is for orchestration code to express the semantic type directly and avoid hand-written helpers like float_to_u64() in examples and production orchestration code.

Priority

Low (no impact today, good to fix eventually)