A Curious Error using Select/Case with Greater Than/Equals

Jon Chandler · Post by **Jon Chandler** » Fri Dec 28, 2012 1:00 pm

I'm making progress with my 7-segment LED routines but I had an interesting failure when using Select/Case with a greater than/equal test.

Code: Select all

 '       Case >= 1000000     '7 digits
        Case > 999999     '7 digits
            LED_Data = num/1000000
            LED_Reg = 2
            WriteLED

Here's a snippet showing the error. When the first line ( commented out here) was used, when the value was 1000000, which is the "equals" case, then test would fail.

When the line was modified as shown by the second line to just test the "greater than" case, 1000000 does satisfy the test.

The values are all integers ( not floats) so it's not a case of rounding error or "close enough".

This causes a very strange error in parsing the data. Instead of being a 1 for the current digit, a number like 1000000 becomes a 10 for the next digit, and a 10 is the value for a negative sign in the decode mode on the As1106 / MAX7219. This error took a while to track down!

Jerry Messina · Post by **Jerry Messina** » Fri Dec 28, 2012 3:58 pm

Probably something a little more subtle going on than meets the eye.

I just tried this with the SwordfishSE version, and it worked ok.

Code: Select all

dim lw as longword
dim b as byte

lw = 1000000

select (lw)
    case >= 1000000
        b = 6              // executes this case
    case >= 100000
        b = 5
    case >= 10000
        b = 4
    else
        b = 0
end select

Jon Chandler · Post by **Jon Chandler** » Fri Dec 28, 2012 4:21 pm

Thanks for taking a look Jerry. I can't think of what might be causing the problem but the same thing happened for the entire series of tests (I.e., 1, 10, 100, etc.). The small change fixes it in any case.

Jon Chandler · Post by **Jon Chandler** » Fri Dec 28, 2012 4:27 pm

Hmmmm... I'm actually using a LongInt so that I can (eventually) handle negative numbers as well. I'll have to look at that and see if it makes a difference.

Jerry Messina · Post by **Jerry Messina** » Fri Dec 28, 2012 4:34 pm

After your comment, I took a look at what happens of you use signed integers (I tried unsigned longwords in that first test). It fails...

Code: Select all

dim li as longint
dim b as byte

li = 1000000

select (li)
    case >= 1000000
        b = 6             // this case NOT executed with signed ints
    case >= 100000
        b = 5
    case >= 10000
        b = 4
    else
        b = 0
end select

Jon Chandler · Post by **Jon Chandler** » Fri Dec 28, 2012 4:42 pm

Thanks for verifying my results Jerry. Sorry I forgot to mention I'm using signed integers.

David Barker · Post by **David Barker** » Sat Dec 29, 2012 10:05 am

I'll take a look after the holidays...

Jon Chandler · Post by **Jon Chandler** » Sat Dec 29, 2012 11:15 am

David Barker wrote:I'll take a look after the holidays...

Thanks David.

Jerry Messina · Post by **Jerry Messina** » Sun Jan 20, 2013 4:13 pm

Was there ever a resolution to this?

If I'm looking at the asm code correctly, it seems that when you use longints the code for the CASE comparison literal is off by 1.

Doesn't seem to do this for unsigned types or integers.

David Barker · Post by **David Barker** » Sun Jan 20, 2013 4:17 pm

It's on my to do list to take a look, honestly! But thanks for bumping the topic...

Jon Chandler · Post by **Jon Chandler** » Sun Jan 20, 2013 5:09 pm

Thank you Jerry for bumping this and thanks for looking at it David.

I discovered another interesting feature the other day. I had a hyphen in an include module name, something like "my module-new" with the file name "my module-new.bas" I don't remember the exact order...if I attempted to compile the module first or the calling program first but things just didn't work. After a couple attempts, on a hunch I changed the hyphen to an underscore and things worked normally. My thought is that the hyphen was interpreted as a compiler directive? I don't recall seeing a prohibition against this. I can recreate it to detail the exact sequence if this isn't a recognized behavior.

David Barker · Post by **David Barker** » Sun Jan 20, 2013 8:09 pm

A module name has the same rules as variable names etc, so a minus symbol or space is not a legal character. You should use underscores like you would a variable.