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

Groups > comp.lang.forth > #13199

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: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?

Certainly the number of registers changed, allowing the use of
additional registers.  The calling convention is also different.  Why
does gcc place SP there?  Who knows?  Why not?

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

SP is a local.  On some architecture Gforth tries to build with some
explicit register declarations for variables like SP, on a few (in
particular, PowerPC) gcc manages to allocate registers for all
important VM registers by itself.

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

Maybe.  But I'm not in the business of working around gcc's suckage
unless it has a very big impact.  The next gcc release will break the
workaround anyway.  Note how gcc-2.95 sucks much less.

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

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")?

It's actually a disassembler bug.  It should be disassembled as "-4".
It's a one-byte sign-extended displacement with the value -4 (or $FC).

>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;
}

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

I see it there, too; it's just that the disassembler there uses AT&T
syntax, where it looks as follows: "4(%esi)".  The IA-32 disassembler
uses Intel syntax.

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

Gcc does not manage to keep more than one stack item in registers on
any architecture but PowerPC (possibly SPARC and IA-64, too, but I
have not done much with them).  So, while Gforth supports an
optimization that can make use of more registers for the stack, it's
only used on PowerPC.  This optimization is described in
<http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz> and is
more sophisticated than just having two stack items in registers all
the time (and if you keep the same number of stack items in registers
all the time, using just one register is optimal, see Figures 8-10 of
the paper above).

- 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