home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / arch / 12456 < prev    next >
Encoding:
Text File  |  1993-01-28  |  1.4 KB  |  36 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!math.fu-berlin.de!ira.uka.de!rz.uni-karlsruhe.de!stepsun.uni-kl.de!uklirb!kirchner
  3. From: kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner)
  4. Subject: Re: Harvard architecture
  5. Message-ID: <1993Jan28.100206.238@uklirb.informatik.uni-kl.de>
  6. Sender: news@uklirb.informatik.uni-kl.de (Unix-News-System)
  7. Nntp-Posting-Host: uklira.informatik.uni-kl.de
  8. Organization: University of Kaiserslautern, Germany
  9. References: <1993Jan25.153333.7251@crd.ge.com>
  10. Date: Thu, 28 Jan 1993 10:02:06 GMT
  11. Lines: 23
  12.  
  13. From article <1993Jan25.153333.7251@crd.ge.com>, by davidsen@ariel.crd.GE.COM (william E Davidsen):
  14. > 
  15. >   I agree, and I don't have the refference, either.
  16. > 
  17. >   What we had done was bank switching, such that when the CPU did an
  18. > opcode fetch, the M1 cycle, it came from the code bank, and when the CPU
  19. > did any other data access it went in the "data" bank. The program was
  20. > all written in a B offshoot called IMP, so I could easily avoid the self
  21. > modifying code prevalent at that time.
  22. > 
  23. So I wonder:
  24.  
  25. How was distinguished between the addtitonal fetches ( e.g. address, immediate
  26. operand ) of an instruction, and the true operand accesses ?
  27.  
  28. It might be done be a decoder who knows about the various instruction lengthes,
  29. but this would be a quite complex piece of hardware. ( appr. halve a processor
  30. or so )
  31.  
  32. R. Kirchner
  33. Univ of Kaiserslautern, Germany
  34. kirchner@informatik.uni-kl.de
  35.  
  36.