Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Strange behaviour with memory pointer calculation (*solved*)
#4
Thanks, boriel - it's much appreciated as always.

This one behaves better than 1.6.2, but I'm still having trouble with the other part of my calculation - I revised the test program to show this by adding a few extra lines:

Code:
dim n, b, c as ubyte
dim x as uinteger
declare sub start()

start()

UDGS:
asm
defb 255,255,255,255,255,255,255,255
end asm

sub start()

    cls
    print "@UDGS = ";@UDGS
    print "@UDGS/256 = ";(@UDGS/256)
    print "int(@UDGS/256) = ";int(@UDGS/256)
    print "@UDGS-((int(@UDGS/256))*256) = ";@UDGS-((int(@UDGS/256))*256)
    b=int(@UDGS/256)
    c=@UDGS-((int(@UDGS/256))*256)
    print "b = ";b
    print "c = ";c
    
    print
    
    x=@UDGS
    print "x = ";x
    print "x/256 = ";(x/256)
    print "int(x/256) = ";int(x/256)
    print "x-((int(x/256))*256) = ";x-((int(x/256))*256)
    b=int(x/256)
    c=x-((int(x/256))*256)
    print "b = ";b
    print "c = ";c
    
end sub

The (slightly dodgy, please forgive me - I was trying to do the whole thing in one line) code to calculate the high and low byte values for the UDG pointer is now getting one of the two values right but the other one is still wrong unless I assign the memory pointer to a variable first.

When I run the new test the value of @UDGS is 24601, so I would expect the values of b and c to be 96 and 25 respectively. Looking at the second set of results (where I assign @UDGS to the variable 'x' first) you can see this is what I get. But on the first set of results where I do the calculations with @UDGS directly the 'c' calculation results in '24576' rather than '25', so the byte value becomes '0'.

Sorry if this is a bit of a pain - I realise I could just adjust the code and avoid the issue entirely but I'm not sure how likely it is that the problem will appear elsewhere... Sad
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)