Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Walter Banks Newsgroups: comp.lang.forth Subject: Re: Metrics on stack usage Date: Mon, 22 Sep 2014 21:59:19 -0400 Organization: Aioe.org NNTP Server Lines: 97 Message-ID: <5420D3F7.FCFBD0F9@bytecraft.com> References: <541855C0.2558D27D@bytecraft.com> <7xmw9zletd.fsf@ruckus.brouhaha.com> <541891FE.9157C03@bytecraft.com> <2014Sep17.092044@mips.complang.tuwien.ac.at> <5419F72B.F5EC2F16@bytecraft.com> <2014Sep18.134054@mips.complang.tuwien.ac.at> <54203843.BD257924@bytecraft.com> <_OWdnfIBlttBDb3JnZ2dnUU7-QOdnZ2d@supernews.com> NNTP-Posting-Host: WS9whZ/ot+e+Q+IoL9T/mw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Mailer: Mozilla 4.79 [en]C-CCK-MCD NSCPCD479 (Windows NT 5.0; U) X-Accept-Language: en X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:33517 "Elizabeth D. Rather" wrote: > On 9/22/14 4:54 AM, Walter Banks wrote: > > Anton Ertl wrote: > >> Walter Banks writes: > ... > >> >You made a comment, "behave like hand-written Forth?" I think that > >> >this is more than an off hand comment. What makes hand-written > >> >forth special? and why? > >> > >> Many different things, in particular: > >> > >> * Shorter definitions than your typical Algol-family language program, > >> because it's easier to add definitions, and harder to make them long > >> than in Algol. > >> > > This can have a real impact on code size. We did a study on C optimization > > and found that even bad C compilers generated reasonably good code > > if the source statements were kept short. > > Yes. Forth takes this to an extreme, with many definitions in a typical > application being 3 lines or less. The cost of calling a word in Forth > is far less than in languages that manage calling sequences, because of > the stack. In ITC implementations it could be as few as a couple of > machine instructions each for call/return, and in modern implementations > it's just call/return. Forth newbies often say, "but you have to put > your arguments on the stack," but in practice there's relatively little > fetching/storing, intermediate values are just *there*, passed through > whatever procedures are necessary. This is one reason so many > Forthwrites are down on locals. > > >> * Forth programmers use a wide variety of techniques for dealing with > >> the limitations of stack-based programming, often very specific to > >> the program at hand, and exploiting knowledge that the Algol > >> compiler does not have (because it's not expressed in the Algol > >> source code). > > Do you have an example of the kind information that would be useful? > > I think you are correct but am having a hard time coming up with an > > example. > > I find myself a little put off by "limitations of stack-based > programming." I've never found it "limiting", it's just a very different > programming paradigm. > > >> * Studies of Forth programs have found fewer dynamic conditional > >> branches and far more calls and returns than instruction statistics > >> for e.g., C-compiler generated programs. E.g., compare the date from > [ links snipped ] > > > What is the underlying reason for lower dynamic conditionals. Is it the > > higher overall cost for using them encouraging the use of branchless > > code? > > Fascinating issue. Chuck and I wrote a paper on this for an ACM (I > think) conference back in the 70's. I wish I could find a copy! We were > asked to rewrite a PDP-11 control application from Fortran to Forth. > They were having terrible performance issues, largely due to the fact > that the program was too large for the 64K memory limit in those days, > and the DEC OS was doing a lot of page swapping. Our main constraint was > that the behavior of our version (including the user interface) had to > be identical. Our program ran is well under 64K, so no page swapping, > and was an order of magnitude faster. But one of the comparisons that we > focused on in the paper was that the Fortran program had nearly 400 IF > statements, and the Forth version had 7. That's right, seven. There was > a vector of addresses, the selection offset being calculated from a > switch reading (no IF there), and multiple tasks responding to different > parts of the machine. But the main difference was that the Fortran style > was large subroutines that took indicators as to which path to take > through, and the Forth version had just tiny words that did what they > did without having to figure out what they were supposed to do. > > > The higher call / return metrics is understandable with the macro language > > origins of Forth. > > > > Do you know of any papers on code reliability in Forth applications given > > that functions don't have a formal interface? (The implication is the > > series terms in the system reliably are larger than say algol languages) > > I don't understand what "don't have a formal interface" means. All Forth > words have very specific expectations as to the arguments they expect > and leave. Not to digress to far but the difference between Forth and many other languages is the interface to words is not independently enforced. The effect is the series effects of sequential words. I once did a lot of work making real time applications work reliably, a lot of it was simply segmenting code into well defined pieces and restructuring applications to improve the reliability numbers of the application. This is the stuff of heated discussions. Interesting numbers on your PDP 11 app It suggests the real cost of conditionals. w..