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

Groups > comp.lang.forth > #13177

Re: SEE in gforth 7.0.0 64 bits

Show all headers | View raw

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2012Jun22.131649@mips.complang.tuwien.ac.at...
> Mark Wills <markrobertwills@yahoo.co.uk> writes:
> >On Jun 22, 3:31=A0am, Paul Rubin <no.em...@nospam.invalid> wrote:
> >> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
> >>
> >> > It is a 64 bit AMD system.
> >>
> >> > I encounter the following:
> >> > SEE works fine, except for code words. Then it hangs.
> >>
> >> Works fine for me on an Intel Core 2:
> >>
> >> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> >> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> >> Type `bye' to exit
> >> see dup
> >> Code dup
> >> [...]
> >> end-code
> >> =A0ok
> >
> >Wow. Don't want to hijack this thread, but why so much code for a DUP?
>
> Why so many "=A0"s, when the posting you cite had none?
>
> Anyway, I'll annotate it:
>
> Code dup
> mov %rbx,0x23b63b(%rip) save IP for the backtrace (if there is an
> exception)
> mov  (%r15),%rdx        get TOS

gcc places SP into %esi for the other sequences.  I.e., why does gcc place
SP into %r15 here?  Did the register allocator change for 64-bits?  Is %esi
in use for 64-bits, but not 32-bits?  I.e., the change of register seems a
bit strange to me.  Perhaps, it's something to look into.

Is gforth using a "register" keyword or a procedure local for SP?  Neither?

Sometimes, just copying a global, i.e., file scope, variable into a local
(auto) procedure variable, will improve gcc's optimization.  Other times,
changing the type of the variable can do wonders, e.g., "unsigned long" or
"unsigned char" instead of "short" or "int".

> mov  %r15,%rax          gcc sucks
> lea  -0x8(%r15),%r15    decrement SP
> add  $0x8,%rbx          increment IP
> mov  %rdx,-0x8(%rax)    store new TOS

Could the "gcc sucks" issue, i.e., gcc using both %r15 and %rax for SP,
be fixed by slightly reorganizing the code for DUP?

> mov  -0x8(%rbx),%rbp    gcc sucks
> mov  %rbp,%rax          gcc sucks
> jmpq 0x403c21           gcc sucks really bad (this should be "jmp %eax")
> end-code
>

Did you mean "jmp %rax" instead of "jmp %eax"? (yes.)

> On a gcc that sucks less (gcc-2.95), but unfortunately does not
> generate AMD64 code, an IA-32 DUP looks as follows:
>
> Code dup
> mov dword ptr 806256C , ebx  save IP
> mov eax , dword ptr [esi]    get TOS
> add esi , # -4               decrement SP
> add ebx , # 4                increment IP
> mov dword ptr [esi] , eax    store new TOS
> mov eax , dword ptr FC [ebx] get code address of next word
> jmp eax                      jump there
> end-code
>
> If gcc worked perfectly, it would generate "jmp dword ptr FC [ebx]"
> instead of the last two instructions.  Actually I think that gcc-2.95
> works as well as possible here for the code we give it, but the code
> contains workarounds for getting decent performance out of other gcc
> versions.

What is "FC" here?  hex constant (0xFC)?  address label (FC:)?  assembly
keywords ("far call")?

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.  I see the following definitions in gforth for DUP:

  : DUP   SP@ @ ;

  : DUP   PICK S0 ;

> To make it a little more balanced, let's look at gforth-fast's DUP
> (Gforth-fast does not notice all stack underflows and does not
> pinpoint where an exception occured):
>
> Code dup
> add     esi , # -4                decrement SP
> add     ebx , # 4                 increment IP (NEXT)
> mov     dword ptr 4 [esi] , ecx   store TOS
> mov     eax , dword ptr FC [ebx]  code address of next word (NEXT)
> mov     esi , esi                 two-byte NOP
> jmp     eax                       jump there (NEXT)
> end-code
>

It appears that gforth-fast uses that form the indirect+offset form of the
move instruction, e.g., the 4[esi].  Is this a result of optimization? The
compiler for the other posted sequences seemed to "avoid" this form.  This
could imply out-of-order operations in the code for DUP.  I.e., only after
optimization of simpler code or code with different order does the compiler
chose 4[esi].  E.g., perhaps the unoptimized DUP code is decrementing SP
first, when it might be better to decrement it later.

For gforth-fast, TOS apparently is a register: ECX.  What about NOS (2nd) in
register?


Rod Pemberton

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