Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Question about checking the stack Date: Wed, 25 Nov 2015 18:00:22 -0800 Organization: A noiseless patient Spider Lines: 41 Message-ID: <8737vtfrk9.fsf@nightsong.com> References: <87io4qh7fm.fsf@nightsong.com> <87k2p5g4n0.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="d09d25b6b873a1567c8bb21cd9fda25b"; logging-data="19588"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18XeRjEBuNXRi0+rfOFZ6sX" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:pXQMaBkmOPEobshirTT2RHu5A1o= sha1:07DHVxDmTMWpw7RQKq3PHKzUXec= Xref: csiph.com comp.lang.forth:43794 "Elizabeth D. Rather" writes: > No computer cycles are "free". Even a dinky MCU runs at millions of cycles per second, and sitting typing interactively at it generally won't use even 1% of them. Do you have a way of saving the rest for later? > And doubling the cost of something that is happening as frequently as > stack access in Forth is simply not worth it. Are there some benchmarks showing the cost doubling? Obviously it will cost something but I'd hope it isn't as bad as doubling. Even if it does double, so what? You use 2% of your CPU instead of 1%. > Actually, we did write a special Forth with buckets of error checking > for use in classes some years ago. It had the effect of tremendously > slowing down the learning process Gforth effectively does such a check (it uses a memory protection trap instead of a runtime comparison, but it still signals the error where it happens). I've found it very helpful. >> What happens if you type dup with an empty stack? > You dup the stack underflow position (which contains a zero). Why > would you want to do that? It can happen by accident during development. Obviously it's an error: so why should the programmer spend her time hunting it down, instead of having the computer flag it immediately? > We are working mostly with low-end microcontrollers, where cycles > count, but even on super-fast PCs it has just never proven genuinely > helpful. I haven't written any Forth code so far where I cared in the slightest how fast it ran-- i.e., a 2x or even 10x slowdown would not have been noticed. Even speed-critical and realtime applications tend to be like that. There are a few hot spots that have to be optimized carefully, and the rest of the code should just do whatever is simplest and safest. And the speed critical parts can usually run slow during debugging, under simulation if necessary.