Object Oriented Assembler

Thomas G. Marshall wrote:

But is assembly considered inherently procedural?

Any language that supports indirect transfer of control (jumping to a FunctionPointer) can be used to implement ObjectOriented principles.

In 1977 I wrote a significant amount of true object oriented code in 8080 AssemblyLanguage. This was not theoretically OO code, this code has a hard constraint to be OO. We were using 2708 EPROMS that held only 1K bytes of memory each. We had a 32K program. If we compiled that program as a single executable, then every time we made a one line change we'd have to reburn 32 EPROMs per machine and ship them to all the hundreds of installed sites. This was unacceptable.

Thus, I partitioned the system into 32 little objects, each of which fit neatly on a single EPROM. Each EPROM declared a set of entry points into itself. These entry points were copied into RAM vectors. Anybody who wanted to call a function, called it through the RAM vector. (We'd now call them vtables).

This allows us to recompile individual EPROMs and ship them to the customers. They could pop out the old ones and push in the new ones and the system would just run. We could also make easy patches by rerouting a vector to RAM, copying some code to that RAM and then patching it.

This may not seem like traditional OO, and certainly the system was not designed with this kind of partitioning in place. On the other hand, from a purely mechanical point of view, those EPROMs were objects that used DynamicPolymorphism? to break dependencies between them.

-- RobertCecilMartin

Hey TopMind, read this; that's why we like OO. :)

Afraid not. RobertCecilMartin's system described above might or might not be OO; there isn't enough detail to say for sure. All we can say for sure is that he carved the program up into small pieces, very similar to hand-loaded overlays that have been used since the 1950s on systems without virtual memory.

I did similar work on 8080s and 2780s, and what he's describing is very familiar. He's just dressing it up in OO terms as far as I can tell.

To be truly OO requires more: for each unit of encapsulation to be a single data item of a single type along with exactly those operations that concern that data type/item; no more, no less.

Martin's 8080/2780 may or may not have done this. I very much doubt that he did, actually, given my own experience back then in this area (and yes, I knew what OO was at the time).

It is definitely possible to do OO in assembler, of course, and I have. So no, no language is inherently procedural. However, assembler doesn't give any support for non-procedural methods. Obviously.

I should mention that people find ways to do purely procedural programming even in OO languages, and I don't mean just in C++. Just as one can fake OO programming in a non-OO language, one certainly can fake purely procedural programming in Java or even Smalltalk. The result is of course superficially OO, but not in a good-practices sense.

There is far more to OO than the language one uses. Bad practice knows no boundaries.

-- DougMerritt

I think the point is that OO is simply a way of thinking, a way of spreading around responsibility. It can be done in any language, OO languages just help enforce some of the ideas and make things easier, but the code is OO whether or not the languages enforces the concepts. For example, a lack of forced encapsulation doesn't mean it's not OO, as long as the code uses encapsulation as a concept. OO is about certain concepts, not the implementations of them. Rob Martin is a respected OO vet, if he says it's OO, then it's OO, who are you to question him on something he wrote?

RCM's definition of OO is essentially the DependencyInversionPrinciple. This is useful at times, and IMHO far better than the C++/Java notion of "a bunch of related functions with their associated data." But it's at odds with other respected OO vets, notably AlanKayOnObjects and the NygaardClassification, along with the common definition that appears on ObjectOrientedProgramming (which appears to be what Doug is going by). RCM's definition is also overbroad for many practical reasons. For example, FunctionalProgramming would classify as OOP under the dependency inversion principle, as would any form of first class procedures (including eval!) -- JonathanTang

No, that's not his definition, that's one of the principles he abides by, probably the most controversial of the bunch. You can't look at this principle in isolation; you must include the others to see the full picture. The SingleResponsibilityPrinciple, The LiskovSubstitutionPrinciple, The InterfaceSegregationPrinciple, The DependencyInversionPrinciple, Stability, Granularity, and The OpenClosedPrinciple are all things RobertCecilMartin subscribes to. Some of his beliefs seem strong, DependencyInversion possibly, but I'd say that's from his Manifest typed C++ heritage and long compile times. He's more than qualified to say something he wrote is OOP or not, and just as much an expert as Ward or Kent, IMHO.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3bb75285.7175698%40news.supernews.com. And I'm not referring to Ward or Kent when I say "other OO vets", I'm referring to AlanKay (inventor of SmallTalk and the term "object-oriented") and KristenNygaard (inventor of Simula, widely acknowledged as the first OO language.

In that post, Martin says: "I define Object Oriented programming as programming in which abstractions are independent, and concrete modules depend upon them. i.e. Dependency Inversion." He couldn't be any clearer than that.

Jonathan is making a better argument than I would have (thanks!), so I will just add that this is a classic example of why appeal to authority is a logical fallacy. Who am I to (gasp) question an expert? Heh. So if you considered me a famous expert on this topic, then maybe I'd be right after all? Maybe I am, and you just need to get out more. ;-)

-- DougMerritt

Fine, so we can now agree that no one can agree one what OO is, great accomplishment. Let me put it this way, I've seen SmallTalk, and it's OO, I've seen Roberts code, and it's OO too. There may not be an exact agreement on the true nature of OO, but there sure is a lot of agreement on what most of its attributes are. I wasn't making an argument to authority,

You said "Rob Martin is a respected OO vet, if he says it's OO, then it's OO, who are you to question him on something he wrote?" That is as clear a case of the fallacy of appeal to authority as I've ever seen; there's no ambiguity or risk of misunderstanding. Google on "logical fallacies"+"appeal to authority".

I don't care to try and define OO, I was saying it's rude to call someone a liar, if Rob said what he did was OO, it's rude to say it wasn't just because you don't fully agree with his definitions. I thought the story above was a nice little story, you're the one that jumped in and tried to make it a battle over definitions.

Don't put words in my mouth, I did not say "liar". The thing is, everyone tends to recall the past with a rosy tint to it. The story "improves in the telling". This is practically universal.

I am not transforming the purpose of the page, I am arguing that the example that is at the heart of the page is a false example, and that its author is (note carefully that this is what I previously said) not giving enough detail for us to know whether it is OO or not, and that therefore as far as I can tell he's just dressing up the story in OO terms.

Your hostility is unwarranted. Are you Martin? Is this personal for you?

-- DougMerritt

Oh, wait, a light dawns. You're basically saying that you put in this cute story as part of a long-term battle with TopMind, and my quibbling is just getting in the way of your central purpose. I see.

Well, even so, I would think that the primary thing with Top would be to convince him with truths, not just propaganda. And I think that the 8080 story is salvageable for that purpose. Potentially.

-- DougMerritt

Assembler instruction pointer(IP) handling is usually done through jump commands(JMP), essentially a GOTO to named addresses.

"essentially"? What is the difference between a GOTO and a JMP?

A JMP will pass arguments to a function through the stack. I've never seen GOTO used in that way.

I don't follow you. You mean a JMP instruction with an operand that pushes something on the stack? You need to give more details; my point is that, without extra specificity, JMP and GOTO are synonyms. We haven't said which languages or architectures we're talking about, after all.

Comparing GOTO and JMP is like comparing "+" and ADD or "=" and MOVE. This may be valid if you have a certain use of these instructions in mind, but doesn't hold true in general. Thats because assembly provides inherently more low level control, which may or may not be used (e.g. in a macro). After all a function call may be implemented with a JMP.

To map members and methods, a way to meld them in memory would be needed. Object files(.OBJ) act as OOP objects at this level.

How so?

They encapsulate the members & methods. Of course multiple objects could be in one object file, so it's really a matter of terminology - since multiple classes can exist in a single class too

Also, an infinite form of polymorphism is possible with self-modifying assembler(code=data=code).

Nitpick: self-modifying machine code, not assembler.

Really? Self-mod assembler functions are written with the understanding of how the generated machine code would behave, but the code is still written at a "higher level" than machine code, allowing polymorphism(in a sense).

So classes "are" OBJ files, methods are memory addresses, members calls are JMP commands, encapsulation is possible through memory IO privileges, and inheritance by calling linked code

I get the feeling that you have some brainstorm here that is not getting across very well

My intent was to state how OOP code becomes assembler/machine code. i.e. the machine code from say CeePlusPlus might be indistinguishable from the machine code from assembler written with understanding of OOP principles. Someone writing assembler can still apply OOP concepts. . . it's just not as automatic. OOP needs assembler(at some point), so it's not a fair comparison to begin with, since assembler is a "subset" of OOP.

[I feel there is a risk of confusion in assembler is a "subset" of OOP. AssemblyLanguage is only a "subset" in the way that bricks are a subset of house, or that molecules are a subset of brick. Any house can be built with the bricks. OO is just one style of house, and bricks are not confined to this style. And while I'm in here making trouble: JMP and GOTO are synonyms, but it's a bad comparison. There are many kinds of JMP, and in Assembly contexts they're the only way to mechanize a loop, a switch/case statement, and so on, while the GOTO is a "primitive" command in a "high level" language with advanced conditional and looping constructs. The use of GOTO is often the failure of the language designer to provide a construct, or of the programmer to grasp a structured way to do the task. The use of JMP is unavoidable in Assembly. The programmer is charged with the invention and preservation of structure. And yes, this structure can be OO.] -- gh

The real question should be: "Is goto inherently procedural?"

Again, unless I'm missing something, this is no different than what I said previously about OO and assembler

If we can get a third someone to find way to say the same thing, we'll have a pattern!

It's been said before by others, so indeed it is a pattern! Now to name it! :-)

I HaveThisPattern. And I wrote ObjectOriented code in assembly (an m68k kernel). Just define some nice macros for defining and extending "classes" (read: virtual method dispatch tables) and method invocation (read: indirect jump over aforementioned tables) and you have OO assembly. -- GunnarZarncke

I also have this pattern. I wrote OO assembly code in the early 80's, for the M68K, and for the PDP-11 before that. A "class" is a pointer to a collection of helpful state that includes the address of a "method dictionary." A "method dictionary" is a collection of function addresses. A "method selector" is an offset into that table. A "message send" is a JSR through the method table, using the method table address and aformentioned offset, to the desired function. A drawing of this on a whiteboard has, for twenty-five years now, been the most straightforward way I know to explain OO to programmers seeing it for the first time. Said drawing also makes the design of the ObjectiveCee -- which started its life as a CeeLanguage macro pre-processor -- obvious and understandable, as well as the differences between ObjectiveCee and CeePlusPlus. -- TomStambaugh

I had to discover, that explaining OO this way works (in the sense of understanding what goes on), but somehow takes the spirit out of OO. The ProceduralWeenie?s just say: "Nice structure, but seldom useful." -- .gz

I just ask the ProceduralWeenie?'s to please add a tool palette to the drawing editor, with items like a "line", "box" and "brush" tool. Oh, by the way, the palette needs to be extensible at runtime with plugins. -- TomStambaugh

I'm afraid I'm 1000 km away from my literature now, but I remember one of the methodology books mentioning that they took some procedural coders (Forth guys, I think), measured their productivity (somehow) and taught them an OO language, let them program in that language, then measured again. Productivity went up, measurably. They took this as evidence that this other language was better. But a later measurement showed that they still showed this higher productivity when returning to their old language. It was not the language, it was the thought patterns it encouraged. I think this anecdote fits here somewhere, and I'll try to get some sources for it. --ClaesWallin

Apparently, GeoworksCorporation? developed an OO Assembler, and used it for developing the 16-bit, PC version of GeOs. At one point, Geoworks offered a development package that included that assembler, and although BreadBoxComputerCompany? still probably uses that assembler, I can't find that it's available in any way to those outside the company.

What about the CommonLanguageInfrastructure? I believe that the bytecode for that is 100% OO. Maybe not quite assembler (after all, it does need a VM) but still...

The people who develop cpu's, assembler, use both math concepts, and "psychologyzed" O.O. concepts.

It's possible to fake O.O. stuff with procedural stuff (GObject / GLib Library is an example of this)., and fake procedural stuff with O.O. (static classes int C#, VB.NET & Java is an example of that).

J.V.M. and .NET are virtual CPU with their assembler counterparts trying to be Object Oriented. Of course, there have been many others O.O. like machines before, but this are the ones, that are very well known.

umlcat