Help I need to call a member from assembler code (WIN32)

[enfis.the.paladin]

Hi to all!
I have something like this:

class FWrap {
public:
virtual void READ (void) = 0;
}

class Optimized {
private:
FWrap* FFile;

public:
void Calc (void);
}

I need to optimize Calc routine as much as I can because it is called
billion of times. In Calc function I must call FFile->READ () within
assembler code.

I have something like this now ...

void Calc (void)
{
__asm {
MOV EAX, &this // I get cell address which contain
'this' address
MOV EBX, [EAX] // Now I have 'this' address in EBX
MOV ECX, [EBX].FFile // Cell address which contain 'FFile'
address
MOV EBX, [ECX] // Now EBX contain 'FFile' address (EBX
= PIC)
...
???
}
}

Now I must call READ with something like "CALL DWORD PTR [EBX + ADDRESS
OF READ]" but I have no Idea how I can get the right offset READ
function.
I've tried FWrap::READ, FFile.READ and so on ... but I can't figure out
how I can call the right function address.

Is vital for me to create a function made of asm at 100%

Anyone can help me?

[benben]

<en************ ***@gmail.com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

Hi to all!
I have something like this:

class FWrap {
public:
virtual void READ (void) = 0;
}

class Optimized {
private:
FWrap* FFile;

public:
void Calc (void);
}

I need to optimize Calc routine as much as I can because it is called
billion of times. In Calc function I must call FFile->READ () within
assembler code.

I have something like this now ...

void Calc (void)
{
__asm {
MOV EAX, &this // I get cell address which contain
'this' address
MOV EBX, [EAX] // Now I have 'this' address in EBX
MOV ECX, [EBX].FFile // Cell address which contain 'FFile'
address
MOV EBX, [ECX] // Now EBX contain 'FFile' address (EBX
= PIC)
...
???
}
}

Now I must call READ with something like "CALL DWORD PTR [EBX + ADDRESS
OF READ]" but I have no Idea how I can get the right offset READ
function.
I've tried FWrap::READ, FFile.READ and so on ... but I can't figure out
how I can call the right function address.

Is vital for me to create a function made of asm at 100%

Anyone can help me?

You can use a global, extern "C" wrapper function to call the member
function. Then your assembly can simple call the global function.

ben

[Karl Heinz Buchegger]

en************* **@gmail.com wrote:

I need to optimize Calc routine as much as I can because it is called
billion of times. In Calc function I must call FFile->READ () within
assembler code.
Is vital for me to create a function made of asm at 100%

Anyone can help me?

Not here. comp.lang.c++ is for platform independent C++.
Your question obivously deals with very platform specific things.
You need to ask in a newsgroup dealing with your particular compiler.

--
Karl Heinz Buchegger
kb******@gascad .at

[peter.koch.larsen]

en************* **@gmail.com wrote:

Hi to all!
I have something like this:

class FWrap {
public:
virtual void READ (void) = 0;
Do not use all uppercase names for functions. READ screams MACRO
according to established (and good!) conventions.
}

class Optimized {
private:
FWrap* FFile;

public:
void Calc (void);
}

I need to optimize Calc routine as much as I can because it is called
billion of times. In Calc function I must call FFile->READ () within
assembler code.
This reminds me about an example assemlber program, Borland sent out
many, many years ago. Written in wonderful Borland assembler and
awfully slow because all time was spent inside an inefficient
IO-routine.
I have something like this now ...

[snip]

Is vital for me to create a function made of asm at 100%
Are you sure? Did you profile your program. To me it looks as if the
time is spent in the read function.
Anyone can help me?

Your code would be most fragile. Surely not portable - not to other
compilers, not to the next release of the same compiler and not from
one compiler setting to another. Much better would be to delegate to
some function where the function-call is not virtual - e.g.
extern "C" void Read(FWrap* fw)
{
return fw->READ();
}

This would probably improve portability regardless of compilersetting s
(esp. if you decorate Read with __cdecl or whatever it is called), and
perhaps even from one compiler version to the next.
Still I recommend you not use my solution. Instead find out what takes
so much time.

/Peter