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.
One of the reasons for going the C route was that I wanted to analyse the rstack in detail; OpenBIOS unfortunately is not standards-compliant Forth in that some words pop information from the rstack which they did not put there themselves.
That is perfectly valid, standard-compliant Forth. A portable program cannot do such things since it doesn't know what a nesting-sys looks like; but OpenBIOS includes the Forth system as well.
Anyway, run benchmarks and report them here please.
Segher