RE: Trivia: Processor MHz

> 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.