From: user5857@newsgrouper.org.invalid   
      
   Robert Finch  posted:   
      
   > On 2025-08-01 5:04 p.m., John Savard wrote:   
   > > On Fri, 01 Aug 2025 18:08:17 +0000, Thomas Koenig wrote:   
   > >   
   > >> Question: Do the pointers point to the same block only, or also to other   
   > >> blocks?  With 5 bits, you could address others as well. Can you give an   
   > >> example of their use, including the block headers?   
   > >   
   > > Actually, no, 5 bits are only enough to point within the same block.   
   > > That's because it's a byte pointer, as it can be used to point to any type   
   > > of constant, including single byte constants.   
   > >   
   > > This is despite the fact that I do have an instruction format for   
   > > conventional style byte immediates (and I've just squeezed in one for   
   > > 16-bit immediates as well).   
   > >   
   > > However, they _can_ point to another block, by means of a sixth bit that   
   > > some instructions have... but when this happens, it does not trigger an   
   > > extra fetch from memory. Instead, the data is retrieved from a copy of an   
   > > earlier block in the instruction stream that's saved in a special   
   > > register... so as to reduce potential NOP-style problems.   
   > >   
   > > John Savard   
   >   
   > I tried something similar to this but without block headers and it   
   > worked okay. But there were a couple of issues. One was the last   
   > instruction in cache line could not have an immediate. Or instructions   
   > had to stop before the end of the cache line to accommodate immediates.   
   > This resulted in some wasted space. There would sometimes be a 32-bit   
   > hole between the last instruction and the first immediate. I used a   
   > four-bit index and 32-bit immediate, instruction word size. Four bits   
   > was enough for a 512-bit (cache line size). IIRC the wasted space was   
   > about 5%.   
      
   We really don't want to waste space.   
      
   > It made the assembler more complex. I had immediates being positioned   
   > from the far end of the cache line down (like a stack) towards the   
   > instructions which began at the lower end. The assembler had to be able   
   > to keep track of where things were on the cache line and the assembler   
   > was not built to handle that.   
   > Also, it made reading listings more difficult as constants were in the   
   > middle of sequences of instructions.   
      
   We really don't want to make it any harder to read ASM code.   
      
   > Sometimes constants could be shared, but this turned out to be not   
   > possible in many cases as the assembler needed to emit relocation   
   > records for some constants and it could not handle having two or more   
   > instructions pointing to the same constant.   
      
   All the more reason to place the constant in the instruction stream.   
   a) never wastes space*   
   b) ASM readability   
      
   (*) never wastes space refers to placement of constant, not that the   
   constant-container is optimal for the placed constant.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)