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


Groups > comp.lang.forth > #26400

Re: A problem with gforth-fast

From Bernd Paysan <bernd.paysan@gmx.de>
Newsgroups comp.lang.forth
Subject Re: A problem with gforth-fast
Date 2013-10-11 21:30 +0200
Organization 1&1 Internet AG
Message-ID <l39jkc$a0d$1@online.de> (permalink)
References <63d44691-4272-4e9f-9e61-9637dcc1ce91@googlegroups.com> <l393po$kea$1@online.de> <xeednaA0e5SbvcXPnZ2dnUVZ_sSdnZ2d@supernews.com> <l39a61$so1$1@online.de>

Show all headers | View raw


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/

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


Thread

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

csiph-web