From: robfi680@gmail.com   
      
      
      
   > One would argue that maybe prefixes are themselves wonky, but otherwise   
   > one needs:   
   > Instructions that can directly encode the presence of large immediate   
   > values, etc;   
   > Or, the use of suffix-encodings (which is IMHO worse than prefix   
   > encodings; at least prefix encodings make intuitive sense if one views   
   > the instruction stream as linear, whereas suffixes add weirdness and are   
   > effectively retro-causal, and for any fetch to be safe at the end of a   
   > cache line one would need to prove the non-existence of a suffix; so   
   > better to not go there).   
   >   
   I agree with this. Prefixes seem more natural, large numbers expanding   
   to the left, suffixes seem like a big-endian approach. But I use   
   suffixes for large constants. I think with most VLI constant data   
   follows the instruction. I find constant data easier to work with that   
   way and they can be processed in the same clock cycle as a decode so   
   they do not add to the dynamic instruction count. Just pass the current   
   instruction slot plus a following area of the cache-line to the decoder.   
      
   Handling suffixes at the end of a cache-line is not too bad if the cache   
   already handles instructions spanning a cache line. Assume the maximum   
   number of suffixes is present and ensure the cache-line is wide enough.   
   Or limit the number of suffixes so they fit into the half cache-line   
   used for spanning.   
      
   It is easier to handle interrupts with suffixes. The suffix can just be   
   treated as a NOP. Adjusting the position of the hardware interrupt to   
   the start of an instruction then does not have to worry about accounting   
   for a prefix / suffix.   
      
      
   >   
   > For the most part, superscalar works the same either way, with similar   
   > efficiency. There is a slight efficiency boost if it would be possible   
   > to dynamically reshuffle ops during fetch. But, this is not currently a   
   > thing in my case.   
   >   
   > This latter case would apply if, say, a MEM op is followed by non-   
   > dependent ALU ops, which under current superscalar handling they will   
   > not co-execute, but it could be possible in theory to swap the ops and   
   > allow them to co-execute.   
   >   
   >   
   > ...   
   >   
   >   
   >> - anton   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)