Fortran - Packing multiple integers into one.

Author

Packing multiple integers into one.

wellsed

2004-11-16, 3:56 am

Hello All,

I'm trying to figure out a nice way to pack several integers into the
space of a single integer using Fortran 90. In my application this
makes my most-used derived types fit nicely into processor cachelines.
However, the only way I've been able to do it is rather combersome
and ugly.

Anyone have suggestions?

For example, in C/C++, I've seen the following macro declared (please
forgive obvious typos as I'm not yet proficient in C).:

#define RGB(r,g,b) (r | g << 5 | b << 10);

However, is this portable across different processor architectures
(assuming 32-bit integers)? How could I express this in Fortran?

I'm not familiar with Fortran bit functions, but I'd be happy to hear
other neat tricks to learn them.

Thanks,

Ed Wells
wellsed .at. gmail .dot. com

E. Robert Tisdale

2004-11-16, 3:56 am

wellsed wrote:
>
>
> I'm trying to figure out a nice way to pack several integers into the
> space of a single integer using Fortran 90. In my application this
> makes my most-used derived types fit nicely into processor cachelines.
> However, the only way I've been able to do it is rather combersome
> and ugly.
>
> Anyone have suggestions?
>
> For example, in C/C++, I've seen the following macro declared (please
> forgive obvious typos as I'm not yet proficient in C).:
>
> #define RGB(r,g,b) (r | g << 5 | b << 10);

integer function RGB(r, g, b)
integer r, g, b
RGB = r + 32*g + 1024*b
end function RGB
>
> However, is this portable across different processor architectures
> (assuming 32-bit integers)? How could I express this in Fortran?
>
> I'm not familiar with Fortran bit functions,
> but I'd be happy to hear other neat tricks to learn them.

glen herrmannsfeldt

2004-11-16, 3:56 am

wellsed wrote:

> I'm trying to figure out a nice way to pack several integers into the
> space of a single integer using Fortran 90. In my application this
> makes my most-used derived types fit nicely into processor cachelines.
> However, the only way I've been able to do it is rather combersome
> and ugly.

> For example, in C/C++, I've seen the following macro declared (please
> forgive obvious typos as I'm not yet proficient in C).:

> #define RGB(r,g,b) (r | g << 5 | b << 10);

> However, is this portable across different processor architectures
> (assuming 32-bit integers)? How could I express this in Fortran?

For positive r, g, b, between 0 and 31 it is portable, and the
result will fit in 16 bits. In Fortran this would be

RGB(r,g,b)=(r+g*32+b*1024)

(are statement functions still allowed?)

It can also be done with the ISHFT and IOR functions. Note that
the bit order in memory may not be portable, but as integer values
you can extract the original r, g, and b again portably.

It is somewhat easier to extract them using IAND and ISHFT
instead of divide and MOD, but either will work.

-- glen

James Van Buskirk

2004-11-16, 8:56 am

"wellsed" <wellsed@gmail.com> wrote in message
news:c02349b5.0411152055.65cf18e9@posting.google.com...

> #define RGB(r,g,b) (r | g << 5 | b << 10);

RGB(r,g,b) = ior(ior(r,ishft(g,5)),ishft(b,10))

If you like IBITS and MVBITS:

RGB = IBITS(r,0,5)
CALL MVBITS(g,0,5,RGB,5)
CALL MVBITS(b,0,5,RGB,10)

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Richard E Maine

2004-11-16, 3:57 pm

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> (are statement functions still allowed?)

Yes, though they are on the obsolescent list. But that is
obsolescent - not deleted - so they are still standard-conforming.

Whether they will ever (in the foreseeable future anyway) move from
the obsolescent list to deleted is a question that my crystal ball
is silent on.

(But I don't use them in my own new code.)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

glen herrmannsfeldt

2004-11-16, 6:56 pm

Richard E Maine wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

[color=darkred]
> Yes, though they are on the obsolescent list. But that is
> obsolescent - not deleted - so they are still standard-conforming.

(snip)

> (But I don't use them in my own new code.)

I haven't used them much either, but it just looked right for
the example, which would be done with a preprocessor macro in C.

At least some compilers expand statement functions inline so that
they can be optimized with the rest of the expression.

-- glen

Sponsored Links