From 89e17b88c93b7d8ff5e04e6206989693b995247e Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Fri, 14 Jun 2019 07:16:28 +0100 Subject: [PATCH] add 48bit conflict FAQ --- isa_conflict_resolution/isamux_isans.mdwn | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/isa_conflict_resolution/isamux_isans.mdwn b/isa_conflict_resolution/isamux_isans.mdwn index a9f61f7df..d92f76ac2 100644 --- a/isa_conflict_resolution/isamux_isans.mdwn +++ b/isa_conflict_resolution/isamux_isans.mdwn @@ -121,6 +121,18 @@ first sight not to make any sense. It's complicated in other words! +# Surely it's okay to just tell people to use 48-bit encodings? + +Short answer: it doesn't help resolve conflicts, and costs hardware and +redesigns to do so. Softcores in cost-sensitive embedded applications may +even not actually be able to fit the required 48 bit instruction decode engine +into a (small, ICE40) FPGA. 48-bit instruction decoding is much more complex +than straight 32-bit decoding, requiring a queue. + +Second answer: conflicts can still occur in the (unregulated, custom) 48-bit +space, which *could* be resolved by ISAMUX/ISANS as applied to the *48* bit +space in exactly the same way. And the 64-bit space. + # Why not leave this to individual custom vendors to solve on a case by case basis? The suggestion was raised that a custom extension vendor could create -- 2.30.2