× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.