forums.silverfrost.com

[sparge]

Have been making some use of these functions recently. Was doing OK until today when I started messing around with trying to store and extract bit patterns and they seem to be coming out the other way round when I extract them. Was assuming that IBITS would extract "in the direction of decreasing significance". FTN95 manual talks about how the result is based on right-shifting of the pattern. Other compiler documentations say things like "bit positions number from right to left" and even underline it, to emphasize how important it is to get it right. As I am finding. But what is "right to left" supposed to mean in the context of memory, when individual bytes are displayed in reverse order and back to front? Oh yes, and another thing, saying that the function extracts LEN bytes starting at position POS is all very well, but is POS inclusive or non-inclusive?

Aaaaargggh ...

[IanLambley]

This might help

[sparge]

Thank you! It might have helped, hours ago I still can't get my head around it though. The convention you refer to makes perfect sense, but then the convention for indexing the bits is back to front (31 to 0 reading from left to right) ... so with IBITS and MVBITS, which work with LEN bits starting from position POS, position N ought to be "from the right" but it's from the left. It's not the bit index. So stuff has to get written out back to front, because IBSET, IBCLR, BTEST etc are based on bit index.

I got my thing to work in the end but only by dint of writing something out on paper, pressing heavily, and then turning it over and holding it up to the light . Think I must have my stupid head on today.

My only consolation is that I seem to have discovered a (somewhat academic) bug, in the function IBITS ...

INTEGER FUNCTION IBITS (I, POS, LEN)

This returns LEN bits from integer I starting at position POS, right-shifted and padded with remaining bits off. So I would expect (not that anyone would do it, it's pointless unless one is wrestling to understand something, like I was) that:

J = IBITS (I, 0, 32)

should return I. But it doesn't - it returns 0. It does what I expect for all values of the third argument from 0 to 31 inclusive, though ...

Cheers,

Andy

[IanLambley]

Andy,
From right to left is the convention irrespective of the base of the number system. In decimal, the right hand position contains the count of values which are 10^0, i.e. the 1s; the next position to the left contains the count of values which are 10^2, i.e. the 10s.

In binary, the are in the order of:
2^31, 2^30 ..........2^3, 2^2, 2^1, 2^0
or for the right most 8 columns, these denote the existence of values of
128, 64, 32, 16, 8, 4, 2, 1

Therefore, the index position is simply the power to which 2 is raised for that bit position.

To account for positive and negative numbers, the left most bit denotes the sign and the remainder denote the magnitude and a "twos-complement" method is used.
That is the "ones-complement" plus 1 - a bit of a tongue in cheek name!
For example, using a single byte (signed), the value for 7 in binary is:
00000111
and minus 7 is obtained by first reversing the bits to give the "ones-compliment", that is
11111000
and adding 1 to give
11111001

Check this by adding 7 in binary and performing the necessary carries giving:
11111001 +
00000111
-----------
00000000

So a 1 in the fist bit denotes a negative, and a zero denotes a positive (or zero).
0 = 00000000
+1 = 00000001
-1 = 11111111

and the ibits function probably will only work up to 31, because for a 4byte integer, whilst there are 32 bits, these are numbered from 0 to 31 and 32 does not exist. Try using an integer*8 variable with the bit range of 0 to 63 and remember that the highest indexed bit is the sign bit.

Ian

[sparge]

I don't see your logic. Bit patterns are independent of their interpretation as integers, +ve or negative, or anything else for that matter - they're just patterns.

[IanLambley]

The bits are numbered from 0 to 31 and it is these numbers that are being referred to in the function.

The problem of where a number system starts; zero or one, has caused difficulties throughout history. I believe the Babylonians did not originally have a character for zero and were a bit stuck for a while when one of their digit positions was not in the range 1 to 10 or 1 to 6 depending on the digit position. This was eventually solved by using a particular digit turned on its side in that digit position to denote a missing or zero digit.

The Venrable Bede also avoided the use of the year zero when he popularised the AD year numbering system in 731. (He lived just around the corner from me and, as a lad, I went to Bede School). Hence 1BC and 1AD are adjacent years!

Of course, something we havn't tried yet is referfing to digits greater than 31 in an integer*4 array. I must try that sometime.

I think that:
T = IBITS (S, 0, 0) should transfer the least significant bit of S into T with bits 1 to 31 of T being set to zero.
T = IBITS (S, 0, 1) the two least significant bits of S are moved to T with bits 2 to 31 of T being set to zero.
T = IBITS (S, 0, 32) If S is not an array, I would hope that this would give an error, if it does not, then there would be an attempt to transfer 33 bits from S, which only contains 32, to T and the 33rd bit (called bit 32) would be lost. it is possible that if a check on the length of the input value "S" is not made, then an attempt would be made to transfer data from the next variable in storage which it may assume to be the second element in an array. If T=IBITS(S,1,32) were used, this may pick up 32 bits starting at the second bit of S and overflowing into the first bit of the next byte in storage and would be like not applying bounds checking to arrays. I remember my boss at work many years ago who wrote a program in an antique language called "Telcomp" otherwise known as ICL "Jean" or DEC "Focal" in which he had two arrays A(100),B(100) and he accessed A(101) which was actually B(1). In doing so, he accidently improved the convergence of his algorithm. When I converted it to Fortran, it just didn't work.

I hope this helps.

Regards
Ian

[sparge]

[Sebastian]

Did you check what happens with negative values for I? As INTEGER is signed and (in the *4 default case) has 31 significant digits and maybe this function does something special with respect to the sign (always-keep or whatever).

[sparge]

[IanLambley]

Modification to my test program:

[IanLambley]

Perhaps the ISO standard for Fortran (ISO/IEC 1539-1) will clarify the situation.