FRAC tool?

FRAC tool?

[Ken Garlington]

I'm using the PRICE-S cost model, and one of the parameters of the model is
FRAC (Fraction of Non-Executable Code) - the fraction of source lines of
code that describe type declarations and data and format statements. Has
anyone written a tool that will scan Ada (or C) source code to compute such
a number?

Re: FRAC tool?

[Ehud Lamm]

I don't know of any such tool, but it seems that it should be quite
straight forward to hack something in Perl/AWK.
What should be considered is which lines to count. Only type/subtype
declarations?

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

On Mon, 17 May 1999, Ken Garlington wrote:

> I'm using the PRICE-S cost model, and one of the parameters of the model is
> FRAC (Fraction of Non-Executable Code) - the fraction of source lines of
> code that describe type declarations and data and format statements. Has
> anyone written a tool that will scan Ada (or C) source code to compute such
> a number?
> 
> 
> 
> 

Re: FRAC tool?

[Robert Dewar]

In article
<Pine.A41.3.96-heb-2.07.990520213104.169052A-100000@pluto.mscc.h
uji.ac.il>,
  Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
> I don't know of any such tool, but it seems that it should be
> quite
> straight forward to hack something in Perl/AWK.
> What should be considered is which lines to count. Only
type/subtype
> declarations?

No, it is of course far more complex than this. The
initialization expression in a type declaration, or
function calls in the bounds of course generate code.

On the other hand, many other rep clauses etc should be
considered

This is not a trivial AWK tool!


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: FRAC tool?

[Ehud Lamm]

> No, it is of course far more complex than this. The
> initialization expression in a type declaration, or
> function calls in the bounds of course generate code.
> 
> On the other hand, many other rep clauses etc should be
> considered
> 
> This is not a trivial AWK tool!

My aim wasn't to insult anyone by mentioning AWK :-)

What I would find interesting is seening what code is supposed to be
counted by this tool. I find that the definitions are the hard part in
this kind of game.
So
type A is range F(1)..F(2)
will not be counted? Or maybe it should, since the code for F is coutned
as executable code, and this is defined as a declearation?

I am not expressing an opinion. I simply would be happy to know.
References are of course welcome too.

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: FRAC tool?

[Stuart Palin]

Ken Garlington <Ken.Garlington@computer.org> wrote in message
news:hQT%2.24$Wu1.441@news.flash.net...
> I'm using the PRICE-S cost model, and one of the parameters of the model
is
> FRAC (Fraction of Non-Executable Code) - the fraction of source lines of
> code that describe type declarations and data and format statements. Has
> anyone written a tool that will scan Ada (or C) source code to compute
such
> a number?

The ASAP tool from the PAL (IIRC) gives a load of statistics on Ada source
code.  ISTR that it does distinguish between executable and non-executable
code; but I don't know the rules that it uses.

Regards
--
Stuart

Re: FRAC tool?

[Robert A Duff]

"Stuart Palin" <stuart@palin-26.freeserve.co.uk> writes:

> The ASAP tool from the PAL (IIRC) gives a load of statistics on Ada source
> code.  ISTR that it does distinguish between executable and non-executable
> code; but I don't know the rules that it uses.

Given that declarations in Ada *are* executable, it's hard to see what
to measure here.  Comments and blank lines are not executable, I guess.
;-)

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: FRAC tool?

[Robert Dewar]

In article <wcclndti94g.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Given that declarations in Ada *are* executable, it's hard to
> see what to measure here.  Comments and blank lines are not
> executable, I guess.
> ;-)
I would measure statements that generate some code, that
seems a reasonable and well defined criterion (it's where
for example gdbtk let's you put a breakpoint :-)

I think it is a bit specious to consider

  A : Integer;

as executable in the absence of Normalize_Scalars.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: FRAC tool?

[Richard Kenner]

In article <7jmnk0$vvv$1@nnrp1.deja.com> Robert Dewar <robert_dewar@my-deja.com> writes:
>I would measure statements that generate some code, that
>seems a reasonable and well defined criterion

Not completely, especially in the presence of optimization.

Consider:

	A := A * 4;
	A := A + B;

On the Alpha, that can be done in one instruction, so only one of those
lines can be considered to generate code.

Re: FRAC tool?

[Robert Dewar]

In article <2oRa3.14$Lc3.1167@typhoon.nyu.edu>,
 kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:

> Not completely, especially in the presence of optimization.
>
> Consider:
>
> 	A := A * 4;
> 	A := A + B;
>
> On the Alpha, that can be done in one instruction, so only one
of those
> lines can be considered to generate code.


You misunderstand my criterion. In this case I would still say
that both statements generate code. The fact that the single
amazing Alpha instruction will take care of both statements
is interesting but irrelevant.

The issue is whether the given statements generate code. In
this case clearly both statements generate code. The fact that
the one instruction of the code takes care of both statements
does not change this fact.

If you think of Ada as defined by a virtual operational machine,
the issue is whether this virtual operational machine would have
code generated, assuming an appropriate realistic abstraction
level for the machine.

Sure this is vague, but could be made quite precise if someone
desired to do so.

I still see a quite clear intuitive distinction between the
above two statements, and a statement that says

 >begin

:-)




Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: FRAC tool?

[Richard Kenner]

In article <7l03ds$5a4$1@nnrp1.deja.com> Robert Dewar <robert_dewar@my-deja.com> writes:
>The issue is whether the given statements generate code. In
>this case clearly both statements generate code. The fact that
>the one instruction of the code takes care of both statements
>does not change this fact.
>
>If you think of Ada as defined by a virtual operational machine,
>the issue is whether this virtual operational machine would have
>code generated, assuming an appropriate realistic abstraction
>level for the machine.
>
>Sure this is vague, but could be made quite precise if someone
>desired to do so.
>
>I still see a quite clear intuitive distinction between the
>above two statements, and a statement that says
>
> begin

I don't.  In the presence of exception handlers or cleanup code, the
"begin" could easily generate far more code than the two arithmetic
statements in question.  Even a declaration with no initialization
might do a dynamic stack allocation in some contexts (e.g., some
declarations with -fstack-check in GNAT).