flat assembler
Message board for the users of flat assembler.
Index
> Main > OO assembly Goto page 1, 2 Next |
Author |
|
vid 17 Dec 2006, 03:36
it would be possible with FASM macros. But there is no reason to do it. you can do OOP without any macros at all.
|
|||
17 Dec 2006, 03:36 |
|
kohlrak 17 Dec 2006, 04:32
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.
|
|||
17 Dec 2006, 04:32 |
|
Erikina 17 Dec 2006, 05:09
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. |
|||
17 Dec 2006, 05:09 |
|
kohlrak 17 Dec 2006, 05:20
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.
|
|||
17 Dec 2006, 05:20 |
|
Mac2004 17 Dec 2006, 09:54
Hi Erikina!
Quote:
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 |
|||
17 Dec 2006, 09:54 |
|
vid 17 Dec 2006, 12:32
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 |
|||
17 Dec 2006, 12:32 |
|
tantrikwizard 18 Dec 2006, 16:13
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. |
|||
18 Dec 2006, 16:13 |
|
vid 18 Dec 2006, 16:16
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
|
|||
18 Dec 2006, 16:16 |
|
MichaelH 18 Dec 2006, 20:50
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.
|
|||
18 Dec 2006, 20:50 |
|
flash 22 Dec 2006, 01:35
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.
_________________ i don't hate goto |
|||
22 Dec 2006, 01:35 |
|
vid 22 Dec 2006, 01:59
unless HLA has some specifc OOP macros, there is no reason to use it for this
|
|||
22 Dec 2006, 01:59 |
|
flash 22 Dec 2006, 14:14
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 |
|||
22 Dec 2006, 14:14 |
|
vid 22 Dec 2006, 22:08
flash: do you understand what code is produced by those statements? If no, don't use them.
|
|||
22 Dec 2006, 22:08 |
|
Kain 24 Dec 2006, 02:52
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. |
|||
24 Dec 2006, 02:52 |
|
hopcode 25 Mar 2008, 06:14
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 http://ourworld.compuserve.com/homepages/ernies_world/a.htm .:;. . Last edited by hopcode on 29 Mar 2008, 05:20; edited 2 times in total |
|||
25 Mar 2008, 06:14 |
|
vid 25 Mar 2008, 09:48
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 |
|||
25 Mar 2008, 09:48 |
|
daniel.lewis 25 Mar 2008, 23:51
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. |
|||
25 Mar 2008, 23:51 |
|
itsnobody 26 Mar 2008, 02:51
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 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 |
|||
26 Mar 2008, 02:51 |
|
daniel.lewis 26 Mar 2008, 06:30
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? |
|||
26 Mar 2008, 06:30 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.