I am rewriting some old codes from the 1970s and 1980s that pack/unpack and move bits around. Back then, none of the bit operators that we used were standard, so we have typically 5-10 #if blocks of conditional code to handle all of the compiler-specific versions. We sometimes use EQUIVALENCE with L…

[image] FortranFan: bit32_to_64() I notice in the bit32_to_64() function that there is a loop over the individual bits. Is that really the best that can be done with fortran? I would expect that to be a factor of 50 to 100 times slower than a solution that copies all the bits at once in a sin…

[image] RonShepard: … I notice in the bit32_to_64() function that there is a loop over the individual bits. Is that really the best that can be done with fortran? … The same post referenced with the quoted comment above also shows one other option that does not involve a loop, why are you not…

[image] FortranFan: The same post referenced with the quoted comment above also shows one other option that does not involve a loop, why are you not taking a look at that? Yes, I did notice that. I’m already doing something similar with c_loc() and c_f_pointer() to simulate the legacy type pu…

[image] RonShepard: However, with this approach, there is still the big/little-endian addressing problem that arises when changing KINDs, right? Well, if you have a big-endian machine, try out the code and adapt it as needed. At this point, it ain’t a discourse, damn it - it’s just do it! H…

Re: “The solution proposed upstream with Fortran OOP feature is overkill to say the least” - Not in the least. The solution proposal using the custom type (say bitbucket_t) once tailored to the needs of OP and used properly will help as follows: no need for unpacking and the consumer can avoid a…

[image] FortranFan: The solution proposal using the custom type (say bitbucket_t) once tailored to the needs of OP and used properly will help So the point here about a custom type and tailoring it to the needs is that the solution proposal can easily be adapted to be generic. Then if OP want…

Duh!, bit32_to_64 is not part of the custom type approach with bitbucket_t suggested upthread, the one being termed “Fortran OOP solution proposal”. bit32_to_64 was mentioned upthread earlier and a variant was indicated by @RonShepard with a question along the lines of whether that was the best For…

[image] RonShepard: call mvbits( int(i32,int64), 0, 32, i64, ipos ) should do the trick. That works for positive i32 values, but that doesn’t work when the sign bit is set. Why would it not work for negative values? int(i32,kind=int64) replicates the MSBit of i32 as a sign bit but this onl…

[image] FortranFan: type(bitbucket_t) :: bucket .. bucket%hi() = int(z'01020304', int32) ! store the source integer bucket%lo() = int(z'05060708', int32) ! store the source integer The left-hand side pointer expression does make this code a bit surprising. It took me a while to…

Moving Bits Question

Help

FedericoPerini November 25, 2022, 3:43pm 10

I agree with your observations, a derived type would be spot on if Fortran allowed an access operator like discussed here, that apparently not many care about…

Topic		Replies	Views
Transferring bits with different integer KINDs Help	18	492	May 20, 2026
BITS type in F202Y Language enhancement	27	1750	August 7, 2023
-fallow-argument-mismatch Uncategorized	76	5049	December 20, 2022
Fortran 2023 standard Help	153	9998	January 9, 2024
Should these various ways of converting anything to an array of bytes not produce the same answer? Help	13	603	January 19, 2023

Moving Bits Question

Related topics