Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #13219

Re: SEE in gforth 7.0.0 64 bits

Show all headers | View raw

"Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
>news:2012Jun23.155121@mips.complang.tuwien.ac.at...
>> "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>...
>
>> >What code for DUP is being used to generate the assembly
>> >sequences you posted?  I thought it was supposed to be C
>> >code.  If it's C code, I'd like to see the code.
>>
>> Actually the source code is:
>>
>> dup ( w -- w w ) core dupe
>>
>> This is translated into the following C code (after macro
>> expansion, on AMD64, debugging version):
>>
>> H_dupe: asm(""); I_dupe:
>> { saved_ip=ip; asm(""); }
>> {
>> Cell w;
>> ;
>> ((w)=(Cell)(sp[0]));
>> sp += -1;
>> {
>> # 1323 "prim"
>> # 6744 "prim.i"
>> }
>> (ip++);
>> ((sp[0])=(Cell)(w));
>> K_dupe: asm("");
>> do {asm("":"=X"(cfa)); do {(real_ca=(*(ip-1)));} while(0);} while(0);
>> J_dupe: asm("");
>> goto *real_ca;
>> }
>>
>
>Things I see.
>
>They may be of no real consequence since it seems much of the emitted code
>is unused by DUP, i.e., macro's, code template, generic pattern code, etc.

The C code I posted is after macro expansion, so it contains no
macros.

>a) unused label's and empty asm's.  If gforth "knows" to not emit asm code,
>why doesn't it "know" to not emit unused labels and empty asm directives?

The labels are used, and the empty asm statements are there for a
reason; they are always empty, BTW.

>b) unneeded do-while's.  If gforth "knows" it doesn't need to use a break or
>continue within the do-while as goto's, why does it emit do-while's?

This is the gcc maintainer's preferred way for getting around the C
syntax anomaly that a block ("{...}") behaves syntactically different
from a statement.  Originally we used statement expressions for that,
but the gcc maintainers seem to hate GNU C extensions and quibble
about them when code in a bug report includes them, if they don't just
classify the bug report as invalid outright.

>  From
>the many label's, it seems gforth is mostly using goto's.  So, why is
>do-while being used?  E.g., macro's?  Or, vice-versa, if you can use
>do-while's with break and continue as goto's, why use actual goto's and
>label's elsewhere?  The do-while's might optimize better.

Gforth uses goto * to implement the indirect jumps used for threaded
code.  I would love to see your code that achieves that with
do...whiles and how that optimizes better (although, given the
direction gcc has been going, some day we might get there, not by
actually getting better code for do..while than we have now, but by
having worse code for goto *).

>c) using an increment ++ operator for ip, but using += for sp ...  Even if
>there is a need to adjust sp by multiple cells, it seems likely the stack
>adjustments or operations would be done one cell at a time.

Who cares?  The code is the same.

>d) ip is incremented, then later, one is subtracted from ip for the
>dereference ...  Should or could the decrement be relocated?

In the old times we looked at a lot of ways to implement NEXT, and
have different ones for different architectures.  I am not sure this
bought much, although we did compare with threaded-code Forth systems
written in assembly language (among others) in the 486 times, and
Gforth performed well
<http://www.complang.tuwien.ac.at/forth/performance.html>

In the meantime we do stuff like dynamic superinstructions, so NEXT
becomes a little less important and other things more important.

>e) the code is incrementing sp as if it's pointer to cell, but not
>dereferencing sp to access the object sp points to.  Instead of
>dereferencing sp, e.g., *sp, the subscript operator [], e.g., sp[0], is
>being used for accessing what sp points to.  If the code is directly
>adjusting sp, one has to ask if the index is being used.  I.e., is the index
>in sp[index] _always_ zero ... ?  If so, there is no need for the subscript
>operator.  The subscript operator will also typically add an additional
>addition operation on x86 versus a pointer dereference.  However, gcc is
>good with constants, so zero likely optimizes away here, but other values
>won't.  I.e., if the index is non-zero sometimes, adjust sp by the index,
>then eliminate the index and subscript operator.  Dereferencing sp may also
>eliminate the ' Cell' casts, depending on how sp is declared.

Most of the stuff you write are non-issues as should be easy to see if
you look at the assembly language code and compare it with the C code.
Some stuff is real, but has either little or unpredictable impact on
performance.

If you think that your changes really produce a significant impact, go
ahead and try them out, and measure the results.

I remember one paper (otherwise not so bad) that compared two variants
of the source code that produced exactly the same assembly language
code (possibly even the same code after macro expansion).  Try not to
fall into the same trap.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

SEE in gforth 7.0.0 64 bits Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-21 21:05 +0000
  Re: SEE in gforth 7.0.0 64 bits Josh Grams <josh@qualdan.com> - 2012-06-21 22:52 +0000
    Re: SEE in gforth 7.0.0 64 bits Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 11:25 +0000
    Re: SEE in gforth 7.0.0 64 bits Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 12:23 +0000
      Re: SEE in gforth 7.0.0 64 bits anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 11:57 +0000
        Re: SEE in gforth 7.0.0 64 bits Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 20:42 +0000
          Re: SEE in gforth 7.0.0 64 bits rugxulo@gmail.com - 2012-06-24 05:28 -0700
  Re: SEE in gforth 7.0.0 64 bits Paul Rubin <no.email@nospam.invalid> - 2012-06-21 19:31 -0700
    Re: SEE in gforth 7.0.0 64 bits Mark Wills <markrobertwills@yahoo.co.uk> - 2012-06-22 00:54 -0700
      Re: SEE in gforth 7.0.0 64 bits anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 11:16 +0000
        Re: SEE in gforth 7.0.0 64 bits "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-22 16:17 -0400
          Re: SEE in gforth 7.0.0 64 bits anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-23 13:51 +0000
            Re: SEE in gforth 7.0.0 64 bits "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-24 04:06 -0400
              Re: SEE in gforth 7.0.0 64 bits Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-24 06:55 -0500
              Re: SEE in gforth 7.0.0 64 bits anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 13:24 +0000
                Re: SEE in gforth 7.0.0 64 bits "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-24 18:44 -0400
                Re: SEE in gforth 7.0.0 64 bits Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-25 05:00 -0500
                Re: SEE in gforth 7.0.0 64 bits "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-25 17:54 -0400
                Re: SEE in gforth 7.0.0 64 bits Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-26 03:41 -0500
            Re: SEE in gforth 7.0.0 64 bits rugxulo@gmail.com - 2012-06-24 05:25 -0700
              Re: SEE in gforth 7.0.0 64 bits anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 14:08 +0000
                Re: SEE in gforth 7.0.0 64 bits rugxulo@gmail.com - 2012-06-25 07:56 -0700
        OT: fixing Mark's A0's, was [Re: SEE in gforth 7.0.0 64 bits] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-22 16:18 -0400
          Re: OT: fixing Mark's A0's, was [Re: SEE in gforth 7.0.0 64 bits] Marc Olschok <nobody@nowhere.invalid> - 2012-06-25 12:42 +0000
            Re: OT: fixing Mark's A0's, was [Re: SEE in gforth 7.0.0 64 bits] Mark Wills <markrobertwills@yahoo.co.uk> - 2012-06-25 06:30 -0700
              Re: OT: fixing Mark's A0's, was [Re: SEE in gforth 7.0.0 64 bits] rugxulo@gmail.com - 2012-06-25 08:04 -0700
                Re: OT: fixing Mark's A0's, was [Re: SEE in gforth 7.0.0 64 bits] Mark Wills <markrobertwills@yahoo.co.uk> - 2012-06-25 11:00 -0700
                Re: OT: fixing Mark's A0's, was [Re: SEE in gforth 7.0.0 64 bits] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-25 17:47 -0400
      Re: SEE in gforth 7.0.0 64 bits "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-22 16:01 -0400
  Re: SEE in gforth 7.0.0 64 bits Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-06-24 15:15 +0100

csiph-web