Posted on May 26, 2005 at 04:57 Is there anyone who has a medicine for the MACRO bug?
This disease happens in assembly programs that use MACROS.
During debug sessions this bug misalign sources and execution point.
For this reason it is a very difficult to use any debugging tool.
The attached project builds under STVD7 v.3.1.1 and shows how debugging may be painful.
In my setting the solution that was posted in this forum does not work since the BEGIN_SEQ macro has to add a variable in RAM segment and some code in the ROM segment.
For the ones interested, the project contains a skeleton for a co-routine scheduler that switches contexts in only 22 cpu cycles (i.e. 2.75 us @ 8MHz).
Since it manipulates stack, I prefer to use macros and have a clean interface.
The macros help also to reduce the efforts in changing the implementation details.
For instance, to reduce the code size, the SCHEDULER macro may be mapped to a TRAP (one byte) instead of a CALL (three bytes).
Because real applications contain many instances of the SCHEDULER macro, this would lead to important savings in ROM code which may balance the penalty of execution efficiency.
When using the TRAP approach, the MACRO must be used because the hardware simulation tools (e.g. InDART) use TRAP to pass control to the runtime monitor.
For this reason one has to simulate it when debugging and switch back to the hardware implementation in the release build.
However, a nasty bug makes this approach useless...
EtaPhi
________________
Attachments : Bug.zip :
https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I07i&d=%2Fa%2F0X0000000bTo%2F7a4B3yHKIXSAfm4T1jMsD0n4kKVRh2VWsB62nbUiVeA&asPdf=false
