Instead of 5 lines with a couple jumps, it's over a page of junk, and the students are STILL struggling to get it to work right. All this contortion to avoid using goto.
In the C language, there are 4-5 scenarios where GOTOs are an accepted good thing, so the language specification left them in. And one of those things is state machines. And embedded control is mostly about state machines.
In my last five firmware projects, they have been pretty much nothing but state machines. (Note I specified "embedded control" and by that I do not mean "embedded PC" )
Mickster is a successful entrepreneur and yet is a proponent of PropBasic. A coincidence ? Hmmmm...
The "over-capacity" thing is crazy. It drives me nuts when I see these wind-turbines, shut down on windy days(!!!!).
What amused me was the suggestion of the water-tank storage because I had the exact same idea but dismissed it as a limitation of my own knowledge/imagination.
Some complain that the turbines are eyesores but I can sit and watch them all day. However, huge, elevated water-storage tanks would be a different story unless they were buried in the top of a mountain or something.
My other thought was a flywheel but how big would they have to be, to be useful.
The "over-capacity" thing is crazy. It drives me nuts when I see these wind-turbines, shut down on windy days(!!!!).
What amused me was the suggestion of the water-tank storage because I had the exact same idea but dismissed it as a limitation of my own knowledge/imagination.
Some complain that the turbines are eyesores but I can sit and watch them all day. However, huge, elevated water-storage tanks would be a different story unless they were buried in the top of a mountain or something.
My other thought was a flywheel but how big would they have to be, to be useful.
Okay, that sounds like a positively outlook of the technologies I guess. Correct me if I'm wrong. Do you think that's the way forward?
Okay, that sounds like a positively outlook of the technologies I guess. Correct me if I'm wrong. Do you think that's the way forward?
Well certainly from an environmental perspective but the "conspiracy-factist" in me believes that we will never be allowed to pop down to Home Depot (B&Q in UK) and pick up a "Mr. Fusion" (Back to the future) to provide free energy for our cars/homes.
If there will ever be a (safe) fusion device that small, then I suspect that yes, we will be able to buy them privately. Just not via Home Depot.. probably more like ordering them on Amazon, the way things are going.
I don't see any indication of affordable technology getting suppressed (even though it may start out un-affordable). Just look at computers - the most powerful tech ever invented, and it's everywhere. Despite IBM at one point believing that the world needed only 5 of the things, and Ken Olson of Digital couldn't see that anyone would ever want one at home.
As for the wind turbines - yes, I find them esthetically pleasing too. Seen them all over the world, at various kinds of locations. And another yes - water towers are *not* pleasing to look at, in general.
An interesting submission. Irrelevant of course, "structured programming" does not dictate one use a clunky tool like Blockly.
Your statement in that thread, "It's so 90's" shows a lack of domain knowledge. The ideas of structured programming date back the late 1960's and were well entrenched in the 1970's. I would say that the 1990's was the decade of object oriented programming, what with the arrival of C++, Delphi and such.
In the C language, there are 4-5 scenarios where GOTOs are an accepted good thing,
That depends on who you ask But I'll go with that.
And one of those things is state machines.
Odd that. I have lost count of the number of state machines I have written, in a variety of languages, none of them needed goto.
As a counter to that assertion I will point out that in the world of logic design using VHDL, Verilog, etc, one is pretty much not doing anything but creating state machines. Yet those languages do not have a GOTO !
Arguably all programming is about state machines.
Note I specified "embedded control" and by that I do not mean "embedded PC"
Not sure what distinction you are trying to make there.
Mickster is a successful entrepreneur and yet is a proponent of PropBasic. A coincidence ?
That is good. However it says nothing to support that assertion that "structured programming is asinine". PropBasic supports structured programming.
IF var cond value THEN
' code
ELSEIF var cond value THEN
' code
ELSE
' code
ENDIF
GOSUB Calc
SUB Calc
' Code
RETURN value
ENDSUB
Having said all that, I love a good GOTO as much as the next man. It's rare that I need one or that it would make my code easier to read and understand.
Well certainly from an environmental perspective but the "conspiracy-factist" in me believes that we will never be allowed to pop down to Home Depot (B&Q in UK) and pick up a "Mr. Fusion" (Back to the future) to provide free energy for our cars/homes.
That's cool. I have my own little beef with the local lines company here. They dictate to the retailers the rules of grid connected home generation ... which includes denial of the cheaper nightrate power that's available otherwise.
Fusion is, of course, still on the horizon and very exciting to watch, but it's serious R&D! I loved the article about the German stellarator alternative to the ITER tokamak. I'm not sure but I think ITER are not locked into the tokamak just yet and could switch to the stellarator instead. Having a read of the timeline, it looks pretty well locked in.
I'll be blown away if small scale is ever possible for fusion. Now that would be a worthy line of research for the bleeding edge of science!
Instead of 5 lines with a couple jumps, it's over a page of junk, and the students are STILL struggling to get it to work right. All this contortion to avoid using goto.
In the C language, there are 4-5 scenarios where GOTOs are an accepted good thing, so the language specification left them in. And one of those things is state machines. And embedded control is mostly about state machines.
In my last five firmware projects, they have been pretty much nothing but state machines. (Note I specified "embedded control" and by that I do not mean "embedded PC" )
Mickster is a successful entrepreneur and yet is a proponent of PropBasic. A coincidence ? Hmmmm...
You just reminded me of a question that I keep meaning to ask but keep forgetting.
I always believed that my method of process control WAS a state machine but then I came across an article about what a state machine really was and it was nothing like mine:
Pseudo code
Select case Sequence_step
Case 1
Close_clamp
Incr Sequence_step
Case 2
IF Clamp_is_closed Then Incr Sequence_step
Case 3
Advance_slide
Incr Sequence_step
Case 4
IF Slide_is_forward Then Incr Sequence_step
Case 5......
End Select
Is this a state machine?
In PropBasic, the same can also be accomplished using ON-Gosub. Not sure if
ON-Goto is still supported.
With address labels (and thus jmp/goto) state can be represented by position in the program.
Without address labels, you have to continuously evaluate a switch statement (causing a typical 50% decrease in performance, in either MIPS or amps) and use a bunch of extra variables to indicate state. And you're adding a lot of program complexity. Just look at the blockly link and see what they are doing.
With address labels (and thus jmp/goto) state can be represented by position in the program.
Without address labels, you have to continuously evaluate a switch statement (causing a typical 50% decrease in performance, in either MIPS or amps) and use a bunch of extra variables to indicate state. And you're adding a lot of program complexity. Just look at the blockly link and see what they are doing.
I use labels and GOTO for my quadrature encoder counter. From what I can tell from the generated PASM, it should be good for close to 2M quad counts/sec. Any other method would not come close.
The comparison of VHDL and software case statements is strictly superficial. Case statement in VHDL is a physical description of hardware. Software is a set of sequential instructions given to a machine.
But this point reminded me philosophically of the essence of the problem with 'structured' language. To some degree it's trying to obfuscate the fact that a program is a set of sequential instructions. A young person sees this for the first time when you are learning C++ (or whatever) in school. Just go look at the blockly page. There is no sense of time flow in the code.
A "structured programming" version of this might look as follows:
void stateMachine_1() {
static uint32_t state = 0;
while (1) {
switch (state) {
case 0:
if (input) state = 2;
break;
case 1:
if (input) state = 3;
break;
case 2:
if (!input) state = 1;
break;
case 3:
if (!input) state = 0;
break;
}
output = state;
}
}
There, much nicer
Without address labels, you have to continuously evaluate a switch statement (causing a typical 50% decrease in performance, in either MIPS or amps)
Hmm...Let's see..If I compile those for x86 and RISC V I get the following instruction counts for the endlessly looping inner parts of the two versions.
Structured Spaghetti
x86 23 26
RISC-V 23 21
Well how about that? The structured programming style is smaller than the GOTO spaghetti mess for x86!
For RISC V it's only a tiny bit bigger. I don't know where you get your 50% from.
...and use a bunch of extra variables to indicate state.
Well, no. Generally a state machine will only have one state variable.
And you're adding a lot of program complexity.
No. Admittedly the guts of the structured code above is 17 source lines instead of the 16 lines of the spaghetti mess. The structured version more clearly expresses that there is an endless loop and a state machine there.
Just look at the blockly link and see what they are doing.
I did. Don't care. As I said above, structured programming does not imply using a clunky tool like Blockly.
Of course neither of my examples are actually useful. Not unless you have a dedicated processor to run them endlessly. If your program has something else to do you are going to have to arrange for that somehow. At which point trying to micro-optimize things by making a GOTO spaghetti mess seems even more pointless.
I don't think structured programming is asinine. The opposite probably is.
I think I see what The_Master is getting at, it's like unrolling a loop. There is a speed advantage. The counterbalance being if there is any significant complexity to the state space then the number of duplicated conditional branches will skyrocket. Lots of identical lines that all need edited in the same way becomes hard to maintain, hence being labelled a messy solution.
You've already shown a slight speed advantage on the RISC V. Once you get rid of all language overhead, that speed advantage would be proportionally bigger.
Once you get to a <real> example of a state machine, the speed advantage will even further get bigger.
And of course I don't know what your input is.
So, yeah, we're talking about a 100% performance advantage.
No matter how efficient the compiler, evaluating a switch always adds instructions and lowers performance. Sure, there are more efficient ways of the compiler implementing it (lookup table etc), if as a programmer you set up your code just right, but it still always has to evaluate the switch.
Whenever I am feeling down and want a good laugh to cheer me up, I go to stack exchange, etc and read postings from people asking how to implement state machines in C
What language overhead? My first example uses goto, which becomes a JMP. Other than that it has only the bare essentials, reading and testing the input and, changing the state and setting the output. It's totally unstructured, as I thought you liked it.
The second example is structured and introduces very little language overhead.
The input and output there are just global volatile integers. Rather like the I/O registers on a Prop.
I don't see where the 100% performance advantage will come from.
No matter how efficient the compiler, evaluating a switch always adds instructions and lowers performance.
My example shows this is not true. There is only a slight disadvantage for RISC V and a disadvantage for x86.
Please could you post here an example code of what you consider a good state machine? Otherwise I'm not going to get it.
The Jeopardy game control thing was pretty interesting, because this was exactly what got me started with electronics, and then from there computers, and then engineering. Otherwise today I might be selling insurance or something.
A friend in college was a tutor and he wanted to make a lockout type of Jeopardy game control to run Jeopardy-style quizzes with his students. I then went to an electronics store where the counter guy showed me little chips with logic gates on them, and how they worked. I was hooked.
Anyways, the best example to explain why the entire 'structured' thing is out of control is right here:
What should be literally 5 lines of Basic with a couple address labels, is instead 1.5 pages of crud. And I think they still didn't get it working correctly.
My position is that an optimum programming language is a mix imperative plus modular. When each module of code is no more than a page or so, any spaghetti code will just be a couple short strands. So maybe macaroni code then. You would then have the best of both worlds: Fully modular coding without the forced structure. Faster to develop. Higher performance. Faster to learn.
I think I even saw a term for this. It was called "free form programming" I think.
What should be literally 5 lines of Basic with a couple address labels, is instead 1.5 pages of crud. And I think they still didn't get it working correctly.
Bad idea to mix up points of concern. That isn't a speed of execution concern. So your earlier argument is not valid for this point.
Instead of 5 lines with a couple jumps, it's over a page of junk, and the students are STILL struggling to get it to work right. All this contortion to avoid using goto.
I'm interested in knowing what the students are STILL struggling with to get it to work right? Example please.
I'm not sure the purpose of the exercise was to show the most efficient way to program. I believe it was part of a curriculum demonstrating how the case statement works. I also don't think that Blockly is intended to be a programming environment for advanced programming, but is for beginners who don't need to be bogged down by syntax.
It's been years since I've used Basic, so I'd like to see how you would program it.
Comments
Mickster,
What is your first impressions of this article? https://www.theguardian.com/environment/climate-consensus-97-per-cent/2018/mar/26/study-wind-and-solar-can-power-most-of-the-united-states
Do you see it as a good approach for the future, a positive outlook, environmentally friendly, truthful? Or otherwise?
https://forums.parallax.com/discussion/168171/jeopardy-style-game-control
Instead of 5 lines with a couple jumps, it's over a page of junk, and the students are STILL struggling to get it to work right. All this contortion to avoid using goto.
In the C language, there are 4-5 scenarios where GOTOs are an accepted good thing, so the language specification left them in. And one of those things is state machines. And embedded control is mostly about state machines.
In my last five firmware projects, they have been pretty much nothing but state machines. (Note I specified "embedded control" and by that I do not mean "embedded PC" )
Mickster is a successful entrepreneur and yet is a proponent of PropBasic. A coincidence ? Hmmmm...
What amused me was the suggestion of the water-tank storage because I had the exact same idea but dismissed it as a limitation of my own knowledge/imagination.
Some complain that the turbines are eyesores but I can sit and watch them all day. However, huge, elevated water-storage tanks would be a different story unless they were buried in the top of a mountain or something.
My other thought was a flywheel but how big would they have to be, to be useful.
Okay, that sounds like a positively outlook of the technologies I guess. Correct me if I'm wrong. Do you think that's the way forward?
Well certainly from an environmental perspective but the "conspiracy-factist" in me believes that we will never be allowed to pop down to Home Depot (B&Q in UK) and pick up a "Mr. Fusion" (Back to the future) to provide free energy for our cars/homes.
I don't see any indication of affordable technology getting suppressed (even though it may start out un-affordable). Just look at computers - the most powerful tech ever invented, and it's everywhere. Despite IBM at one point believing that the world needed only 5 of the things, and Ken Olson of Digital couldn't see that anyone would ever want one at home.
As for the wind turbines - yes, I find them esthetically pleasing too. Seen them all over the world, at various kinds of locations. And another yes - water towers are *not* pleasing to look at, in general.
An interesting submission. Irrelevant of course, "structured programming" does not dictate one use a clunky tool like Blockly.
Your statement in that thread, "It's so 90's" shows a lack of domain knowledge. The ideas of structured programming date back the late 1960's and were well entrenched in the 1970's. I would say that the 1990's was the decade of object oriented programming, what with the arrival of C++, Delphi and such. That depends on who you ask
As a counter to that assertion I will point out that in the world of logic design using VHDL, Verilog, etc, one is pretty much not doing anything but creating state machines. Yet those languages do not have a GOTO !
Arguably all programming is about state machines. Not sure what distinction you are trying to make there. That is good. However it says nothing to support that assertion that "structured programming is asinine". PropBasic supports structured programming.
Having said all that, I love a good GOTO as much as the next man. It's rare that I need one or that it would make my code easier to read and understand.
Fusion is, of course, still on the horizon and very exciting to watch, but it's serious R&D! I loved the article about the German stellarator alternative to the ITER tokamak. I'm not sure but I think ITER are not locked into the tokamak just yet and could switch to the stellarator instead. Having a read of the timeline, it looks pretty well locked in.
I'll be blown away if small scale is ever possible for fusion. Now that would be a worthy line of research for the bleeding edge of science!
You just reminded me of a question that I keep meaning to ask but keep forgetting.
I always believed that my method of process control WAS a state machine but then I came across an article about what a state machine really was and it was nothing like mine:
Pseudo code
Is this a state machine?
In PropBasic, the same can also be accomplished using ON-Gosub. Not sure if
ON-Goto is still supported.
You have a state variable : Sequence_step
You have states : Case 1, Case 2, etc
You have some inputs : Clamp_is_closed etc.
You have some outputs : Close_clamp, Advance_slide.
It performs actions and changes state depending on the current inputs and current state.
Yep, I'd call it a state machine.
Cool. I thought I'd been making a fool of myself, all these years, for describing it that way.
I supply full source code with my products and this has been well received by in-house, ladder-logic guys.
Without address labels, you have to continuously evaluate a switch statement (causing a typical 50% decrease in performance, in either MIPS or amps) and use a bunch of extra variables to indicate state. And you're adding a lot of program complexity. Just look at the blockly link and see what they are doing.
Are we talking jump tables?
Edit: I guess they still rely on labels
Edit: Hub writes are the bottle neck, however.
But this point reminded me philosophically of the essence of the problem with 'structured' language. To some degree it's trying to obfuscate the fact that a program is a set of sequential instructions. A young person sees this for the first time when you are learning C++ (or whatever) in school. Just go look at the blockly page. There is no sense of time flow in the code.
Would the following be a correct illustration of the idea (Sorry, it's C)?
void stateMachine() { state_0: if (input) goto state_2; output = 0; goto state_0; state_1: if (input) goto state_3; output = 1; goto state_1; state_2: if (!input) goto state_1; output = 2; goto state_2; state_3: if (!input) goto state_0; output = 3; goto state_3; }A "structured programming" version of this might look as follows:void stateMachine_1() { static uint32_t state = 0; while (1) { switch (state) { case 0: if (input) state = 2; break; case 1: if (input) state = 3; break; case 2: if (!input) state = 1; break; case 3: if (!input) state = 0; break; } output = state; } }There, much nicerFor RISC V it's only a tiny bit bigger. I don't know where you get your 50% from. Well, no. Generally a state machine will only have one state variable. No. Admittedly the guts of the structured code above is 17 source lines instead of the 16 lines of the spaghetti mess. The structured version more clearly expresses that there is an endless loop and a state machine there. I did. Don't care. As I said above, structured programming does not imply using a clunky tool like Blockly.
Of course neither of my examples are actually useful. Not unless you have a dedicated processor to run them endlessly. If your program has something else to do you are going to have to arrange for that somehow. At which point trying to micro-optimize things by making a GOTO spaghetti mess seems even more pointless.
I don't think structured programming is asinine. The opposite probably is.
It depends on the job requirements in the end.
The C example in compiled Basic would boil down to just 4 lines, and take 11 instruction counts.
And you only have one state variable here in your example, because there's only one variable of state.
I don't feel that unrolling a loop necessarily moves us away from "structured programming".
It may give a speed advantage. The trade off is bigger code and perhaps maintenance problems if the number of loop iterations ever needs to change.
Once you get to a <real> example of a state machine, the speed advantage will even further get bigger.
And of course I don't know what your input is.
So, yeah, we're talking about a 100% performance advantage.
No matter how efficient the compiler, evaluating a switch always adds instructions and lowers performance. Sure, there are more efficient ways of the compiler implementing it (lookup table etc), if as a programmer you set up your code just right, but it still always has to evaluate the switch.
Whenever I am feeling down and want a good laugh to cheer me up, I go to stack exchange, etc and read postings from people asking how to implement state machines in C
The second example is structured and introduces very little language overhead.
The input and output there are just global volatile integers. Rather like the I/O registers on a Prop.
I don't see where the 100% performance advantage will come from. My example shows this is not true. There is only a slight disadvantage for RISC V and a disadvantage for x86.
Please could you post here an example code of what you consider a good state machine? Otherwise I'm not going to get it.
The Jeopardy game control thing was pretty interesting, because this was exactly what got me started with electronics, and then from there computers, and then engineering. Otherwise today I might be selling insurance or something.
A friend in college was a tutor and he wanted to make a lockout type of Jeopardy game control to run Jeopardy-style quizzes with his students. I then went to an electronics store where the counter guy showed me little chips with logic gates on them, and how they worked. I was hooked.
Anyways, the best example to explain why the entire 'structured' thing is out of control is right here:
https://forums.parallax.com/discussion/168171/jeopardy-style-game-control#latest
What should be literally 5 lines of Basic with a couple address labels, is instead 1.5 pages of crud. And I think they still didn't get it working correctly.
My position is that an optimum programming language is a mix imperative plus modular. When each module of code is no more than a page or so, any spaghetti code will just be a couple short strands. So maybe macaroni code then. You would then have the best of both worlds: Fully modular coding without the forced structure. Faster to develop. Higher performance. Faster to learn.
I think I even saw a term for this. It was called "free form programming" I think.
I'm not sure the purpose of the exercise was to show the most efficient way to program. I believe it was part of a curriculum demonstrating how the case statement works. I also don't think that Blockly is intended to be a programming environment for advanced programming, but is for beginners who don't need to be bogged down by syntax.
It's been years since I've used Basic, so I'd like to see how you would program it.
Thanks
tom
I use it exclusively for programming the Prop because it is FAST! Ease of use is a bonus.
Search the forum for PropBasic and take it for a (instead of) Spin
"The program works but I found a couple of issues."
This should have taken 5 lines, a couple address labels, and 15 minutes.
If you worked for me you would be in the doghouse, while me and Mickster would be playing Counterstrike and eating pizza.
There is such a thing is learning you know.
Also, now you've jumped from complaining about a programming method to dis'ing a particular person! That's a lot of aggro.