Convert assembly to C

That depends, what's the point of the exercise?

--
Rob Gaddi, Highland Technology
Email address is currently out of order

or even with Switch/case stetments perhaps?

tim

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!!

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

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

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

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

None. State/Event matrix and function pointers

ry to

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

I'm used to work in Ada so bounds checking is nothing I think specially about.

It has one advantage. Constant dispatch time. It always takes the same time to translate a state and an event into a new state. With two nested case (switch?) statements the time will vary depending on which branches you end up in.

This forces you to make very *big* tables and/or preprocess events to reduce the number of stimuli that the FSM responds to.

E.g., build a FSM that will successfully parse messages of the form:

"The battery voltage is +#.###\n"

and

"Power has failed at XX:XX:XX\n"

Silly examples (?) but they illustrate the point.

I've found the "present_state x input_stimulus = next_state" table approach rarely justifies the speed/spade tradeoff for anything but trivial automata.

YMMV.

Maybe. Depends on how smart your compiler is. The difference is probably in the order of 10-15 instructions though at most. I try not to write code in any HLL that's going to get that tight on the jitter introduced by different branches through the code. Seems like a recipe for horror every time you upgrade your compiler.

Also, in the systems where I need to worry about it, I usually have factors orders of magnitude greater that are affecting code execution determinism - caches and DMA bus contention, for instance.

If it is a state machine I would try to rewrite it as a switch, and keep the remainder as goto (for starters).

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst