RVMODEL_IO_ASSERT_GPR_RQ used for float point registers

[andreasWallner]

When updating an old testbench where we use a custom RVMODEL_IO_ASSERT_GPR_EQ macro in model_test.h for reporting I can't build the F & D tests. The reason for this is that TEST_CASE_F in test_macros.h uses RVMODEL_IO_ASSERT_GPR_EQ, passing a float point register as the destreg, and our implementation of that macro assumes that destreg will be an integer register.

Given that the template also provides two macros that seem to me to be for float comparison (https://github.com/riscv-software-src/riscof/blob/108fa2d4e824b3e37fcff82e4fbbb7243127320b/riscof/Templates/setup/reference/env/model_test.h#L40-L42), should TEST_CASE_F call those instead of the GPR version?
If not, did I overlook a way to decide between mv and fmv depending on the register?

The trail of breadcrumbs:

riscv-arch-test/riscv-test-suite/rv32i_m/F/src/fmin_b1-01.S

Line 44 in 8a52b01

TEST_FPRR_OP_NRM(fmin.s, f25, f25, f31, 0, 0, x3, 0*FLEN/8, x4, x1, x2)

passes f25 as the destreg

riscv-arch-test/riscv-test-suite/env/test_macros.h

Lines 721 to 722 in 8a52b01

	#define TEST_FPRR_OP_NRM(inst, destreg, freg1, freg2, fcsr_val, correctval, valaddr_reg, val_offset, flagreg, swreg, testreg) \
	TEST_CASE_F(testreg, destreg, correctval, swreg, flagreg, \

passes that on to:

riscv-arch-test/riscv-test-suite/env/test_macros.h

Lines 613 to 616 in 8a52b01

	#define TEST_CASE_F(testreg, destreg, correctval, swreg, flagreg, code... ) ;\
	code ;\
	RVTEST_SIGUPD_F(swreg,destreg,flagreg) ;\
	RVMODEL_IO_ASSERT_GPR_EQ(testreg, destreg, correctval)

and on to RVMODEL_IO_ASSERT_GPR_EQ as _R

https://github.com/riscv-software-src/riscof/blob/108fa2d4e824b3e37fcff82e4fbbb7243127320b/riscof/Templates/setup/reference/env/model_test.h#L38

In our specific RVMODEL_IO_ASSERT_GPR_EQ we then mv that register to s0 which yields an invalid instruction for this (and many other) case.

#define RVMODEL_IO_ASSERT_GPR_EQ(_SP, _R, _I)                                 \
    LOCAL_IO_PUSH(_SP)                                                  \
    mv          s0, _R;     

[allenjbaum]

I thought PR 426 iswaiting to get approved for that- check that and see if it fits your needs

…

On Sun, Feb 4, 2024 at 2:47 PM Andreas Wallner ***@***.***> wrote: When updating an old testbench where we use a custom RVMODEL_IO_ASSERT_GPR_EQ macro in model_test.h for reporting I can't build the F & D tests. The reason for this is that TEST_CASE_F in test_macros.h uses RVMODEL_IO_ASSERT_GPR_EQ, passing a float point register as the destreg, and our implementation of that macro assumes that destreg will be an integer register. Given that the template also provides two macros that seem to me to be for float comparison ( https://github.com/riscv-software-src/riscof/blob/108fa2d4e824b3e37fcff82e4fbbb7243127320b/riscof/Templates/setup/reference/env/model_test.h#L40-L42), should TEST_CASE_F call those instead of the GPR version? If not, did I overlook a way to decide between mv and fmv depending on the register? The trail of breadcrumbs: https://github.com/riscv-non-isa/riscv-arch-test/blob/8a52b016dbe1e2733cc168b9d6e5c93e39059d4d/riscv-test-suite/rv32i_m/F/src/fmin_b1-01.S#L44 passes f25 as the destreg https://github.com/riscv-non-isa/riscv-arch-test/blob/8a52b016dbe1e2733cc168b9d6e5c93e39059d4d/riscv-test-suite/env/test_macros.h#L721-L722 passes that on to: https://github.com/riscv-non-isa/riscv-arch-test/blob/8a52b016dbe1e2733cc168b9d6e5c93e39059d4d/riscv-test-suite/env/test_macros.h#L613-L616 and on to RVMODEL_IO_ASSERT_GPR_EQ as _R https://github.com/riscv-software-src/riscof/blob/108fa2d4e824b3e37fcff82e4fbbb7243127320b/riscof/Templates/setup/reference/env/model_test.h#L38 In our specific RVMODEL_IO_ASSERT_GPR_EQ we then mv that register to s0 which yields an invalid instruction for this (and many other) case. #define RVMODEL_IO_ASSERT_GPR_EQ(_SP, _R, _I) \ LOCAL_IO_PUSH(_SP) \ mv s0, _R; — Reply to this email directly, view it on GitHub <#434>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJV4B56JGVTBKFVMY6DYSAFZPAVCNFSM6AAAAABCZGOF4SVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEYTOMZVGE4TMOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[andreasWallner]

Yes, you are totally right - I shouldn't have only searched the issues...
Closing this as there is #426 already