Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enhanced general definition and descriptions regarding profiles #102

Open
mark-riscv opened this issue May 3, 2023 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@mark-riscv
Copy link

In responding to a TSC effort, it became clear that we are missing some context for profiles in this specification. Krste asked me to add this in as an issue here so we have all of this in one place.

here is the text (note a couple of small things have not been agreed to):

Why Profiles?
Profiles (along with accompanying APIs and ABIs) are intended to allow application software developers to compile their application once and run on multiple implementations
Profiles provide targets for toolchains and platforms and hardware implementations to focus on a profile and not have to spend resources chasing divergent implementations

Prerequisite Definitions
Bases - a base is a set of instructions, states, and behaviors that is the required foundation for a profile. Ratified bases include RVI32, RVI64, RVE32, RVE64
Extensions - an extension is a set of instructions, states and behaviors. Instructions, states and behaviors may appear in multiple extensions. Extensions may include other extensions.

What is a Profile?
A Profile is a ratified base plus a set of ratified extensions
A Profile specifies whether an extension is mandatory or optional. Even though optional extensions may include other extensions, it does not imply that included extensions are optional too.
Implementations branded as Profile compatible for a particular profile must implement the base and the mandatory extensions, and may implement all, some, or none of the optional extensions. It is preferred that they either implement the options (optional extension) or fail gracefully if they do not (not agreed to).
A Profile may be a major Profile or a minor Profile. We expect toolchains to support major profiles. The minor profiles are checkpoints so we don’t have too much content in one major profile. It is intended to provide a runway for toolchains to support the minor Profile content as intermediate steps on the way to the next major Profile but it is up to the individual projects to determine their own timelines. Determination about whether a profile is major or minor occurs when the profile specification hits the freeze milestone
Profiles may contain instructions, state, and behaviors for multiple privileged modes and implementations may choose to support and be compatible with a subset of the modes
See the profiles specification for naming details.

Platform interaction
Platforms may add additional requirements but may not reduce an included Profile.

Ramp & Lifetime
While we expect basic toolchain support to be available as part of most extension ratifications (and hence profile ratifications), advanced toolchain work (like optimizers) may take some time post ratification.
While IP vendors may support ratified extensions simultaneous with ratification, both IP and silicon implementations supporting profiles may take time to implement (e.g. chips may take from 12-48 months).
It is expected that Profile versions will overlap in time and likely will be used for 10 or more years.

@kasanovic
Copy link
Collaborator

This to be added once profiles are rolled into main ISA document.

@rpsene rpsene added the enhancement New feature or request label Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants