From: paaronclayton@gmail.com   
      
   On 11/5/25 3:52 PM, MitchAlsup wrote:   
   >   
   > Robert Finch  posted:   
   >   
   >> On 2025-11-05 1:47 a.m., Robert Finch wrote:   
   > -----------   
   >> I am now modifying Qupls2024 into Qupls2026 rather than starting a   
   >> completely new ISA. The big difference is Qupls2024 uses 64-bit   
   >> instructions and Qupls2026 uses 48-bit instructions making the code 25%   
   >> more compact with no real loss of operations.   
   >>   
   >> Qupls2024 also used 8-bit register specs. This was a bit of overkill and   
   >> not really needed. Register specs are reduced to 6-bits. Right-away that   
   >> reduced most instructions eight bits.   
   >   
   > 4 register specifiers: check.   
   >   
   >> I decided I liked the dual operations that some instructions supported,   
   >> which need a wide instruction format.   
   >   
   > With 48-bits, if you can get 2 instructions 50% of the time, you are only   
   > 12% bigger than a 32-bit ISA.   
      
   I must be misunderstanding your math; if half of the   
   6-byte instructions are two operations, I think that   
   means 12 bytes would have three operations which is   
   the same as for a 32-bit ISA.   
      
   Perhaps you meant for every two instructions, there   
   is a 50% chance neither can be "fused" and a 50%   
   chance they can be fused with each other; this would   
   get four operations in 18 bytes, which _is_ 12.5%   
   bigger. That seems an odd expression, as if the   
   ability to fuse was not quasi-independent.   
      
   It could just be that one of us has a "thought-O".   
      
   >> One gotcha is that 64-bit constant overrides need to be modified. For   
   >> Qupls2024 a 64-bit constant override could be specified using only a   
   >> single additional instruction word. This is not possible with 48-bit   
   >> instruction words. Qupls2024 only allowed a single additional constant   
   >> word. I may maintain this for Qupls2026, but that means that a max   
   >> constant override of 48-bits would be supported. A 64-bit constant can   
   >> still be built up in a register using the add-immediate with shift   
   >> instruction. It is ugly and takes about three instructions.   
   >   
   > It was that sticking problem of constants that drove most of My 66000   
   > ISA style--variable length and how to encode access to these constants   
   > and routing thereof.   
   >   
   > Motto: never execute any instructions fetching or building constants.   
      
   I am guessing that having had experience with x86   
   (and the benefit of predecode bits), you recognized   
   that VLE need not be horribly complex to parse.   
   My 66000 does not use "start bits", but the length   
   is quickly decoded from the first word and the   
   critical information is in mostly fixed locations   
   in the first word. (One might argue that opcode   
   can be in two locations depending on if the   
   instruction uses a 16-bit immediate or not —   
   assuming I remember that correctly.)   
      
   Obviously, something like DOUBLE could provide   
   extra register operands to a complex instruction,   
   though there may not be any operation needing   
   five register inputs. Similarly, opcode refinement   
   (that does not affect operation routing) could be   
   placed into an "immediate". I think you do not   
   expect to need such tricks because reduced   
   number of instructions is a design principle and   
   there is lots of opcode space remaining, but I   
   feel these also allow the ISA to be extended in   
   unexpected directions.   
      
   I think that motto could be generalized to "do   
   not do at decode time what can be done at   
   compile time" (building immediates could be   
   "executed" in decode). There are obvious limits   
   to that principle; e.g., one would not encode   
   instructions as control bits, i.e., "predecoded",   
   in order to avoid decode work. For My 66000   
   immediates, reducing decode work also decreases   
   code size.   
      
   Discerning when to apply a transformation and if/   
   where to cache the result seems useful. E.g., a   
   compiler caches the source code to machine code   
   transformation inside an executable binary. My   
   66000's Virtual Vector Method implementations   
   are expected, from what I understand, to cache   
   fetch and decode work and simplify operand   
   routing.   
      
   Caching branch prediction information in an   
   instruction seems to be viewed generally as not   
   worth much since dynamic predictors are generally   
   more accurate. Static prediction by branch   
   "type" (e.g., forward not-taken) can require no   
   additional information. (Branch prediction   
   _directives_ are somewhat different. Such might   
   be used to reduce the time for a critical path,   
   but average time is usually a greater concern.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)