I can get down and dirty with machine code, but my standard coding practice is to use lots of macros to automate repetitive tasks, sometimes with different code paths depending on the target processor.
As to library overhead, I've certainly written code design to fir well in a PL/I environment and never found the overhead to be unreasonable. And, yes, there is other code where I sweat every cycle, but that's the exception. I can't see using the full OO paradigm in HLASM, but I've certainly seen implementation of parts of it in assembler code. That "definition" isn't a definition, it's simply a list of purport6ed benefits. There are theological arguments about the one true definition, but there is a broad consensus that it includes classes, methods, objects, messages and inheritance. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Tony Thigpen <t...@vse2pdf.com> Sent: Tuesday, February 6, 2018 10:48 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: OOP in HLASM I think that Paul has forgotten that his favorite OOP still generates machine instructions. If C can do it, then it can be done in HLASM. OOP really boils down into a different type of 'calling' standard other than our nice and simple R1=>Parmlist, R14=return, R15=branch_to_address. It's just that HLASM programmers are close enough to machine code that we 'see' those hundreds (or thousands) of instructions that are used to call an OOP routine and we are smart enough to know that we don't want that overhead on every single call. Why do you think that LE enabled HLASM code is so few and far between. It's the overhead. The real definition of OOP should be: "A programming method that 1) reduces code development time, 2) allows code to be shared with little or no documentation, and 3) allows the used of less-skilled programmers. This one time savings is then paid back many thousands of times over the life of the program due to the inefficiency of the generated code. OOPs promote the 'pay me later' part of 'pay me now or pay me later'." Tony Thigpen Paul Raulerson wrote on 02/06/2018 10:15 PM: >> On Feb 6, 2018, at 7:09 PM, Jon Perryman <jperr...@pacbell.net> wrote: >> >>> Poster wrote: reflects the poster's lack of knowledge of OOP. >> >> >>> Poster wrote (Yes, many differences. The weakness of my example >> >>> kind of proves the larger point: HLASM is not an OOP language.) >> >> >> This poster and several C programmers here believe OOP is difficult in >> HLASM. Very basic objects are extremely simple to implement (a few objects >> with methods and private attributes). It would take me less than 5 minutes >> to code. >> >> >> >> Is there a C programmer here who knows assembler well enough to tell us how >> to create a few simple objects with methods and private attributes? If you >> can't easily do this, then you don't know HLASM as well as you think. Who (C >> programmers) knows how to create simple objects in HLASM? >> >> >> OOP is not rocket science. Most system problems don't need full blown OOP. >> There are many examples in z/OS where this simple implementation is all that >> we need. It has the benefit that it is very low overhead. In C++, you either >> have objects or you don't. If you are writing a large applications in HLASM, >> then Inheritance, virtual functions, overloading and ... may become >> necessary. Each of these can be handled as needed without much difficulty. >> > [snip] > > Clearly, this is getting silly. Let’s be clear here, you can not write > Object Oriented Programs (OOP) in HLASM. The language does not support Object > Oriented Programming. > > You *can* write programs that implement Object Oriented Design (OOD) in > HLASM, but you can do that in just about *any* language. It is much more > difficult in HLASM than other languages, mostly because of “old school” > programmers who scoff at things like data typing. (“I can move any kind of > data I want into that memory area…!”) Well of course they can, but that is > not objected oriented design or programming in HLASM. (shrug) > > If you want to argue that, show me an example of an object you have designed > in HLASM, defining the object, the class it defines and what inheritance it > has, as well as the interface and package in whatever form you choose to > implement. I purposely used the more generic terms here, rather than the > terms from any specific language or implementation. Extra points, write a > test hardness that shows us it actually works the way you designed it. > > I do not believe you can do it satisfactorily. You can code an OOP language > in HLASM, I will grant, but I hold serious doubts you can do what you claim > there. > > C - K&R C that is, does not support OOP either. But like almost every other > language, you can implement Object Oriented Design (OOD) in the language. > > This is all pretty basic stuff and it is hard to argue with. > > Please consider, HLASM is a fantastic platform for writing Bottom Up Design > programs. It is fun to hack away in the weeds and see a really cool result > pop out. > > It is also really good for coding detailed low level logic in. Yes of course > you an read a record from a file with HLASM, but it doesn’t really shine in > doing so until you read files with variable length data and dozens of > variable length trailers - all of which require intense fiddling around with > the data which may or may not be properly aligned for more structured access. > > It is ideal when you are getting down and really fiddling with hardware - > although that is anything but a common task these days. Even a very clever > person will most likely fail trying to outwit modern mainframe hardware, or > out optimize a high level language. It isn’t good or bad, it just *is*. > > It’s like anything else, the right tool for some jobs. And it was written by > very clever people indeed- it is awesome to see and use their work. > > However, insisting it is the best tool for every - or even most - jobs is > just being pig headed. Same for implying that HLASM or z/OS is portable. They > are not. > > If all you have is a hammer, everything looks like a nail and you neat > yourself silly trying to pound in that screw. > >
