- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Other languages offer direct support for bit data type, why not your next fortran?
Its my understanding to do so with declaration like above do not comprise an extension, just a filling out of what the standard allows for vendor implementations of these existing data types..
An alias like BIT for INTEGER(0) similiar to BYTE for
INTEGER(1) could also be considered..
If implemented, would this be first-ever for any Fortran compiler, (something to consider in its press release)
Its my understanding to do so with declaration like above do not comprise an extension, just a filling out of what the standard allows for vendor implementations of these existing data types..
An alias like BIT for INTEGER(0) similiar to BYTE for
INTEGER(1) could also be considered..
If implemented, would this be first-ever for any Fortran compiler, (something to consider in its press release)
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using a single bit for an INTEGER type would violate the standard's definition of a model integer. A single-bit LOGICAL type could be used, but it would require some major rework in the compiler to have it support a LOGICAL type that was not some multiple of bytes.
The era of vendors filling their compilers with unique extensions is gone - that's not what most customers want anymore. Fortran has standard bit-manipulation features that are actually more useful than a LOGICAL bit type would be, considering that one might want a 2-bit field, 5-bit field, etc. With LOGICAL, you're restricted to operators such as .AND., .EQV., etc. Extended intrinsics such as LEADZ, TRAILZ and POPCNT are already widely accepted.
Steve
The era of vendors filling their compilers with unique extensions is gone - that's not what most customers want anymore. Fortran has standard bit-manipulation features that are actually more useful than a LOGICAL bit type would be, considering that one might want a 2-bit field, 5-bit field, etc. With LOGICAL, you're restricted to operators such as .AND., .EQV., etc. Extended intrinsics such as LEADZ, TRAILZ and POPCNT are already widely accepted.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Considering the number of earlier vintage compilers it would be very surprising if this would be a "first". Back in 76 I had a colleague, who had a relation who worked with a compiler which allowed them to use a 2-dimensional array of single-bit logicals to fit a large image within the space available. They would have been interested in things like counting the number of contiguous blocks of a given size with all-off or all-on. They obviously did most of the programming themselves rather than having compiler-functions available. However they were pleased not to have to do the extra addressing steps involved in first finding the right word and then the right bit to look at for each array element.
Obviously this was a somewhat specialised case. While there have been a number of recent postings relating to the sizes of arrays that can be used within CVF, I doubt if any of these were applications where making better use of unused bits within byte-based arrays would be relevant.
Notionally, if there were a substantial demand for this type of feature, it should have reached the standards committee.
David Jones
Obviously this was a somewhat specialised case. While there have been a number of recent postings relating to the sizes of arrays that can be used within CVF, I doubt if any of these were applications where making better use of unused bits within byte-based arrays would be relevant.
Notionally, if there were a substantial demand for this type of feature, it should have reached the standards committee.
David Jones

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page