home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10439 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  2.6 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!cs.utexas.edu!wupost!usc!rpi!batcomputer!munnari.oz.au!uniwa!john
  2. From: john@gu.uwa.edu.au (John West)
  3. Newsgroups: comp.arch
  4. Subject: Re: RTX and SC32
  5. Date: 6 Nov 1992 05:29:58 GMT
  6. Organization: The University of Western Australia
  7. Lines: 43
  8. Message-ID: <1dcvsmINNiop@uniwa.uwa.edu.au>
  9. References: <17131@mindlink.bc.ca> <1992Nov4.191038.12063@news.arc.nasa.gov>
  10. NNTP-Posting-Host: mackerel.gu.uwa.edu.au
  11.  
  12. lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
  13.  
  14. >It would be interesting to know exactly what instructions cause this 
  15. >(alleged?) speedup.  Could one or two instructions be added to a standard 
  16. >RISC processor (SPARC/MIPS/m88k/RIOS/HP-PA) to support the same operations
  17. >and provide the same speedup?
  18.  
  19. I don't think it is any actual instructions that cause the speedup, but the
  20. whole architecture of the processor. Its just designed to do stack intensive
  21. things simply and quickly. You could try adding on-chip stacks with fast access
  22. to a standard RISC chip, but you'd end up with something looking more and more
  23. like a Forth chip. It isn't instructions. Its a totally different way of
  24. looking at things.
  25.  
  26. >I suspect that standard RISCs already provide what is needed to run Forth
  27. >efficiently, they just are not handled in one cycle on load/store machines.  
  28.  
  29. No. Load/store architectures are designed to use registers as much as possible,
  30. without going to memory unless it is really needed. Unfortunately, the stack(s)
  31. always go in memory. Your single Forth instruction to add two numbers can be
  32. executed in a single cycle, but on the load/store processor, you've got two
  33. memory reads, the operation itself, and then a memory write - all memory
  34. accesses changing the stack pointer. This sort of destroys any hope of
  35. going superscalar with any sanity.
  36.  
  37. >So, the question remains:  are there any Forth operations which are not
  38. >efficiently supported on the current crop of RISCs, and are on the 
  39. >named Forth machines?  If so, what operations are they, and why?
  40.  
  41. The answer remains: stacks. Load/store is nowhere near as good at stack
  42. handling as a dedicated stack architecture, simply because it was never
  43. designed to be.
  44.  
  45. RISC processors were designed to run the same sort of languages as CISCs.
  46. They run C very well. Forth and its friends are very very different languages,
  47. and you need a processor dedicated to running that sort of language to do it
  48. well. I don't think they can really be compared - not at a low level, anyway.
  49. They're just too different. The only valid comparison is how well it does the
  50. job.
  51.  
  52. John West
  53. --
  54. For the humour impaired: Insert a :-) after every third word
  55.