Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman From: koopman@a.gp.cs.cmu.edu (Philip Koopman) Newsgroups: comp.lang.forth Subject: Re: FORTH, RISC, and other new architectures Summary: some data points Message-ID: <5763@pt.cs.cmu.edu> Date: 5 Aug 89 11:12:14 GMT References: <385@ryn.esg.dec.com> <975@key.COM> <26573@amdcad.AMD.COM> Organization: Carnegie-Mellon University, CS/RI Lines: 33 In article <26573@amdcad.AMD.COM>, tim@cayman.amd.com (Tim Olson) writes: > First, are 64 words of control and operand stack enough? How deeply > nested to FORTH words typically get? My data showed that 32 elements are typically enough. Many Forth programs don't really need more than 16 elements. Having hardware spill detection logic is very handy, but it's enough just to generate an interrupt when a spill is about to happen (hardware spill handling logic is nice to have, but not essential). > Second, does a typical FORTH program (coded with in-line primatives and > call-threaded) spend most of its time executing FORTH primatives or > executing the thread of control for user-written words? My measurements for dynamic instruction mix are: CALL: 12.2% RETURN: 11.7% (There are obscure reasons why this isn't 12.2%) in terms of frequency of execution compared to other Forth primitives. The definition of a primitive for this study was "anything in assembly language in a highly optimized Forth compiler, including 32-bit math functions". So, I think these represent a lower bound for less optimized Forth systems. These numbers provide an obvious source of motiviation for designing Forth chips that often get subroutine returns for free by combining them with other operations, and can even get subroutine calls for free, or at least perform calls in a single clock cycle. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.