Announcement

Collapse
No announcement yet.

Dangerous functions like OVF(), CY(), iterator(), to() when using Events

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dangerous functions like OVF(), CY(), iterator(), to() when using Events

    Very IMPORTANT INFORMATION for everyone who use functions like OVF(), CY(), iterator(), to()and in the same program any Event or CallBack functions like sys_SetTimerEvent(), com_TXemptyEvent(), comX_TXemptyEvent(), bus_SetChangeInterrupt(), pin_Counter(), pin_PulseoutCount(), ana_HS(), ...

    Undocumented behavior is that the EVE on Diablo16 doesn't save a context when entering event functions, so operations in these event functions can change values returned by context functions!!!

    Example:

    func DisplayResult() //Event function
    gfx_MoveTo(100,100);
    count++; //can use wrong iterator() and destroy OVF() and CY() in interrupted program
    print(count); //can use wrong to() and destroy context
    endfunc

    func Example()
    // ...
    sys_SetTimerEvent(TIMER0, DisplayResult); sys_SetTimer(TIMER0, 100); //after 0.1s calls DisplayResult()
    // and/or
    pin_PulseoutCount(PA4, 100, 50, DisplayResult); //generate some pulses and after 0.5s calls DisplayResult()
    // ...
    low := a * b; // expected signed 30 bits result => lower 16 bits in low
    high := OVF(); //upper 14 bits in high
    // ...
    sum := a + b;
    if (CY()) SolveOverflow();
    // ...
    iterator(stepsize);
    if (++counter > max) DoSomething();
    // ...
    to(buf);
    print("Result: ", [DEC3ZB] result);
    //...
    endfunc

    If the triggering of an event falls between two interdependent operations, i.e. the second uses temporary changes of the context caused by the first operation, operations in the event function may change this context and cause an unexpected result in the interrupted program.

    However, this phenomenon is the work of great chance, and therefore it is not easy to detect !

    So if your program runs properly most of the time, but only occasionally there is something unexpected, unpredictable or the program freezes or crashes, then I recommend looking for all uses of these potentially dangerous functions and replacing them, if possible, with 32-bit arithmetic (uadd, usub , umull, udiv) and strictly do not use any to() or putch, putstr, putnum, print, str_Printf and other functions redirectable by and influencing to() in any event functions!

    Or everytime write these interdependent operations between
    events disable (sys_EventsPostpone) and events enable (sys_EventsResume) functions - like:
    sys_EventsPostpone();
    low := a * b; high := OVF();
    sys_EventsResume();

    or

    sys_EventsPostpone();
    to(buf); print("Result: ", [DEC3ZB] result);
    sys_EventsResume();

    The main question is: how often are these functions used in EVE and Internal/Inherent widgets itself, which determines the overall stability of the created programs?

    Now I know at least about usage of function to() in gfx_LedDigits, ledDigitsDisplay() and in every inherent widgets showing value like gfx_Dial(), gfx_Needle(), gfx_RullerGauge(), gfx_Scale(), gfx_Slider5, etc.
    And let's be sure that the sys_EventsPostpone() function is not used once.


    PS1: The similar problem may be with function pair strwidth() & strheight().
    PS2: Any graphical cursor moves inside event functions are risky too as it can interrupt gfx_MoveTo(x,y) followed by any graphical cursor dependent function (like print) too. (But that should occur to the programmer.)
    Last edited by Miroslav Kovar; 1 week ago.
Working...
X