Re: CRC in Ada?

[Michael & Amy Hartsough <Hartsough@worldnet.att.net>]

Robert Dewar wrote:
> No, you felt compelled to *misuse* an Ada 83 I/O package and write highly

I totally disagree with your use of the term "misuse" here. The only other
Ada 83 I/O package that can possibly be used to read a binary file is Direct I/O. 
You "use" what you have available.

> OK, if you lacked the knowledge to write
> the trivial pragma Import for the appropriate C routine (I assume this
> if it would have taken you half a day), then you may have been stuck, and
> generating this solution may have been the best you could do.

And of course THIS statement is TOTALLY off-base. I was writing import
pragmas for FORTRAN routines back in the 80s.

What WOULD have taken a half a day was locating the desired C routines,
locating a C compiler (no, there are no C compilers on our LAN. I work for
a Dod Contractor, and because of THE mandate, there's no reason to have C
compilers lying around), then compiling the routines to get the .obj files,
then searching through my Ada compiler's documentation to figure out how
to link those .obj files into my Ada executable.

You see, I HAVE written import pragmas.  ;^)

> But it was NOT the right solution in Ada, since it did not meet the spec
> of the problem except by accident.

The "spec" of the problem was to implement CRC32 in Ada 83. All other
considerations were secondary. One of those secondary considerations was
to read bytes from a file. Using Sequential_IO was the ONLY solution
in Ada. True, I COULD have gone out of my way to code up some overblown
contrivance that would have provided more efficient file I/O (and appeased
Robert Dewar), but as this was essentially throwaway code (the file I/O
portion), it would have been a complete waste of my time.

> You cannot expect to do everything in Ada.

That's an easy thing to say if you're not developing software for the DoD.
My manager HATES writing waivers.

And besides, I DO expect to do everything in Ada.

> Suppose I tell you to write an Ada program that plays a tune on the
> speaker.
>
> You have around a C callable routine called Play_Tune that does exactly
> what you want, but instead you write a hairy piece of Ada that uses
> address clauses to directly address the memory mapped IO port for the
> speaker, and write loops with the right frequencies to play the tune.

The fallacy of your argument (in this case) is that you assume
that I have these C routines lying around, as well as a C compiler I
can compile them with. I don't. I would have to go far out of my
way to acquire these things. Maybe things are different in commercial
shops and ivory towers...

Anyway, this sounds like a lot of fun. I've written similar routines to
drive a videodisc player from a PC. These weren't so horrible. Besides,
once I write them, I have them forever. No need to carry around the excess
baggage of a bunch of C routines and their .obj files, or having to
remember to include them in my link command.

And, since we ARE talking about Ada 83 here, not all Ada 83 compilers are
compatible with all C compilers. If I change Ada 83 compilers, I may well have
to change C compilers too. Where's my portability now? If I had a 100% Ada
solution, I might have a good shot at portability. But now you're telling me
I have to have cross-language portability as well. Now, I really don't know
C all that well, but I have heard reports that it's not particularly
noted for its portability.

> It would not surprise me at all if the
> difference you see, a factor of 30, has nothing at all to do with buffering,
> but rather is a natural consequence of the implementation approach for
> sequential_IO, which is undoubtedly written to be reasonable for correct
> use of the package, and which may well be slow for this clear misuse.

My vendor stated that sequential_io flushes the read buffer prior to each
read. So regardless of whether I was reading bytes or reading records, it
would have been extremely slow.

> Just to get a bit of a feel for what I mean by sequential_IO being at
> a different level of abstraction from the C getchar
> :
> : snip snip
> :
> Does this mean that sequentio_Io is less efficient than the C routine,
> no! It means that they are doing different kinds of things.

No need to explain. This is understood. I was not surprised that there
was a difference in the execution speed. I WAS surprised by the
magnitude of the difference.

It should not take 20 minutes to read an 8mb file on a 166MHz pentium PC.
Even if one IS "misusing" sequential_io!

Later,
	Michael