From LPMeissner@msn.com Fri Dec 6 20:44:38 1996 Received: from upsmot03.msn.com (upsmot03.msn.com [204.95.110.85]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA00513 for ; Fri, 6 Dec 1996 20:44:35 +0100 Received: from upmajb04.msn.com ([204.95.110.81]) by upsmot03.msn.com (8.6.8.1/Configuration 4) with SMTP id LAA06396; Fri, 6 Dec 1996 11:42:00 -0800 Date: Fri, 6 Dec 96 19:41:45 UT From: "Loren Meissner" Message-Id: To: "Fortran 90 Mailing List" Cc: sc22wg5@dkuug.dk Subject: RE: Summary (So Far) of Bit Type Discussion It seems to me that varying-length bit strings is a separate issue, and that stream I/O is also a separate issue that needs to be addressed anyway, for other things as well as for bits. ================================= If bit data is to be stored in a reasonably compact form, then addressing an individual bit, or a string - with lucky exceptions, will be slow. No matter what form the feature takes, integrating it into the language can make it faster, as Nagel points out. But I can't see that the baggage of creating a whole new Fortran type just for single bits is worth it, when it could be implemented instead as a closely-coupled, well-designed extension of logical data type. Any vendor who RESISTS implementing a 1-bit logical kind, but really WANTS to introduce a new data type for bits, seems to me not to be thinking clearly. Putting a new data type into the Fortran standard would require A LOT of changes. Every page has to be reviewed to see what are the implications of the new type: what is a constant? which intrinsic functions are to be permitted in initialization? what type mixing is permitted in an expression, between bits and other types (logical and integer, presumably - others as well?) Would new edit descriptors be needed? etc. . . . I am not sure it can be done in time for F2000. On the other hand. I think that adding a few intrinsic functions, and perhaps a few other changes, to make packed logical arrays work as (fixed-length, but allocatable) bit strings would be a "minor technical enhancement" that could easily be squeezed into the F2000 workload. ================================= However, I see no harm in preparing a proposal for a separate data type, then looking at the requirements and seeing whether they can be satisfied with a less drastic revision. - Loren Meissner ---------- From: comp-fortran-90-request@mailbase.ac.uk on behalf of Dan Nagle Sent: Friday, December 06, 1996 5:10 AM To: Fortran 90 Mailing List Subject: Summary (So Far) of Bit Type Discussion All, Most respondants so far have asked for a built in type which would handle more-or-less arbitrarily sized strings of bits. To support, I suppose, the experiment/satelite/ whatever which makes data in batches of xxx bits, they'd like to be able to code at a higher level than at present. Those with a compiler writer background have argued against addressing arbitrary bits on the grounds that it will be slow. My reaction is that this argument is really a reason to have the type built-in. The more difficult it is to do something, the more reason to have the compiler do it. Also, I think the "slowness" argument against supporting a bit type is weak on the grounds that, many times anyway, a rather long calculation will set the logical value. There must be many such values due to the size of the overall problem. These values will then be used once further on in another rather long calculation. Thus, the speed of the bit access will not dominate the calculation overall. And reducing the size of the program (or file) may well speed things up. And if not, there's always the default logical type. If one is viewing bit strings, then presumable what happens is that the odd-length bit strings are decoded once, and the calculation proceeds. So again, the relative slowness of the bit manipulation doesn't dominate the speed of the overall calculation. And, in any case, the speed of the bit access will be increased, more than likely, by having the compiler and libraries do it rather than relying on user code. Most folks who sound like Fortran programmers, rather than compiler programmers, and who have responded seem to like the idea and have a list of intrinsic subprograms they want to have included. Most seem to want bit strings modeled after character strings. I don't think we'll see a hard-coding of kind parameters, I think the strategy is to use Selected_???_Kind() to give the kind parameter. Also, I would expect the kind parameters for type logical to match those of the same sized integer kind. I'd settle for the ability to _address_ bits, somehow, and construct the structures as user defined types, some of which might then go on to become standard. But a built-in bit string type, being more general, would also be more useful. I really want to see Fortran somehow get the ability to address bits- I don't like having C++ be able to do something easily which Fortran _can't do well_. It's in the long-term interest of the language not to let this situation fester. I agree that "bit logical" is a pleonasm, I only used the term to distinguish what I was tyring to define from the built in type. Christian Webber (to whom I am forwarding the summary) has asked that he receive the summary by the 8th, German time (I'm East coast USA time). Thus, I'll have to cut the summary off over the weekend. The discussion, of course, may go on forever... Thanks to all who have responded. -- Cheers! Dan Nagle dnagle@erols.com