On Thu, Mar 7, 2024 at 9:35 PM Richard Henderson
wrote:
>
> >>> -for (size_t i = 0; i < ARRAY_SIZE(decoders); ++i) {
> >>> -if (decoders[i].guard_func(ctx->cfg_ptr) &&
> >>> -decoders[i].decode_func(ctx, opcode32)) {
> >>> +for (size_t i = 0; i < decoder
Hello, Richard and Daniel,
Thanks to your review, the suggestions about decoder_table_size and
decoder's place will be adopted in the next version of the patch.
But I would not agree that this patch is a wash or worse. On average,
though, the two approaches may be comparable. However, as more
On 3/7/24 17:11, Richard Henderson wrote:
On 3/7/24 09:55, Daniel Henrique Barboza wrote:
(--- adding Richard ---)
On 3/6/24 06:33, Huang Tao wrote:
In this patch, we modify the decoder to be a freely composable data
structure instead of a hardcoded one. It can be dynamically builded up
ac
- for (size_t i = 0; i < ARRAY_SIZE(decoders); ++i) {
- if (decoders[i].guard_func(ctx->cfg_ptr) &&
- decoders[i].decode_func(ctx, opcode32)) {
+ for (size_t i = 0; i < decoder_table_size; ++i) {
+ if (ctx->decoder[i](ctx, opcode32)) {
On 3/7/24 09:55, Daniel Henrique Barboza wrote:
(--- adding Richard ---)
On 3/6/24 06:33, Huang Tao wrote:
In this patch, we modify the decoder to be a freely composable data
structure instead of a hardcoded one. It can be dynamically builded up
according to the extensions.
This approach has s
(--- adding Richard ---)
On 3/6/24 06:33, Huang Tao wrote:
In this patch, we modify the decoder to be a freely composable data
structure instead of a hardcoded one. It can be dynamically builded up
according to the extensions.
This approach has several benefits:
1. Provides support for heteroge
In this patch, we modify the decoder to be a freely composable data
structure instead of a hardcoded one. It can be dynamically builded up
according to the extensions.
This approach has several benefits:
1. Provides support for heterogeneous cpu architectures. As we add decoder in
CPUArchState,
