flat assembler
Message board for the users of flat assembler.

Index > Main > OO assembly

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



Joined: 06 Apr 2006
Posts: 8
Erikina
I was wondering, would it be feasible to have object oriented assembly? I've come up with a little class using c++ish syntax.

I'm assuming all methods are private, and member variables private. For methods I use the syntax

method_name(parmaters) : returnType


Code:
class counter; A simple counter class
{
        int TheCount; this stores the count
        int Increment; this is how much to increment the counter by
        
        constructor() : void ;is the contructor. Constucts the class. returns void/nothing
        {
                mov TheCount, 0
                mov Increment, 1
        }
        
        constructor(int increment) : void ; overloaded contructor
        {
                mov TheCount, 0
                mov Increment, increment
        }
        
        
        Increment() : void ;returns nothing
        {
                add TheCount, Increment
        }
        
        Value() : int ;returns an int
        {
                return TheCount
        }
        
        Value(int set) : void ;overloaded to set value
        {
                mov TheCount, set
        }
        
        destructor() : void ;...this is the destructor
        {
                ; doesn't do anything. No-need. 
        }
}
    


Anyone got any thoughts? Very Happy
Post 17 Dec 2006, 02:30
View user's profile Send private message MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
it would be possible with FASM macros. But there is no reason to do it. you can do OOP without any macros at all.
Post 17 Dec 2006, 03:36
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
I'm assuming you're starting to use assembly after knowing C++. It's a thing alot of people have trouble with when moving from an OOP language. They are taught the OOPs in a wrong way and become dependant on the object orientation. When i started out i was expecting a later chapter on functions, but i'm still learning and still havn't seen anything about functions, with the exception of procs. I also had this problem with learning foreign languages like french and japanese, i expected to learn equivalents of "the." The french have "la," le," "l'," and "les" which are all forms of the word "the," and japanese does not have a word for "the." Enough practice and you'll quickly see that you can easily make code without the objects, though you can declare structs.
Post 17 Dec 2006, 04:32
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Erikina



Joined: 06 Apr 2006
Posts: 8
Erikina
Yes, I am starting assembly after OO programming. Admittedly, I am quite dependant on it.

Without it, is practical making large programs in assembly? Doesn't it get all messy without the nice encapsulation OO languages offer? As a c++ programmer, you always hear that large programs in C become unmanageable as they get large – wouldn’t you get the same in assembly?

Regards,
Eric.
Post 17 Dec 2006, 05:09
View user's profile Send private message MSN Messenger Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Well, you have macro just like in OOP, only the macro in this programmng language take parameters, just like functions. And the encapsulation is a big ugly to even me. And that's a false rumor about C. I find programs get umanagable when you have so many objects and functions that you don't know what they do. To be honest, i never found much of an advantage to objects. Once you get used to assembly, you'll understand how to keep your code manageable. And if worst comes to worst, you can either group them as coffs and link them together, or if you think you might update it at a later time, use DLLs, which'll make it easier to update your program as well.
Post 17 Dec 2006, 05:20
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 313
Mac2004
Hi Erikina!

Quote:

Without it, is practical making large programs in assembly? Doesn't it get all messy without the nice encapsulation OO languages offer? As a c++ programmer, you always hear that large programs in C become unmanageable as they get large – wouldn’t you get the same in assembly?


I have been writing big assembler project for a couple of years and I can say that big assembler projects can be handled as well. Of course it requires planning how organize things and keep them in hand!

regards,
Mac2004
Post 17 Dec 2006, 09:54
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Erikina: "unmannageable once they get big" means much bigger than you probably think. Look at pretty well managed programs in C, which are huge. OO programs are more manageable (thinner interfaces between layers), but on other side objects introduce many more abstraction layers than you would have in structured programming, so all becomes a "design mess".

2nd: i bet you got those statements from some theoretists. They are really not the right people to give ideas on this topic.

To object oriented programming in ASM: you have to implement it yourself (or use macros, but none such are written yet), just like you would do in C:
- declare structure (class) with pointers to functions (methods)
- these methods always take pointer to structure instance (this pointer) as first argument, so they can change their data
- if you want to inherit class2 from class1, you just make first data of class2 same as class1, and add more data after. This makes sure you can use class1 procedures with it.

This is, by the way, how COM objects work (not exactly, but...). Of course you must handle yourself some things which are automatic in C++ this way, but it is not problem.

Maybe some demo of creating COM object in assembly would help
Post 17 Dec 2006, 12:32
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
tantrikwizard
vid wrote:
Maybe some demo of creating COM object in assembly would help


Here's a link to doing COM in MASM http://ourworld.compuserve.com/homepages/ernies_world/a.htm it can be easily done with FASM too. I've worked with a macro library for OO in TASM called TOM (TASM Object Model) written by KomsBomb which automates interface and object decleration and VTBL creation, but a quick search on the net looks like its no longer around. I would like to see some standard OO macros for object decleration, VTBL creation and such with FASM, will probably create these when I get a better understanding of FASM's macro language. Right now I'm coding it by hand which isnt much code at all and easily managable.
Post 18 Dec 2006, 16: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: 7105
Location: Slovakia
vid
i was thinking about writing such macros, but i don't think it is good to let people use them when they don't know what they do. and, as you say, it's no pain to do it by hand
Post 18 Dec 2006, 16:16
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
Good point Vid. Going by the number of new comers that are struggling to understand how procedures set up the stack, maybe a small tutorial on creating a PE file without macros would be a good idea first.
Post 18 Dec 2006, 20:50
View user's profile Send private message Reply with quote
flash



Joined: 11 Mar 2006
Posts: 55
Location: Cuba
flash
Well, this is curious. Anayway you can use HLA (High Level Assembly). In some place of this foro, you can find FASM libraries for it. Excuse me for my few information but I never test this HLA thing.
Question

_________________
i don't hate goto
Post 22 Dec 2006, 01:35
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
unless HLA has some specifc OOP macros, there is no reason to use it for this
Post 22 Dec 2006, 01:59
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
flash



Joined: 11 Mar 2006
Posts: 55
Location: Cuba
flash
I found some intresting HLA documentation at:
http://webster.cs.ucr.edu/AsmTools/HLA/index.html

On the HLA guide there is a point:

14.13.1 Classes, Objects, and Object-Oriented Programming in HLA
HLA provides support for object-oriented program via classes, objects, and automatic method invocation. Indeed, supporting method calls requires HLA to violate an important design principle (that HLA generated code does not disturb values in any registers except ESP and EBP). Nevertheless, supporting object-oriented programming and automatic method calls was so important, an exception was made in this instance. But more on that in a moment.

And some examples:
Code:
type baseClass : class
var
    i:int32;
procedure create; @returns( "esi" );
procedure geti; @returns( "eax" );
method seti( ival:int32 ); @external;
endclass;

procedure baseClass.create;
begin create;
    push( eax );
    if( esi = 0 ) then
    malloc( @size( baseClass ));
    mov( eax, esi );
endif;
mov( baseClass._VMT_, this._pVMT_ );
pop( eax );
ret();
end create;

procedure baseClass.geti; @nodisplay; @noframe;
begin geti;
    mov( this.i, eax );
    ret();
end geti;

method baseClass.seti( ival:int32 ); @nodisplay;
begin seti;
    push( eax );
    mov( ival, eax );
    mov( eax, this.i );
    pop( eax );
end seti;
    


I hope this help you
Luis Enrique

_________________
i don't hate goto
Post 22 Dec 2006, 14:14
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
flash: do you understand what code is produced by those statements? If no, don't use them.
Post 22 Dec 2006, 22:08
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Kain



Joined: 26 Oct 2003
Posts: 108
Kain
You can always look at the .asm files to see exactly what code is produced. It's pretty straight-forward. VMTs are pointers to the virtual method tables and just about the only extra code generated are the procedure frames (unless @nodisplay; @noframe are specified).

It's not the most efficient method. For example, every time a class procedure or method is called (except when ESI is specifically used as a reference), esi and edi are loaded with object pointer and vmt pointer.

But the advantage of OOP support built into the language is that it will be a consistent and standardized language structure which will make it easier for anyone who knows the language to understand.

In macro assemblers, this is not the case since everyone has their own idea on how OOP should be implemented and you end up with many OOP formats with few people who use them or even understand code written in OOP.
Post 24 Dec 2006, 02:52
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
Hallo to all,
I am a newcomer in this superforum.I want to thank all of this forum, and in
particular Tomasz, who has created a fantastical macro compiler.

I have spent my last month only in learning by reading your already posted code. As first post, i want to submit an implementation of building objects
and classes.
This is NOT optimized. Perhaps it is different from the STANDARD implementation of classes and objects as in C++, i dont know it
very well.
Let me know, your ideas or eventual bugs in
my code.
Thanx all,

Here the code
...
updated -> see following posts
zipped file attached
.
BTW
perhaps an already well-known link
on COM & ASM. Good material from
the competition Twisted Evil
http://ourworld.compuserve.com/homepages/ernies_world/a.htm
.:;.
.


Last edited by hopcode on 29 Mar 2008, 05:20; edited 2 times in total
Post 25 Mar 2008, 06:14
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
keeping method pointers right in class object isn't the best idea, it's a waste of memory.

i suggest reading this: http://x86asm.net/articles/oop-from-low-level-perspective/index.html
Post 25 Mar 2008, 09:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
I've yet to encounter a reason to encapsulate information. Export symbols that are meant to be used by others.

An optimal program should not duplicate (inherit) algorithms by default.

Anything being created more than once could well enough go in an array and be block allocated to improve performance by invoking malloc() less.

Anything being allocated only once could probably well enough be declared static.

Storing data and code in the same memory is bad. This is because when you write to memory on the same cached page being executed, it gets flushed from code cache; consuming ~100 cycles as it reloads the new data before continuing execution.
Post 25 Mar 2008, 23:51
View user's profile Send private message Reply with quote
itsnobody



Joined: 01 Feb 2008
Posts: 93
Location: Silver Spring, MD
itsnobody
Erikina wrote:
I was wondering, would it be feasible to have object oriented assembly? I've come up with a little class using c++ish syntax.

I'm assuming all methods are private, and member variables private. For methods I use the syntax

method_name(parmaters) : returnType


Code:
class counter; A simple counter class
{
 int TheCount; this stores the count
 int Increment; this is how much to increment the counter by
 
    constructor() : void ;is the contructor. Constucts the class. returns void/nothing
      {
              mov TheCount, 0
             mov Increment, 1
    }
      
    constructor(int increment) : void ; overloaded contructor
       {
              mov TheCount, 0
             mov Increment, increment
    }
      
    
    Increment() : void ;returns nothing
     {
              add TheCount, Increment
     }
      
    Value() : int ;returns an int
   {
              return TheCount
     }
      
    Value(int set) : void ;overloaded to set value
  {
              mov TheCount, set
   }
      
    destructor() : void ;...this is the destructor
  {
              ; doesn't do anything. No-need.        
    }
}
    


Anyone got any thoughts? Very Happy


I don't know about the constructors/destructors, but you can kind of have OOP in FASM like this:
Code:
struc counter {
      .TheCount dd ?
      .Increment dd ?

      proc .constructor
           mov [.TheCount], 0
           mov [.Increment], 1
      ret
      endp

      proc .IncrementCount
           mov eax,[.Increment]
           add [.TheCount],eax
      ret
      endp
}  
    


I've made lots of objects this way, works similarly to a class, though not exactly the same, more low-level


Last edited by itsnobody on 26 Mar 2008, 14:12; edited 1 time in total
Post 26 Mar 2008, 02:51
View user's profile Send private message Reply with quote
daniel.lewis



Joined: 28 Jan 2008
Posts: 92
daniel.lewis
Confused forgive me if I'm wrong, but your code would take upwards of 120 cycles to Increment.

It would take ~16 cycles to reload the instruction pipeline through call and then ret. Another cycle for the mov, and 100 cycles because you wrote to memory currently in code cache being executed, which would invoke a cache miss as the code cache block is reloaded with the newly incremented value.

Am I off?
Post 26 Mar 2008, 06:30
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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.