The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, July 19, 2012

Code phases: Distinction between simulation and instrumentation code

I often find in simulators that I want to distinguish the simulation code, the code actually needed to run, from the instrumentation code.  The latter exists only for analysis of the results, but is not necessary if all you care about is functional correctness.

Information should only flow one way, from simulation code to instrumentation. Never backwards.

I have experimented with C preprocessor macrios like  INSTRUMENTATION( perf_counter++ ), and so on, but these are clumsy.  I will admitt hat INSTRUMENTATION: looks better than INSTRUMENTATION( )

If you use sch macros, you can always do #define INSTRUMENTATION(x) /*nothing*/
and test that it still compiles and runs tests.

However, simulation/instrumentation are just two phases of code.

Debug may be a another phase, at least read-only debug observation. (Sometimes there is active debug, that influences the actual running.)

Asserts are yet another phase.  Different from debug, because you often leave them on.

In both debg and assert phases, information flows from program main phase to the phases.

How about server/client partitioning?  Although in this case data flows both ways.

No comments: