OOP asm
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
OOP asm
I'm reading The Art of Assembly Language chapter 14: Classes and Objects. While this is all and well, it is targeted at HLA. Can anyone show me a (non-high level) assembly example of OOP? How do you deal with accessing members, inheritance, and polymorphism?
My OS is Perception.
You could also try using gcc's -S options to get some assembly.
From when I did it, I found that GCC declares an area of memory and uses that as the class. Then, it creates all member functions as normal functions. So, for example, let's say I do this:
I get:
The member variables are simply indexes to the allocated class space and the functions are just normal functions that take the address of the class automatically.
From what I can tell a lot(most?) of the OOP is pre calculated by the compiler before compile time.
As for the inheritance, it would appear as though the compiler handles all of the dirty work before compilation. I derived a class d from class c and found the only difference in the instance of class d named monkey was that it's size had increased from 16 to 24. Moreover, the member calls from d acted as though they were written in c. (ie. They acted the same as the call described above.)
When virtual functions were added to the mix, a table in the form of entries of this nature endued:
(Formally called the Virtual Method Table)
Note: I haven't read the ABI, so I could (probably are) a little (a lot?) off. This is all just a bit of disassembly work.
From when I did it, I found that GCC declares an area of memory and uses that as the class. Then, it creates all member functions as normal functions. So, for example, let's say I do this:
Code: Select all
monkey.i = 12;
monkey.koo();
Code: Select all
movl $12, monkey(%rip)
movl $monkey, %edi
call koo
From what I can tell a lot(most?) of the OOP is pre calculated by the compiler before compile time.
As for the inheritance, it would appear as though the compiler handles all of the dirty work before compilation. I derived a class d from class c and found the only difference in the instance of class d named monkey was that it's size had increased from 16 to 24. Moreover, the member calls from d acted as though they were written in c. (ie. They acted the same as the call described above.)
When virtual functions were added to the mix, a table in the form of entries of this nature endued:
Code: Select all
_ZTV1d:
.quad 0
.quad _ZTI1d
.quad _ZN1d3eatEv
.weak _ZTI1d
.section .rodata._ZTI1d,"aG",@progbits,_ZTI1d,comdat
.align 16
.type _ZTI1d, @object
.size _ZTI1d, 24
Note: I haven't read the ABI, so I could (probably are) a little (a lot?) off. This is all just a bit of disassembly work.
C8H10N4O2 | #446691 | Trust the nodes.
You could take a look at v2_os 0.70 which is a (oop) assembly OS.
http://v2os.v2.nl/cgi-bin/v2wiki.py?show=WhatIsV2OS
http://v2os.v2.nl/cgi-bin/v2wiki.py?show=WhatIsV2OS
-
- Member
- Posts: 566
- Joined: Tue Jun 20, 2006 9:17 am
I think.....
I am not such a great asm hacker ... Still it seems thats
David Bell's Assembly Language Book has some material
on the subject......
Other than HLA ....
take a look at 1) Terse
2) C--
etc...
David Bell's Assembly Language Book has some material
on the subject......
Other than HLA ....
take a look at 1) Terse
2) C--
etc...
-
- Member
- Posts: 134
- Joined: Thu Aug 18, 2005 11:00 pm
- Location: Sol. Earth. Europe. Romania. Bucuresti
- Contact:
TASM supported OOP and it's manual contained info about OOP in ASM from year 1995 or before. Objects, multiple Inheritance, polymorphism, virtual methods etc. Never seen it to be used very much.
It is not hacking. Simply the same OOP like in any other programing languages.
The powerful macro system from ASM alows you to also develop your own OOP in ASM if you so like... Some did like this (ObjASM, ULTRANO's ATC)
But when you can develop things so fast and simple in ASM who needs OPP anyway?
It is not hacking. Simply the same OOP like in any other programing languages.
The powerful macro system from ASM alows you to also develop your own OOP in ASM if you so like... Some did like this (ObjASM, ULTRANO's ATC)
But when you can develop things so fast and simple in ASM who needs OPP anyway?
Ambition is a lame excuse for the ones not brave enough to be lazy; Solar_OS http://www.oby.ro/os/