Optimizing away return stack ops on RISC

I'm wondering if others have found a "simple" solution to optimizing out push and pop instructions to the return stack on RISC machines (in this case the ARM). For example, given the following definition: : CELL+ ( a -- a+4 ) 4 + ; This easily assembles to: ADD TOS,TOS,#4 However, there is the added overhead of pushing LR onto the return stack and popping it back off with ; or at least LDR PC,[RSP],#4 to immediately return (which I believe is slower than loading the LR register then using BX LR). As I keep re-working my own Forth systems, from ITC to DTC and now to STC, I'm learning more than I could have imagined. And my own optimizations are coming along great. But this is one optimization that still elludes me. How can I know to not compile ENTER if there are no calls to other non-inlined functions made? Or better yet, how could I make the above function become inlined? Branching to a single instruction function is a total waste. I would like to not use new defining words (like :INLINE). What have other systems done? -- Best regards, Jeff Massung jma[at]mfire.com http://www.jm-basic.com/

Jeff Massung <jma[at]nospam.mfire.com> writes: > : CELL+ ( a -- a+4 ) 4 + ; [snip] > As I keep re-working my own Forth systems, from ITC to DTC and now to > STC, I'm learning more than I could have imagined. And my own > optimizations are coming along great. But this is one optimization that > still elludes me. How can I know to not compile ENTER if there are no > calls to other non-inlined functions made? Or better yet, how could I > make the above function become inlined? Branching to a single instruction > function is a total waste. I would like to not use new defining words > (like :INLINE). What have other systems done? My Forth has a very simple inliner. On encountering ';' a check is made on the the size of the current definition and if it is below a certain threshold (and some othe criteria are satisfied) then the current definition is marked as inlinable. When the word is next encountered in a compilation scenario then the body of the word is copied into the caller rather than planting a call. There are various ways that this can fail since it isn't at all smart about words that fiddle with the return stack. However, rather than complicate the inliner, I just try to remember not to write code that will break the assumptions I built into the inliner.

stephen@dino.dnsalias.com (Stephen J. Bevan) writes: > There are various ways that this can fail since it isn't at all > smart about words that fiddle with the return stack. However, > rather than complicate the inliner, I just try to remember not to > write code that will break the assumptions I built into the inliner. How about using a separate word in the spirit of IMMEDIATE, called INLINE to mark the last colon definition as inlinable? -russ

Op Wed, 24 Dec 2003 10:01:32 -0500 schreef Russell McManus <russell_mcmanus@yahoo.com>: > >stephen@dino.dnsalias.com (Stephen J. Bevan) writes: > >> There are various ways that this can fail since it isn't at all >> smart about words that fiddle with the return stack. However, >> rather than complicate the inliner, I just try to remember not to >> write code that will break the assumptions I built into the inliner. > >How about using a separate word in the spirit of IMMEDIATE, called >INLINE to mark the last colon definition as inlinable? > >-russ Another possibility is to make DUP SWAP @ etc. to be inlined by default and others, like EXECUTE IF UNTIL not. When these are encountered, the INLINE flag is reset for the current definition, so it will be called and not inlined instead. Here only the implementer needs to know about INLINE, the user doesn't need to learn c.q. write it. -- Coos

Stephen J. Bevan wrote: > Jeff Massung <jma[at]nospam.mfire.com> writes: > >>: CELL+ ( a -- a+4 ) 4 + ; > > [snip] > >>As I keep re-working my own Forth systems, from ITC to DTC and now to >>STC, I'm learning more than I could have imagined. And my own >>optimizations are coming along great. But this is one optimization that >>still elludes me. How can I know to not compile ENTER if there are no >>calls to other non-inlined functions made? Or better yet, how could I >>make the above function become inlined? Branching to a single instruction >>function is a total waste. I would like to not use new defining words >>(like :INLINE). What have other systems done? > > > My Forth has a very simple inliner. On encountering ';' a check is > made on the the size of the current definition and if it is below a > certain threshold (and some othe criteria are satisfied) then the > current definition is marked as inlinable. When the word is next > encountered in a compilation scenario then the body of the word is > copied into the caller rather than planting a call. This is what I was planning. The little details I came up with were: 1) It means the word header needs to contain not just a pointer to the code, but the length of the code so the inline knows how much to copy when inlining 2) There may need to be an agreement between compiler and inliner about how to trim the ENTER and RETURN 'head and tail' off of the compiled word when inlining. Either a known number of bytes of code for each that the inliner can just skip, or extra pointers in the word header to indicate which bit of code to copy for inlining. 3) It ought to be self-relocating code! Eg, use relative jumps in-word if possible, otherwise your inlined version will just jump into the shared version, which will be fine until it hits the RETURN at the end... > There are various ways that this can fail since it isn't at all smart > about words that fiddle with the return stack. However, rather than > complicate the inliner, I just try to remember not to write code that > will break the assumptions I built into the inliner. Quite! ABS

Russell McManus <russell_mcmanus@yahoo.com> writes: > How about using a separate word in the spirit of IMMEDIATE, called > INLINE to mark the last colon definition as inlinable? Jeff didn't want to use any explicit directive like INLINE. Nor do I.