Author Topic: NASM OOP - Work In Progress  (Read 25840 times)

Offline Keith Kanios

  • Full Member
  • **
  • Posts: 383
  • Country: us
    • Personal Homepage
Re: NASM OOP - Work In Progress
« Reply #30 on: July 23, 2010, 10:53:23 PM »
If you are looking for a contributor I am willing pitch in.

On my behalf, and to be honest, I am looking for someone to completely take over primary maintenance of the project.

See http://www.asmcommunity.net/board/index.php?topic=30111.0 for more details.

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 430
  • Country: us
Re: NASM OOP - Work In Progress
« Reply #31 on: July 23, 2010, 11:07:27 PM »
Turn on PMs for us newbie posters plz  ;D

Offline Keith Kanios

  • Full Member
  • **
  • Posts: 383
  • Country: us
    • Personal Homepage
Re: NASM OOP - Work In Progress
« Reply #32 on: July 24, 2010, 02:46:38 AM »
I think it eases up at 5 posts. I've had experiences in the past with spamers/bots getting through and flooding everyone via PM... even despite send limits... and that is something I would rather avoid :)

You can PM me at this forum too, if you'd like.
« Last Edit: July 24, 2010, 02:50:55 AM by Keith Kanios »

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 430
  • Country: us
Re: NASM OOP - Work In Progress
« Reply #33 on: July 24, 2010, 01:01:15 PM »
Well I don't want to spam the forums just to increase post count...

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 430
  • Country: us
Re: NASM OOP - Work In Progress
« Reply #34 on: July 24, 2010, 01:01:54 PM »
but sometimes a guy's gotta do what a guys gotta do  ;D

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 430
  • Country: us
Re: NASM OOP - Work In Progress
« Reply #35 on: July 24, 2010, 01:14:37 PM »
To me NASMX has a bright future. I would like to maintain the 32/64bit Windows development portion in the role of a co-maintainer. A git/svn would be set up to provide for other individuals to nuture it's development on other platforms.

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 430
  • Country: us
Re: NASM OOP - Work In Progress
« Reply #36 on: July 24, 2010, 07:36:19 PM »
Personally, I tend to use the typedef method in my code. And I would probably do the same thing in NASMX if I was to do any internal updates. My personal 'base.asm' file (which gets pre-included via NASMENV) contains the following lines.

Code: [Select]
%define sizeof(_x_) _x_ %+ _size
%define reserve(_x_) _x_ %+ _res

%idefine byte_size 1
%idefine word_size (byte_size * 2)
%idefine dword_size (word_size * 2)
%idefine qword_size (dword_sized * 2)
%idefine tword_size 10
%idefine oword_size (qword_size * 2)

%idefine byte_res RESB
%idefine word_res RESW
%idefine dword_res RESD
%idefine qword_res RESQ
%idefine tword_res REST
%idefine oword_res RESO

%define int8_t byte
%define int16_t word
%define int32_t dword
%define int64_t qword
%define int80_t tword
%define int128_t oword

%define int8_t_size 1
%define int16_t_size (int8_t_size * 2)
%define int32_t_size (int16_t_size * 2)
%define int64_t_size (int32_t_size * 2)
%define int80_t_size 10
%define int128_t_size (int64_t_size * 2)

%define int8_t_res RESB
%define int16_t_res RESW
%define int32_t_res RESD
%define int64_t_res RESQ
%define int80_t_res REST
%define int128_t_res RESO

%define iax8 al
%define iax16 ax
%define iax32 eax
%define iax64 rax
%define iax128 xmm0

%define ibx8 bl
%define ibx16 bx
%define ibx32 ebx
%define ibx64 rbx
%define ibx128 xmm1

%define icx8 cl
%define icx16 cx
%define icx32 ecx
%define icx64 rcx
%define icx128 xmm3

%define idx8 dl
%define idx16 dx
%define idx32 edx
%define idx64 rdx
%define idx128 xmm4

%define ibp8 sp
%define ibp16 sp
%define ibp32 esp
%define ibp64 rsp
%define ibp128 rsp

%define isp8 sp
%define isp16 sp
%define isp32 esp
%define isp64 rsp
%define isp128 rsp

This gives me very C-ish style types and allows me to do some really cool stuff like:

Code: [Select]
STRUC MSG
.hwnd reserve( int%[__BITS__]_t ) 1
.message reserve( dword ) 1
.wParam reserve( int%[__BITS__]_t ) 1
.lParam reserve( int%[__BITS__]_t ) 1
.time reserve( dword ) 1
.pt reserve( byte ) POINT_size
ENDSTRUC

Which will change it to the correct RESD/RESQ based on the BITS n definition in your code.

And..

Code: [Select]
push ibp%[__BITS__]
mov ibp%[__BITS__], isp%[__BITS__]
;...
leave
ret

I don't use these register mods a whole lot, but they do come in handy in some projects... the type mods however I use in almost everything.. definitely useful. :)

That is beautiful code. I had to quote the entire post to give it the proper attention it deserves since it is exactly what I have in mind for updating NASMX with. ;D

Klod

  • Guest
Re: NASM OOP - Work In Progress
« Reply #37 on: July 26, 2010, 01:41:34 AM »
Hi Bryan,
Thanks very much for sharing your oop implementation. For some time have I been interested to do oop in Nasm. I have downloaded the example from http://assembly.ath.cx/code/objects.inc. I use nasm with goasm and modified slightly to make it work. I have tried your second example from earlier in this post and wonder if there is an updated objects.inc file. I do get a compile time ERROR from line      new CTest, dword strAuthor

Quote
C:\NasmEd\Project\NasmObject>mak
Assembling main.asm
main.asm:15: error: symbol `CTest_CTest' undefined
Assembling myObject.asm
project file attached



Offline Bryant Keller

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 360
  • Country: us
    • About Bryant Keller
Re: NASM OOP - Work In Progress
« Reply #38 on: July 26, 2010, 02:47:19 AM »
Hi Bryan,
Thanks very much for sharing your oop implementation. For some time have I been interested to do oop in Nasm. I have downloaded the example from http://assembly.ath.cx/code/objects.inc. I use nasm with goasm and modified slightly to make it work. I have tried your second example from earlier in this post and wonder if there is an updated objects.inc file. I do get a compile time ERROR from line      new CTest, dword strAuthor

Quote
C:\NasmEd\Project\NasmObject>mak
Assembling main.asm
main.asm:15: error: symbol `CTest_CTest' undefined
Assembling myObject.asm
project file attached

I've uploaded a new version which should take care of that little problem. The issue is simply that I forgot to add a Global/Extern for the user-ctor in the event it exists. Now, just a note.. this is marked as a "Work in Progress" for a reason, there are going to be bugs... probably lots of them. p1ranha and I were just recently discussing on asmcommunity about an issue with the inheritance system (it doesn't recursively call parent constructors, but I posted on that same thread a possible fix for later on). I'm just letting you know, don't do any mission critical stuff with this OOP kit just yet, it's not up to par for anything like that, it's ultra-alpha-ware.

http://assembly.ath.cx/code/objects.inc

About Bryant Keller
bkeller@about.me

Klod

  • Guest
Re: NASM OOP - Work In Progress
« Reply #39 on: July 27, 2010, 04:05:47 AM »
Thanks Briant
The updated objects.inc file did the trick. As always, I am intrigued by your macros. I have been working on a simplistic implementation of an oop model in Nasm but alas not very successful. I will study yours with more attention to the details.

You mentioned a work around  the ctor bug and I assume this would be to mandatory defining a ctour for each class?
Klod

Offline Bryant Keller

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 360
  • Country: us
    • About Bryant Keller
Re: NASM OOP - Work In Progress
« Reply #40 on: July 27, 2010, 07:17:05 PM »
Thanks Briant
The updated objects.inc file did the trick. As always, I am intrigued by your macros. I have been working on a simplistic implementation of an oop model in Nasm but alas not very successful. I will study yours with more attention to the details.

You mentioned a work around  the ctor bug and I assume this would be to mandatory defining a ctour for each class?
Klod

Well, the version you are using now doesn't require you to have a ctor or a dtor at all. No, the bug I'm talking about is because I don't support ancestor ctor calls. My temporary fix was just to recurse over the %{$parent} definitions like I do when generating the symbol table for the class itself in the first place and look for the presence of an %{$parent}_has_ctor symbol with a value of '1', then placing a cdecl call to the Ctor for that parent. This would require that all Ctor's be written with the Cdecl calling convention and that ctor parameters couldn't change, only extend per inherited class... So it's not really a solution as much as a hack-fix.

About Bryant Keller
bkeller@about.me

Klod

  • Guest
Re: NASM OOP - Work In Progress
« Reply #41 on: August 02, 2010, 04:02:52 AM »
Hi Bryant,

I have been playing around with your code sample for the last few days.


C:\NasmEd\Project\NasmObject>mak
Assembling main.asm
MyObject.inc:11: warning: (static:20) CTest_static_data_0_size     4
MyObject.inc:13: warning: (endclass:8) CTest_total_virtual_methods     1
MyObject.inc:13: warning: (endclass:9) CTest_total_static_methods     2
Assembling myObject.asm
myObject.inc:11: warning: (static:20) CTest_static_data_0_size     4
myObject.inc:13: warning: (endclass:8) CTest_total_virtual_methods     1
myObject.inc:13: warning: (endclass:9) CTest_total_static_methods     2

I noticed that CTest_total_static_methods  = 2, yet there are 3 static methods defined. I assume that ctor is handled different?

I could not quite figure out how you implemented the class definition so that its members can be inherited by derived classes. I expected similar definitions like for struc definitions. I assume CTest_static_data_0_size  (4) and CTest_static_data_N_size  to be  offsets  and _total_static_methods be the upper limit.  The parent class had been defined in an other context but it can be inherited by means of the above defines? The Total size of the Class is then the sum of number_of_static_methods, number_of_virtual_methods, number_of_static_members, number_of_virtual_members.

.vmt and vdt would be the first 2 elements (pointers) to their respective tables.

Call %{1}_%{1} call to ctor either default or user defined

I haven't yet build a project using your model but think it is a good start. Waiting to see your next update.
Klod








Offline Bryant Keller

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 360
  • Country: us
    • About Bryant Keller
Re: NASM OOP - Work In Progress
« Reply #42 on: August 02, 2010, 06:14:13 AM »
Hi Bryant,

Hi Klod, Always good to hear from you man. :)

I have been playing around with your code sample for the last few days.


C:\NasmEd\Project\NasmObject>mak
Assembling main.asm
MyObject.inc:11: warning: (static:20) CTest_static_data_0_size     4
MyObject.inc:13: warning: (endclass:8) CTest_total_virtual_methods     1
MyObject.inc:13: warning: (endclass:9) CTest_total_static_methods     2
Assembling myObject.asm
myObject.inc:11: warning: (static:20) CTest_static_data_0_size     4
myObject.inc:13: warning: (endclass:8) CTest_total_virtual_methods     1
myObject.inc:13: warning: (endclass:9) CTest_total_static_methods     2

I noticed that CTest_total_static_methods  = 2, yet there are 3 static methods defined. I assume that ctor is handled different?

That's right. This is because there are two possible ctors. There is an internal ctor which is created for every class %{1}___%{1} and a user defined ctor which only appears when the user wishes to preform some run-time initialization , %{1}_%{1}.

The internal ctor handles setting up all the pointers that the class will be dependent on for invoking methods. The user ctor, although it is a static method, doesn't appear as part of the CTest_total_static_methods definition because it doesn't need to be. The internal constructor uses those symbols (%{$name}_*_static_* and %{$name}_*_virtual_*) to preform the updating of the pointers of the class memory. Because the user ctor is invoked directly, it's not required to be updated as part of this and is not included.

I could not quite figure out how you implemented the class definition so that its members can be inherited by derived classes. I expected similar definitions like for struc definitions. I assume CTest_static_data_0_size  (4) and CTest_static_data_N_size  to be  offsets  and _total_static_methods be the upper limit.  The parent class had been defined in an other context but it can be inherited by means of the above defines? The Total size of the Class is then the sum of number_of_static_methods, number_of_virtual_methods, number_of_static_members, number_of_virtual_members.

Well, the idea is pretty simple, as you have no doubt figured out, I'm creating a description of the class using these symbols, and when I reach the ENDCLASS macro I use ABSOLUTE directly to create a structure (basically the way STRUC does internally).

For inheritance, I'm keeping a list of what parents, if any, each class has. At the beginning of the definition in the CLASS macro, I loop through all the parents and copy the values of these symbols into the symbols for my current class. This basically extends my class automatically.

Code: [Select]
%if %0 = 2
%[%{$name}]_has_parent equ 1
%define %[%{$name}]_parent %{2}
%define %$parent %2
%if %{1}_has_parent > 0
%[%{$name}]_parent_count equ (%[%{$parent}]_parent_count + 1)
%else
%[%{$name}]_parent_count equ 1
%endif
%assign %$number_of_virtual_methods %[%{$parent}]_total_virtual_methods
%assign %$number_of_virtual_members %[%{$parent}]_total_virtual_members
%assign %$ii 0
%rep %{$number_of_virtual_methods}
%define %[%{$name}]_virtual_method_%[%{$ii}]_full %[%{$parent}]_virtual_method_%[%{$ii}]_full
%define %[%{$name}]_virtual_method_%[%{$ii}]  %[%{$parent}]_virtual_method_%[%{$ii}]
%assign %$ii %{$ii} + 1
%endrep
%assign %$ii 0
%rep %{$number_of_virtual_members}
%define %[%{$name}]_virtual_data_%[%{$ii}]_size %[%{$parent}]_virtual_data_%[%{$ii}]_size
%define %[%{$name}]_virtual_data_%[%{$ii}]  %[%{$parent}]_virtual_data_%[%{$ii}]
%assign %$ii %{$ii} + 1
%endrep
%else
%[%{$name}]_has_parent equ 0
%[%{$name}]_parent_count equ 0
%endif

Also take a look at the BUILD_CLASS_STRUCTURE macro which creates the actual memory imprint for the class (and makes use of the inherited symbols). You'll notice in that macro a call to another macro called INHERIT_PARENT_DATA, this ensures that our inherited classes come before our current class data in memory, but our current class's VDT/VMT and Dtor come before our inherited data.

.vmt and vdt would be the first 2 elements (pointers) to their respective tables.

Call %{1}_%{1} call to ctor either default or user defined

I haven't yet build a project using your model but think it is a good start. Waiting to see your next update.
Klod

I'm actually working on something else atm, so an update won't be real soon. This project is something I've been doing off and on for some time now. I just thought since it was showing some form of progress I would post it.

About Bryant Keller
bkeller@about.me

Klod

  • Guest
Re: NASM OOP - Work In Progress
« Reply #43 on: August 03, 2010, 03:55:16 AM »
Hi Bryant,
Thanks for sharing your methodology behind your OOP model. I had to buckle down and "work" on understanding how it all works.

Quote
Also take a look at the BUILD_CLASS_STRUCTURE macro which creates the actual memory imprint for the class (and makes use of the inherited symbols). You'll notice in that macro a call to another macro called INHERIT_PARENT_DATA, this ensures that our inherited classes come before our current class data in memory, but our current class's VDT/VMT and Dtor come before our inherited data.

I did have a look at these macros. I missed however the order of inheritance, vdt/vmt and dtpr. Isn't this causing some difficulties later in addressing? some people suggest to inherit/include parent classes in structure fashion by appending only at the end. In this way ptr to vmt would always be at offset 0.

Quote
I'm actually working on something else atm, so an update won't be real soon. This project is something I've been doing off and on for some time now. I just thought since it was showing some form of progress I would post it.

Time is a precious commodity and as time goes on becomes scarcer. My coding time has been shorted lately, other projects moved to the foreground. I still try to visit the forums a few times a week. Whenever I see a post of yours, I'm all over it. You are a very gifted programmer and especially your knowledge and skill shine through your posts. Your macros have dazzled me quite a few times and helped me a great deal in my quest for better programming with Nasm.

thanks
Klod

Offline Bryant Keller

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 360
  • Country: us
    • About Bryant Keller
Re: NASM OOP - Work In Progress
« Reply #44 on: August 04, 2010, 12:41:23 AM »
For the most part, that is what's happening. The structure I'm creating does append the child to the parent, with the exception of the pointers to the VMT/VDT which is at the beginning. As for the VMT/VDT itself, the entries have to support overloading, therefore new entries are appended to the table while entries which already exist are simply overwritten.

The only actual difficulty is that I don't support an ancestor call method or any technique to descend through parent ctor/dtor (both are a related issue).

About Bryant Keller
bkeller@about.me