Accessing c++ class member variables in ASM
I can program ASM functions and call them from C++ modules no problem, but what if I wanted to access C++ Class member variables from an asm function, how would I go about that??
I''m using GCC ARM ASM by the way. Wasn''t sure whether this is special interest or not, as it is kinda General Programming.
Cheerz,
Basically, you add parameters to your ASM functions and pass the class variables through the parameters. That's the easiest way to do it. I'm pretty sure you can only pass basic types, so you might want to wrap your ASM function with a class function that passes its own variables.
EDIT: On second thought, I've worked with MASM32 before and it allowed you to do a lot of neat things... is GCC assembly similar?
[edited by - Zipster on October 22, 2002 12:55:19 PM]
EDIT: On second thought, I've worked with MASM32 before and it allowed you to do a lot of neat things... is GCC assembly similar?
[edited by - Zipster on October 22, 2002 12:55:19 PM]
yes, you can inline gcc asm
however, its a bit different from masm. i know that you can do about everything in gcc that you can do with asm, but im not an expert
null and void probably knows
however, its a bit different from masm. i know that you can do about everything in gcc that you can do with asm, but im not an expert
null and void probably knows
Imagine you have a class foo, like this:
class foo
{
private:
int foobar1;
int foobar2;
public:
bar();
};
And then you have a pointer to a class foo. Just store that pointer into a register. foobar1 is the first element in the class, so to load foobar1, just store what that pointer is pointing to into a register of int size. (sorry, not familiar with the architecture you''re working with so I can''t go into more detail). To load foobar2, just load from the address foopointer+sizeof(int), and you''re ready to go. The same principle applies for writing the variables.
class foo
{
private:
int foobar1;
int foobar2;
public:
bar();
};
And then you have a pointer to a class foo. Just store that pointer into a register. foobar1 is the first element in the class, so to load foobar1, just store what that pointer is pointing to into a register of int size. (sorry, not familiar with the architecture you''re working with so I can''t go into more detail). To load foobar2, just load from the address foopointer+sizeof(int), and you''re ready to go. The same principle applies for writing the variables.
quote:And then you have a pointer to a class foo. Just store that pointer into a register. foobar1 is the first element in the class, so to load foobar1, just store what that pointer is pointing to into a register of int size. (sorry, not familiar with the architecture you''re working with so I can''t go into more detail). To load foobar2, just load from the address foopointer+sizeof(int), and you''re ready to go. The same principle applies for writing the variables.
Is that guaranteed to be the internal storage structure though?
quote:Original post by Zipster
Is that guaranteed to be the internal storage structure though?
If by that you mean "member variables are stored in memory in the order you declare them", then yes. Think back to C when you'd load structs from files.
[edit] - Assuming there is no vtable though. Its a fairly dangerous assumption, but it'll work.
[edited by - sark on October 23, 2002 1:20:56 PM]
I''m not sure, but you can use the ''strict'' (?) keyword or something, to instruct the compiler not to optimize the structure (and class, I think).
Is there no way you can include the structure offsets as symbols, as you do with assembly language structures?
---------------------------------------------
"VB is a disease"
Is there no way you can include the structure offsets as symbols, as you do with assembly language structures?
---------------------------------------------
"VB is a disease"
quote:Original post by sarkOriginal post by Zipster
[edit] - Assuming there is no vtable though. Its a fairly dangerous assumption, but it''ll work.
(disclaimer: I''m the original AP)
Afaik the vtable will always be located after the member variables. So it should be pretty safe anyways…
Plus you have to account for struct padding too. Hmm... the safest route is not to assume anything
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement