|
Generally you are right, usually the codewitch works on small embedded systems where performances and code footprint can be extremely stringent.
I found myself doing things I would have abhorred only a few scant years ago...
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
Table driven implementations usually reduces the control code to typically a couple hundred bytes (or even less), at the expense of data space for the table.
By using data elements no larger than required in the transition table entries, each entry can be kept to a very moderate size.
One possible issue is the number of states and events. It takes some experience to control both, to keep the table size (#states * #events) under control. A common trick is to introduce 'state variables'.
Some times you can use 2+ small tables rather than a huge one, e.g. if you implement a communication protocol: One table for the connect phase, one for the data transfer phase.
Many transition tables are rather sparse anyway, but a lot of methods for space efficient storage of sparse matrices are basic data structure knowledge. E.g. non-empty entries may be factored out to a packed, linear array, and the large table contains indexes to this array. Often, several transitions are identical (typically in one state, for different events, or for one event in several different states) - then a linear table need to hold only a single copy.
Certainly, really old embedded processors (such as 8051) had very little data space; expanding code space was far easier (e.g. through banking hardware). While we would usually call the transition table 'data', it is 100% read-only, and may very well be burnt in ROM (ok, call it 'flash' nowadays) together with the driver code.
If you consider CLR for an embedded CPU (don't try that on an 8051!), then you definitely can fit a packed transition table. My guess is that the total code+data size would be significantly smaller than an equivalent implementation with switch cases and/or if/else-sequences. And faster, even if a packed table will lead to a couple more indirections.
I will maintain that table driven state machines can be a very good solution for embedded processors.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: If I were given the responsibility for a state machine implementation like that, I would immediately run to my boss asking for permission to rewrite the whole thing as a table driven machine.
... or as a state machine that returns function pointers instead of using tables and state variables:
#include <stdio.h>
#include <conio.h>
typedef void (*RT)( int input );
typedef RT (*TER)( int input );
extern TER state1( int input );
extern TER state2( int input );
extern TER state3( int input );
TER state1( int input )
{
printf( "one\t" );
return input < 10 ? (TER)&state2 : (TER)NULL;
}
TER state2( int input )
{
printf( "two\t" );
return (TER)&state3;
}
TER state3( int input )
{
printf( "three\t" );
return (TER)&state1;
}
int main(int argc, char* argv[])
{
int n;
TER state = (TER)&state1;
for ( n = 0 ; state ; ++n ) {
state = (TER)( state( n ) );
}
printf( "\n\nPress any key\n" );
getch();
return 0;
}
Type casts are useful because in C it's impossible to declare function pointers that return function pointers that return function pointers that return function pointers...
Regards
|
|
|
|
|
Wow, too much with the GOTO's already - they put it in the language for a reason. It will always be in certain languages for the same reasons. We are just debating normal human failings that have nothing to do with GOTO.
We are engineers, we should know that ALL humans a fallible and can make a mess of anything.
Careless use of GOTO helps us make a mess faster, careful use of GOTO makes our code run faster.
|
|
|
|
|
Fair enough. Implement a DFA state machine without gotos, achieving comparable performance. I'll wait.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I was agreeing with you - my point was, nobody should care if you are using GOTO's, they should only care if you are making a mess with them.
I have never seen you produce a mess, quite the opposite in fact.
|
|
|
|
|
I clearly misunderstood you. Sorry.
And thanks!
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: I clearly misunderstood you. Sorry.
Np, irony is easily missed in short messaging!
|
|
|
|
|
My CP sig used to be something like, "If you think GOTO's are bad try coding in Assembler without using JMP."
A programmer I once worked with had the opinion that subroutines (that's what methods were called back then) should only have one exit point. Since you couldn't RETURN from where the routine might need to exit and you couldn't use GOTO his longer methods tended to have dozens of embedded IF blocks. Yuck.
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
When all you have is a hammer, every problem looks like a nail.
Goto's have their place, the problem is when they're being abused because all the developer sees is nails and can't come up with a better solution.
That being said, I'm looking glancing at your code and clearly I'm in no position to criticize.
|
|
|
|
|
We're running a heavy process that's causing some of our servers to creak a little. Sorry about any slowness you might experience today. It'll be over soon, I hope.
cheers
Chris Maunder
|
|
|
|
|
No problem, I had to attend a funeral today
(no, not the funeral of the CodeProject website)
|
|
|
|
|
Sorry to hear that, mate.
cheers
Chris Maunder
|
|
|
|
|
Thanks Chris, it was my mothers funeral, everything went well, the weather was perfect, and I'm sure she would have appreciated all the kind words said by the four speakers. I concluded with some lines from an old poem:
Quote: Farewell to thee, farewell to thee
Thou charming one who dwells in shaded bowers
One fond embrace ere I depart
Until we meet again.
|
|
|
|
|
I will do my part to alleviate the server burden by not posting this. Oops.
|
|
|
|
|
Cheers Chris it wasn't slow for me - it was unavailable for hours
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
If a page doesn't load for a few hours can we still claim that as slow loading times?
(Sorry about that)
cheers
Chris Maunder
|
|
|
|
|
No worries Chris I’m sure it couldn’t be helped
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
I thought the server hamsters seemed a little haggard this morning.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I'm a little haggard this morning...
cheers
Chris Maunder
|
|
|
|
|
Honestly, I thought it was the solar flares.
|
|
|
|
|
The introduction to The Lounge says:
Quote: The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I am focused on the sentence: Trolling, (political, climate, religious or whatever) will result in your account being removed.
However, is bashing and trolling M$, Apple, Google, Meta, etc. when they, as companies, act stupid with their technology/programming/API offerings, OK?
Of course it is
|
|
|
|
|
It's not bashing. It's discussing, in painful detail, the issues that we face using our tools as part of a thoughtful dialogue.
To be honest, the state of software today is doing my head in.
(and it's been a while - how are you?)
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: discussing, in painful detail, the issues that we face using our tools as part of a thoughtful dialogue I think I will save that wording, and use it to tag some of the future Lounge postings that the OP is referring to
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Seems like discussing the developer that was fired from Google for claiming that the Google AI is sentient would be border line on that?
|
|
|
|