From: ThatWouldBeTelling@thevillage.com   
      
   George Neuner wrote:   
   > On Tue, 5 Aug 2025 05:48:16 -0000 (UTC), Thomas Koenig   
   > wrote:   
   >   
   >> Waldek Hebisch schrieb:   
   >>> I am not sure what technolgy they used   
   >>> for register file. For me most likely is fast RAM, but that   
   >>> normally would give 1 R/W port.   
   >> They used fast SRAM and had three copies of their registers,   
   >> for 2R1W.   
   >   
   >   
   > I did use 11/780, 8600, and briefly even MicroVax - but I'm primarily   
   > a software person, so please forgive this stupid question.   
   >   
   >   
   > Why three copies?   
   > Also did you mean 3 total? Or 3 additional copies (4 total)?   
   >   
   >   
   > Given 1 R/W port each I can see needing a pair to handle cases where   
   > destination is also a source (including autoincrement modes). But I   
   > don't see a need ever to sync them - you just keep track of which was   
   > updated most recently, read that one and - if applicable - write the   
   > other and toggle.   
   >   
   > Since (at least) the early models evaluated operands sequentially,   
   > there doesn't seem to be a need for more. Later models had some   
   > semblance of pipeline, but it seems that if the /same/ value was   
   > needed multiple times, it could be routed internally to all users   
   > without requiring additional reads of the source.   
   >   
   > Or do I completely misunderstand? [Definitely possible.]   
      
   To make a 2R 1W port reg file from a single port SRAM you use two banks   
   which can be addressed separately during the read phase at the start of   
   the clock phase, and at the end of the clock phase you write both banks   
   at the same time on the same port number.   
      
   The 780 wiring parts list shows Nat Semi 85S68 which are   
   16*4b 1RW port, 40 ns access SRAMS, tri-state output,   
   with latched read output to eliminate data race through on write.   
      
   So they have two 16 * 32b banks for the 16 general registers.   
   The third 16 * 32b bank was likely for microcode temp variables.   
      
   The thing is, yes, they only needed 1R port for instruction operands   
   because sequential decode could only produce one operand at a time.   
   Even on later machines circa 1990 like 8700/8800 or NVAX the general   
   register file is only 1R1W port, the temp register bank is 2R1W.   
      
   So the 780 second read port is likely used the same as later VAXen,   
   its for reading the temp values concurrently with an operand register.   
   The operand registers were read one at a time because of the decode   
   bottleneck.   
      
   I'm wondering how they handled modifying address modes like autoincrement   
   and still had precise interrupts.   
      
    ADDLL (r2)+, (r2)+, (r2)+   
      
   the first (left) operand reads r2 then adds 4, which the second r2 reads   
   and also adds 4, then the third again. It doesn't have a renamer so   
   it has to stash the first modified r2 in the temp registers,   
   and (somehow) pass that info to decode of the second operand   
   so Decode knows to read the temp r2 not the general r2,   
   and same for the third operand.   
   At the end of the instruction if there is no exception then   
   temp r2 is copied to general r2 and memory value is stored.   
      
   I'm guessing in Decode someplace there are comparators to detect when   
   the operand registers are the same so microcode knows to switch to the   
   temp bank for a modified register.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|