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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9c86eb13dd395066
X-Google-Attributes: gid103376,public
From: garriga@logica.com (Stephen Garriga)
Subject: Re: CRC in Ada?
Date: 1997/03/04
Message-ID: <331c6543.31113581@news.logica.co.uk>#1/1
X-Deja-AN: 223051287
References: <1997Mar2.220652@nova.wright.edu>
 <331bf6ce.2832564@news.logica.co.uk> <331C5406.6533@bix.com>
Organization: Logica UK Ltd
Newsgroups: comp.lang.ada
Date: 1997-03-04T00:00:00+00:00
List-Id: <comp.lang.ada>


On Tue, 04 Mar 1997 08:55:34 -0800, Tom Moran <tmoran@bix.com> wrote:

>> I found (exactly the same algorithm)
>> implemented in C took an order of magnitude seconds less to execute
>> than the Ada equivalent. 
>  Was this a byte (or word) lookup or a bit shifting bit-at-a-time
>algorithm?  Ada 83 wasn't real handy with bit shifting.
I am not 100% sure but I think it was a straight forward XOR
algorithm. The problem was not with the actual calculation, but
with the I/O the implementation on the DEC at the time was terrible.
Even reading blocks of data into memory was slower than reading a byte
at a time using C stdio! (There is a LOT of code between a
sequential_io.read and the actual O/S call and significanly less using
the C libs) Also the io routines did not always correctly detect end
of file and I was having to spot it by trapping exceptions.
We took a pragmatic approach, wrote a few interfaces to the C libs, a
few simple C functions and lived it.

Steve Garriga                         garriga@logica.com                 
   type OPINION is access PERSONAL_THOUGHTS_AND_BIAS; 
   OPINION_STATED : new OPINION := not LOGICA.OPINION;
Logica UK Ltd.   +44 171 637 9111   http://www.logica.com