Coverting Asm to C: Metrics?

G'day All,

    I'm trying to estimate the effort involved in a project converting some 
well structured and commented (not mine, needless to say) 8051 assembler to 
C.  As a first estimate, naturally, I'm performing the task on a small part 
of the code and extrapolating.  Does anyone have (or know of) any metrics 
for a similar project as a sanity check.  Doesn't need to be 8051 to C, any 
non automated assembler to HLL conversion stats would be useful.

Thanks,
Alf 

Alf Katz wrote:
> G'day All,
> 
>     I'm trying to estimate the effort involved in a project converting some 
> well structured and commented (not mine, needless to say) 8051 assembler to 
> C.  As a first estimate, naturally, I'm performing the task on a small part 
> of the code and extrapolating.  Does anyone have (or know of) any metrics 
> for a similar project as a sanity check.  Doesn't need to be 8051 to C, any 
> non automated assembler to HLL conversion stats would be useful.
> 
> Thanks,
> Alf 
> 
> 
Hello Alf,

One mans "well documented code" is another mans "just spaghetti code".

Whenever I am asked to convert assembly to C, I bid for a redesign with 
documentation up front.

They way most assembly for micros are written is horrid at best.

Then.....

"But we just want to add a little extra code to ...."

This is where it will fall on its face.

Good Luck, you will need it.

donald

"Alf Katz" <alfkatz@iremove.the.bloody.obvious.ieee.org> wrote in message 
news:44d9bd88$0$22362$afc38c87@news.optusnet.com.au...
> G'day All,
>
>    I'm trying to estimate the effort involved in a project converting some 
> well structured and commented (not mine, needless to say) 8051 assembler 
> to C.  As a first estimate, naturally, I'm performing the task on a small 
> part of the code and extrapolating.  Does anyone have (or know of) any 
> metrics for a similar project as a sanity check.  Doesn't need to be 8051 
> to C, any non automated assembler to HLL conversion stats would be useful.

I've done this sort of thing many times. I usually wind up deriving a 
functional spec, and maybe an architecture, from the existing assembler and 
re-writing clean code in C.

Even with ideal assembler, the idioms are different. With less than ideal 
assembler, the idioms are just plain wrong ;). I can't give you metrics; 
some things are hard, some things are easy.

(FWIW, I often spot a bunch of bugs in the assembler in doing such 
conversion exercises. But I can generally extract what the coder *intended* 
to do, rather than what actually happens. IOW, it's not a bad way of doing a 
code review and a sanity check.)

Steve
http://www.fivetrees.com 

Alf Katz wrote:
> G'day All,
> 
>     I'm trying to estimate the effort involved in a project converting some 
> well structured and commented (not mine, needless to say) 8051 assembler to 
> C.  As a first estimate, naturally, I'm performing the task on a small part 
> of the code and extrapolating.  Does anyone have (or know of) any metrics 
> for a similar project as a sanity check.  Doesn't need to be 8051 to C, any 
> non automated assembler to HLL conversion stats would be useful.

This can be very open-ended ( but you probably already know that ... )

Is this code moving to another platform, or staying on the C51, and 
getting a C makeover, to make new features easier to control ?

If it is staying on the C51, you can quote in stages, and move the
proven/stable asm to libraries, where C can call it.
( ie don't rewrite what you don't have to ... )

You will also be able to have test-able sign-off stages, as this step
should be an operational clone of the existing system.

Then, you can add all the new features in C...

-jg

Hello ,

> Alf Katz wrote:
> G'day All,
>     I'm trying to estimate the effort involved in a project converting some
> well structured and commented (not mine, needless to say) 8051 assembler to
> C.  As a first estimate, naturally, I'm performing the task on a small part
> of the code and extrapolating.  Does anyone have (or know of) any metrics
> for a similar project as a sanity check.  Doesn't need to be 8051 to C, any
> non automated assembler to HLL conversion stats would be useful.

   You can collect the following metrics,
a) Size of the code generated for the C code and compare thesize with
that of the existing ASM code. Set a limit to say the code generated by
the C code should be less that 1.5/2 times that of the ASM code.
b) Do a code coverage and profiling analysis for the ASM and the C
code.

   May I know the exact reason for this conversion?

Best Regards,
Vivekanandan M

Vivekanandan M wrote:

>    You can collect the following metrics,
> a) Size of the code generated for the C code and compare thesize with
> that of the existing ASM code. Set a limit to say the code generated by
> the C code should be less that 1.5/2 times that of the ASM code.
> b) Do a code coverage and profiling analysis for the ASM and the C
> code.

I have found the metrics interesting in the cases we have done this. Evolved
code is rarely that clean and compilers generally do a considerably better
job at local variable allocation and placement than assembler programmers.
Don't be surprised that the generated C results in shorter faster applications
with less RAM requirements.

Of course I am biased.

w..

Walter Banks wrote:
> Vivekanandan M wrote:
>
> >    You can collect the following metrics,
> > a) Size of the code generated for the C code and compare thesize with
> > that of the existing ASM code. Set a limit to say the code generated by
> > the C code should be less that 1.5/2 times that of the ASM code.
> > b) Do a code coverage and profiling analysis for the ASM and the C
> > code.

Fat chance

>
> I have found the metrics interesting in the cases we have done this. Evolved
> code is rarely that clean and compilers generally do a considerably better
> job at local variable allocation and placement than assembler programmers.

Maybe on a C friendly machine but not much chance on a 8051.

> Don't be surprised that the generated C results in shorter faster applications
> with less RAM requirements.

Be amased if it does

> 
> Of course I am biased.

Agreed.
> 
> w..

On Wed, 9 Aug 2006 20:48:40 +1000, the renowned "Alf Katz"
<alfkatz@iremove.the.bloody.obvious.ieee.org> wrote:

>G'day All,
>
>    I'm trying to estimate the effort involved in a project converting some 
>well structured and commented (not mine, needless to say) 8051 assembler to 
>C.  As a first estimate, naturally, I'm performing the task on a small part 
>of the code and extrapolating.  Does anyone have (or know of) any metrics 
>for a similar project as a sanity check.  Doesn't need to be 8051 to C, any 
>non automated assembler to HLL conversion stats would be useful.
>
>Thanks,
>Alf 

Was the assembly code originally written by someone who is a also
skilled C programmer? 

I'd guess somewhat longer than it would take to write the C program
from scratch (given good documentation), because you have to extract
the design, evaluate it, probably modify aspects of it, and then
implement it. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On Thu, 10 Aug 2006 09:27:32 -0400, Walter Banks
<walter@bytecraft.com> wrote:

>Vivekanandan M wrote:
>
>>    You can collect the following metrics,
>> a) Size of the code generated for the C code and compare thesize with
>> that of the existing ASM code. Set a limit to say the code generated by
>> the C code should be less that 1.5/2 times that of the ASM code.
>> b) Do a code coverage and profiling analysis for the ASM and the C
>> code.
>
>I have found the metrics interesting in the cases we have done this. Evolved
>code is rarely that clean and compilers generally do a considerably better
>job at local variable allocation and placement than assembler programmers.
>Don't be surprised that the generated C results in shorter faster applications
>with less RAM requirements.
>
>Of course I am biased.

hehe, yes you are.

I've never had the experience of a C compiler reducing my code and
data footprint or improving on the execution time.  But then, I've
only had one truly comparable experience where I was paid to actually
port an assembly-coded, full-up application that I'd also written, as
exactly as I could manage into C.  The size expanded dramatically on
all points and I was seriously trying to write good maintainable C and
accurately reflect the details of operation.  I'm not ignorant of
library issues, nor numerical methods, and I feel I applied a good
degree of expertise in writing the C code.

Even in the case of small routines, where I'm forced to apply the
model required by C for interfacing purposes (frames, stack unwind
support if appropriate, register preservation, etc), I don't find yet
any C compiler able to improve on execution -or- space.

Jon

Alf Katz wrote:
> 
> G'day All,
> 
>     I'm trying to estimate the effort involved in a project converting some
> well structured and commented (not mine, needless to say) 8051 assembler to
> C.  As a first estimate, naturally, I'm performing the task on a small part
> of the code and extrapolating.  Does anyone have (or know of) any metrics
> for a similar project as a sanity check.  Doesn't need to be 8051 to C, any
> non automated assembler to HLL conversion stats would be useful.
> 
> Thanks,
> Alf

Start from the right end by defining what the product does, (I know this
is obvious :-) perhaps as some sort of functional spec. Then, the
existing code major functional bloacks, relationship between modules in
terms of how data gets passed around the system, how many code banks are
involved and relationships between const data, code and common area
dependencies etc. If the code is well documented already, you have a
head start, but the docs and code comments may not equal current
reality. You could spend weeks or even months trying to work out what
the old code is doing. Then you need to check for bugs and subtle
'intended' side effects etc. You have to assume that all the old code is
suspect.

One major obstacle to analysis of older systems is that there can be
global data all over the place and if the code has been heavily modified
over the years, can be a nightmare to determine what global gets used
where and when. You will also have to modify or write wrappers for the
asm modules that you decide to keep, to conform to the calling
conventions of the C compiler.

IME, reuse of a worn out code base ends up as a dog's dinner. It's
usually quicker to rewrite the whole lot. Sharp pencil, nice new clean
code base, well structured etc - you just have to convince the
management :-)...

Chris



-- 
Greenfield Designs Ltd
-----------------------------------------------------------
Embedded Systems & Electronics: Research Design Development
Oxford. England. (44) 1865 750 681