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: Michael & Amy Hartsough Subject: Re: CRC in Ada? Date: 1997/03/20 Message-ID: <33320957.B@worldnet.att.net>#1/1 X-Deja-AN: 227214873 References: <1997Mar2.220652@nova.wright.edu> <331bf6ce.2832564@news.logica.co.uk> <332B5EBD.3D9E@worldnet.att.net> <332C9185.61C1@worldnet.att.net> <332F5CC8.6D7C@worldnet.att.net> Organization: AT&T WorldNet Services Newsgroups: comp.lang.ada Date: 1997-03-20T00:00:00+00:00 List-Id: 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