Floating point arithmetic and DLLs

[Merrick]

OK, zooba, maybe I dont get it. Perhaps you can explain it in words...

You say that passing pointers with VB is a pain, then show an example where you apparently do it.
That's exactly the way I do it...

So, is that NOT an example of passing pointers, or what it is so hard about it if it is?

[zooba]

I am horrified if I write something superfluous in ASM. I feel that because ASM is the best language to write in in terms of speed, you should always optimise as much as you can. If I don't feel like optimising, I write in VB.

Maybe, but in any case, simply changing from VB to ASM provides a massive speed increase (ignoring procedure call overhead) because VB is basically an interpreted language. Also, it's not superfluous if it helps you understand it better or it makes it work where another option may not.  :U

You say that passing pointers with VB is a pain, then show an example where you apparently do it.
That's exactly the way I do it...

The difference is, you can't access the memory pointer. That is, you can't add 4 to it and have it point to the next DWORD. VB simply interacts automatically with the memory at the other end. Unlike other languages, you can't force a Long to act as a pointer and you can't display the actual value of the pointer (without using hidden internal functions, VarPtr or StrPtr). This is what I mean by the ByRef process being transparent. As far as the VB programmer is concerned, it's just a variable. The assembly programmer can recognise that it is an address being passed rather than the actual value, but VB doesn't care - you can't work with it as a memory pointer, it is just the value.

[AeroASM]

I am horrified if I write something superfluous in ASM.

it's not superfluous if it helps you understand it better or it makes it work where another option may not.

But where you wrote it, it made it harder to understand and the shorter option would still work.

[zooba]

But where you wrote it, it made it harder to understand and the shorter option would still work.

Obviously it made it easier for me or I wouldn't have written it that way...

[AeroASM]

But what is simpler?

1. "Put a value on the FPU stack"

2. "Get the address of a value, and then put the contents of that address on the FPU stack"

[Merrick]

zooba - thank you. Now I understand what you were talking about. As you say, to work fully within VB with memory pointers you need to use VarPtr, VarPtrArray, etc. - but it won't by you anything. Since I'd started this thread regarding VB and interaction with DLLs, I assumed you were referring to that - not using pointers exclusively within VB.

[zooba]

Glad I could help, Merrick. Feel free to contact me if you want any more info on VB with ASM.

But what is simpler?

1. "Put a value on the FPU stack"

2. "Get the address of a value, and then put the contents of that address on the FPU stack"

This is a totally fruitless discussion which I refuse to participate any further in.

[Merrick]

Maybe this shuold be in a new topic???

The final goal of this DLL is:

I have a 3D array containing 256 images, 200X200 unsigned ints/image (sadly, stored Big Endian) in 128 sets - that is - the first 200X200 array is image information, the second 200X200 array is the background correction information for that image, etc. So, I have one DLL taking the Big Endian array and converting it to a Little Endian array. Then, in a loop in VB, I call the image correction DLL 128 times, passing the starting address of successive data sets to the DLL to be processed one image set at a time. This is pretty straight forward. I intend to put the little/big endian conversion in the same DLL so I can just do one call, but doubt that will save any time (and since I'm making 128 DLL calls for the image processing, so what, right?) What I think WILL save time is if I can process the whole array in one call - which requires nested loops. I tried this a couple of times and had bad results. Can anyone help me track down examples of design with nested loops?

Thanks...