From: user5857@newsgrouper.org.invalid   
      
   Robert Finch  posted:   
      
   >    
   >   
   > > 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;   
      
   This is the direction of My 66000.   
      
   The instruction stream is a linear stream of words.   
   The first word of each instruction encodes its total length.   
   What follows the instruction itself are merely constants used as   
   operands in the instruction itself. All constants are 1 or 2   
   words in length.   
      
   I would not call this means "prefixed" or "suffixed". Generally,   
   prefixes and suffixes consume bits of the prefix/suffix so that   
   the constant (in my case) is not equal to container size. This   
   leads to wonky operand/displacement sizes not equal 2^(3+k).   
      
   > > 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.   
      
   But not "self identified".   
      
   >                          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.   
      
   I would have thought that the previous instruction (last one retired) would   
   provide the starting point of the subsequent instruction. This way you don't   
   have to worry about counting prefixes or suffixes.   
      
   > >   
   > >> - anton   
   > >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)