Results 1 to 5 of 5

Thread: - ?

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Registered User 249644943's Avatar
    Join Date: Sep:2004
    Location: Berlin
    Posts: 64

    - ?

    ?

  2. #2
    Registered User 249644943's Avatar
    Join Date: Sep:2004
    Location: Berlin
    Posts: 64
    !

  3. #3
    Registered User 249644943's Avatar
    Join Date: Sep:2004
    Location: Berlin
    Posts: 64
    , .

  4. #4
    Banned pe6o's Avatar
    Join Date: Jan:2002
    Location: Sofia
    Posts: 1,263
    Originally posted by 249644943
    , .
    , http://www.google.com/search?q=object+oriented+assembler ,

  5. #5
    Registered User 249644943's Avatar
    Join Date: Sep:2004
    Location: Berlin
    Posts: 64
    Object Oriented Assembler
    From news:comp.object

    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 truly be 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 encapulation doesn't mean it's not OO, as long as the code uses encapulation 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 one of the principles he abides by, probably the most contriversal of the bunch. You can't look at this principle in isolation, you must include the others to see the full picture, The Single Responsibility Principle, The Liskov Substitution Principle, The Interface Segregation Principle, The Dependency Inversion Principle, Stability, Granularity, and The Open Closed Principle are all things Rob Martin 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=e...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 programmign as programming in which abstractions are independent, and concrete modules depend upon them. i.e. Dependency Inversion." He couldn't be any more clear 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 it's 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.

    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 priveleges, 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! :-)
    --------------------------------------------------------------------------------
    EditText of this page (last edited February 6, 2004)
    FindPage by searching (or browse LikePages or take a VisualTour)



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Copyright © 1999-2011 . .
iskamPC.com | mobility.BG | Bloody's Techblog | | 3D Vision Blog |