Found a bug in visual studio 2005 beta 2...array access!

[OceanJeff32]

So I've been learning how to debug and create visual programs, but I'm still on a quest to create a 3D Graphics Engine in Assembly...

In trying to compute the length of a vector, I decided to store the vector in an array, instead of separate variables, like I've been doing, because my 1st step was general purpose, then onto mmx.

Take a look at my source code, for the enclosed program, hopefully I've compiled it correctly as release version and it will work on your machine(s).  The debugging session I just had reveals a bug in microsoft's implementation of _asm and array access, I noticed the code only incrementing the pointer, offset, address whatever you call it, but 01h, but it should have noticed the size of the array item was an INT (04h).  So I had to change the array variables to vector[0], then vector[4] for what should have been vector[1], then vector[8] for vector[2]...???

It takes a good programmer to learn how to use a mis-behaving compiler  :wink  I'm sure a lot of you guys have seen things like this before.

I've already reported this bug to microsoft.

later,

jeff c
:U :bdg :lol :red :clap: :dazzled:

[attachment deleted by admin]

[GregL]

It's not a bug Jeff.

C increments or decrements a pointer by the size of the data type, asm does not. Asm increments and decrements a pointer by one byte. For data types larger than a byte you use [base+index*scale].

It's easy to get confused when jumping back and forth between C and asm.

[OceanJeff32]

Take a look at my source code, to access array element #2, you would normally use thisarray[1]

inside the _asm block, I had to use thisarray[4]

(Remember inline assembly breaks all the rules too!)

mov eax, that's definitely
mov ebx, a bug
ret

later,

jeff c
:toothy

what I am curious about now is how many versions have this bug?

[Eóin]

I would say that its "buggyness" could be debated. After all if you were using thisarray[eax] then eax would have to be 4 to access element 1. It makes sense that immediate values would treated the same, otherwise you'd have situations where one each of the following codes would access different locations of the array.

Code Select Expand

mov eax,thisarray[1]

Code Select Expand

mov edx,1
mov eax,thisarray[edx]

Still though I can see your point.

[GregL]

Jeff,

You are thinking you should be able to use the C syntax to access the array in the _asm block, right? Well, you can't. You have to use assembler syntax to access the array in the _asm block.

If the data type is larger than a byte, thisarray[1] in C is not the same as thisarray[1] in the _asm block.

In C you would use thisarray[1] to access the second element, no matter what the data size. C takes the data size into consideration when calculating the pointer (asm does not).

In the _asm block you would use thisarray[4] or [thisarray+4] to access the second DWORD element.

I found this on MSDN: Using C Operators in _asm Blocks


I'm not trying to be an asshole here, just trying explain the point.  :)

[OceanJeff32]

oOOH, <BLUSH>

you guys may be right, well microsoft said they have the 'bug' under review, let's see what they come up with.

you may be right though...never thought of it like that. I thought the _asm block was to spoil us programmers to death...<LOL>

[GregL]

Don't worry about it Jeff, I've banged my head against that one more that once.  :bg

That one page on MSDN is the only documentation I've ever seen on the subject. The documentation on Inline Assembly in Visual C++ is pretty slim.

[OceanJeff32]

Note that you can use the TYPE operator to achieve scaling based on a constant. For example, the following statements are equivalent:

__asm mov array[6 * TYPE int], 0 ; Store 0 at array + 24

array[6] = 0;   

Quote from Microsoft's MSDN online reference.  OOPS, maybe they won't remember putting that in the documentation, and might actually try to fix it...that'd be funny.  :wink

later guys, thanks for the reference,

jeff c
:U

P.S. Maybe this means you should be working at Microsoft.?