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

Mickster

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

__deets__

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

Mickster

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

Yup, same for both examples

__deets__

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.

Mickster

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

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

Simonius

Case closed.

Wuerfel_21

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

Mickster

@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

Wuerfel_21

@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

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

Mickster

@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

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)

JRoark

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

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. 🤣

evanh

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.

Scroungre

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.

pik33

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

Wuerfel_21

@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

evanh

@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.

evanh

@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.

pik33

@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)

__deets__

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.