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

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.

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.

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.

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

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

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

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

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

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