Did anybody programmed OOP in MASM? Can there be realized the model like in TASM?
Posted on 2001-01-09 02:45:00 by The CHEMI$T
Object Orientated Programming is a high level language construct. What do you mean by an assembly language object? What's TASM got that MASM doesn't (I've only briefly looked at TASM) to make objects?
Posted on 2001-01-09 03:51:00 by Ernie
CHEMI$T, OOP is as much a concept as a programming technique, most modern implimentations are technically poor but it does not need to be that way. You can use the traditional procedural model to write your own objects and you can use assembler modules to fully encapsulate code that you have written which makes object construction easier but you will not find VB / VC style models of OOP in assembler, they are built into the compilers thay use and are the other end of programming from assembler code. IDEAL mode died with TASM and most cheered its demise, me among them :) Regards hutch@pbq.com.au
Posted on 2001-01-09 03:56:00 by hutch--
Object Oriented Programming comes in at least three different flavors. 1) The simplest version is also called object-based, and many do not consider it to be OO, because it has no concept of classes and therefore no concept of inheritance. Microsoft's COM is a static version of this type of programming. Languages like Self provide a dynamic form, each object is potentially a prototype or exemplar of a new object. To create a new object, you clone it and optionally modify it. Executable code can be managed as objects. This provides the same kind of flexibility associated with LISP. 2) The mainstream form of OO is also called single receiver, single dispatch, or class based. Each method (subroutine) called is associated with a single class of objects. The most common method of implementing the sharing of methods is for all objects of the same class to point to an address or jump table. This table is known generically as a dispatch table. C++ programmers know it as the vtable. Inheritance with modification involves making a copy of the dispatch table and changing or adding entries in it. OOPL compilers make these modifications at compile time. With most assemblers, this would require cut-paste-edit unless you want to build these tables at runtime (as part of initializing your program). Since address tables are also used to implement switch or case statements, you could implement the dispatch table with a bunch of if-else's. Just like the message handling code in your window or dialog proc. Inheritance would be implemented just like window subclassing. (As a matter of fact, one OOPL compiler actually generates this kind of code.) 3) Another form of OO allows multiple dispatch. In this form methods are not associated with a single class of objects. The method chosen depends on potentially more than one object. It's a little like C++ function overloading, except that you don't know the exact object types at compile time. The most generic form requires a lookup table. You can use hashing or some other scheme to speed up lookup.
Posted on 2001-01-09 15:27:00 by tank
Yeah... I see now, what it is... I'm trying to solve this problem for now by building my own model, it consists from a kernel and a lot of macroses, which make programming VERY easy (of cause there are a lot of problems, but it works). And I know that OOP can be realized by the procedural model, but why I must do that? What TASM has, which is not realized in MASM? There you can do something like that: List STRUC GLOBAL METHOD{ Construct:Dword = List_Construct virtual Insert:Dword = List_Insert Destroy Dword = List_Destroy } List_Insert PROC PASCAL NEAR ARG @@List:Dword, .... List_Insert Endp And this is all I need. Maybe someone tryied this?
Posted on 2001-01-09 21:01:00 by The CHEMI$T
You keep quoting TASM. This is a MASM board. I don't speak TASM. WHAT are you attempting to do with that code?
Posted on 2001-01-09 23:25:00 by Ernie
I know, you asked for an example, I gave it to you! I need the type of describing objects like it realized in TASM. It's easier for me. But of course, I can realise it by miself.
Posted on 2001-01-11 23:41:00 by The CHEMI$T
If you cannot clearly state your problem you'll never get to the solution. Copying some code you don't understand is NOT giving an example. Stating what you need to do IN ENGLISH (even broken english, it's understood and accepted we're not all native speakers) gets you help. Pasting code from some obscure off-board language is a waste of time.
Posted on 2001-01-12 00:04:00 by Ernie
I believe his problem is that he wants to write in pure Object Oriented programming, not 'emulated OOP'. (I use emulated for lack of a better word.) He keeps referring to TASM because ever since version 4, TASM has supported a system of Object Oriented programming. However, since MASM does not, you CANNOT use native OOP techniques in Microsoft's Assembler. You must write macros and/or design your own OOP system to use. Since this is rather extreme, most Assembly programmers on this board will say not to do it unless you need to (ie: writing OCXs, using DirectX/OpenGL, etc.) However, if you wish to use TASM's native OOP programming, you should check out a forum deticated to TASM, not MASM. I'd be willing to bet that over 90% of the people on this board don't even KNOW TASM supports Object Oriented Programming, much less how to use it effectively.
Posted on 2001-01-12 01:03:00 by Racso
I'd bet near 100% of the people on the MASM board don't know dirt about TASM. It's off topic. I read about tasm oop in Kauler's Windows Assembly Language book, it did not impress me as anything relevant or useful, but it's a confused book with no clear direction. He didn't aid me a bit in writing the COM library for masm32.
Posted on 2001-01-12 01:16:00 by Ernie
Thanx for all of your replies, but I made it all by myself.
Posted on 2001-01-12 01:38:00 by The CHEMI$T
All he's trying to do is convert TASM OOP techniques into MASM, which is very much ON TOPIC here. Or do you think people should post COM/C++ to ASM questions on a C++ board?
Posted on 2001-01-12 01:48:00 by Racso
TASM's OOP stuff seems only to make it easy to do inheritance. You can use prefixing and separate files to do "encapsulation". What I expect TASM to be doing is storing addresses of "virtual" functions in the structure. If you have 15 virtual functions, and you only need to change 2 of them to create a structure for another (derived) class, TASM copies the entries for the 13 unchanged functions for you. The two entries don't need to be consecutive, so you don't need to reorder the entries. Plus, you don't need to list the functions when initializing the structure. I haven't checked to see whether the function addresses are embedded in the structure (like the window proc function in WNDCLASSEX), or if they are gathered together in a separate structure (the C++ way).
Posted on 2001-01-12 17:58:00 by tank
Rasco: I was getting quite frustrated with this guy because he's asking about stuff I routinely do in masm, but he's asking in such a way I HAVE NO IDEA WHAT HE WANTS. And when asked for more info, he evadeds and receeds. A waste of time. I'm still wondering what magic TASM had that MASM supposedly lacks so it can't do what I do with MASM. (Hey, I might even learn a new trick or something).
Posted on 2001-01-13 07:23:00 by Ernie
Ernie: I didn't try to recede or evade something! For me, what I told was FAR enough to understand what I really need. If you didn't understand me - write! I not talking that TASM is better in any way than MASM. I HAD NO IDEA that it is so bad topic for'ya. I tried a lot of languages, I'm trying to see what new is realized in any of them, and than if I see anything that can help me - I try to realize it in any way. Read my first post in here. I needed only an advice, or maybe some sources if someone tried it. I like the way Interfaces done in Masm, and I want to see REALLY WORKING OOP MODELS IN MASM. In sources in ideas or ... And if there is need to talk, please, anytime write me a letter: dovgalenko@bratsk-city.ru
Posted on 2001-01-14 01:12:00 by The CHEMI$T
CHEMI$T, I'll try asking you again. What are you trying to do in OOP in MASM? This is the first questionI asked. It's not about code, it's conceptual. Not about code because, pure and simply, NO assembler can do OOP, OOP is a high level CONSTRUCT. One may simulate OOP in a few ways, but most features are just not available... For example, anyone can set a ponter to the object structure and read out all the data members, including the private ones. There goes encapsulation. It's just not possible in asm. I've done lots of stuff for COM, see either my site (here.is/cominasm) or the new MASM32 service pack.
Posted on 2001-01-14 02:07:00 by Ernie
For me, that'd be enough to see just realized model of describing objects, like it is realized in TASM. I wonna try it. First of all, I think that mostly all of the windows/controls/files or etc. which Windows give us would be easier to describe as objects. I would like to see something like Visual Assembler, and it must be not just editor! It MUST have it's own programming model or something like that... And I realized some kind of programming model which helps me now to write good programs in no time. But I need inheritance, and a lot of other features, which I'm trying to realize.
Posted on 2001-01-17 01:21:00 by The CHEMI$T
CHEMI$T, This has been an interesting discussion, if a little convoluted. It seems you want the capacity in TASM to do certain types of abstraction without losing the performance advantage of MASM. Sad to say it cannot be done. The right place to design OOP style programming is at the compiler level, an assembler is a high level language in that you are not directly working with opcodes. OOP of whatever flavour is conceptually different in that it does not directly address such concerns as registers and other hardware, it is a conceptual level type of programming. Wanting to program OOP in an assembler is like trying to have your cake and eat it, sell it and flaunt it at the same time. assembler can deliver in speed and size terms but it is done at a low level, OOP is easier to write if you bother to learn it but it is not a performer in size & speed terms. With modern implimentations of OOP, if you want the gimmicks, you get the bloat as well, thats the price of trying this style of coding. If you are willing to accept the overhead you should be working with a compiler designed to do that type of coding. What has been suggested is that you can do a lot of OOP based code at a procedural level if you bother to write it but it will not be the same as compiler based OOP. Regards, hutch@pbq.com.au
Posted on 2001-01-17 03:49:00 by Steve Hutchesson
On the other hand, it makes sense to implement the mechanics of OOP at least once, just to know how much overhead is involved. As others have said, forget about encapsulation. At ASM level, you use the same techniques for encapsulation as C (not C++) code. I've recently looked at TASM's OOP as documented for TASM 4.0. The only thing that appears to be much, much easier to do directly (rather than using macros or cut-paste-edit) is inheritance of subroutines (methods). The benefits only come when you have a chain of inheritance and need to change the base classes. Some OO programmers believe such inheritance is overrated and overused. ...To retain the flexibility and maintainability without using the special inheritance feature is best done with "delegation" or what J.Coplien (in one of his advanced C++ books) calls "forwarding". That adds at least another jump to each "inherited" routine at each new level. ...The terminology used by TASM's features are those used by Object Pascal (presumably now called Delphi). So the dispatch (method) tables are created separately from the "object structure". This is mainstream style, as implemented in Delphi and C++. The TBLINST directive is weaker than I expected -- it only creates one dispatch table. ...You still do all of the work of allocating and deallocating objects. Constructors and destructors are not automatically called. Initialization is trivial -- store a pointer to the dispatch table into your object structure at a standard offset, and call your object initialization routine. Calling methods involves passing the object's address somehow -- either in a register (perhaps ECX) or on the stack. Calling "nonvirtual" methods is a direct call -- who needs special notation for that? Calling "virtual" methods is trivial -- it is simply an indirect CALL using the object's dispatch (address) table. If all this sounds too much like non-OO code, all I can tell you is: this is what mainstream OOPL compilers generate.
Posted on 2001-01-17 22:25:00 by tank
Having been there, done that, AND got the T-shirt... Low level object programming in MASM is quit possible, doable, lightweight, and practicable. How you implement it is, of course, your choice. But certain guidelines should be upheld. An object is basically run-time allocated memory. The basis behind all of OOP is sending the method code a reference to the object being worked with. This reference is typically called "THIS" THIS is the address of some part of the object, so THIS can be used to reference any part of the structure. And by imposing the THIS to point to the implementation method pointer (or virtual) table gives us a simple way of implementing dynamic casting (more on this later). As a minimum, any OOP implementation will need 3 functions: CreateObject, DestroyObject, and DynamicCast. It's often heard a CLASS defines the OBJECT. In practical terms, a CLASS is a set of definitions of how the object should be built. It is just a structure, it contains the values that define in some way, what the object will be. The CreateObject method takes a pointer to a class definition structure, and creates an object to this model. Should special object initialization be needed, the CLASS may be defined with a pointer to a custom initialization method. The CLASS may also contain a custom release method for DestroyObject to use so it may clean up after itself. DynamicCast can give you fits until it gels in your mind. It comes about because there are two types of inheritance possible: single (or direct) and multiple. Single inheritance implements the "is-a" relationship. Multiple inheritance implements the "has-a" relationship. They work like so: Class Joe{ISA Man} Class Man {ISA Human} Class Human{ISA Mammal} This defines a single inheritance model for Joe. However, is we want Joe to be able to wave his hand and walk and talk, we need something else like: Class Joe{ISA Man} Class Man {ISA Human} Class Human{HASA Mouth, HASA RHand, HASA LHand, HASA LFoot, HASA RFoot} Class RFoot {ISA Foot} Class LFoot {ISA Foot} and so on. The point being, if we have a reference to Joe, we need some way to find his foot to get him moving! Somehow his object must contain all these other details. That is why you need THIS to point to the object, and then on to the function table. You will need to change THIS if your class needs a dynamic cast. THIS points to one member of a table of pointers, each pointing to a different implementation table. I will admit my CLASS models take a few shortcuts: only the bottom level (most derived) CLASS may have data members, and the function tables must be assigned directly (this is mostly due to the 500 characters per line limit of MASM when defining structures). Macros handle class member definitions such that the interface inheritance is realized, which is far more important to easy coding then having the function pointer table filled in for you (which you would have to implement by getting the proc names the same anyway). How much overhead does it all bring? The gross line count for these routines, heavily commented, with compile directives to make an object library is thus: CreateObject 174 lines DestroyObject 54 lines DynamicCast 133 lines Objects are: 4 x (7 + (data members in dwords) + 2 x (interface count + 1) ) bytes IE, a direct CLASS (no inheritance), with 1 DWORD of data would be 40 bytes. Finally, objects are just necessary. The Windows OS will continuously increase it's reliance on Common Object Model techniques, and those who refuse to learn them will forever be kept from some very interesting places. PS: I'm still curious about what TASM's got that MASM doesn't for OOP
Posted on 2001-01-18 01:49:00 by Ernie