On Mon, Nov 2, 2009 at 8:15 PM, Segher Boessenkool segher@kernel.crashing.org wrote:
Interesting - thanks for your comments on this. I'd like to get an idea as to what kind of impact the patch has as it stands. Is there a standard benchmark for Forth implementations?
No standard, no. It wouldn't matter anyway, you can measure this slowdown on _any_ code.
Or alternatively some word implementations that will stretch the kernel, for example Fibonacci, Mandelbrot etc. that I can use for comparison?
Sure, fib or mandel will do.
performance critical, I think it is acceptable to allow a slight degradation in speed over the ease of use of debugging.
Yes, but my point is your patch does not cause a "slight" slowdown (I haven't measured it though!), while standard techniques cause no slowdown at all.
Did you try to change the actual compiled Forth code at runtime? That's how all other Forth debuggers do it.
Possibly; there are probably several ways in which you can implement something like this.
My point is that your strategy has some severe disadvantages. Just run the benchmarks and then someone can decide if it's worthwhile. My opinion would be that it is not worth it, since it inserts code into the "hot path" while that's not necessary at all.
The debug stuff could be made a compile time option. We could even enable the debugging for non-release versions, so release versions would not suffer.