From 1a58ac3eb5c95961ce657be1212762ba606b6e25 Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 30 Nov 2020 23:50:33 +0000 Subject: [PATCH] --- openpower/sv/16_bit_compressed.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/openpower/sv/16_bit_compressed.mdwn b/openpower/sv/16_bit_compressed.mdwn index 762a68139..741ed14d8 100644 --- a/openpower/sv/16_bit_compressed.mdwn +++ b/openpower/sv/16_bit_compressed.mdwn @@ -829,11 +829,13 @@ At this phase, knowing that the length is 16bit and the mode is either 10b or 16 decode_10bit(insn) elif mode == 16bit: if N == 1 & M == 1 & op_001_1 + # see immediate opcodes table decode_16bit_immed_mode(insn) if op_001_1: + # see CR and System tables + # (16 bit ones at least) decode_16bit_cr_or_sys(insn) else: - # see immediate opcodes table decode_16bit_nonimmed_mode(insn) From this point onwards each of the decode_xx functions perform straightforward combinatorial decoding of the 16 bits of "insn". In sone cases this involves further analysis of bit 1, in some cases (Cmaj.m = 0b010.1) even further deep-dive decoding is required (CR ops). *All* of it is entirely combinatorial and at **no time** involves changing of, or interaction with, or disruption of, the Phase 1 determination of Length+Mode (that has *already taken place* in an earlier decoding pipeline time-schedule) -- 2.30.2