From: user5857@newsgrouper.org.invalid   
      
   Paul Clayton  posted:   
      
   > 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.   
      
   My 66000 Constants are available when:   
   inst<31> = 0 and   
   inst<30> != inst<29> and   
   inst<6> = 1 where   
   inst<6:5> = 10 means 32-bit   
   constant and inst<6:5> = 11 means 64-bit constant.   
   6 total gates and 2-gates of delay gives unary 3-bit   
   instruction length.   
      
   >                    (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   
   or link time.   
   > "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.   
      
   First v in vVM is lower case.   
      
   > Caching branch prediction information in an   
   > instruction seems to be viewed generally as not   
   > worth much since dynamic predictors are generally   
   > more accurate.   
      
   Yes. If your branch predictor is having problems   
   then use predication for flow control.   
      
   >                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)