Nibbles, bit operations and C dll's [RESOLVED]

Quote:

---

Originally Posted by krtxmrtz

I have to make sure what exactly the error was but at the moment I'm sitting in front of a computer where VC++ is not installed. think it was something like "It was not possible to add a reference to this library" when I tried to add the reference in the VB project/references menu.

---

But you're not making an ActiveX DLL so you will not be able to set a reference to it. What you're making is a standard DLL file so you will need to use a Declare statement just as with API calls.

Quote:

---

Originally Posted by Joacim Andersson

But you're not making an ActiveX DLL so you will not be able to set a reference to it. What you're making is a standard DLL file so you will need to use a Declare statement just as with API calls.

---

Of course, thank you. Very obviously I'm quite new to this jungle. I just can't wait till I go back home and try it!

How about the def file thing? Do you know if I can add it as a cpp source code file although it's a text file?

By the way, is it mandatory to place the dll in windows/system? Could I have it in the app directory or elsewhere?

Quote:

---

Originally Posted by krtxmrtz

How about the def file thing? Do you know if I can add it as a cpp source code file although it's a text file?

---

I don't understand. Did you add the file by clicking Project > Add To Project > Files or did you use File > New? You should use the first option, you can then select to add a definition file by selecting the correct item in the "Files of type" drop down of the Open dialog box.

It doesn't matter where you put the DLL file, however if it's not in the System folder or in the application folder you must specify the path of it in the Declare statement in VB.

Quote:

---

Originally Posted by Joacim Andersson

Did you add the file by clicking Project > Add To Project > Files or did you use File > New? You should use the first option, you can then select to add a definition file by selecting the correct item in the "Files of type" drop down of the Open dialog box.

---

I don't remember how I did it but from what you say I probably used the second option. I'll check it out this evening.
Thanks for being so patient with my clumsy attempts :)

You don't need to add a reference, just declare it as I showed you above

Oh... I see this question has been answered.

I may be going too fast as I haven't had a chance yet to check whether "the magic" works, but I've just thought of another question: can I pass a control to a procedure in a c++ dll? The idea is I have a program that plots on a picturebox according to a complicated algorithm and the result is the plot takes about 10 s. to complete. maybe I could speed that up if I could call a C sub from VB.

Pass the hDC of the PictureBox instead.

Quote:

---

Originally Posted by krtxmrtz

I may be going too fast as I haven't had a chance yet to check whether "the magic" works, but I've just thought of another question: can I pass a control to a procedure in a c++ dll? The idea is I have a program that plots on a picturebox according to a complicated algorithm and the result is the plot takes about 10 s. to complete. maybe I could speed that up if I could call a C sub from VB.

---

Probably, but you would hve to know MFC. I think you can pass an HANDLE around which is a window handle.

Quote:

---

Originally Posted by Joacim Andersson

Pass the hDC of the PictureBox instead.

---

OK, but then how about plotting? I mean, the line method, scale and all that stuff.

Quote:

---

Originally Posted by krtxmrtz

OK, but then how about plotting? I mean, the line method, scale and all that stuff.

---

They don't exist in C/C++ anyway, you would need to use the GDI APIs to draw on the picbox. Like MoveToEx() to move to a particular point and then use LineTo() to draw a line.

Quote:

---

Originally Posted by Joacim Andersson

They don't exist in C/C++ anyway, you would need to use the GDI APIs to draw on the picbox. Like MoveToEx() to move to a particular point and then use LineTo() to draw a line.

---

That's more or less what I expected. But I think it's enough for now and maybe I should keep from thinking big before I can handle the simplest things.

Quote:

---

Originally Posted by krtxmrtz

That's more or less what I expected. But I think it's enough for now and maybe I should keep from thinking big before I can handle the simplest things.

---

While you should not always implement for performance, you should plan for performance. Eventually you may really need to plot with a faster platform than VB. However there seems to be a performance boundary line, allowing you to break the performance responsibilities into 2 functions without sacrificing overall performance:

1) Create a C-DLL for string parsing, and do your plotting in VB
2) If the plotting is painfuilly slow, keep the C-DLL for string parsing and then work on an MFC-DLL for plotting.

In the end you can keep both functions seperate without trying to mix them both into the same DLL.

I don't think you would gain very much by moving the graphic plotting to a C DLL. The built in VB graphic functions are extremly slow but you can use all GDI functions from VB instead. They won't run much faster in a C application compared to a VB application, all you add is one more API call (the one to your own DLL).

Quote:

---

Originally Posted by moeur

If you need help translating the magic I can help too.

---

Well, I'm stuck so after all I'm afraid I do badly need help.

It appears that my code is faulty for it returns all values of Val12bit
as well as that of Max12bit as 0. This is what I've done:

In VB:

Private Declare Sub ProcessData Lib "Mydll.dll" (DataByte As Byte, _
Val12bit As Long, _
ByVal Max12bit As Long, _
ByVal BufferSize As Long)

The C code according to your template:

Code:

---

#include <stdio.h>
#include <math.h>
#include <stdlib.h>

__declspec( dllexport ) void _stdcall ProcessData (char DataByte[][3],
short Val12bit[], long Max12bit,long BufferSize)

{

        /* WELL, I'VE JUST REALIZED i and j should be long.
        Could that alone explain it? (I can't test it at the moment) */
        int i;
        int j;
       
        Max12bit=0;
        for (i=0;i<=BufferSize;i++)
                j=2*i;
                Val12bit[j] = (DataByte[i][2] & 240) * 16 | DataByte[i][0];
                Val12bit[j + 1] = (DataByte[i][2] & 15) * 256 | DataByte[i][1];
        if (Max12bit < Val12bit[j])
                        Max12bit = Val12bit[j];
        if (Max12bit < Val12bit[j + 1])
                        Max12bit = Val12bit[j + 1];               
        return;
}

---

Quote:

---

Originally Posted by krtxmrtz

Well, I'm stuck so after all I'm afraid I do badly need help.

Code:

---


        /* WELL, I'VE JUST REALIZED i and j should be long.
        Could that alone explain it? (I can't test it at the moment) */
        int i;
        int j;

---

---

I've rebuilt the dll after changing these to long and... oh no, it wasn't that, integer i and j didn't account for the returned 0 values. Help!

First of all there is an error in your declaration, should be

Code:

---

__declspec( dllexport ) void _stdcall ProcessData (char DataByte[][3],
short Val12bit[], long* Max12bit, long BufferSize)

{

        int i;
        int j;
       
        *Max12bit=0;

        for (i=0;i<=BufferSize;i++)
                j=2*i;
                Val12bit[j] = (DataByte[i][2] & 240) * 16 | DataByte[i][0];
                Val12bit[j + 1] = (DataByte[i][2] & 15) * 256 | DataByte[i][1];
        if (*Max12bit < Val12bit[j])
                        *Max12bit = Val12bit[j];
        if (*Max12bit < Val12bit[j + 1])
                        *Max12bit = Val12bit[j + 1];               
        return;
}

---

Show me how you're dimensioning your arrays and calling the routine from VB.
Should be

VB Code:

Private Declare Sub ProcessData Lib "MyDll.dll" ( _
  DataByte As Byte, _
  Val12bit As Integer, _
  Max12bit As Long, _
  ByVal BufferSize As Long _
)

and something like

VB Code:

Dim DataByte(0 To 3, 0 To 100) As Byte
Dim Val12bit(0 To 100) As Integer
Dim Max12bit As Long
Dim BufferSize As Long
BufferSize = 100

And call it like

VB Code:

Call ProcessData(DataByte(0, 0), Val12bit(0), Max12bit, BufferSize)

Quote:

---

Originally Posted by moeur

Show me how you're dimensioning your arrays and calling the routine from VB.

---

VB Code:

'These are my declarations:
 
Private Declare Sub ProcessData Lib "Mydll.dll" (DataByte As Byte, _
Val12bit As Integer, _
Max12bit As Integer, _
ByVal BufferSize As Long)
 
'Data declarations:
 
Dim Max12bit As Integer
Dim DiskData() As Byte
Dim Val12bit() As Integer
 
'Calling of dll code:
 
    Dim BufferSize As Long
    'dsize is the size of the data area in the file
    'i.e. dsize = filesize - headersize
 
    BufferSize = 2 * dSize \ 3 
 
    ReDim Val12bit(BufferSize )
 
    Call ProcessData(DiskData(0, 0), Val12bit(0), Max12bit, BufferSize)

This however produces an error (see figure):

Shouldn't it be?

VB Code:

ReDim Val12bit(2*BufferSize )

Since in your C code,
i goes from 0 to Buffersize-1 and j=2*i

Besides the fact pointed out by moeur above there is also a logical error in your C code. The for loop should use the curly brackets...

Code:

---

for (i=0; i<BufferSize; i++) {
    j=2*i;
    //... the rest of the code
}
return;

---

Quote:

---

Originally Posted by Joacim Andersson

Besides the fact pointed out by moeur above there is also a logical error in your C code. The for loop should use the curly brackets...

Code:

---

for (i=0; i<BufferSize; i++) {
    j=2*i;
    //... the rest of the code
}
return;

---

---

You're right, the brackets were missing... it's been so long since I was fluent in C...

Quote:

---

Originally Posted by moeur

Shouldn't it be?

VB Code:

ReDim Val12bit(2*BufferSize )

Since in your C code,
i goes from 0 to Buffersize-1 and j=2*i

---

Actually it was the other way round:

BufferSize = dsize\3 and not 2*dsize\3

I don't get any errors now, but the Val12bit values calculated in the dll are wrong because some of them come out negative. Maybe the variable type is not correct and it should be "unsigned" or something...?

But we're getting close.

I don't remember the order, but isn't a bit wise operation evaluated before a multiplication in C? If so then this code is wrong:

Code:

---

Val12bit[j] = (DataByte[i][2] & 240) * 16 | DataByte[i][0];
Val12bit[j + 1] = (DataByte[i][2] & 15) * 256 | DataByte[i][1];

---

To me it looks like you, on the first line, multiply with 16 | DataByte[i][0] which is not what you want to do. Try this:

Code:

---

Val12bit[j] = ((DataByte[i][2] & 240) * 16) | DataByte[i][0];
Val12bit[j + 1] = ((DataByte[i][2] & 15) * 256) | DataByte[i][1];

---

Quote:

---

Originally Posted by Joacim Andersson

Besides the fact pointed out by moeur above there is also a logical error in your C code. The for loop should use the curly brackets...

Code:

---

for (i=0; i<BufferSize; i++) {
    j=2*i;
    //... the rest of the code
}
return;

---

---

This can be further optimized by removing the painfully slow multiplication operation and replacing it with a bit shift:

Code:

---

j = i << 1;

---

Always replace multiplications and divisions of (2) with bit shifts instead.

Quote:

---

I don't get any errors now, but the Val12bit values calculated in the dll are wrong because some of them come out negative. Maybe the variable type is not correct and it should be "unsigned" or something...?

---

Change Val12bit to type Long in both VB and C program.

Quote:

---

Actually it was the other way round:
BufferSize = dsize\3 and not 2*dsize\3

---

Did you make some change to the C++ code to compensate? If not you are still doing something wrong here.

Quote:

---

Originally Posted by Dave Sell

Always replace multiplications and divisions of (2) with bit shifts instead.

---

This isn't necessary in C++ since the compiler will do it for you. Now assembler is a different story.

Quote:

---

Originally Posted by moeur

Change Val12bit to type Long in both VB and C program.

---

I don't think that's the problem even if it's a good idea to use 32 bit integers instead since they are faster. I think the problem with the overflow error is the bitwise OR as I mentioned in my last post.

Quote:

---

Originally Posted by moeur

This isn't necessary in C++ since the compiler will do it for you. Now assembler is a different story.

---

Really? Are you sure? That would be sweet if they did.

The compilers know every trick in the book. That is why you can often produce faster code with C than with assembler.

Quote:

---

Originally Posted by moeur

In many cases a C compiler will produce faster code than you will produce writing in assembly language yourself. This is beacuse the compiler knows a lot of tricks that you don't. I've actually tested it.

---

Can you post some code form both for me to test? Something no doubt memory heavy?

I've written a few things in C/C++ that are about 100-200ms quicker in ASM (32-bit: both).

Please, post something I can test..

Phreak

Quote:

---

Can you post some code form both for me to test? Something no doubt memory heavy?

I've written a few things in C/C++ that are about 100-200ms quicker in ASM (32-bit: both).

---

I don't have any asm code anymore.
Make sure that when you compile the C code, you are otimizing for maximum speed and that you are not compiling the Debug code.

Of course if you know all the tricks too (like memory alignment issues) then you can produce asm code that is faster than C code since the C compiler is not 100% optimized, but I only know the obvious ones like Dave mentioned and hence produce slower code. That's why I don't use ASM anymore.

Quote:

---

Originally Posted by «°°phReAk°°»

Remember that a Megabyte, a Meg, an MB are 1048576 bytes. Most of the time though, manufacturers give specifications showing a Mebabyte is 1000000 bytes in size to let their products look 4.8576% more impressive.

---

Actually, this is an incorrect statement. A Megabyte is not 1048576 bytes.

See http://helios.augustana.edu/~dr/kibibytes.html.

A Megabyte is 10^6, or 1,000,000 (a million) bytes.
A Mebibyte is 2^20, or 1,048,576 bytes.

Quote:

---

Originally Posted by Joacim Andersson

I don't remember the order, but isn't a bit wise operation evaluated before a multiplication in C? If so then this code is wrong:

Code:

---

Val12bit[j] = (DataByte[i][2] & 240) * 16 | DataByte[i][0];
Val12bit[j + 1] = (DataByte[i][2] & 15) * 256 | DataByte[i][1];

---

To me it looks like you, on the first line, multiply with 16 | DataByte[i][0] which is not what you want to do. Try this:

Code:

---

Val12bit[j] = ((DataByte[i][2] & 240) * 16) | DataByte[i][0];
Val12bit[j + 1] = ((DataByte[i][2] & 15) * 256) | DataByte[i][1];

---

---

It isn't that, I'm still getting negatives.

Quote:

---

Originally Posted by krtxmrtz

It isn't that, I'm still getting negatives.

---

I haven't really been following this thread much - as I do not know C...

But a negative value is simply one with the high-order bit set and touching that high order bit in multiplication will usually cause an overflow error...

Don't know if that means anything helpful!

Quote:

---

Originally Posted by szlamany

I haven't really been following this thread much - as I do not know C...

But a negative value is simply one with the high-order bit set and touching that high order bit in multiplication will usually cause an overflow error...

Don't know if that means anything helpful!

---

Ya I was just getting ready to suggest that he cast his result to a signed int...

Quote:

---

Originally Posted by moeur

Change Val12bit to type Long in both VB and C program.
Did you make some change to the C++ code to compensate? If not you are still doing something wrong here.

---

Still not working, the dll returns some negative Val12bit values. Could it have something to do with declaring the variables signed or unsigned?
This is what it looks like now:

Code:

---

'The VB side
Private Declare Sub ProcessData Lib "Mydll.dll" (DataByte As Byte, _
Val12bit As Long, _
Max12bit As Long, _
ByVal BufferSize As Long)

Dim Max12bit as Long
Dim DiskData() As Byte
Dim Val12bit() As Long

'...
'...
'...
'Later on, after the data file has been read in:

    ReDim DiskData(2, dSize \ 3 - 1)

'In the data processing sub:

    Dim BufferSize As Long
    BufferSize = dSize \ 3
    ReDim Val12bit(2*BufferSize)
    Call ProcessData(DiskData(0, 0), Val12bit(0), Max12bit, BufferSize)
'...
'...

'**********************************************************************
'The C part

#include <stdio.h>
#include <math.h>
#include <stdlib.h>

__declspec( dllexport ) void _stdcall ProcessData (char DataByte[][3],
long Val12bit[], long* Max12bit, long BufferSize)

{

        long i;
        long j;
       
        *Max12bit=0;

        for (i=0;i<BufferSize;i++)
        {
                j=i<<1; /* Multiply by 2 by doing a left shift */
                Val12bit[j] = ((DataByte[i][2] & 240) * 16) | DataByte[i][0];
        Val12bit[j + 1] = ((DataByte[i][2] & 15) * 256) | DataByte[i][1];
        if (*Max12bit < Val12bit[j])
                        *Max12bit = Val12bit[j];
        if (*Max12bit < Val12bit[j + 1])
                        *Max12bit = Val12bit[j + 1];       
        }               
        return;
}

---

Quote:

---

Originally Posted by szlamany

But a negative value is simply one with the high-order bit set

---

This is why I told him to declare Val12bit to Long about 10 posts back

Quote:

---

Originally Posted by moeur

This is why I told him to declare Val12bit to Long about 10 posts back

---

Just because it displays as negative is not a bad thing though - right? That's just a silly "display property" of signed integers with high-order bit set...

Quote:

---

Originally Posted by Dave Sell

Ya I was just getting ready to suggest that he cast his result to a signed int...

---

You mean declaring Val12bit as signed int in the dll? And how about signed long? Does such a type exist?

OK, need more info.
Are the values that are not negative the correct values?
Are the negative values only on the even or odd Val12bit[]s?
Can you supply some data for us to work with?