OpenEuphoria

RE: poke4 won't accept my 32bit values

• Posted by Al Getz <Xaxo at aol.com> Mar 20, 2001
• 493 views

Hi Chris,


Sounds like your doing something fundamentally incorrect.
Sometimes in haste we skip over something very simple
because it seems so familiar.

When a problem like this occurs, its usually advisable
to develop a simple test to challenge all the basic
premises.  The results of the test will shed light on the
problem in most cases.

(see simple test routine below also)


In this case it seems all we need to do is
indentify the "universe of possible inputs", and then
determine what part of the universe works, and what part
doesnt.  This often provides enough info to understand
the solution immediately.

In this case you want to see what is being stored with
poke4() because apparently you get an error in that
line?

1. Since you are dealing with 32 bit numbers, the universe
of inputs is simply #00000000 to #FFFFFFFF (hex).

2. Since the error seems to occur with one value and not
another, the next step is to find the "threshold of error".
Some numbers between 0 and #FFFFFFFF  work, while others
cause an error.  Somewhere in between you may reach a single
number that doesnt work, where all numbers after that point
fail, while the others up to that point all work fine, or
you may find a pattern in the numbers that work and those
that dont work.

3. Start with a reasonable number, say #0FFFFFFF and see if that 
works.  Then try #0FFFFFFF + 16 and see if that works.  When you get 
a failure, note the number that it failed at and restart the test 
from that number minus 16 with the increment set to 1 instead of 16. 
When you get a failure again, you should know at least the first 
number it fails at. 
(Of course you use a programmed loop to do the testing, untill a 
failure and then you must restart the test loop with different start 
values.)

This should shed much light on the problem.

A simple test routine might look like this:

----------------------
integer inc
atom n,m
address a

a=allocate(4)

with trace

n=#0FFFFFFF  --starting number 
inc=16       --starting increment

while n<=#FFFFFFFF do
    poke4(a,n)
    m=peek4u(a)
    if m!=n then
      puts(1,"didnt peek the same number!\n")
      ?n
      trace(1)
    end if
    n=n+inc
end while
free(a)

----------------------

Important notes:

1.  Naturally you need to insert this test in the EXACT location
in the file where your error occurs, NOT JUST ANYWHERE.

2.  If your code is being translated, you will have to find the 
appropriate position in the Euphoria file.
If you can modify the translated file, you can always insert
an appropriatly modified version of the test loop above.

3.  If you cant indentify the number n after an error you may
have to print values to a file so that when the error occurs,
you may read the file to see the number.

4.  Of course if that fails on the first n, you need to lower the 
start value of n and possibly increase the initial increment to speed 
up the test.

This kind of test really does help in most situations.  The neat 
thing is, if it turns out to be something else, it usually becomes 
apparent after the test is run.


Good luck with it.
--Al