Date 1 - 2 of 2
[RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions
Philipp Tomsich <philipp.tomsich@...>
toggle quoted message Show quoted text
Duplicating the information (i.e. having the individual extensions marked and the profile itself indicated) seems like an error-prone proposal, unless we mandate/enforce consistency checking.
Given that this does not provide a significant benefit, it seems safer to stick with the canonical form listing the base and individual extensions.
What is the expected benefit from duplicating this information?
On Mon, 11 Jul 2022 at 23:15, Allen Baum <allen.baum@...> wrote:
On Mon, Jul 11, 2022 at 2:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:
This was a point I tried to make in another thread about tech-config and profiles. Support for a profile implies support for all the extensions mandated by the profile (but still leaves unspecified the support for further extensions).
So the question - that should be answered by the direct software user community of tech-config discovery structures - is whether the rest of a tech-config structure must only specify supported extensions not mandated by a profile, or must it also specify (redundantly) all the supported individual extensions, or is any degree of redundancy from zero to full allowed?
For example, having full redundancy would allow someone to simply check for presence of a specific extension of interest - without having to also check profile presence bits and understand what each of them implies. Conversely, does someone feel that any redundancy creates confusion or complications for software using tech-config structures?
The rest of us can raise questions, but the direct users of tech-config are the best ones to determine the right answer.
|1 - 2 of 2|