| James Van Buskirk 2005-12-16, 9:58 pm |
| "Steven G. Kargl" <kargl@troutmask.apl.washington.edu> wrote in message
news:dnvkev$tvn$1@gnus01.u.washington.edu...
> Then, any implemention that returns -1 is nonconforming via 13.7:
Ah, Richard is just right in this thread. And I say this not as
a yes-man but as one who has long-standing differences of opinion
with Richard on some issues. The bitwise logical and shift
intrinsics manipulate integers as though they were buckets of bits,
but at the end the processor has to put some kind of interpretation
on the resulting bucket and the standard specifies that the
interpretation is one of a signed integer.
The fact that the standard always specifies sign extension is
an annoyance to those of us who like the bucket of bits model
of integers, and the only way to work within the standard is
to use an IAND to pick out the low byte/word/dword:
PROGRAM p
INTEGER(KIND=4) :: A
INTEGER(KIND=8) :: B
INTEGER(KIND(B)) :: mask
DATA mask /Z'FFFFFFFF'/
PRINT *, BIT_SIZE(A), BIT_SIZE(B), BIT_SIZE(0)
A = NOT(0)
B = IAND(INT(NOT(0),KIND(B)),mask)
PRINT *, A, B
END PROGRAM p
Output with g95 (gcc version 4.0.2 (g95!) Dec 7 2005)
32 64 32
-1 4294967295
The above code seems like it requires extra operations
for the zero extension, but ISTR that CVF used to be
smart enough that it would detect that the mask variable
remained unchanged and would interpret the IAND as a
zero-extension request, and would be smart enough to
convert into ZAP or ZAPNOT instructions for other
suitable constants. The thing it was deficient at
was ISHFT(x,-IAND(A,31)), or in a 64-bit context,
ISHFT(y,-IAND(B,63_8)).
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|