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:

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.

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

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.



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).



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.



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.

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]


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.

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:

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.


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.

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.

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.

I work now on such library implementation. I think it could be done in 2-3 weeks. It will use the following syntax:




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.

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)

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? :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

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

Just kidding afw2004





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


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

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.

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



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



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?

I am not planning to develop cross-platform library



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



I will upload my sources on this week, but macroses are not done yet..

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.

Here is my sources. It is can not be compiled now, because I begun to implement macroses (and these macroses is not working now).

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)

KRA: any links? what is your error handling mechanism?

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.

Vid: Have you considered porting FASMLIB to ARM4 as well ???