From 3d0c40b2b0949b1850327e60a5deb6318c023015 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Thu, 26 Apr 2018 06:19:56 +0100 Subject: [PATCH] add isa conflict resolution page --- isa_conflict_resolution.mdwn | 50 ++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index 10b141b43..b8291c32c 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -85,6 +85,11 @@ TBD TBD +> * MISA Extension disabling is permitted (optionally) to DESTROY the state +> information (which means that it *has* to be re-initialised just to be +> safe... mistake in the standard, there), and +> * MISA was only designed to cover Standard Extensions. + # MISA-like TBD @@ -93,6 +98,51 @@ TBD TBD +> In an earlier part of the thread someone kindly pointed out that MISA +> already switches out entire sets of instructions [which interacts at the +> "decode" phase]. However it was noted after a few days of investigating +> that particular lead that: +> +> * MISA Extension disabling is permitted (optionally) to DESTROY the state +> information (which means that it *has* to be re-initialised just to be +> safe... mistake in the standard, there), and * MISA was only designed +> to cover Standard Extensions. +> +> So the practice of switching extensions in and out - and the resultant +> "disablement" and "enablement" at the *instruction decode phase* is +> *already* a hard requirement as part of conforming with the present +> RISC-V Specification. +> +> Around the same MISA discussion, someone else also kindly pointed out +> that one solution to the heavyweight nature of the switching would +> be to deliberately introduce a pipeline stall whilst the switching is +> occurring: I can see the sense in that approach, even if I don't know the +> full details of what each implementor might choose to do. They may even +> choose two, or three, or N pipeline stalls: it really doesn't matter, +> as it's an implementors' choice (and problem to solve). +> +> So yes it's pretty heavy-duty... and also already required. +> +> For the case where "legacy" variants of the RISC-V Standard are +> backwards-forwards-compatibly supported over a 10-20 year period +> in Industrial and Military/Goverment-procurement scenarios (so that +> the impossible-to-achieve pressure is off to get the spec ABSOLUTELY +> correct, RIGHT now), nobody would expect a seriously heavy-duty amount +> of instruction-by-instruction switching: it'd be used pretty much once +> and only once at boot-up (or once in a Hypervisor Virtual Machine client) +> and that's it. +> +> I can however foresee instances where implementors would actually +> genuinely want a bank of operations to be carried out using one extension, +> followed immediately by another bank from a (conflicting binary-encoding) +> extension, in an inner loop: Software-defined MPEG / MP4 decode to call +> DCT block decode Custom Extension followed immediately by Custom Video +> Processing Extension followed immediately by Custom DSP Processing +> Extension to do YUV-to-RGB conversion for example is something that +> is clearly desirable. Solving that one would be entiiirely their +> problem... and the RISC-V Specification really really should give them +> the space to do that in a clear-cut unambiguous way. + # ioctl-like TBD -- 2.30.2