• Welcome to Valhalla Legends Archive.
 

Code Submission - Extended Boolean Math

Started by n00blar, December 23, 2002, 04:42 PM

Previous topic - Next topic

n00blar

These are some advanced extended boolean functions you can put in a dll and export for visual basic. I originaly designed these to use for a game that is being made in visual basic using TrueVision3D! This also is an example of using naked functions for you guys who have never used them!

#define Param1 [ebp+0x08]
#define Param2 [ebp+0x0C]
#define BitMask 0x00000001
#define NAKED __declspec(naked)

bool EXOR(bool x, bool y);
bool Implication(bool x, bool y);
bool Inhibition(bool x, bool y);
bool NAND(bool x, bool y);
bool NOR(bool x, bool y);


NAKED bool EXOR(bool x, bool y)
{
      // Prolog
      __asm
      {
            push ebp
            mov ebp, esp
            sub esp, __LOCAL_SIZE
      }

      // Functionality
      __asm
      {
            mov ecx, Param1
            xor ecx, Param2
            xor ecx, BitMask
            mov eax, ecx
      }

      // Epilog
      __asm
      {
      mov esp, ebp
      pop ebp
      ret
      }
}

NAKED bool Implication(bool x, bool y)
{
      // Prolog
      __asm
      {
            push ebp
            mov ebp, esp
            sub esp, __LOCAL_SIZE
      }
      
      // Functionality
      __asm
      {
            cmp Param1, 0x01
            jz lbl_true
            mov eax, Param2
            xor eax, BitMask
            jmp lbl_done
lbl_true:
            mov eax, Param2
lbl_done:
      }

      // Epilog
      __asm
      {
      mov esp, ebp
      pop ebp
      ret
      }
}

NAKED bool Inhibition(bool x, bool y)
{
      // Prolog
      __asm
      {
            push ebp
            mov ebp, esp
            sub esp, __LOCAL_SIZE
      }
      
      // Functionality
      __asm
      {
            mov ecx, Param2
            xor ecx, BitMask
            cmp Param1, ecx
            jz      lbl_true
            mov eax, 0x00
            jmp lbl_done
lbl_true:
            mov eax, 0x01
lbl_done:
      }

      // Epilog
      __asm
      {
      mov esp, ebp
      pop ebp
      ret
      }
}

NAKED bool NAND(bool x, bool y)
{
      // Prolog
      __asm
      {
            push ebp
            mov ebp, esp
            sub esp, __LOCAL_SIZE
      }
      
      // Functionality
      __asm
      {
            mov ecx, Param1
            and ecx, Param2
            xor ecx, BitMask
            mov eax, ecx
      }

      // Epilog
      __asm
      {
      mov esp, ebp
      pop ebp
      ret
      }
}

NAKED bool NOR(bool x, bool y)
{
      // Prolog
      __asm
      {
            push ebp
            mov ebp, esp
            sub esp, __LOCAL_SIZE
      }
      
      // Functionality
      __asm
      {
            mov ecx, Param1
            or ecx, Param2
            xor ecx, BitMask
            mov eax, ecx
      }

      // Epilog
      __asm
      {
      mov esp, ebp
      pop ebp
      ret
      }
}

Yoni

#1
IMO, if you write these functions in VB instead of in ASM, they will run faster, since VB is stupid and dynamically loads all DLLs you want to import functions from. Worth checking though.

n00blar

#2
or i could assemble them and load them into a string array and use callwindprocedure but uh-- I think its faster in asm than visual basic! Have you ever seen a visual basic function its really icky and slow!

Skywing

#3
Quoteor i could assemble them and load them into a string array and use callwindprocedure but uh-- I think its faster in asm than visual basic! Have you ever seen a visual basic function its really icky and slow!
That's bad.  The WNDPROC parameter passed to CallWindowProc isn't guaranteed to be a real pointer.
QuotelpPrevWndFunc
[in] Pointer to the previous window procedure.
If this value is obtained by calling the GetWindowLong function with the nIndex parameter set to GWL_WNDPROC or DWL_DLGPROC, it is actually either the address of a window or dialog box procedure, or a special internal value meaningful only to CallWindowProc.

Use at risk of your program breaking with no warning.

n00blar

Thanks for the information skywing. I never knew that; probably because I never looked! However, I still think using a DLL will be faster than a visual basic function though.

Yoni

#5
Umm, either way, using CallWindowProc = dynamically loading user32.dll... Though it'll be much faster than dynamically loading a different dll (since user32.dll is always loaded, so all it'll do is increment a reference count, if at all), it'll still have to call GetProcAddress, search for the CallWindowProc function in the user32.dll export table, etc... Plus, if you're using VB6, it has some restrictions on callback functions (which VB5 didn't have), which may apply in this case (not sure if they do). Either way, I think it'll still be slower.

iago

#6
Well, there's only one way to find out.. do it 50000 times each way and see which goes faster! :-D
This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*