> From: srichter > > >From: "Joe Pluta" <joepluta@PlutaBrothers.com> > > > >-- Mainline > >PUSH BASEPTR Save "this" pointer > >MOVE %ADDR(CUSTOMER), BASEPTR Set "this" pointer > >CALL .GETPHONE, +4 Call method saving space > for return value > > The PUSH has to know how much to push, has to handle call stack > overflow and extension and has to return a ptr to the stack > location. It winds up being a call in and of itself. Wow, this is news to me. PUSH is a basic instruction and as low level as you can get. Leif, help me here... is there a PUSH instruction in MI, and is it as cycle intensive as Steve implies? I thought memory boundaries and things like that would be handled as exception processing and not at the application program level. > The CALL has to load the return address in the call stack entry. Yup. A single move. > The RETURN from the called module has to pop the stack, deal with > call stack extension boundaries, call the destructor mbr > function of any objects in the called module, unwind any "throw" > and "Catch" exception handlers, ... Um, I think you're starting to reach with the destructor issue. Java doesn't have destructors, and the finalize method is only called when the object is garbage collected, which is in another thread. If there are no exception handlers, then there is no overhead. Yeah, you're reaching. I mean, sure, you can add all the overhead you want, but let's try to assume tight code, shall we? > If you want the debugger to have some brains the call stack needs > to be loaded with an identifier of the function being called ( so > the source debugger knows which source code to display ). Come come now. This is definitely "argument for argument's sake". We're talking performance, and optimized code, not debug code. Please let's stay on one subject at a time. > The proof would be in the results though. Get one of the 20 > people in the world who know how to code C++ on the AS400. Write > similar code and see how many times faster is the RPG version. I agree. My only point was that blanket statements about OOP versus procedural aren't as simple as they might seem at first.