On Thu, 2 Jul 2020 20:52:04 -0400, "David Horner" <ds2horner@...> said:
| On 2020-07-02 8:20 p.m., Krste Asanovic wrote:
|| I added a note on this issue to spec:
||
|| NOTE: When migrating a software thread between two harts with
|| different microarchitectures, the `vstart` value might not be
|| supported by the new hart microarchitecture. The runtime on the
|| receiving hart might then have to emulate instruction execution to a
|| supported vstart element position.
| I appreciate you not punting this to "profiles"
|| Alternatively, migration events
|| can be constrained to only occur at mutually supported
|| `vstart`
|| locations.
| However, isn't this "mutually supported" effectively a profile
| constraint or consideration?
| Should we therefore include in the note that the specifics need to be
| defined by any profile that requires thread migration?
The note implies that but also includes the case where there is no
explicit profile, where two or more disparate harts are being created
by one designer between which migration will occur.
Krste
|| When migration is triggered by an epoch expiry, the interrupt can be
|| designed set to only occur between instructions, with vstart=0. But
|| in general, a software thread could be migrated between harts when it
|| has been descheduled for another reason, and when vstart might be
|| whatever the microarch decided (e.g., a device interrupt during a
|| long-running vector instruction).
| thumbs up.
||
|| I can't see a different solution than that given in the note, which
|| might limit freedom of designers to not support some vstart values
| specifically vector instructions that are not rerunable in a imprecise
| exception machine.
|| if they are to be compatible with a profile that supports migration.
||
|| Krste
||
||
||
|
