From 3ebe82ec5a6bb2f32306efe7109e245fa320e8b3 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Fri, 27 Apr 2018 04:46:55 +0100 Subject: [PATCH] clarify --- isa_conflict_resolution.mdwn | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/isa_conflict_resolution.mdwn b/isa_conflict_resolution.mdwn index eb91163f0..d96c5eeaf 100644 --- a/isa_conflict_resolution.mdwn +++ b/isa_conflict_resolution.mdwn @@ -316,8 +316,8 @@ On this latter point, it was observed that MISA already switches out entire sets of instructions (interacts at the "decode" phase). The difference between what MISA does and the mvendor/march-id WARL idea is that whilst MISA only switches instruction decoding on (or off), the WARL idea -*redirects* encoding, to *different* engines, fortunately in a deliberately -mutually-exclusive fashion. +*redirects* encoding, effectively to *different* simultaneous engines, +fortunately in a deliberately mutually-exclusive fashion. Implementations would therefore, in each Extension (assuming one separate "decode" engine per Extension), simply have an extra (mutually-exclusively @@ -325,8 +325,8 @@ enabled) wire in the AND gate for any given binary encoding, and in this way there would actually be very little impact on the latency. The assumption here is that there are not dozens of Extensions vying for the same binary encoding (at which point the Fabless Semi Company has other much more -pressing issues to deal with that make resolving encoding conflicts trivial -by comparison). +pressing issues to deal with that make resolving binary encoding conflicts +trivial by comparison). Also pointed out was that in certain cases pipeline stalls could be introduced during the switching phase, if needed, just as they may be needed for -- 2.30.2