From: gneuner2@comcast.net   
      
   On Wed, 06 Aug 2025 10:23:26 -0400, EricP   
    wrote:   
      
   >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.   
      
   I was aware of this (thank you), but I was trying to figure out why   
   the VAX - particularly early ones - would need it.  And also it does   
   not mesh with Waldek's comment [at top] about 3 copies.   
      
      
   The VAX did have one (pathological?) address mode:   
      
     displacement deferred indexed  @dis(Rn)[Rx]   
      
   in which Rn and Rx could be the same register.  It is the only mode   
   for which a single operand could reference a given register more than   
   once.  I never saw any code that actually did this, but the manual   
   does say it was possible.   
      
   But even with this situation, it seems that the register would only   
   need to be read once (per operand, at least) and the value could be   
   used twice.   
      
      
   >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)+   
      
   You mean exceptions?  Exceptions were handled between instructions.   
   VAX had no iterating string-copy/move instructions so every   
   instruction logically could stand alone.   
      
   VAX separately identified the case where the instruction completed   
   with a problem (trap) from where the instruction could not complete   
   because of the problem (fault), but in both cases it indicated the   
   offending instruction.   
      
      
   >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)