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

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

A problem with gforth-fast

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

Contents

  A problem with gforth-fast humptydumpty <ouatubi@gmail.com> - 2013-10-11 02:51 -0700
    Re: A problem with gforth-fast Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-11 17:00 +0200
      Re: A problem with gforth-fast humptydumpty <ouatubi@gmail.com> - 2013-10-11 08:54 -0700
      Re: A problem with gforth-fast Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-11 10:57 -0500
        Re: A problem with gforth-fast Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-11 18:49 +0200
          Re: A problem with gforth-fast Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-11 21:08 +0200
            Re: A problem with gforth-fast humptydumpty <ouatubi@gmail.com> - 2013-10-11 12:54 -0700
              Re: A problem with gforth-fast Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-11 23:21 +0200
                Re: A problem with gforth-fast humptydumpty <ouatubi@gmail.com> - 2013-10-11 23:58 -0700
          Re: A problem with gforth-fast Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-11 21:30 +0200
          Re: A problem with gforth-fast Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-12 03:06 -0500
            Re: A problem with gforth-fast Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-12 15:50 +0200
            Re: A problem with gforth-fast anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-14 17:17 +0000
              Re: A problem with gforth-fast Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-14 12:49 -0500
                Re: A problem with gforth-fast anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 09:50 +0000
                  Re: A problem with gforth-fast Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-10-15 07:48 -0500
                  Re: A problem with gforth-fast anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-15 13:35 +0000
                    Re: A problem with gforth-fast Bernd Paysan <bernd.paysan@gmx.de> - 2013-10-15 17:09 +0200
                      Re: A problem with gforth-fast anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-10-16 16:36 +0000

#26388 — A problem with gforth-fast

Hi!

For some angles (windows)/all angles (linux) - "fcos" messes with data-stack.
Here in linux:

 gforth-fast
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
: .stacks cr .s f.s ;  ok                               
0 0 -2e 3e f/ pi f* .stacks fcos .stacks drop drop fdrop 
<2> 0 0 <1> -2.09439510239E0 
<2> 0 -1073740718 <1> -5.0000000000E-1  ok

Gforth behaves normally.

Have a nice day,
humptydumpty

[toc] | [next] | [standalone]

#26391

humptydumpty wrote:

> Hi!
> 
> For some angles (windows)/all angles (linux) - "fcos" messes with
> data-stack. Here in linux:
> 
>  gforth-fast
> 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
> : .stacks cr .s f.s ;  ok
> 0 0 -2e 3e f/ pi f* .stacks fcos .stacks drop drop fdrop
> <2> 0 0 <1> -2.09439510239E0
> <2> 0 -1073740718 <1> -5.0000000000E-1  ok
> 
> Gforth behaves normally.

Yes, we know; this is a bug somewhere either in glibc's libm or GCC for x86 
only (not honoring the calling conventions).  We have a workaround in the 
current development version, but not backported it to the stable release.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26393

On Friday, October 11, 2013 6:00:08 PM UTC+3, Bernd Paysan wrote:
> humptydumpty wrote:
> 
> 
> 
> > Hi!
> 
> > 
> 
> > For some angles (windows)/all angles (linux) - "fcos" messes with
> 
> > data-stack. Here in linux:
> 
> > 
> 
> >  gforth-fast
> 
> > 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
> 
> > : .stacks cr .s f.s ;  ok
> 
> > 0 0 -2e 3e f/ pi f* .stacks fcos .stacks drop drop fdrop
> 
> > <2> 0 0 <1> -2.09439510239E0
> 
> > <2> 0 -1073740718 <1> -5.0000000000E-1  ok
> 
> > 
> 
> > Gforth behaves normally.
> 
> 
> 
> Yes, we know; this is a bug somewhere either in glibc's libm or GCC for x86 
> 
> only (not honoring the calling conventions).  We have a workaround in the 
> 
> current development version, but not backported it to the stable release.
> 
> 
> 
> -- 
> 
> Bernd Paysan
> 
> "If you want it done right, you have to do it yourself"
> 
> http://bernd-paysan.de/

Thank you!

Keep up the good working!

Enjoying gforth,
humptydumpty

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

#26394

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> humptydumpty wrote:
> 
>> Hi!
>> 
>> For some angles (windows)/all angles (linux) - "fcos" messes with
>> data-stack. Here in linux:
>> 
>>  gforth-fast
>> 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
>> : .stacks cr .s f.s ;  ok
>> 0 0 -2e 3e f/ pi f* .stacks fcos .stacks drop drop fdrop
>> <2> 0 0 <1> -2.09439510239E0
>> <2> 0 -1073740718 <1> -5.0000000000E-1  ok
>> 
>> Gforth behaves normally.
> 
> Yes, we know; this is a bug somewhere either in glibc's libm or GCC for x86 
> only (not honoring the calling conventions).  We have a workaround in the 
> current development version, but not backported it to the stable release.
> 

Fascinating.  Is it simply that cos() leaves the stack pointer
depressed?  And no-one noticed!  I guess as long as you don't call it
too many times in a loop, no-one ever would.  :-)

Andrew.

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

#26395

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Fascinating.  Is it simply that cos() leaves the stack pointer
> depressed?  And no-one noticed!  I guess as long as you don't call it
> too many times in a loop, no-one ever would.  :-)

It clobbers ECX.  As long as you don't keep anything of value in ECX, it 
works fine.  Apparently, GCC doesn't usually allocate ECX, which is 
precisely the reason why we use it as TOS cache.  All assembly instructions 
that needs ECX, like shifts or rep movs/rep stos do fit with the TOS=ECX.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26399

Bernd Paysan wrote:

> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Fascinating.  Is it simply that cos() leaves the stack pointer
>> depressed?  And no-one noticed!  I guess as long as you don't call it
>> too many times in a loop, no-one ever would.  :-)
> 
> It clobbers ECX.  As long as you don't keep anything of value in ECX, it
> works fine.  Apparently, GCC doesn't usually allocate ECX, which is
> precisely the reason why we use it as TOS cache.  All assembly
> instructions that needs ECX, like shifts or rep movs/rep stos do fit with
> the TOS=ECX.

Question for the users: The workaround and the backport to then 0.7.3 is not 
actually difficult; the difficult part was to identify all the math 
functions which do it.  Should I just do a backport and make a 0.7.3 
release?  It's after all a critical bug, because it breaks programs.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26401

On Friday, October 11, 2013 10:08:46 PM UTC+3, Bernd Paysan wrote:
> Bernd Paysan wrote:
> 
> 
> 
> > Andrew Haley wrote:
> 
> > 
> 
> >> Bernd Paysan wrote:
> 
> >> Fascinating.  Is it simply that cos() leaves the stack pointer
> 
> >> depressed?  And no-one noticed!  I guess as long as you don't call it
> 
> >> too many times in a loop, no-one ever would.  :-)
> 
> > 
> 
> > It clobbers ECX.  As long as you don't keep anything of value in ECX, it
> 
> > works fine.  Apparently, GCC doesn't usually allocate ECX, which is
> 
> > precisely the reason why we use it as TOS cache.  All assembly
> 
> > instructions that needs ECX, like shifts or rep movs/rep stos do fit with
> 
> > the TOS=ECX.
> 
> 
> 
> Question for the users: The workaround and the backport to then 0.7.3 is not 
> 
> actually difficult; the difficult part was to identify all the math 
> 
> functions which do it.  Should I just do a backport and make a 0.7.3 
> 
> release?  It's after all a critical bug, because it breaks programs.
> 
> 
> 
> -- 
> 
> Bernd Paysan
> 
> "If you want it done right, you have to do it yourself"
> 
> http://bernd-paysan.de/

Hi!

That would be great.

Have a nice time,
humptydumpty

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

#26402

humptydumpty wrote:
> That would be great.
> 
> Have a nice time,
> humptydumpty

The backport is in the git repository, v0-7-0 branch. So do a

git clone git://git.savannah.gnu.org/gforth.git

or

git clone https://github.com/forthy42/gforth

(github is a lot faster than savannah)

cd gforth
git checkout -b v0-7-0 origin/v0-7-0
./BUILD-FROM-SCRATCH

and give it a try (building gforth requires an installed Gforth).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26413

On Saturday, October 12, 2013 12:21:11 AM UTC+3, Bernd Paysan wrote:
> humptydumpty wrote:
> 
> > That would be great.
> 
> > 
> 
> > Have a nice time,
> 
> > humptydumpty
> 
> 
> 
> The backport is in the git repository, v0-7-0 branch. So do a
> 
> 
> 
> git clone git://git.savannah.gnu.org/gforth.git
> 
> 
> 
> or
> 
> 
> 
> git clone https://github.com/forthy42/gforth
> 
> 
> 
> (github is a lot faster than savannah)
> 
> 
> 
> cd gforth
> 
> git checkout -b v0-7-0 origin/v0-7-0
> 
> ./BUILD-FROM-SCRATCH
> 
> 
> 
> and give it a try (building gforth requires an installed Gforth).
> 
> 
> 
> -- 
> 
> Bernd Paysan
> 
> "If you want it done right, you have to do it yourself"
> 
> http://bernd-paysan.de/

Many thanks!

Have a nice day,
humptydumpty

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

#26400

Bernd Paysan wrote:

> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Fascinating.  Is it simply that cos() leaves the stack pointer
>> depressed?  And no-one noticed!  I guess as long as you don't call it
>> too many times in a loop, no-one ever would.  :-)
> 
> It clobbers ECX.  As long as you don't keep anything of value in ECX, it
> works fine.  Apparently, GCC doesn't usually allocate ECX, which is
> precisely the reason why we use it as TOS cache.  All assembly
> instructions that needs ECX, like shifts or rep movs/rep stos do fit with
> the TOS=ECX.

BTW: It is not sufficient to just store TOS somewhere and aftewards fetch it 
back there, this are the actually requried macros:

#if defined(USE_TOS)
#define CLOBBER_TOS_WORKAROUND_START sp[0]=spTOS; __asm__ __volatile__ ("" 
::: "memory");
#define CLOBBER_TOS_WORKAROUND_END   __asm__ __volatile__ ("" ::: "memory"); 
spTOS=sp[0];
#endif

The "memory" affecting empty asm statement makes sure GCC does not assume 
that ECX survives the math function - well it assumes that the later 
restored value might be affected by the assembly instruction.  Having the 
barrier twice makes sure that GCC clearly has to place the math operation 
between the two other instructions.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26415

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Fascinating.  Is it simply that cos() leaves the stack pointer
>> depressed?  And no-one noticed!  I guess as long as you don't call it
>> too many times in a loop, no-one ever would.  :-)
> 
> It clobbers ECX.  As long as you don't keep anything of value in ECX, it 
> works fine.

So what?  It's allowed to clobber ECX:

%ecx and %edx

Scratch registers have no specified role in the standard calling
sequence. Functions do not have to preserve their values for the
caller.

Andrew.

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

#26422

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Andrew Haley wrote:
>> 
>>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Fascinating.  Is it simply that cos() leaves the stack pointer
>>> depressed?  And no-one noticed!  I guess as long as you don't call it
>>> too many times in a loop, no-one ever would.  :-)
>> 
>> It clobbers ECX.  As long as you don't keep anything of value in ECX, it
>> works fine.
> 
> So what?  It's allowed to clobber ECX:
> 
> %ecx and %edx
> 
> Scratch registers have no specified role in the standard calling
> sequence. Functions do not have to preserve their values for the
> caller.

Registers EAX, ECX, and EDX are caller-saved, and the rest are callee-saved.  
Which means when the C compiler allocates %ecx as register (either implicit 
or explicit), it must save it on function calls. GCC doesn't (it also 
doesn't tell that you can't eplicitely allocate %ecx across function calls, 
because it might be clobbered; it did that in gcc-3.x), but the problem only 
becomes one since the trigonometric functions don't just call the x87 
instuctions. All other calls return some integer values which then become 
the new TOS.

However, it seems to be that more recent GCC 4.x again allow us to use %ebp 
as register (despite -fomit-frame-pointer, previous didn't), so I'll use 
%ebp when possible.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26514

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Andrew Haley wrote:
>> 
>>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Fascinating.  Is it simply that cos() leaves the stack pointer
>>> depressed?  And no-one noticed!  I guess as long as you don't call it
>>> too many times in a loop, no-one ever would.  :-)
>> 
>> It clobbers ECX.  As long as you don't keep anything of value in ECX, it 
>> works fine.
>
>So what?  It's allowed to clobber ECX:
>
>%ecx and %edx
>
>Scratch registers have no specified role in the standard calling
>sequence. Functions do not have to preserve their values for the
>caller.

If it's a caller-saved register (those that do not have to be
preserved by the callee), then gcc should save it before the call and
restore it after the call.  Apparently it doesn't.  It also does not
complain when we use ecx in explicit register allocation.  Under no
circumstances should a self-respecting compiler just silently clobber
a variable.

- 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 2013: http://www.euroforth.org/ef13/

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

#26517

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Andrew Haley wrote:
>>> 
>>>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>> Fascinating.  Is it simply that cos() leaves the stack pointer
>>>> depressed?  And no-one noticed!  I guess as long as you don't call it
>>>> too many times in a loop, no-one ever would.  :-)
>>> 
>>> It clobbers ECX.  As long as you don't keep anything of value in ECX, it 
>>> works fine.
>>
>>So what?  It's allowed to clobber ECX:
>>
>>%ecx and %edx
>>
>>Scratch registers have no specified role in the standard calling
>>sequence. Functions do not have to preserve their values for the
>>caller.
> 
> If it's a caller-saved register (those that do not have to be
> preserved by the callee), then gcc should save it before the call and
> restore it after the call.  Apparently it doesn't.

Why?  ECX is known to be call-clobbered, and you're using it.

Andrew.

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

#26543

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>> Andrew Haley wrote:
>>>> 
>>>>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>>> Fascinating.  Is it simply that cos() leaves the stack pointer
>>>>> depressed?  And no-one noticed!  I guess as long as you don't call it
>>>>> too many times in a loop, no-one ever would.  :-)
>>>> 
>>>> It clobbers ECX.  As long as you don't keep anything of value in ECX, it 
>>>> works fine.
>>>
>>>So what?  It's allowed to clobber ECX:
>>>
>>>%ecx and %edx
>>>
>>>Scratch registers have no specified role in the standard calling
>>>sequence. Functions do not have to preserve their values for the
>>>caller.
>> 
>> If it's a caller-saved register (those that do not have to be
>> preserved by the callee), then gcc should save it before the call and
>> restore it after the call.  Apparently it doesn't.
>
>Why?  ECX is known to be call-clobbered, and you're using it.

spTOS is a local variable, and these are not clobbered by calls.  If
it's in a caller-saved register (whether allocated automatically or
explicitly), it's the compiler's job to save them before the call and
restore them after the call.  That's why they are called "caller-saved
registers".

And given that spTOS is not clobbered by calls in general, but only by
a few transcendental functions, it seems that gcc mostly gets this
right.  But not always.  I'll look into that later.

- 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 2013: http://www.euroforth.org/ef13/

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

#26548

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> If it's a caller-saved register (those that do not have to be
>>> preserved by the callee), then gcc should save it before the call and
>>> restore it after the call.  Apparently it doesn't.
>>
>>Why?  ECX is known to be call-clobbered, and you're using it.
> 
> spTOS is a local variable, and these are not clobbered by calls.

Ahh, my apologies.  That's a GCC bug, then.

> And given that spTOS is not clobbered by calls in general, but only by
> a few transcendental functions, it seems that gcc mostly gets this
> right.  But not always.  I'll look into that later.

Sure, but you don't know that the code you're calling is compiled by
GCC.

Andrew.

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

#26550

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>And given that spTOS is not clobbered by calls in general, but only by
>a few transcendental functions, it seems that gcc mostly gets this
>right.  But not always.  I'll look into that later.

Ok, now I did.  I started with the current git, and I had to disable
two workarounds: The new TOS_CLOBBERED flag and the older one (in
test/float.fs) that tests whether certain FP words clobber the TOS
(and then explicit registers are disabled automatically).

With gcc-4.6.3 I indeed get TOS in ecx:

see 1+ 
Code 1+  
( $804BC6A )  add     ebx , # 4  \ $83 $C3 $4 
( $804BC6D )  inc     ecx  \ $41 
( $804BC6E )  mov     ebp , dword ptr FC [ebx]  \ $8B $6B $FC 
( $804BC71 )  mov     eax , ebp  \ $89 $E8 
( $804BC73 )  jmp     eax  \ $FF $E0 
end-code

and FCOS indeed does not save ecx when calling cos():

see fcos 
Code fcos  
( $804DFEF )  mov     ebp , dword ptr 50 [esp]  \ $8B $6C $24 $50 
( $804DFF3 )  add     ebx , # 4  \ $83 $C3 $4 
( $804DFF6 )  fld     double dword ptr 0 [ebp]  \ $DD $45 $0 
( $804DFF9 )  fstp    double dword ptr [esp]  \ $DD $1C $24 
( $804DFFC )  call    804AA10  \ $E8 $F $CA $FF $FF 
( $804E001 )  fstp    double dword ptr 0 [ebp]  \ $DD $5D $0 
( $804E004 )  mov     ebp , dword ptr FC [ebx]  \ $8B $6B $FC 
( $804E007 )  mov     eax , ebp  \ $89 $E8 
( $804E009 )  jmp     eax  \ $FF $E0 
end-code

Yet the test case at the start of the thread does not clobber TOS on
my system, but FCOSH does clobber it, and the code for it looks
very similar:

see fcosh 
Code fcosh  
( $804E17F )  mov     ebp , dword ptr 50 [esp]  \ $8B $6C $24 $50 
( $804E183 )  add     ebx , # 4  \ $83 $C3 $4 
( $804E186 )  fld     double dword ptr 0 [ebp]  \ $DD $45 $0 
( $804E189 )  fstp    double dword ptr [esp]  \ $DD $1C $24 
( $804E18C )  call    804AF60  \ $E8 $CF $CD $FF $FF 
( $804E191 )  fstp    double dword ptr 0 [ebp]  \ $DD $5D $0 
( $804E194 )  mov     ebp , dword ptr FC [ebx]  \ $8B $6B $FC 
( $804E197 )  mov     eax , ebp  \ $89 $E8 
( $804E199 )  jmp     eax  \ $FF $E0 
end-code

12345 0e fcosh cr f. . 
1. -1073741825  ok

- 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 2013: http://www.euroforth.org/ef13/

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

#26552

Anton Ertl wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>And given that spTOS is not clobbered by calls in general, but only by
>>a few transcendental functions, it seems that gcc mostly gets this
>>right.  But not always.  I'll look into that later.
> 
> Ok, now I did.  I started with the current git, and I had to disable
> two workarounds: The new TOS_CLOBBERED flag and the older one (in
> test/float.fs) that tests whether certain FP words clobber the TOS
> (and then explicit registers are disabled automatically).

In older 3.x GCCs, using eax, ecx, or edx failed with an error message.  
That error message went away with GCC 4.2, and the resulting code "mostly" 
worked, which gave me the impression that the GCC team finally had managed 
to caller-save user-allocated registers.  But apparently not...

> With gcc-4.6.3 I indeed get TOS in ecx:

I don't have such an old GCC anymore; can you test if it's possible to use 
%ebp on gcc-4.6.3 instead of %ecx?

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#26591

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>I don't have such an old GCC anymore; can you test if it's possible to use 
>%ebp on gcc-4.6.3 instead of %ecx?

Works:

see 1+ 
Code 1+  
( $804BC9D )  add     ebx , # 4  \ $83 $C3 $4 
( $804BCA0 )  inc     ebp  \ $45 
( $804BCA1 )  mov     ecx , dword ptr FC [ebx]  \ $8B $4B $FC 
( $804BCA4 )  mov     eax , ecx  \ $89 $C8 
( $804BCA6 )  jmp     eax  \ $FF $E0 
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 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [standalone]

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

csiph-web