FB II Compiler







Disk I/O














Made with FB



A lot of the programming I do is just for the fun of it, so to speak. I'll come up with an idea and see if i can implement it. This was the case when I set out to write a generic set of array functions (such as find the element with the max value). Basically these functions take a pointer to an array, the number of elements, the element size and a start and finish number. All of these are long ints (as they must be) to accomodate any array.

I'm not having a problem so much as some curiosity as to why I'm seeing the results that I see.

The function is declared as such:

LOCAL FN findMaxEl& (arr&,numElem&,elemSize&,start&,finish&)

One of my lines of code is this

BLOCKMOVE arr&+(x&*elemSize&),@compare&,elemSize&

Maybe I just keep misusing BLOCKMOVE, but what I think is happening is that BLOCKMOVE is copying elemSize& amount of data from what should be the correct offset in arr& (x& is my for loop counter) into compare&.

To test this I made an array 10 elements long that was filled with ints 1-10 and wrote this:

arrLoc& = @arr(0)
max& = FN findMaxEl&(arrLoc&,9,2,0,9)

(the function doesn't account for starting at zero... it will tho ;)

Everything seems ok at this point. It's not until after I call blockmove that things get odd. Instead of being a 2 byte int (such as the number 1) I get 65536 for the compare& (first time through). Each subsequent loop has a different number, but never is it 2 bytes long. What I see as strange (outside of that) is that every time I run the function (on random sets of data), it picks out the right maxelement. So the numbers are being compared correctly, but not being stored as 2 bytes inside the long int (ie a bunch of zeros and then the int). I would think that, if I set elemSize& to two and then only blockmoved those two bytes the long int would be zeroed (because of the clear local) with two bytes of data moved in.

That doesn't seem to be the case, so what am I missing?

The expression "@compare&" equals the _first_ of the four memory addresses that make up the "compare&" variable. On the Mac, that's the "high-order" byte of compare&.

Here's something analogous to what you're trying:

a% = 1
aPtr& = @a%
BLOCKMOVE aPtr&, @compare&, 2

a% consists of 2 bytes which (in binary) look like this in memory:

00000000 00000001

If you've initialized compare& to zero, then it initially looks like this:

00000000 00000000 00000000 00000000

The BLOCKMOVE tells the system to move the contents of a% into the _leftmost_ two bytes of compare&. After the BLOCKMOVE, compare& looks like this:

00000000 00000001 00000000 00000000

And this indeed evaluates to 65536.

This happens because the Mac is a "big-endian" machine, which means its integers are stored with their most significant byte in their lowest address. On a Pentium (which is "little-endian,") the same experiment probably would have given you a "1" in compare& as you expected.--If Pentium machines were lucky enough to be able to run FutureBasic.