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

Groups > comp.lang.forth > #13142 > unrolled thread

SEE in gforth 7.0.0 64 bits

Back to article view | Back to comp.lang.forth

Contents

  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

Page 1 of 2  [1] 2  Next page →

#13142 — SEE in gforth 7.0.0 64 bits

I have gforth Version: 0.7.0+ds1-5 (gforth)
installed on Ubuntu 10.04.4 via the official route, i.e.
the synaptic package manager.
It is a 64 bit AMD system.

I encounter the following:
        SEE works fine, except for code words. Then it hangs.

If there anything I/Canonical  could have done wrong with the
installation?

Is this a known problem?

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [next] | [standalone]

#13143

Albert van der Horst wrote: <m5zjxf.lgd@spenarnc.xs4all.nl>
> I have gforth Version: 0.7.0+ds1-5 (gforth)
> installed on Ubuntu 10.04.4 via the official route, i.e.
> the synaptic package manager.
> It is a 64 bit AMD system.
>
> I encounter the following:
>         SEE works fine, except for code words. Then it hangs.
>
> If there anything I/Canonical  could have done wrong with the
> installation?
>
> Is this a known problem?

Yeah, gdb 7.0 and 7.1 have incompatible syntax...

gforth CVS has a fix that checks which syntax works.

Or you can do  ' dump is discode  as a temporary fix...

--Josh

[toc] | [prev] | [next] | [standalone]

#13155

In article <4fe3a5ad$0$5792$882e7ee2@usenet-news.net>,
Josh Grams  <josh@qualdan.com> wrote:
>Albert van der Horst wrote: <m5zjxf.lgd@spenarnc.xs4all.nl>
>> I have gforth Version: 0.7.0+ds1-5 (gforth)
>> installed on Ubuntu 10.04.4 via the official route, i.e.
>> the synaptic package manager.
>> It is a 64 bit AMD system.
>>
>> I encounter the following:
>>         SEE works fine, except for code words. Then it hangs.
>>
>> If there anything I/Canonical  could have done wrong with the
>> installation?
>>
>> Is this a known problem?
>
>Yeah, gdb 7.0 and 7.1 have incompatible syntax...

Okay. I see that the disassembly relies on the external program gdb 7.0.
I'm going to use gdb 7.0 instead of gdb 7.1

>
>gforth CVS has a fix that checks which syntax works.
>
>Or you can do  ' dump is discode  as a temporary fix...
>
>--Josh


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#13159

In article <4fe3a5ad$0$5792$882e7ee2@usenet-news.net>,
Josh Grams  <josh@qualdan.com> wrote:
>Albert van der Horst wrote: <m5zjxf.lgd@spenarnc.xs4all.nl>
>> I have gforth Version: 0.7.0+ds1-5 (gforth)
>> installed on Ubuntu 10.04.4 via the official route, i.e.
>> the synaptic package manager.
>> It is a 64 bit AMD system.
>>
>> I encounter the following:
>>         SEE works fine, except for code words. Then it hangs.
>>
>> If there anything I/Canonical  could have done wrong with the
>> installation?
>>
>> Is this a known problem?
>
>Yeah, gdb 7.0 and 7.1 have incompatible syntax...
>
>gforth CVS has a fix that checks which syntax works.

That fix doesn't help with a binary version. So your advice amounts
to loading the latest source distribution and building it.
I had the file dis-gdb.fs in good shape, then discovered that
it wasn't used.

So this is my new and improved answer:
This is a known problem and is fixed in the latest source
distribution that hasn't made it yet into the binary distributions.

>
>Or you can do  ' dump is discode  as a temporary fix...

Question: What is worse than Intel assembler code?
Answer: There is only one thing worse than Intel assembler code,
Intel machine code.

>
>--Josh


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#13162

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>In article <4fe3a5ad$0$5792$882e7ee2@usenet-news.net>,
>Josh Grams  <josh@qualdan.com> wrote:
>>gforth CVS has a fix that checks which syntax works.
>
>That fix doesn't help with a binary version. So your advice amounts
>to loading the latest source distribution and building it.

That's certainly the fastest way to a working disassembler.

A slower way is to report this as a bug to your distribution.

I don't see how we as a source distributor can do more for fixing
something in your binary distribution.

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

[toc] | [prev] | [next] | [standalone]

#13182

In article <2012Jun22.135750@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>In article <4fe3a5ad$0$5792$882e7ee2@usenet-news.net>,
>>Josh Grams  <josh@qualdan.com> wrote:
>>>gforth CVS has a fix that checks which syntax works.
>>
>>That fix doesn't help with a binary version. So your advice amounts
>>to loading the latest source distribution and building it.
>
>That's certainly the fastest way to a working disassembler.
>
>A slower way is to report this as a bug to your distribution.
>
>I don't see how we as a source distributor can do more for fixing
>something in your binary distribution.

That is if you consider it an error in gforth.
I think that it is an error in the distribution, not shipping
compatible versions of packages.

>
>- anton
>--

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#13213

Hi,

On Friday, June 22, 2012 3:42:14 PM UTC-5, Albert van der Horst wrote:
> In article <2012Jun22.135750@mips.complang.tuwien.ac.at>,
> Anton Ertl <a...@mips.complang.tuwien.ac.at> wrote:
> >Albert van der Horst <a...@spenarnc.xs4all.nl> writes:
> >>In article <4fe3a5ad$0$5792$882e7ee2@usenet-news.net>,
> >>Josh Grams  <j...@qualdan.com> wrote:
> >>>gforth CVS has a fix that checks which syntax works.
> >>
> >>That fix doesn't help with a binary version. So your advice amounts
> >>to loading the latest source distribution and building it.
> >
> >That's certainly the fastest way to a working disassembler.

Welcome to Linux, git!  :-) j/k

> >A slower way is to report this as a bug to your distribution.

Alas, too quickly dropped for newer ones (IMO).

> >I don't see how we as a source distributor can do more for fixing
> >something in your binary distribution.

Why not, who's stopping you?

> That is if you consider it an error in gforth.
> I think that it is an error in the distribution, not shipping
> compatible versions of packages.

Bah, just use something like CDE to package it up and be done with it, much much easier!  ;-)   (Or heck, you could even just build static, even with OpenWatcom if GLIBC is too bloated for you. And yes, I know, GForth probably uses too many GCC-specific junks, bleh.)

http://www.pgbovine.net/cde.html

[toc] | [prev] | [next] | [standalone]

#13148

Albert van der Horst <albert@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  
0x00000000004060be <gforth_engine+9470>:        mov
%rbx,0x23b63b(%rip)        # 0x641700 <saved_ip>
0x00000000004060c5 <gforth_engine+9477>:        mov    (%r15),%rdx
0x00000000004060c8 <gforth_engine+9480>:        mov    %r15,%rax
0x00000000004060cb <gforth_engine+9483>:        lea    -0x8(%r15),%r15
0x00000000004060cf <gforth_engine+9487>:        add    $0x8,%rbx
0x00000000004060d3 <gforth_engine+9491>:        mov    %rdx,-0x8(%rax)
0x00000000004060d7 <gforth_engine+9495>:        mov    -0x8(%rbx),%rbp
0x00000000004060db <gforth_engine+9499>:        mov    %rbp,%rax
0x00000000004060de <gforth_engine+9502>:        jmpq   0x403c21
<gforth_engine+97>
end-code
 ok

[toc] | [prev] | [next] | [standalone]

#13154

On Jun 22, 3:31 am, 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
> 0x00000000004060be <gforth_engine+9470>:        mov
> %rbx,0x23b63b(%rip)        # 0x641700 <saved_ip>
> 0x00000000004060c5 <gforth_engine+9477>:        mov    (%r15),%rdx
> 0x00000000004060c8 <gforth_engine+9480>:        mov    %r15,%rax
> 0x00000000004060cb <gforth_engine+9483>:        lea    -0x8(%r15),%r15
> 0x00000000004060cf <gforth_engine+9487>:        add    $0x8,%rbx
> 0x00000000004060d3 <gforth_engine+9491>:        mov    %rdx,-0x8(%rax)
> 0x00000000004060d7 <gforth_engine+9495>:        mov    -0x8(%rbx),%rbp
> 0x00000000004060db <gforth_engine+9499>:        mov    %rbp,%rax
> 0x00000000004060de <gforth_engine+9502>:        jmpq   0x403c21
> <gforth_engine+97>
> end-code
>  ok

Wow. Don't want to hijack this thread, but why so much code for a DUP?
Can someone educate me? I'm not up on the latest and greated Intel
assembly. But what gives?

I know it's apples and oranges, but DUP on my system is a single
instruction, and my CPU doesn't even have a stack!

DUP:  MOV *R4+,*R4

??

[toc] | [prev] | [next] | [standalone]

#13161

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:
>> > =A0 =A0 =A0 =A0 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
>> 0x00000000004060be <gforth_engine+9470>: =A0 =A0 =A0 =A0mov
>> %rbx,0x23b63b(%rip) =A0 =A0 =A0 =A0# 0x641700 <saved_ip>
>> 0x00000000004060c5 <gforth_engine+9477>: =A0 =A0 =A0 =A0mov =A0 =A0(%r15)=
>,%rdx
>> 0x00000000004060c8 <gforth_engine+9480>: =A0 =A0 =A0 =A0mov =A0 =A0%r15,%=
>rax
>> 0x00000000004060cb <gforth_engine+9483>: =A0 =A0 =A0 =A0lea =A0 =A0-0x8(%=
>r15),%r15
>> 0x00000000004060cf <gforth_engine+9487>: =A0 =A0 =A0 =A0add =A0 =A0$0x8,%=
>rbx
>> 0x00000000004060d3 <gforth_engine+9491>: =A0 =A0 =A0 =A0mov =A0 =A0%rdx,-=
>0x8(%rax)
>> 0x00000000004060d7 <gforth_engine+9495>: =A0 =A0 =A0 =A0mov =A0 =A0-0x8(%=
>rbx),%rbp
>> 0x00000000004060db <gforth_engine+9499>: =A0 =A0 =A0 =A0mov =A0 =A0%rbp,%=
>rax
>> 0x00000000004060de <gforth_engine+9502>: =A0 =A0 =A0 =A0jmpq =A0 0x403c21
>> <gforth_engine+97>
>> 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
mov  %r15,%rax          gcc sucks
lea  -0x8(%r15),%r15    decrement SP
add  $0x8,%rbx          increment IP
mov  %rdx,-0x8(%rax)    store new TOS
mov  -0x8(%rbx),%rbp    gcc sucks
mov  %rbp,%rax          gcc sucks
jmpq 0x403c21           gcc sucks really bad (this should be "jmp %eax")
end-code

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.

>I know it's apples and oranges, but DUP on my system is a single
>instruction, and my CPU doesn't even have a stack!
>
>DUP:  MOV *R4+,*R4

It's apples and oranges because you compare a DUP with NEXT to one
without, and because you compare the debugging version of Gforth to a
system that does not notice all stack underflows and probably cannot
pinpoint where an exception (like stack underflow) occured, whereas
the debugging version of Gforth can do both).

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

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

[toc] | [prev] | [next] | [standalone]

#13177

"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

[toc] | [prev] | [next] | [standalone]

#13199

"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/

[toc] | [prev] | [next] | [standalone]

#13208

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

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?

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

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.

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

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.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#13210

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:

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

do { F } while(0) don't generate any more code than { F } .  It does,
however, solve the dangling else problem.

http://en.wikipedia.org/wiki/Dangling_else

Andrew.

[toc] | [prev] | [next] | [standalone]

#13219

"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/

[toc] | [prev] | [next] | [standalone]

#13226

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2012Jun24.152416@mips.complang.tuwien.ac.at...
> "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
...

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

IIRC, the asm directive for GCC disables code optimization for all
procedures and code blocks.  That doesn't seem like a reason gforth would
desire to have...  Was that the reason?  I.e., if gforth isn't using
assembly, it should stick to C, then the C can be optimized, IMO.

> >b) unneeded do-while'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.

I.e., I believe you mean to prevent GCC treating a "{...}" block as a
"compound statement"...  As in:
http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs

If gforth doesn't need do-while or some other control-flow construct
(switch, if, for, etc), why does gforth need to emit curly-braces for a
block in the first place?  I.e., with the DUP example, there seems to be no
need for the block...  I'm assuming the block is needed or used somehow,
perhaps some other Forth word emits a switch() etc instead?

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

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

Oh, no...  I suggested do-while's using "break" or "continue" to replace
(assumed) goto's to the other label's: H_dupe, I_dupe, etc.  Maybe, that's a
locality-of-reference problem... too far apart or scope issue... different
block or procedure.  Or, maybe my assumption that the label's are goto'd is
incorrect.

I'm assuming the indirection on the goto is a GCC extension.  In my own
code, I use function pointers, dereferenced, to call the primitives or
low-level code.  I've kept to ANSI C without goto's, but's it's normal ITC
code.  Goto's are likely quicker.  If gforth's emitted code manages to be
output in a single section or procedure, there won't be any procedure
overhead (prologue, epilogue, parameters).  I'm not sure how the indirection
affects goto's in assembly since I don't use goto's.  It should map well
onto x86, but I've seen GCC emit some inefficient code.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#13236

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> news:2012Jun24.152416@mips.complang.tuwien.ac.at...
>> "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
> ...
> 
>> >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.
>>
> 
> IIRC, the asm directive for GCC disables code optimization for all
> procedures and code blocks.

You do not recall correctly: the asm directive does not have that
effect.

Andrew.
 

[toc] | [prev] | [next] | [standalone]

#13251

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:SbudndckesRLq3XSnZ2dnUVZ7tqdnZ2d@supernews.com...
> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> > "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> > news:2012Jun24.152416@mips.complang.tuwien.ac.at...
> >> "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
> > ...
> >
> >> >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.
> >>
> >
> > IIRC, the asm directive for GCC disables code optimization for all
> > procedures and code blocks.
>
> You do not recall correctly: the asm directive does not have that
> effect.

Well, I do believe I'm correct about that.  My inline assembly doesn't get
optimized by GCC.  I also believe it's in the GCC manual somewhere too.
That's where I would've learned about it.  No, I don't have the time to
(re)locate it.  But, I just did do a trivial Google search.  It located
statements by others saying the same thing about GCC and "asm" disabling
optimization.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#13262

Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:SbudndckesRLq3XSnZ2dnUVZ7tqdnZ2d@supernews.com...
>> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
>> > "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
>> > news:2012Jun24.152416@mips.complang.tuwien.ac.at...
>> >> "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
>> > ...
>> >
>> >> >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.
>> >>
>> >
>> > IIRC, the asm directive for GCC disables code optimization for all
>> > procedures and code blocks.
>>
>> You do not recall correctly: the asm directive does not have that
>> effect.
> 
> Well, I do believe I'm correct about that.  My inline assembly
> doesn't get optimized by GCC.

No, of course it doesn't, but that's not what you said.

> I also believe it's in the GCC manual somewhere too.  That's where I
> would've learned about it.  No, I don't have the time to (re)locate
> it.  But, I just did do a trivial Google search.  It located
> statements by others saying the same thing about GCC and "asm"
> disabling optimization.

Some C compilers have the unfortunate property that an asm disables
optimization of the function in which it appears, but GCC does not.
An asm statement in GCC is emitted as is, with no alteration, and it
does not disable optimization of the code block in which it appears.
This is essential for kernel programmers, who need to be able to use
single-instruction drop-ins from time to time.  It would be
intolerable if these disabled optimization.

Andrew.

[toc] | [prev] | [next] | [standalone]

#13212

Hi,

On Saturday, June 23, 2012 8:51:21 AM UTC-5, Anton Ertl wrote:
> "Rod Pemberton" <do_not_have@notemailnot.cmm> writes:
> >
> >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.

Why not just write some primitives (for x86 port) in assembly? It's not like you'll be rewriting DUP etc. a lot, will you? Granted, you could argue it's pointless, but hey, you're the ones discussing it here!  ;-)

Or just use GCC 4.4.0 (or newer)'s "pragma optimize" for certain functions.

http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html

"
#pragma GCC optimize ("string"...)
This pragma allows you to set global optimization options for functions defined later in the source file. One or more strings can be specified. Each function that is defined after this point will be as if attribute((optimize("STRING"))) was specified for that function. The parenthesis around the options is optional. See Function Attributes, for more information about the optimize attribute and the attribute syntax.
"

> The next gcc release will break the
> workaround anyway.  Note how gcc-2.95 sucks much less.

Which next, 4.8.0? 4.7.1 was just released, and 4.5.4 is coming out in probably two weeks. Regarding 2.95, I don't think it's very popular anymore, and I don't know of anybody shipping or using it much except maybe? Haiku and OpenBSD (for some older ports, VAX??). Though, at least for C code, I imagine object files produced from it should maybe? still be compatible with newer BinUtils etc, so maybe you could mix and match the best ones (but probably don't want the hassle).

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web