flat assembler
Message board for the users of flat assembler.

flat assembler > Projects and Ideas > FASM OO library.

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
tantrikwizard



Joined: 13 Dec 2006
Posts: 142
I'm curious if anyone else is using FASM for OO development and if there would be any shared interest in a standard FASM OO library and macros to ease/speed OO development. I really like the .NET framework methodology and have some ideas that I think are worthy of discussion yet am unsure of FASMs ability to handle such a design. One thing I think would be nice is automate virtual method table creation and namespaces. Some ideas I've been throwing around might look like:
Code:
namespace company.application ;<--begin a namespace decleration
    class a; <--begin a class decleration
        memberA dd ? ;<--member variable of class
        proc new uses esi, .this; <--constructor
            mov esi, [.this]
            mov [esi+a.memberA], 0
            ret
        endp
        proc delete, .this <--destructor
            ret
        endp
        proc dostudd uses esi, .this ;<--member function of a class
          mov esi, [.this]
          inc [esi+a.memberA]
          ret
        endp
    endclass
endnamespace
    

Some macros may create a structure for the class and automatically create a VTBL by finding the methods and members declared between the class and endclass statements. A 'new' macro could be created to allocate the required memory for the object, set the VTBL pointer and call the classes constructor. Likewise the 'delete' macro would call the destructor of the class and free the allocated memory. I'm kind of at odds about namespaces and would like to have a discussion on them. They're handy for categorizing large object models and encapsulating data but it maybe beyond the possibility or scope of a potential FASM OO library. Any thoughts or suggestions are welcome.
Post 23 Jan 2007, 21:54
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
there were more such attempts in various assemblers (FASM included) in past, try searching.

But I somehow miss the point of doing all this the HLLy way in asm :

when you need array of pointers to producedure, why macro to declare it?

what is unified construction / desctructor good for, if it cannot be called automatically by compiler? when object needs to be destroyed, you have to call it manually anyway. This is lacking the point.

I just don't see much of use in this, for asm programming. You can do it all by hand, without much extra effort
Post 23 Jan 2007, 23:06
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tantrikwizard



Joined: 13 Dec 2006
Posts: 142
vid wrote:
there were more such attempts in various assemblers (FASM included) in past, try searching.


Yes I've used such models before for TASM and have seen some discussion on this board but haven't seen any libraries. I will search again though.

vid wrote:
when you need array of pointers to producedure, why macro to declare it?


Same reason to use macros for any other reason, it reduces the amount of code one has to maintain by doing it by hand. Under normal circumstances, (I would say about 99% of the time), the programmer has no need to directly interact with the VTBL or binary layout of objects. They're used internally being that they're created upon compile time and never modified in code. Indeed it is easy enough to code by hand, but with it automatically generated the chances of errors reduce. Also the code becomes more tidy and readable, easier to maintain. For example, when adding or removing a method from a class there's no need to modify the associated VTBL when it's generated automatically (similar to the header of any binary file, e.g. elf, PE, etc).

vid wrote:
what is unified construction / desctructor good for, if it cannot be called automatically by compiler? when object needs to be destroyed, you have to call it manually anyway.


This was my idea with the 'new' and 'delete' macros. There is more to object creation and destruction than the constructor and destructor. When an object is created, memory must be allocated, the VTBL is copied to the new memory location then the constructor is called. This is 3 or 4 steps that can be reduced to a single 'new' macro. The new macro can allocate the memory for the object, copy the VTBL to the newly allocated memory and call the constructor of the class in one line of code which is much easier to handle and reduces the possiblity of typos. Likewise the 'delete' macro can call the destructor and then free the memory in a single line of code, which would take several lines without macros.

vid wrote:
I just don't see much of use in this, for asm programming. You can do it all by hand, without much extra effort


I agree, it does not take much effort to do it by hand. The OO programming paradigm is just as useful for asm as for .NET or C++ or other OO languages. For example, one can code a single bubble sort algorithm that sorts strings, bytes, words or double words without much effort. With traditional procedural programming a different routine would normally be needed for each data type. There are many good reasons to use OO methodology in asm. Specifically asm offers performance gains that can be exploited where as other OO languages do not.

Presently in my OO projects the task of declaring and creating objects require several tasks:
1) declare structure for member variables and include a pointer member for the VTBL
2) declare a 'virtual at 0' instance of the structure so it can be referenced in memory
3) write methods for the object and add them to a VTBL
These 3 tasks can be reduced significantly with a proper macro library. Steps 2 and 3 can be automated with macros which reduces the probability for errors and makes the code more readable and managable.

Likewise, to instantiate an object also takes several steps which are superflous with each object:
1) call alloc(struct.sizeof)
2) set the VTBL pointer to the hand written VTBL
3) call the objects constructor.

I've automated the 'new' macro already in one of my libraries and have reduced several lines of code down to 1. At best case scenerio creating an object takes no less than 5 or 6 lines of repeatitive code and opens the door to to make a mistake. The macro reduces the amount of code I must manually type which makes it cleaner, smaller and less error prone. Likewise, destroying an object takes several steps when done manually:
1) call the destructor
2) free the allocated memory
My 'delete' macro does this already and reduces the amount of code from 5-6 lines to 1 with the same benifits. (reduced code=reduced chance for errors).

Now consider the case of inheritance, the amount of superflous code that must be maintained by hand grows even more thus making the code more error prone. In the event that a method name changes, one must likewise modify the other associated VTBLs.

OO methodologies are going to be around for a long time, it only makes sense to assist in this form of development. I like FASMLIB's error standards and cross platform ability. FASMLIB could be the underlying guts for a possible TRY...CATCH and memory management of objects.
Post 24 Jan 2007, 00:13
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
why multicommand new/delete? you can still make constructors in pure assembly:

push some_arg
call MyClass_Constructor
jc error

destructor can be done same way, or even be a method:
call [ebx + MyClass.destructor]

Quote:
OO methodologies are going to be around for a long time, it only makes sense to assist in this form of development. I like FASMLIB's error standards and cross platform ability. FASMLIB could be the underlying guts for a possible TRY...CATCH and memory management of objects.

yes, it's pretty easy to try-catch error. problem is what to do with uncatched error at the end of try-catch block. just passing to higher-level block (like in typical SEH) is not possible using normal code flow.

being in your position, i would think about real SEH, and throw macro cooperating with new macro, which will destroy all objects created since last try block. This IS possible with FASM macros. But it will force usage of those macros on programmer.

don't bother with portability too much, all you need are two things - malloc and free. very easy to port.
Post 24 Jan 2007, 00:21
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
tantrikwizard



Joined: 13 Dec 2006
Posts: 142
vid wrote:
why multicommand new/delete? you can still make constructors in pure assembly:

push some_arg
call MyClass_Constructor
jc error

destructor can be done same way, or even be a method:
call [ebx + MyClass.destructor]


I'm not sure I follow you on this. It will always require multiple commands to first allocate memory then assign the VTBL to the memory whether done within a macro or within a virtual constructor. If done within a macro one doesn't have to rewrite allocate and VTBL assignment code within each virtual constructor. For example, here's my simple new macro at present:
Code:
macro new [ObjectType] {
        objcall Kernel.MemoryManager.Alloc, sizeof#.#ObjectType
        push ebx
        mov ebx, ObjectType#_#VTBL
        mov [eax], ebx
        pop ebx
        stdcall ObjectType#.#new, eax }
    

This code is for my OO operating system thus the memory manager and kernel objects. In a standard OO library we could probably use FASMLIB for this allocation.

vid wrote:
yes, it's pretty easy to try-catch error. problem is what to do with uncatched error at the end of try-catch block. just passing to higher-level block (like in typical SEH) is not possible using normal code flow.

being in your position, i would think about real SEH, and throw macro cooperating with new macro, which will destroy all objects created since last try block. This IS possible with FASM macros. But it will force usage of those macros on programmer.

Excellent! I've never really looked at the guts of a SEH implementation before but it shouldn't be that difficult. It shouldn't be a problem forcing the macros use in a full featured library. There already exists certain limitations on macro usage in existing libraries.
Thanks for the feedback, any contribution is welcome.
Post 24 Jan 2007, 01:02
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
Even SEH can be done portable easily, with very little unportable code. I think Randall Hyde uses it in HLA. Feel free to ask if you are unsure how to do some of these ideas.

and, you really don't need FASMLIB. Also if you decide to go for SEH (better idea IMHO), then FASMLIB error returning is incompatible.

But if you decide to fo for CF-errors, and use FASMLIB, i'm still happy someone uses it. Very Happy
Post 24 Jan 2007, 01:26
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1046
Location: Michigan, USA
I agree with vid, you should use C-Sharp (preferred) or Managed-C++ if you like Object Oriented programming. Fasm has the if/endif, while/endw, repeat/until, etc., This is quite high level enough, and many people think that's even too high level. In my opinion, OO Assembly is more trouble than it's worth.
Post 24 Jan 2007, 08:31
View user's profile Send private message Reply with quote
afw2004



Joined: 16 Jun 2005
Posts: 49
Location: Kharkov, Ukraine
I work now on such library implementation. I think it could be done in 2-3 weeks. It will use the following syntax:


Code:
struct MyClass, parentStruct
; members declaration
ends

class MyClass, parentClass
    begin_interface IMyInterface, parentClass_parentInterface, m_myInterface
        begin_method myMethod, ...
              push ebx
               ...
              pop ebx
              ret
        end_method
    end_interface

    begin_interface ...
    end_interface


    BEGIN_COM_MAP
        ...
    END_COM_MAP

    BEGIN_MSG_MAP
        ...
    END_MSG_MAP
end_class
    


It will be like an ATL library, but implementation will be in binary form (in dll, not in source code). Object creation and destruction support also will be in binary form, not as macros.

Now library supports multiple inheritance, smart pointers (both local and contained as class members), event model based on IConnectionPoint interface. It is not packed as dll yet, macroses are not tested, deriving from a class implemented in another dll is not tested.
Post 24 Jan 2007, 09:41
View user's profile Send private message ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
i didn't say you should use C#. I say, if you don't know assembly, use Java (more portable, ahem). If you know assembly, use C++ (unusable without knowing what is behind, but strong and good if you understand it)
Post 24 Jan 2007, 11:24
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Mr_Silent



Joined: 25 Apr 2006
Posts: 30
Funny... The interesting part about bringing OOP in assembly is that everyone tries to bring in a different langugage's object model. How about Smalltalk? Smile Wink :0
No offence here, cos' theese holydays I tried to complete the third revision of my own implementation of OOP in asm (yeah, yeah, everyone wants to be a Stroustrup). That was fun, since I was able to discover mush more power in this this single-pass preprocessor, and I wonder how much is still beyond Smile Smile Smile Smile
Post 24 Jan 2007, 12:54
View user's profile Send private message Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
Quote:

It will be like an ATL library


Contact civil defense, alert the fire brigade, call in the army, afw2004 is making something similar to the ATL library Shocked

Just kidding afw2004 Wink



Quote:

.NET or C++ or other OO languages


tantrikwizard, this sort of talk is often defined as 'delusional schizophrenia' Smile


BTW guys, I don't know if you've heard of a really cool thing called FASM ..... I've heard it's got something to do with programming Wink
Post 24 Jan 2007, 13:55
View user's profile Send private message Reply with quote
tantrikwizard



Joined: 13 Dec 2006
Posts: 142
madmatt wrote:
I agree with vid, you should use C-Sharp (preferred) or Managed-C++ if you like Object Oriented programming. Fasm has the if/endif, while/endw, repeat/until, etc., This is quite high level enough, and many people think that's even too high level. In my opinion, OO Assembly is more trouble than it's worth.

With all due respect, we have seen this argument repeated time and again. This thread is not aimed at discussing why or why not to do OO in asm, rather contributions and discussion on how the library IS GOING to be built. OO in asm is here to stay, it may not be your particular preference but some use it heavily. Sense OO in asm is not going away, this thread is intended to contribute to said library and assist developers of same in standards, ideas and macros.
Post 24 Jan 2007, 14:08
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
tantrikwizard



Joined: 13 Dec 2006
Posts: 142
afw2004 wrote:
It will be like an ATL library, but implementation will be in binary form (in dll, not in source code). Object creation and destruction support also will be in binary form, not as macros.


I'm a bit unclear about this. These functions would be need to be imported from an external library? What about cross-platform ability?

afw2004 wrote:
Now library supports multiple inheritance, smart pointers (both local and contained as class members),


So would there be a sort of QueryInterface method of classes or does the external library handle the parent inherited classes?

afw2004 wrote:
event model based on IConnectionPoint interface. It is not packed as dll yet, macroses are not tested, deriving from a class implemented in another dll is not tested.


This sounds excellent and I would like to take a look at it. Would you be willing to contribute what you have to an open source collaborative project?
Post 24 Jan 2007, 14:37
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
afw2004



Joined: 16 Jun 2005
Posts: 49
Location: Kharkov, Ukraine
I am not planning to develop cross-platform library

Quote:

So would there be a sort of QueryInterface method of classes or does the external library handle the parent inherited classes?


Yes, all classes is derived from IUnknown interface, but all methods of IUnknown, are implemented in library dll.

Quote:

Would you be willing to contribute what you have to an open source collaborative project?


I will upload my sources on this week, but macroses are not done yet..
Post 24 Jan 2007, 14:56
View user's profile Send private message ICQ Number Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1046
Location: Michigan, USA
Let me correct myself a little, OOASM might be useful with the new dual and quad core intel/amd processors coming out now. OOASM might help keep things more organized and you and your code a little more sane.
Post 25 Jan 2007, 00:37
View user's profile Send private message Reply with quote
afw2004



Joined: 16 Jun 2005
Posts: 49
Location: Kharkov, Ukraine
Here is my sources. It is can not be compiled now, because I begun to implement macroses (and these macroses is not working now).


Description: source code for OO library
Download
Filename: stltest.zip
Filesize: 50.95 KB
Downloaded: 353 Time(s)

Post 25 Jan 2007, 09:03
View user's profile Send private message ICQ Number Reply with quote
KRA



Joined: 14 Jun 2005
Posts: 24
class CRect RECT
func Width ()
mov eax, dword [ebx+RECT.right]
sub eax, dword [ebx+RECT.left]
clc
test eax, eax
ret
endf
endc CRect

class CArea CRect
func someFunc ()
this Width()
ret
endf
endc CArea

------- Usage

new CArea
ocall eax CArea someFunc ()
ocall eax CArea Width ()

handling inheritance, virtual routines etc...

Interesting ????

currently creating a package built on FLTK so that same code can be
used both in windows and linux
This is part of my own library called FOOLIB ( Flat Object Oriented LIBrary)
Post 25 Jan 2007, 19:11
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
KRA: any links? what is your error handling mechanism?
Post 25 Jan 2007, 19:26
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
KRA



Joined: 14 Jun 2005
Posts: 24
Actually it should be built in the same way your FASMLIB is. It actually
uses it for memory, string and streaming. Since I have no package ready
to show I have NOT given i out yet. But quite soon I will post my first example on how it could be used.
Must way I love your FASMLIB since it makes me able to test my code on both windows and linux.
I run andLinux in windows XP and it works great.
Whenever I want to I enter the console of the linux distro (ubuntu) and are able to test the build and the executable.
Post 27 Jan 2007, 10:33
View user's profile Send private message Reply with quote
KRA



Joined: 14 Jun 2005
Posts: 24
Vid: Have you considered porting FASMLIB to ARM4 as well ???
Post 27 Jan 2007, 10:35
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.