Segher Boessenkool wrote:
Hi Segher,
Unfortunately, SEMIS is _the_ hotspot in profiles of any ITC/DTC, followed by DOCOL. I never profiled NEXT separately, it is best to inline it into most words. Your approach will slow down the engine by anywhere from 30%-200% when not debugging.
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? Or alternatively some word implementations that will stretch the kernel, for example Fibonacci, Mandelbrot etc. that I can use for comparison?
Given that OpenBIOS is not performance critical, I think it is acceptable to allow a slight degradation in speed over the ease of use of debugging. Perhaps another scenario would be to make the debugger an optional compile-time feature for those people that require the best performance?
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. 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.
In its current form, the patch allows me to trace through words that do this since it doesn't rely on iterating through the rstack. I'm not sure whether the Open Firmware code works in this way though.
You can probably lift most code you need directly from Mitch Bradley's Open Firmware implementation.
I'm not sure that we can; a brief look at the documentation shows that there appears to be a mixture of licenses involved :( Without a clear statement from the core team as to what you can and cannot do, I am quite hesitant in going down this particular route.
ATB,
Mark.