Missing documentation in TestFormatSpec.adoc
cmuellner opened this issue · 3 comments
cmuellner commented
The following widely used elements are not documented in TestFormatSpec.adoc:
- macro
RVTEST_FP_ENABLE() - macro
RVTEST_VALBASEUPD() - macro
TEST_FPIO_OP() - the
rvtest_mtrap_routinemechanism and how it has to be supported in the test files (labelmtrap_sigptr - the canary mechanism (labels:
sig_begin_canary,tsig_begin_canary,tsig_end_canaryand macroCANARY) - the
rvtest_gpr_savemechanism and how it has to be supported in the test files (labelgpr_save)
allenjbaum commented
I am currently rewriting the tsts format spec, and splitting into 2 pieces:
- what test developers need to know (which is really the bulk of it)
- what test users need to know (primarily the YAML files, and the
RVMODEL_<XXX> macros.)
It is coming slowly...
Future test writers should not have to worry about the canary mechanism or
mtrap_sigptr,
as they are all encapsulated in new (but not yet documented...)
RVTEST_SIG_BEGIN, RVTEST_TSIG_BEGIN and RVTEST_SIGEND macros,
Note that there are macros that test developers define for
their specific tests (in a separate test_macros.h file) ,
and those in general will not be documented (as new ones can get added for
each new extension).
Test writers should acquaint themselves with those macros - none are
terribly complicated.
There are also both required and optional macros applicable to all tests
(in arch_test.h). Those will be documented.
VALBASEUPD (and others) are optional, but can be used in many different
specs. I'll make sure they get to the main description
RVTEST_FP_EN is pretty trivial (makes sure mstatus.fs is set to 11, and
clears accumulated status) which encompasses all FP test,s so I'll lump
that in there - though it will only be used once per tests, in generall,
RVTEST_FPIO_OP is pretty specific to a particular set of FP tests, so
don't fall into the category.
…On Mon, Apr 3, 2023 at 11:12 AM Christoph Müllner ***@***.***> wrote:
The following widely used elements are not documented in
TestFormatSpec.adoc:
- macro RVTEST_FP_ENABLE()
- macro RVTEST_VALBASEUPD()
- macro TEST_FPIO_OP()
- the rvtest_mtrap_routine mechanism and how it has to be supported in
the test files (label mtrap_sigptr
- the canary mechanism (labels: sig_begin_canary, tsig_begin_canary,
tsig_end_canary and macro CANARY)
- the rvtest_gpr_save mechanism and how it has to be supported in the
test files (label gpr_save)
—
Reply to this email directly, view it on GitHub
<#324>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJQR6MJNDVRXBPYPF2TW7MHJVANCNFSM6AAAAAAWRVIXRU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
cmuellner commented
Thanks for the response!
Test writers should acquaint themselves with those macros - none are terribly complicated.
Of course, I am able to read the macros, but this does not necessarily lead to answers:
- Why is
RVTEST_ISA()mandatory if it does nothing (even a comment in the code asks this question...)? - Why does code around the use of
RVTEST_CODE_BEGINduplicate the assembler directive that the macro expands to? - Why does code following
RVTEST_DATA_BEGINset the alignment when the macro already does that? - Why are the extension-specific test macros in
test_macros.hnot separated into separate files? - Why does
test_macros.hnot even have an include guard? - Why is there a huge amount of outdated and unmaintained code from Binutils in
encoding.h?
Looking at existing (generated?) test code does not always help either:
flw-align-01.Sdefines useless-empty-newline labelstest_dataset_0,test_dataset_1
The purpose of this list is not a request for support, but to document work items so they can be picked up.
allenjbaum commented
I'll answer what I know:
- RVTEST_ISA is basically a tag that the riscof framework picks up to
configure the build process..
- RVTEST_CODE/DATA_BEGIN: The answer to this is mostly historical: e.g.we
added functionality to macros
(that arguably should have been there at the beginning), but didn't want to
change all the tests to remove harmless, extraneous labels and alignments,
or, in some cases, to preserve backward compatibility while enabling new
features..
From now onwards, the test should need the duplicate code because it has
been moved in thise macros
- the original test_format_spec only allowed a single macro file. We
recently split it up to simplify development and reducing dependencies and
merge conflicts.
That doesn't seem to be a problem with the test_macros, and we don't want
to have to keep track of which macro files should be included, so we put
them all into a single file.
- neither arch_test.h nor test_macros.h have guards because they are
effectively "golden" macros that approved for test use and are always
included.
- again - historical. encoding.h should be re-built whenever new tests are
added, but it's currently not in the C/I tooling.
A lot of this is clearing up harmless code artifacts that do not affect
functionality or correctness - thry are way, way down our priority list.
We have enough trouble getting resources to create new tests.
…On Mon, Apr 3, 2023 at 10:11 PM Christoph Müllner ***@***.***> wrote:
Thanks for the response!
Test writers should acquaint themselves with those macros - none are
terribly complicated.
Of course, I am able to read the macros, but this does not necessarily
lead to answers:
- Why is RVTEST_ISA() mandatory if it does nothing (even a comment in
the code asks this question...)?
- Why does code around the use of RVTEST_CODE_BEGIN duplicate the
assembler directive that the macro expands to?
- Why does code following RVTEST_DATA_BEGIN set the alignment when the
macro already does that?
- Why are the extension-specific test macros in test_macros.h not
separated into separate files?
- Why does test_macros.h not even have an include guard?
- Why is there a huge amount of outdated and unmaintained code from
Binutils in encoding.h?
Looking at existing (generated?) test code does not always help either:
- flw-align-01.S defines useless-empty-newline labels test_dataset_0,
test_dataset_1
The purpose of this list is not a request for support, but to document
work items so they can be picked up.
—
Reply to this email directly, view it on GitHub
<#324 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJXDALZMLB6IUJM5IMTW7OURBANCNFSM6AAAAAAWRVIXRU>
.
You are receiving this because you commented.Message ID:
***@***.***>