Shop OBEX P1 Docs P2 Docs Learn Events
FlexBasic ON X GOTO "deprecated"? Bah Humbug... — Parallax Forums

FlexBasic ON X GOTO "deprecated"? Bah Humbug...

const _clkfreq = 160_000_000

dim as long x, y, tmr

x = 1: y = 0: tmr = getms()
strt:
on x goto l1, l2, l3
goto strt

l1:
x = 2
goto strt

l2:
x = 3
goto strt

l3:
x = 1
y = y + 1
if y = 1_000_000 then goto getout
goto strt

getout:
Print getms() - tmr

Execution time: 1950 mS

const _clkfreq = 160_000_000

dim as long x, y, tmr

x = 1: y = 0: tmr = getms()
do
select case x
case 1
    x = 2
case 2
    x = 3
case 3
    x = 1
    y = y + 1
end select
loop until y = 1_000_000
Print getms() - tmr

Execution time: 2750 mS

Heck of a penalty for prettier code :lol:

Comments

  • You are aware that you are only incrementing y in the last case?

  • @deets said:
    You are aware that you are only incrementing y in the last case?

    Yup, same for both examples

  • __deets____deets__ Posts: 203
    edited 2021-12-02 10:46

    Yeah, sorry, I focused on the second one first and was just editing my answer.

    I don’t see any reason why this would suffer such a speed hit, I’m confident Eric can optimize this.

  • Ah-ha....it was due to the loop evaluating y for every iteration :blush:

    do
    select case x
    case 1
        x = 2
    case 2
        x = 3
    case 3
        x = 1
        y = y + 1
        if y = 1_000_000 then exit do
    end select
    loop
    

    Execution time: 1950 mS

  • Case closed.

  • Hmmm, if the optimizer was a bit smarter, it'd have figured that the loop is pointless and given you 0ms runtime ;P

  • @Wuerfel_21 said:
    Hmmm, if the optimizer was a bit smarter, it'd have figured that the loop is pointless and given you 0ms runtime ;P

    :lol::lol::lol:

  • @Mickster said:

    @Wuerfel_21 said:
    Hmmm, if the optimizer was a bit smarter, it'd have figured that the loop is pointless and given you 0ms runtime ;P

    :lol::lol::lol:

    You jest, but GCC actually will do that - watch what occurs when you switch optimization levels between -O1 and -O2

  • @Wuerfel_21 said:

    @Mickster said:

    @Wuerfel_21 said:
    Hmmm, if the optimizer was a bit smarter, it'd have figured that the loop is pointless and given you 0ms runtime ;P

    :lol::lol::lol:

    You jest, but GCC actually will do that - watch what occurs when you switch optimization levels between -O1 and -O2

    I was just imagining -MLC (Mickster's lousy coding) :lol:

  • @Mickster said:
    I was just imagining -MLC (Mickster's lousy coding) :lol:

    Get in line, ya young Whippersnapper! I was embarrasing myself with childish FlexBASIC coding gaffs (and polluting @ersmith inbox with irrelevant bug reports) when you were still in nappies. 🤣

  • evanhevanh Posts: 15,915

    volatile qualifier seems to get overlooked in courses on C. I distinctly remember not being taught about it and figured that was because it wasn't part of the newly christened ANSI C standard at the time. So I just now decided to go a searching for the proof ... only to find it very much was part of the ANSI standard (C89) - https://en.wikipedia.org/wiki/C_variable_types_and_declarations#Type_qualifiers

    ... and, during this click-fest, I bumped into a course text for C too, and guess what? It talks about use of const qualifier, but not a mention of volatile. Which is just how I remember it all those years ago.

  • Pretty much all 'C' instruction (imho) happens on PC-ish hardware, not embedded systems. Moreover, they tend to happen on "idealized" PC-ish hardware, that never has anything change unless the code you just wrote and executed changed it.

    In a way, the 'volatile' qualifier in such an environment is almost anathematic - that in our perfectly logical world there's a little gremlin running around changing things? What?

    Of course, in the embedded systems world that "little gremlin" is outside input, and is very much worth paying attention to. I'm on a few MCU fora, and one of the very standard pieces of advice to newbies whose code is acting funny (or, more usually, not reacting to input) is "You might want to make that variable volatile" to force the compiler to generate code to carefully re-read it every time. S.

    PS - Arguably that's a compiler problem, too. Write more assembler, and you don't have this problem. ;)

  • pik33pik33 Posts: 2,366
    edited 2021-12-04 20:02

    Today you have multicore PCs and multithreading programs. Then one thread can change a variable for another thread. It is not uncommon to do

    i:=0
    repeat
    until i<>0
    

    In a P2 another cog can change i; in PC it can be another thread of the same program. Now, we have identified the gremlin :)


     - What an IT graduate can do ?
     - He can write a book about programming
    
  • @pik33 said:
    Today you have multicore PCs and multithreading programs. Then one thread can change a variable for another thread. It is not uncommon to do

    i:=0
    repeat
    until i<>0
    

    In a P2 another cog can change i; in PC it can be another thread of the same program.

    Or a thread of a different program sharing the same memory allocation :)

  • evanhevanh Posts: 15,915
    edited 2021-12-04 21:26

    @Scroungre said:
    ... Write more assembler, and you don't have this problem. ;)

    FlexC's inline Pasm gets optimised by default. Don't count on the optimiser leaving that assembly as stated.

    Inline Pasm in FlexSpin doesn't get optimised though. I think Eric did it that way to maintain compatibility with Pnut/Proptool.

  • evanhevanh Posts: 15,915
    edited 2021-12-04 21:39

    @Scroungre said:
    Pretty much all 'C' instruction (imho) happens on PC-ish hardware, not embedded systems. Moreover, they tend to happen on "idealized" PC-ish hardware, that never has anything change unless the code you just wrote and executed changed it.

    Funnily, my C tuition was done on a 68HC11 uC. But yeah, the taught functionality didn't go much beyond a few logic I/O and ADC static level readings. Nothing complex in the software dept. It was an electronics course.

    EDIT: I remember now, it was their first year of teaching C too. They'd just changed from Basic.

  • pik33pik33 Posts: 2,366
    edited 2021-12-05 11:48

    @Wuerfel_21 said:

    @pik33 said:
    Today you have multicore PCs and multithreading programs. Then one thread can change a variable for another thread. It is not uncommon to do

    i:=0
    repeat
    until i<>0
    

    In a P2 another cog can change i; in PC it can be another thread of the same program.

    Or a thread of a different program sharing the same memory allocation :)

    While I can (and I do) write multithreading programs, I don't know how to do this... (on a modern PC)

  • That would be achieved using memory-mapping. The Linux call is mmap, there are equivalent constructs on Windows. Together with a synchronisation primitive like a semaphore or mutex it makes for fast data sharing between programs.

Sign In or Register to comment.