What's more important optimisations or debugging?

No, it is not that easy to make a full trace buffer this way. Continuous single-stepping (whether by using the trace facility of many larger processors, or with external help such as a debugger or your suggested interrupt trick) will let you trace program flow, but not data flow. Thus you can see when the statement "*p++ = *q++;" was executed, but you don't have a record of what p, q, *p or *q are before and after the operation. To do that needs something much more - a hardware trace of data transactions, trapping on memory writes, examination of the statements before they are executed, or tricks like regular snapshots and then replaying the code up to the point of interest.

mvh.,

David

For truly memory-to-memory architectures, you would indeed need some emulation code to interpret the instruction, to see what "side effects" the instruction had on the memory contents.

For many common architectures, at least the pointers would normally be in registers, so taking a register snapshot after each instruction would help a lot.

On RISCy architectures, most data transfer would also go through a register, so again, the transferred value would be visible in a register trace.

Of course tracing in deeply pipelined architectures can cause strange results, unless the pipeline can be disabled during tracing/single stepping.

Paul

Register snapshots would clearly help, but if an instruction causes a write to memory, then knowing the address is only part of the solution. Before executing the instruction, you'd have to figure out that the instruction is a write, figure out which register holds the address, then read and log the original data. Then you carry out the instruction, and log the data written. You have to have the original data so that you can restore it when stepping backwards past the write instruction. That's why I suggested trapping on memory writes (even if your processor does not have an MMU, it could be possible to temporarily make the ram read-only) - that way you don't have to figure everything out yourself, but can get it from the bus error exception stack frame (or equivalent for your processor).

Indeed, it would get so messy, and give such an unrealistic picture due to timing differences, that it's unlikely to be of any real help at all.

As far as I can see, the use of things like trace traps, snapshots, replays, hardware trace buffers, etc., can give you varying benefits for varying costs, but the only way to get true backstepping of relevance to embedded development (where you can seldom rely on having the same input data on two runs, cutting out the Lizard technique I mentioned earlier), is by simulation of the processor. In the days of full hardware emulators for microcontrollers (before jtag-type debugging became common even on small devices), you could get expensive emulators that included full tracing while running at cycle-correct speeds. With modern devices, it's a lot less practical.

I'd be interested to see how they [the enforcers of this rule] cope with the behaviour of the average compiler, since one of the things it's likely to do is convert the HLL into an intermediate representation and then start transformations on that intermediate rep., some of which will never be visible outside the compiler but most of which are certainly optimi[sz]ations and may not even be disablable, before it even thinks about emitting code. Would they disallow the use of such a compiler? Or is "do not permit optimisations" not intended to be taken literally, or to this depth?

mlp

1 mandate no optimisation 2 look at the binary. At high SIL they do compare binary to source,

Yes. The compiler usually validated before user.

No it is taken to mean disable all compiler optimisations.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In a DO-178B level A project the practice is generally to have source to object code traceability. That is to say, inspect/verify the output of the compiler for a given construct, then check that the output is the same each time the same construct is used. This is then used in combination with MCDC test coverage to demonstrate that the compiler output does what you intend, and nothing that you did not intend.

--
Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 certified real time kernel for safety related systems.