I'm converting assembly code to C and there is a lot of branches/jumps (it is a big state machine). When rewriting the different states would you use the goto keyword or try to rewwrite all with if, if-else?
Convert assembly to C
Started by ●June 16, 2010
Reply by ●June 16, 20102010-06-16
On 6/16/2010 2:35 PM, Mith wrote:> I'm converting assembly code to C and there is a lot of branches/jumps (it > is a big state machine). > > When rewriting the different states would you use the goto keyword or try to > rewwrite all with if, if-else? > >That depends, what's the point of the exercise? -- Rob Gaddi, Highland Technology Email address is currently out of order
Reply by ●June 16, 20102010-06-16
"Mith" <mith@no.no> wrote in message news:4c1943ba$0$286$14726298@news.sunsite.dk...> I'm converting assembly code to C and there is a lot of branches/jumps (it > is a big state machine). > > When rewriting the different states would you use the goto keyword or try > to rewwrite all with if, if-else?or even with Switch/case stetments perhaps? tim
Reply by ●June 16, 20102010-06-16
On 2010-06-16, Mith <mith@no.no> wrote:> I'm converting assembly code to C and there is a lot of branches/jumps (it > is a big state machine). > > When rewriting the different states would you use the goto keyword or try to > rewwrite all with if, if-else?Since you're doing a state machine, it sounds like a "switch" statement (or even nested switch statements) is probably a better option. You're probably better off reverse-engineering the state machine, then coding it from scratch in C. -- Grant Edwards grant.b.edwards Yow! I love ROCK 'N ROLL! at I memorized the all WORDS gmail.com to "WIPE-OUT" in 1965!!
Reply by ●June 16, 20102010-06-16
On 06/16/2010 02:35 PM, Mith wrote:> I'm converting assembly code to C and there is a lot of branches/jumps (it > is a big state machine). > > When rewriting the different states would you use the goto keyword or try to > rewwrite all with if, if-else?Would I be in a hurry? Would I be doing this for a once-off prototype or a product that has to work for years? How many other people (including me, later) would have to read and understand the code? With all the time in the world and a need to do it "right", I'd reverse-engineer the assembly back to a detailed specification, then I'd write code to that. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●June 16, 20102010-06-16
On 6/16/2010 3:22 PM, Tim Wescott wrote:> On 06/16/2010 02:35 PM, Mith wrote: >> I'm converting assembly code to C and there is a lot of branches/jumps >> (it >> is a big state machine). >> >> When rewriting the different states would you use the goto keyword or >> try to >> rewwrite all with if, if-else? > > Would I be in a hurry? Would I be doing this for a once-off prototype or > a product that has to work for years? How many other people (including > me, later) would have to read and understand the code? > > With all the time in the world and a need to do it "right", I'd > reverse-engineer the assembly back to a detailed specification, then I'd > write code to that. >Alternatively, if it had to be done yesterday I'd strongly consider a line-for-line translation, gotos and all, and hope to god I never had to do any maintenance on it. Or wrap the whole thing in as inline assembler and be done with it. -- Rob Gaddi, Highland Technology Email address is currently out of order
Reply by ●June 16, 20102010-06-16
On 06/16/2010 03:26 PM, Rob Gaddi wrote:> On 6/16/2010 3:22 PM, Tim Wescott wrote: >> On 06/16/2010 02:35 PM, Mith wrote: >>> I'm converting assembly code to C and there is a lot of branches/jumps >>> (it >>> is a big state machine). >>> >>> When rewriting the different states would you use the goto keyword or >>> try to >>> rewwrite all with if, if-else? >> >> Would I be in a hurry? Would I be doing this for a once-off prototype or >> a product that has to work for years? How many other people (including >> me, later) would have to read and understand the code? >> >> With all the time in the world and a need to do it "right", I'd >> reverse-engineer the assembly back to a detailed specification, then I'd >> write code to that. >> > > Alternatively, if it had to be done yesterday I'd strongly consider a > line-for-line translation, gotos and all, and hope to god I never had to > do any maintenance on it. > > Or wrap the whole thing in as inline assembler and be done with it.Unless it's a port from this here processor to that there processor. Line for line would be messy as hell, and slow, but would do in a hurry. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●June 16, 20102010-06-16
Hi Rob, Rob Gaddi wrote:> On 6/16/2010 2:35 PM, Mith wrote: >> I'm converting assembly code to C and there is a lot of branches/jumps >> (it is a big state machine). >> >> When rewriting the different states would you use the goto keyword or >> try to rewwrite all with if, if-else? > > That depends, what's the point of the exercise?Exactly. Why is the OP doing the conversion at all? To add a new feature to an old product? (is the feature *that* complex that you couldn't just add it into the ALREADY WORKING assembly language code?) As a HEAD branch for a *new* product derived from some old/existing product? (doesn't the new product *deserve* a fresh start?) **IF** something/someone has decided that it is worth your time ($$) to convert the codebase to some HLL (e.g., C), then do everyone a favor and reengineer the product so that it is worth the time/expense. Note that you can't do a one-for-one conversion of assembly language to C as many things available in assembly language don't have corresponding C constructs. What happens when/if you come across one of those in the code? Do you *then* start to rethink that portion of the code? (i.e., why not rethink it *all*, NOW) I suspect the state machine is an ad-hoc FSM and not very structured. So, you'll end up with code that is equally poorly structured. I like my state machines to look like: STATE AWAIT_VALUE CASE '0' THRU '9' GOTO ACCUMULATE_VALUE USING first_digit CASE CLEAR GOTO ACCUMULATE_VALUE USING redisplay_default CASE ENTER GOTO ACCEPT_VALUE USING accept_value OTHERWISE HANDLE_EXTRANEOUS_EVENT STATE ACCUMULATE_VALUE CASE '0' THRU '9' GOTO ACCUMULATE_VALUE USING accept_digit CASE CLEAR GOTO AWAIT_VALUE USING redisplay_default CASE ENTER GOTO CHECK_VALUE USING apply_criteria OTHERWISE HANDLE_EXTRANEOUS_EVENT STATE CHECK_VALUE CASE VALID GOTO ACCEPT_VALUE USING all_done_here CASE INVALID GOTO REJECT_VALUE USING alert_operator OTHERWISE HANDLE_EXTRANEOUS_EVENT STATE REJECT_VALUE CASE CLEAR GOTO AWAIT_VALUE USING redisplay_default CASE '0' THRU '9' GOTO REJECT_VALUE USING alert_operator OTHERWISE HANDLE_EXTRANEOUS_EVENT A fictional FSM, of course. But, you can see what the code wants to do without reading through all the *real* code (e.g., "alert_operator", "all_done_here", etc.)
Reply by ●June 17, 20102010-06-17
Mith wrote:> I'm converting assembly code to C and there is a lot of branches/jumps (it > is a big state machine). > > When rewriting the different states would you use the goto keyword or try to > rewwrite all with if, if-else? >None. State/Event matrix and function pointers
Reply by ●June 17, 20102010-06-17
On Jun 17, 5:06=A0pm, nobody <nob...@nowhere.com> wrote:> > When rewriting the different states would you use the goto keyword or t=ry to> > rewwrite all with if, if-else? > > None. State/Event matrix and function pointersIs this actually better than a switch statement, though? Switch often compiles to much the same thing, plus it lets you use fallthrough if you want, and it has implicit bounds checking on the state variable.
