Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #26400
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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