Better code check before compile?

+ Reply to Thread
Results 1 to 30 of 30

Hybrid View

  1. #1
    Join Date
    Feb 2013

    Default Better code check before compile?

    Hello. Recently accidentially deleted RETURN in one subroutine, and it caused catastrophic failure to attached hardware (almost started a fire). Of course this is my fault, but even on ZX Spectrum we had "gosub without return" error check. So I guess, it'll be nice if this will be implemented in PBP. It does that check for FOR-NEXT, why it can't be done for GOSUB-RETURN?

  2. #2
    Join Date
    Oct 2005

    Default Re: Better code check before compile?

    I don't write compilers and/or preprocessors but from my limited point of view I can't really see how a check like that would work in the case of PBP. How would the compiler or preprocessor be able to "match" a RETURN statement with a GOSUB?

    You can easily have several RETURN statements and multiple labels within a single subroutine.

    Alright, if there's one (or more) GOSUB statements in the program but not a single RETURN statement you know you have a problem but apart from that I'm not sure how it would work.

    In your case I suppose the following represents what happened, the RETURN from Label1 got deleted and is missing but that isn't NECCESARILY an error, the code is still correct.
    Out of curiosity, would you share more details about what happened?


  3. #3
    Join Date
    May 2004
    NW France

    Default Re: Better code check before compile?

    How would the compiler or preprocessor be able to "match" a RETURN statement with a GOSUB?

    As one RETURN statement can match more than one GOSUB's ...

    even math can't do anything for you ... just verify if there's at least one RETURN for one GOSUB ...or number of RETURN is smaller or equal than number of GOSUB

    the only way is to run the debugger and verify you jump at the good moment or to the right location ...

    for critical applications, only a GOTO - GOTO or multiple local subroutine INCLUDE could secure the code ...

    but you also could wipe the critical line ...

    Last edited by Acetronics2; - 26th December 2019 at 12:03.
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!

  4. #4
    Join Date
    Sep 2009

    Default Re: Better code check before compile?

    If your code can start fire, you are doing something really wrong.
    For first run, always use PSU with limited power(at least current limiting) with no load at output. Move actuators if you have them manually to check sensors.
    If you are creating PSU controlled by PIC(or any mcu), simulate output voltage by applying voltage on feedback.
    Any way you must have HW protections that would prevent code to do catastrophic damage.

    As all software in this world PBP can have unsuspected bugs that doesn't manifest all time. I found one few years ago. Other compilers have many more than one.
    Also as this is all clock dependent, it can freeze due falling oscillator eg lot of vibration can cause crystal to breaks.

    I saw result of using PLC with untested code on 300ton press, and actuating pressing and pulling actuators, it wasn't pretty... And that could be avoided if hydraulics was done correctly to disallow engaging both actuators in opposite directions. Or using relay that would disable inputs to other solenoids, etc...

  5. #5
    Join Date
    Nov 2003

    Default Re: Better code check before compile?

    Added to the above, no one can guarantee you that the software will always run, even with faults in it. MCU's can stop anytime and hardware must protect itself in that case.

    Now, regarding Subs, it is not easy or feasible at all, to check for correct pairs of gosub-return. It is not the same as open-close of { and } in C for example.

    In the case of Returns, you can have one or 100 for the same sub. So, how will the compiler check?


  6. #6
    Join Date
    Feb 2013

    Default Re: Better code check before compile?

    it is simple. Just count number of Subroutines and RETURNs and make sure they match, that's all, and already done 30 years ago.

    Regarding what happened - it was huge (about 30 meters) Christmas tree 8 channel light controller. The code enables lights at max power for 0.1 second, to give "blink" effect. It worked for 2 years without any issues, until now, when I added some new programs, and forgot to add RETURN, so lights remain at high power for about 10 minutes, instead of 0.5second. It ended up with 9 pieces of solid state relays fried, until thermal switch cut off the power
    Last edited by CuriousOne; - 26th December 2019 at 14:33.

  7. #7
    Join Date
    Feb 2013

    Default Re: Better code check before compile?

    Even more simple.

    Just add different label for subroutines, say, subroutines should start with SUB statement, after the label. At compile time, do check and that's all.

Similar Threads

  1. Code check and refinement suggestions?
    By kevlar129bp in forum mel PIC BASIC Pro
    Replies: 23
    Last Post: - 31st July 2013, 02:37
  2. Replies: 4
    Last Post: - 24th January 2007, 22:20
  3. Code check -- button not working
    By docwisdom in forum mel PIC BASIC Pro
    Replies: 12
    Last Post: - 2nd March 2006, 22:43
  4. Can some one please check my code out thanks
    By Jhdgkss in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 10th February 2006, 08:19
  5. Code check (sorry)
    By barkerben in forum General
    Replies: 5
    Last Post: - 30th November 2004, 15:54

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts