Coverting Asm to C: Metrics?

"Chris Quayle" <devnull@zzz.co.uk> wrote in message 
news:44DBAF71.84C6F2CF@zzz.co.uk...
> 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 :-)...

Completely agree. Nicely put.

But - the old codebase is useful in terms of analysing:
  - What was intended
  - The workarounds employed to get it to work as intended

Steve
http://www.fivetrees.com 

Chris Quayle wrote:
> 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.
>


 the old code is only thing that is not suspect, it's everything else
that's suspect (comments, low level requirements, customer spec, tests
etc), the only thing that you can be sure of that accurately reflects
the desired product performance and purpose is the old program code,
it's the only thing that was guaranteed to be maintained, however poor
the implementation

"steve" <bungalow_steve@yahoo.com> wrote in message 
news:1155266660.998027.30520@74g2000cwt.googlegroups.com...
>
> Chris Quayle wrote:
>> 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.
>>
>
>
> the old code is only thing that is not suspect, it's everything else
> that's suspect (comments, low level requirements, customer spec, tests
> etc), the only thing that you can be sure of that accurately reflects
> the desired product performance and purpose is the old program code,
> it's the only thing that was guaranteed to be maintained, however poor
> the implementation
>

Yepp, you're right Steve (not at five trees).  In this case the code is the 
spec.  It has been been debugged over 10 years is very stable and is the 
basis of the company's existence.  The code in fact defines what the product 
does.  The code is the documentation.  Although the original coder's brain 
is available for consultation.  The way to work out what the code is doing 
is to rewrite it in something intelligible, may as well make it the original 
version of the next generation product.

Cheers,
Alf 

>   May I know the exact reason for this conversion?
>
> Best Regards,
> Vivekanandan M
>

We have a product that has outgrown the 8051.  Even the 33MHz Dallas single
cycle 8051's are no longer fast enough to do the job.  Both program and data
requirements have outgrown the current 512kB X/P memory mapping schema.  I
am examining and comparing two major solutions.  One is building a better
8051 inside an FPGA with a 3:1 improvement in speed and heaps of hardware
speed ups to critical tasks.  The other is migrating to a faster processor
(e.g. and ARM, but the actual processor is pretty irrelevant once we get to
C).  The latter has numerous other advantages, not least of which is the
maintainability and expandability promised by conversion to C.

The reason I was interested in metrics for the conversion process is that
the major difference in the development cost of the two approaches is the
need to recode to use the faster processor.

Cheers,
Alf

Thanks, all, for your interesting replies.  Unfortunately, no one seems to
have collected metrics for the *effort* involved in translation of C to
assembler, which will be the main determinant of whether we proceed with
this project.  I have performed the task on a small (<1k), but reasonably
representative portion of the code, and find that I can translate it at
approximately 130 assembler SLOC per hour, coming in reasonably cold, but
with an understanding of both C and assembler.  I figure that after a couple
of weeks a(nother) competent assembler/C programmer (thin on the ground in
the antipodes) will get to know the common structures and macro usage a lot
better than I did in a day, so I think a rate of 100 SLOC/hour should be
achievable.  Naturally, I'll budget on significantly less.

Interestingly, the number of lines of code was very close to the 2:1
Assembler:C SLOC ratios predicted by the function point boys.

Cheers,
Alf

On Fri, 11 Aug 2006, Alf Katz wrote:

"[..]

[..]  One is building a better
8051 inside an FPGA with a 3:1 improvement in speed and heaps of hardware
speed ups to critical tasks.  [..]

[..]"

8051s implemented in FPGAs are commercially available.

Alf Katz wrote:

> Yepp, you're right Steve (not at five trees).  In this case the code is the
> spec.  It has been been debugged over 10 years is very stable and is the
> basis of the company's existence.  The code in fact defines what the product
> does.  The code is the documentation.

Yes I deal with this situation all the time, the customer can't even
tell you what precisely the product requirements are, only the legacy
code can.

"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote in message 
news:20060811144153.E69219@docenti.ing.unipi.it...
> On Fri, 11 Aug 2006, Alf Katz wrote:
>
> "[..]
>
> [..]  One is building a better
> 8051 inside an FPGA with a 3:1 improvement in speed and heaps of hardware
> speed ups to critical tasks.  [..]
>
> [..]"
>
> 8051s implemented in FPGAs are commercially available.

The core is (even the one Dallas bought), and I've found them to be a good
starting point.   They tend to be *too* 8051 compatible without taking
advantage of what the extra pins and other resources of the FPGA offer.
Stuff like true harvard architecture (separate P and X mem) with non muxed
address & data busses, single write context switches and the other hardware
speedups alluded to.  That's what makes the C conversion to a cheaper,
faster MCU the riskier approach, and consequently why I'm trying to get a
handle on the effort (man hours/KSLOC) involved in the migration before
comitting to one approach or the other.

Cheers,
Alf

Alf Katz <alfkatz@iremove.the.bloody.obvious.ieee.org> wrote:
> >   May I know the exact reason for this conversion?
> >
> > Best Regards,
> > Vivekanandan M
> >

> We have a product that has outgrown the 8051.  Even the 33MHz Dallas single
> cycle 8051's are no longer fast enough to do the job.  Both program and data
> requirements have outgrown the current 512kB X/P memory mapping schema.  

Hold it a moment, please.  Just so we're 101% perfectly clear about
this: you've outgrown a 512 KiB super-8051 system writing all the code
in *assembler*?  I'll hand it to you, you must have had a team of
brave people work on such monster.  I've maintained a 96 KiB
code-size, Super-8051 project done entirely in assembly, and
considered that to be sitting on the fence, leaning dangerous towards
"mission impossible" territory.

> I am examining and comparing two major solutions.  One is building a
> better 8051 inside an FPGA with a 3:1 improvement in speed

I'd be careful with that expected speedup.  Just ask yourself: if it
were realistic to render that IP core Dallas bought for 100 MHz clock
frequency, what kept Dalls from doing that in their chips (keeping in
mind they're going ASIC, so they should be faster, not slower than an
FPGA)?  Would DalSemi really shoot their own foot just like that?

> The reason I was interested in metrics for the conversion process is that
> the major difference in the development cost of the two approaches is the
> need to recode to use the faster processor.

There is, theoretically at least, a third option, albeit it a
*thoroughly* nasty one: an 8051 machine code interpreter, running on
whatever CPU you can find that is fast enough to pull off that stunt.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Alf Katz wrote:

>>  May I know the exact reason for this conversion?
>>
>>Best Regards,
>>Vivekanandan M
>>
> 
> 
> We have a product that has outgrown the 8051.  Even the 33MHz Dallas single
> cycle 8051's are no longer fast enough to do the job.  Both program and data
> requirements have outgrown the current 512kB X/P memory mapping schema.  I
> am examining and comparing two major solutions.  One is building a better
> 8051 inside an FPGA with a 3:1 improvement in speed and heaps of hardware
> speed ups to critical tasks.  

For another data point, look at these new 'monster 80C51' devices :
http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=91;72;103

These have the Farcall C390 core, and claim 100Mips, with 512K Flash
Prices are apparently sub $6


> The other is migrating to a faster processor
> (e.g. and ARM, but the actual processor is pretty irrelevant once we get to
> C).  The latter has numerous other advantages, not least of which is the
> maintainability and expandability promised by conversion to C.

I'd define the data sizes carefully, depending on the code/data split, 
you might already be above single chip devices. There are very few 
1Mbyte ARM uC, so this might push into microprocessor solutiom, which
is a quite different animal.

> 
> The reason I was interested in metrics for the conversion process is that
> the major difference in the development cost of the two approaches is the
> need to recode to use the faster processor.

It depends on the project, but another viable soultion would be to split 
into two controllers. The stable low level stuff, stays in 80C51(s), and 
the new stuff goes into some 32 bit core.
  uC these days are so cheap, they cost less than the packing, or 
cables, in many projects.

-jg