| Message ID | 20240115222528.257342-2-dbarboza@ventanamicro.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | target/riscv: add 'cpu->cfg.vlenb', remove 'cpu->cfg.vlen' | expand |
On 1/16/24 09:25, Daniel Henrique Barboza wrote: > Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'. > We're using 'vlenb' most of the time, having to do 'vlen >> 3' or > 'vlen / 8' in every instance. > > In hindsight we would be better if the 'vlenb' property was introduced > instead of 'vlen'. That's not what happened, and now we can't easily get > rid of it due to user scripts all around. What we can do, however, is to > change our internal representation to use 'vlenb'. > > Add a 'vlenb' field in cpu->cfg. It'll be set via the existing 'vlen' > property, i.e. setting 'vlen' will also set 'vlenb'. > > We'll replace all 'vlen >> 3' code to use 'vlenb' directly. Start with > the single instance we have in target/riscv/cpu.c. > > Signed-off-by: Daniel Henrique Barboza<dbarboza@ventanamicro.com> > --- > target/riscv/cpu.c | 4 +++- > target/riscv/cpu_cfg.h | 1 + > 2 files changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> r~
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index 8d3ec74a1c..f4261d2ffc 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -847,7 +847,7 @@ static void riscv_cpu_dump_state(CPUState *cs, FILE *f, int flags) csr_ops[csrno].name, val); } } - uint16_t vlenb = cpu->cfg.vlen >> 3; + uint16_t vlenb = cpu->cfg.vlenb; for (i = 0; i < 32; i++) { qemu_fprintf(f, " %-8s ", riscv_rvv_regnames[i]); @@ -1314,6 +1314,7 @@ static void riscv_cpu_init(Object *obj) /* Default values for non-bool cpu properties */ cpu->cfg.pmu_mask = MAKE_64BIT_MASK(3, 16); cpu->cfg.vlen = 128; + cpu->cfg.vlenb = 128 >> 3; cpu->cfg.elen = 64; cpu->env.vext_ver = VEXT_VERSION_1_00_0; } @@ -1810,6 +1811,7 @@ static void prop_vlen_set(Object *obj, Visitor *v, const char *name, cpu_option_add_user_setting(name, value); cpu->cfg.vlen = value; + cpu->cfg.vlenb = value >> 3; } static void prop_vlen_get(Object *obj, Visitor *v, const char *name, diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h index fea14c275f..50479dd72f 100644 --- a/target/riscv/cpu_cfg.h +++ b/target/riscv/cpu_cfg.h @@ -140,6 +140,7 @@ struct RISCVCPUConfig { uint32_t pmu_mask; uint16_t vlen; + uint16_t vlenb; uint16_t elen; uint16_t cbom_blocksize; uint16_t cbop_blocksize;
Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'. We're using 'vlenb' most of the time, having to do 'vlen >> 3' or 'vlen / 8' in every instance. In hindsight we would be better if the 'vlenb' property was introduced instead of 'vlen'. That's not what happened, and now we can't easily get rid of it due to user scripts all around. What we can do, however, is to change our internal representation to use 'vlenb'. Add a 'vlenb' field in cpu->cfg. It'll be set via the existing 'vlen' property, i.e. setting 'vlen' will also set 'vlenb'. We'll replace all 'vlen >> 3' code to use 'vlenb' directly. Start with the single instance we have in target/riscv/cpu.c. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> --- target/riscv/cpu.c | 4 +++- target/riscv/cpu_cfg.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-)