Re: "Mini" tags to reduce the number of op codes

On 4/4/2024 10:13 PM, John Savard wrote:

On some older CPUs, there might be one set of integer opcodes and one
set of floating-point opcodes, with a status register containing the
integer precision, and the floating-point precision, currently in use.
 The idea was that this would be efficient because most programs only
use one size of each type of number, so the number of opcodes would be
the most appropriate, and that status register wouldn't need to be
reloaded too often.
 It's considered dangerous, though, to have a mechanism for changing
what instructions mean, since this could let malware alter what
programs do in a useful and sneaky fashion. Memory bandwidth is no
longer a crippling constraint the way it was back in the days of core
memory and discrete transistors - at least not for program code, even
if memory bandwidth for _data_ often limits the processing speed of
computers.
 This is basically because any program that does any real work, taking
any real length of time to do its job, is going to mostly consist of
loops that fit in cache. So letting program code be verbose if there
are other benefits obtained thereby is the current conventional
wisdom.
 

This was how the FPU worked in SH-4. Reloading some bits in FPSCR would effectively bank out the current set of FPU instructions (say, between Single and Double, etc).
Also it was how 64-bit operations worked in early versions of 64-bit versions of BJX1.
Say. there were DQ and JQ bits added to the control register:
   DQ=0: 32-bit for variable-sized operations (like SH-4)
   DQ=1: 64-bit for variable-sized operations.
   JQ=0: 32-bit addressing (SH-4 memory map)
   JQ=1: 48-bit addressing (like the later BJX2 memory map).
The DQ bit would also effect whether one had MOV.W or MOV.Q operations available.
   DQ=0: Interpret ops as MOV.W (16-bit)
   DQ=1: Interpret ops as MOV.Q (64-bit)
In the DQ=JQ=0 case, it would have been mostly equivalent to SH-4 (and could still run GCC's compiler output). This was a similar situation to switching the FPU mode.
Though, a later version of the BJX1 ISA had dropped and repurposed some encodings, allowing MOV.W and MOV.Q to coexist (and avoiding the need for the compiler to endlessly toggle this bit), albeit with fewer addressing modes for the latter.
All this was an issue mostly because SH-4 had used fixed-length 16-bit instructions, and the encoding space was effectively almost entirely full when I started (so new instructions required either sacrificing existing instructions, or using mode bits).
Though, BJX1 did end up with some 32-bit ops, some borrowed from SH-2A and similar. These were mostly stuck into awkward ad-hoc places in the 16-bit map, so decoding was kind of a pain.
...
When I later rebooted things as my BJX2 project, I effectively dropped this whole mess and started over (with the caveat that it lost SH-4 compatibility). However, it has since gained RISC-V compatibility, for better/worse, at least RISC-V is likely to get slightly better performance than SH-4 at least (and both ISA's can be 64-bit).
...

John Savard