From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5a97e6705e234408
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-09-21 07:09:51 PST
Path: 
 archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!hammer.uoregon.edu!skates!not-for-mail
From: Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
Newsgroups: comp.lang.ada
Subject: Re: Expected bytes per sloc (semicolons) performance
Date: 21 Sep 2001 10:02:40 -0400
Organization: NASA Goddard Space Flight Center
Message-ID: <uadzobq0v.fsf@gsfc.nasa.gov>
References: <8f23da36.0109181403.52128d70@posting.google.com>
 <_hRp7.7630$ot.1153235@typhoon.ne.mediaone.net>
 <8f23da36.0109201115.2f708535@posting.google.com>
NNTP-Posting-Host: anarres.gsfc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: skates.gsfc.nasa.gov 1001081020 15208 128.183.220.71 (21 Sep 2001
 14:03:40 GMT)
X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov
NNTP-Posting-Date: 21 Sep 2001 14:03:40 GMT
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
Xref: archiver1.google.com comp.lang.ada:13228
Date: 2001-09-21T14:03:40+00:00
List-Id: <comp.lang.ada>

mike_harrison80@yahoo.com (Mike Harrison) writes:

> Thanks for the responses.  Sorry the thread turned into a RISC discussion.
> 
> So let me try to get back on track with a different question:
> If you were bidding a 5K sloc estimated size program (algorithmic in 
> nature) to go into a satellite with limited memory, what sort of 
> bytes/per sloc estimate would you use, 5, 10, 20, 50, 100?  Our
> experience is 50 or more.  Is this what others are seeing
> with today's Ada compiler technology?

Hmm. I've never had to actually do such a bid, but I am a Rocket
Scientist, and I've been on the receiving end of such bids, so I'll
venture an opinion :).

I'd do a prototype on the target processor, and measure it. Second
best is to find similar code on a similar processor, and measure that.

If I was on your bid review committee, that's what I'd look for. 

If you don't have a working target processor yet, and you don't have a
simulator, and there is no "similar" processor - pick another
processor!

Rules about n bytes per sloc are just too processor, compiler, and
coding style dependent to be useful.

I guess I need to say I am _not_ speaking for NASA here, just me.

-- 
-- Stephe