From: lkcl Date: Fri, 13 Nov 2020 00:11:48 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~1841 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=8111da1bab7c85d908b16ab3ebc5c2c0598c8ec2;p=libreriscv.git --- diff --git a/openpower/sv/major_opcode_allocation.mdwn b/openpower/sv/major_opcode_allocation.mdwn index 37142fd6a..f6528068f 100644 --- a/openpower/sv/major_opcode_allocation.mdwn +++ b/openpower/sv/major_opcode_allocation.mdwn @@ -23,7 +23,15 @@ See for discussion With the Major Opcode being at the opposite end of the sequential byte order when read from memory in LE mode, a solution which allows 16 and 48 bit instructions to co-exist with 32 bit ones is to look at bytes 2 and 3 *before* looking at 0 and 1. +Option 1: + A 16 bit instruction would therefore be in bytes 2 and 3, removed from the instruction stream *ahead* of bytes 0 and 1, which would remain where they were. The next instruction would repeat the analysis, starting now instead at the *new* byte 2-3. A 48 bit instruction would again use bytes 2 and 3, read the major opcode, and extract bytes 0 thru 5 from the stream. However the 48 bit instruction would be constructed from bytes 2,3,0,1,4,5. Again: after these 6 bytes were extracted fron the stream the analysis would begin again for the next instruction at bytes 2 and 3. +Option 2: + +When reading from memory, before handing to the instruction decoder, bytes 0 and 1 are swapped unconditionally with bytes 2 and 3. Effectively this is near-identical to LE/BE byte-level swapping on a 32-bit block except this time it is half-word (16 bit) swapping on a 32-bit block. + +With the Major Opcode then always being in the 1st 2 bytes it becomes much simpler for the pre-analysis phase to determine instruction length, regardless of what that length is (16/32/48/64/VBLOCK). +