Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ptsfa!hoptoad!academ!uhnix1!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.arch
Subject: Re: What with these Vector's anyways?
Message-ID: <305@nuchat.UUCP>
Date: Thu, 3-Sep-87 10:18:54 EDT
Article-I.D.: nuchat.305
Posted: Thu Sep  3 10:18:54 1987
Date-Received: Sat, 5-Sep-87 17:49:15 EDT
References: <218@astra.necisa.oz> <142700010@tiger.UUCP> <363@astroatc.UUCP> <1496@apple.UUCP>
Organization: Public Access - Houston, Tx
Lines: 40
Keywords: scalar vs. vectors, benchmarks, Dhrystone, sorting
Summary: automagic trace code

I wasn't going to say anything about this if a discussion
started, but it needs saying befor I expire the article:

In article <1496@apple.UUCP>, bcase@apple.UUCP (Brian Case) writes:
> optimizing C compiler at AMD, I was a little worried that dhrystone was
> running incorrectly.  To get a reasonably warm/fuzzy feeling, I put a line
> like
> 	fprintf (outfile, "X\n");
> where 'X' is a unique number (or a unique string, etc.), at each possible
> fork in a branch (this includes procedure/function entrances, etc).  Then
> I ran the program on the VAX and PC RT and simulated it on the Am29000.
> In each case the outfile contained the same sequence of numbers.  At least
> the *branching* behavior was equivalent in each case.  This seems like a
> good first cut at correctness, and it should be possible to construct a
> tool (based on a compiler front end) to insert the fprintf statements
> automatically.  Is this reasonable or hairbrained?

This is indeed very reasonable.  Such tools exist; they are known
as test coverage or source line profiling tools.  The idea is to
measure the number of times each line (or so) of the source is
executed, either for performance tuning or to check the completeness
of the test cases executed.

I'm pretty sure I saw an article on one for C in the Bell System
Technical Journal back when someone I knew subscribed.  The author
of that article chose to run a preprocessor to insert source statements
to extract the information, leaving the compiler system intact.

The alternative is to put the tests in the code generator or a
assembly language post-processor, both of which have advantages
but were rejected by that author for the usual, valid reasons.

People in comp.compilers probably could supply a lot more info.

	steve nuchia
-- 
Steve Nuchia			Of course I'm respectable!  I'm old!
{soma,academ}!uhnix1		Politicians, ugly buildings, and whores
!nuchat!steve			all get respectable if they last long enough.
(713) 334 6720				- John Huston, Chinatown