Convert assembly to C

larwe wrote:
> On Jun 17, 5:06 pm, nobody <nob...@nowhere.com> wrote:
> 
> 
>>>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
> 
> 
> 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.

nobody wrote:
> 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.

On Jun 18, 5:10=A0pm, nobody <nob...@nowhere.com> wrote:

> > Is this actually better than a switch statement, though? Switch often
> > compiles to much the same thing, plus it lets you use fallthrough if
>
> 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.

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.

In article <4c1943ba$0$286$14726298@news.sunsite.dk>, 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?

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