encoding.h is very far from up-to-date

[allenjbaum]

The version of encoding.h is not even cloe to up-to-date. It doesn't even have all the CSRs in the ratified priv spec (e.g. PMPCFGx, PMPADDRx). This needs to be regenerated as part of a C/I script whenever something new is added in its dependencies.

[aswaterman]

This is the canonical version, so it’s up to date by definition.

The file this repo generates is encoding.out.h (which then gets copied by other repos into their encoding.h). That file contains auto-generated macros for all of the CSR numbers.

(We don’t commit the auto-generated version to this repo; you need to check it out and build it.)

[aswaterman]

It probably would’ve been less confusing if the static file in this repo were named encoding.in.h, to make it clear it isn’t the complete file, but rather just one piece of it. It probably wouldn’t be too disruptive to make that change.

cc @neelgala - do you agree?

[allenjbaum]

This is probably a stupid question: there are lots of repositories that have pre-built artifacts, like the (ahem) ISA manual . This should be in the same category. Is there some reason we don't do that?

…

On Wed, Jun 29, 2022 at 6:12 PM Andrew Waterman ***@***.***> wrote: It probably would’ve been less confusing if the static file in this repo were named encoding.in.h, so that the complete auto-generated file could be named encoding.h. It probably wouldn’t be too disruptive to make that change. — Reply to this email directly, view it on GitHub <#132 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTZOZK7DM7R5C5MVOLVRTYARANCNFSM52HSOJKQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[aswaterman]

That’s a per-repo decision. If you have the time to donate that effort in a way that works for this repo’s maintainers, we will consider it. Don’t forget this essentially is a volunteer effort for us, too.

[Abdulwadoodd]

Hi @aswaterman, I'm willing to and want to do what needs to be done as @allenjbaum mentioned.

[aswaterman]

Thanks for volunteering. Can you make a brief proposal for what you'd like to do, so others who use this repo can comment on it?

[neelgala]

It probably would’ve been less confusing if the static file in this repo were named encoding.in.h, to make it clear it isn’t the complete file, but rather just one piece of it. It probably wouldn’t be too disruptive to make that change.

cc @neelgala - do you agree?

yes andrew is right here. the encoding.h file here is infact just a template.. and running the make command should generte encoding.out.h which has the information @allenjbaum is looking for and which is what should be consumed by 3rd party tools.

I just want to point out that the encoding.out.h in its current form is primarily targetted towards usage with spike (check the assumptions of this in PR #106 ). While it may work out of the box for other tools - future changes to generation of encoding.out.h will only be done keeping compatibility with spike in mind.

Other tools are free to add their makefile-targets/scripts to this repo to make generation of artificats (specific to their needs) simple for themselves.

Regarding artifacts generation - we first need a CI to version this repo (check #123 comments for this). Each new PR/release then can simply host the outputs of the make command as a zip artifact.

[allenjbaum]

Some aspects of this might be targeting spike (which also makes it target the ACTs and Sail, I suspect), so I don't see how that's a problem or a limitation until I see someone complain about it. I'm unclear about adding makefile-target scripts to this repo, as there aren't any that I see right now; Are you proposing to add a target directory?

…

On Mon, Jul 4, 2022 at 12:39 AM Neel Gala ***@***.***> wrote: It probably would’ve been less confusing if the static file in this repo were named encoding.in.h, to make it clear it isn’t the complete file, but rather just one piece of it. It probably wouldn’t be too disruptive to make that change. cc @neelgala <https://github.com/neelgala> - do you agree? yes andrew is right here. the encoding.h file here is infact just a template.. and running the make command should generte encoding.out.h which has the information @allenjbaum <https://github.com/allenjbaum> is looking for and which is what should be consumed by 3rd party tools. I just want to point out that the encoding.out.h in its current form is primarily targetted towards usage with spike (check the assumptions of this in PR #106 <#106> ). While it may work out of the box for other tools - future changes to generation of encoding.out.h will only be done keeping compatibility with spike in mind. Other tools are free to add their makefile-targets/scripts to this repo to make generation of artificats (specific to their needs) simple for themselves. Regarding artifacts generation - we first need a CI to version this repo (check #123 <#123> comments for this). Each new PR/release then can simply host the outputs of the make command as a zip artifact. — Reply to this email directly, view it on GitHub <#132 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJTZ6KR7L37ETUKLNGLVSKIJNANCNFSM52HSOJKQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>