Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

INT1() and RGB() macro

gelarimer
Beginner
1,384 Views

The following code returns a warning that argsdo not match definition, because definition requireskind 1for args.

iret = RGB(180, 180, 255)

tried the following,

iret = RGB(INT1(180), INT1(180), INT1(255))

but if left most digitis set then INT1() is a negative number.

How is an unsigned 1 byte value of 255 represented in FORTRAN?

Thanks for any info.

0 Kudos
6 Replies
jimdempseyatthecove
Honored Contributor III
1,384 Views

FORTRAN does not have unsigned integers. The values above unsigned int 128 are negative when represented as integer(1).

255 = -1, 254= -2, ... 128 = -128

One method you can consider to use is to create function like the following

INT1 function asINT1(I)
! calling arg
integer :: I
! local arg to avoid saturation
integer ::Imasked
! force modular 256
Imasked = IAND(I,255)
if(Imasked .ge. 128) then
asINT1 = INT1(256 - Imasked)
else
asINT1 = INT1(Imasked)
endif
end function asINT1

If you are certain that the input arg is always within 0 to 255 then you can remove the masking. If you do this then for the Debug configuration have conditional code insert an assertion to confirm this.

Jim Dempsey

0 Kudos
Jugoslav_Dujic
Valued Contributor II
1,384 Views
...in other words, RGB function as implemented in IFWIN.lib is broken and next to unusable if it has INTEGER(1) arguments; maybe it's translated from C without much thought.

You can roll your own statement or real function with integer(4) arguments, like:

RGB(R, G, B) = MIN(R, 255) + ISHFT(MIN(G, 255), 8) + ISHFT(MIN(B, 255), 16)

...or, simpler still, use Z'BBGGRR' hex notation.
0 Kudos
Steven_L_Intel1
Employee
1,384 Views
The real problem is that CVF ignored KIND differences in the presence of an explicit interface and ifort does not (CVF's behavior was a bug.) Unfortunately, there's a lot of code that depended on the laxness and the uses of RGB is one of them. I have a request in to solve this in various ways, including making RGB a generic and adding a UINT intrinsic.
0 Kudos
Steven_L_Intel1
Employee
1,384 Views

Try this, using RGBX instead of RGB:

module rgbmod

implicit none

interface RGBX

function RGB1 (red, green, blue)
integer(4) :: RGB1
!DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'Rgb' :: RGB1
INTEGER(1)  red
INTEGER(1)  green
INTEGER(1)  blue
end function RGB1

function RGB2 (red, green, blue)
integer(4) :: RGB2
!DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'Rgb' :: RGB2
INTEGER(2)  red
INTEGER(2)  green
INTEGER(2)  blue
end function RGB2

function RGB4 (red, green, blue)
integer(4) :: RGB4
!DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'Rgb' :: RGB4
INTEGER(4)  red
INTEGER(4)  green
INTEGER(4)  blue
end function RGB4

end interface RGBX

end module rgbmod
0 Kudos
gelarimer
Beginner
1,384 Views
Thanks for all the replies.Very helpful code and comments.
0 Kudos
Steven_L_Intel1
Employee
1,384 Views
I fixed the code I posted - RGB returns an INTEGER(4) not INTEGER(1). Sorry for the mixup.
0 Kudos
Reply