Hi Taylor,
On 10/8/26 23:32, Taylor Simpson wrote:
On Mon, Aug 10, 2026 at 3:12 PM Brian Cain <[email protected]>
wrote:
Seems like this change also depends on some kind of mutex around
regstr[] so that we know it's not being used concurrently by multiple
threads. Translation is single-threaded but if we gained another caller
we wouldn't remember to come back and remediate this.
I suppose we could take an input buffer/length. Or maybe we just add
another static _regnames[] array to solve the lifetime/race problems?
How about putting a regstr field in the Insn struct (and pass Insn* to
these two functions)?
A character array? Sure: seems like that should work.
But if we have a static array for the others why not leverage that here
too? We can statically fill these values, right?
These are for cases where there is some sort of error and the reg number is
larger than NUM_SREGS/TOTAL_PER_THREAD_REGS. So, we wouldn't know how to
size these without looking at the number of bits in the encoding of each
instruction that has one of these. However, that could change over time if
the architecture adds new instructions.
The regno field in the Insn struct is a uint8_t, so we could create static
arrays with 256 entries and
We could revert back to returning "???". Alternatively, S<unknown> or
C<unknown> would be more readable.
Hexagon frontend already relies a lot on generators, why not also
generate a static array?
