home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10481 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.3 KB
  1. Xref: sparky comp.arch:10481 comp.lang.forth:3452
  2. Newsgroups: comp.arch,comp.lang.forth
  3. Path: sparky!uunet!gatech!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!aplcen.apl.jhu.edu!aplcenmp!mef
  4. From: mef@aplcenmp.apl.jhu.edu (Marty Fraeman)
  5. Subject: Re: What's RIGHT with stack machines
  6. Message-ID: <BxBFqu.Cu8@aplcenmp.apl.jhu.edu>
  7. Keywords: stack computers, embedded control
  8. Organization: Johns Hopkins Continuing Professional Programs
  9. References: <Bx5AIr.EAy.2@cs.cmu.edu> <1992Nov4.103008.2641@Informatik.TU-Muenchen.DE>
  10. Date: Fri, 6 Nov 1992 22:28:05 GMT
  11. Lines: 36
  12.  
  13. In article <1992Nov4.103008.2641@Informatik.TU-Muenchen.DE> pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
  14. >
  15. ...
  16. >Spill&Fill: did anyone thought about automatic spill&fill-buffers? (if the
  17. >available stack cells decreases to a certain level, a number of stack items are
  18. >load (4 or 8 would be great), and if it increases over a certain level, the same
  19. >amount of stack items is spilled (have a hysterese of about 8 stack entries).
  20. >
  21. The SC32 does exactly this in hardware.  John Hayes has extensively
  22. measured lots of programs and usually sees far less than 1% overhead
  23. for this.  Our first two Forth processors transfered half the on-chip
  24. stack on over/underflow.  Measurements later firmly convinced us this
  25. was not a good strategy.  So our third chip, the SC32, just transfers
  26. one register.  Our fourth chip will do the same.  
  27.  
  28. >Are there any researches how many stack cells should be directly accessed by
  29. ><const> pick or <const> roll? Having only three is messy, I think, 4 or 5 would
  30. >be nice; 
  31. The SC32 has access to the top four elements of both return and data stack.
  32. Four was choosen after inspecting our applications and finding that picks
  33. always used a constant known at compile time and in no case was access deeper
  34. than four needed.  This is another decision we don't regret, from a
  35. software perspective, even on our fourth version of the machine.  This
  36. feature does have a tendency to creep into the critcal path of the machine
  37. if your not careful.
  38.  
  39.  
  40.     Marty Fraeman
  41.  
  42.     mef@glinda.jhuapl.edu    (<--- not the machine this is posted from!)
  43.     301-953-6000, x8360
  44.  
  45.     Room 13-s587
  46.     Johns Hopkins University/Applied Physics Laboratory
  47.     Johns Hopkins Road
  48.     Laurel, Md. 20723
  49.