Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #39232 > unrolled thread
| Started by | chitselb <chitselb@gmail.com> |
|---|---|
| First post | 2015-05-23 19:27 -0700 |
| Last post | 2015-05-24 14:06 +0000 |
| Articles | 20 on this page of 151 — 19 participants |
Back to article view | Back to comp.lang.forth
unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 19:27 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 20:27 -0700
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 13:44 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:36 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 23:16 +0200
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 15:57 -0700
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-25 02:21 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-24 15:21 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 19:49 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:22 -0700
Re: unexpected +LOOP behavior "WJ" <w_a_x_man@yahoo.com> - 2015-05-26 17:20 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 14:15 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 08:37 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 15:09 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 09:19 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 17:08 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 15:42 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 19:30 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 17:45 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 21:33 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 14:08 +0200
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 06:32 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 16:15 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 14:32 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 08:30 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:15 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-29 21:05 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 01:41 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-24 23:26 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:33 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 10:56 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-25 11:28 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 14:33 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:57 -0700
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 23:01 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:21 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-26 23:59 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 09:15 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 10:06 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:03 -0400
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 16:23 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:39 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 22:14 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:13 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 23:36 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 18:06 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:35 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:16 +0100
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 09:42 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 16:16 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 15:24 +0100
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:32 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 23:59 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 19:31 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-27 23:11 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:21 +0100
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:24 +0100
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:53 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:19 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:51 +0000
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 17:48 +0200
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-29 02:08 +0200
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 08:25 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:40 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:16 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-29 18:43 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 20:08 +0100
x86 tricks Lars Brinkhoff <lars.spam@nocrew.org> - 2015-06-05 09:42 +0200
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 09:32 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 09:40 +0000
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 11:17 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 15:49 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 17:45 +0100
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 16:53 +0000
Re: x86 tricks rickman <gnuarm@gmail.com> - 2015-06-07 13:20 -0400
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 07:18 +0000
Re: x86 tricks Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-08 17:18 +0200
Re: x86 tricks Tessa Bonting <tessa.bonting@gmail.com> - 2015-06-08 08:42 -0700
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 09:47 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 15:05 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-07 17:49 +0100
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 13:19 +0100
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:38 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 21:33 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 22:10 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 22:20 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 21:13 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:34 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 22:04 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 01:27 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-28 03:20 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 04:13 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 04:23 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 11:28 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 18:32 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 18:53 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 22:26 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-23 21:37 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:24 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:40 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-25 14:08 +0200
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:47 -1000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:33 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 12:53 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 13:05 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:49 -1000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 18:03 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 16:44 -1000
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 22:56 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:05 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:43 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-24 08:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 15:44 +0000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-27 00:57 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-06-05 13:11 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 12:24 -1000
Re: unexpected +LOOP behavior JennyB <jennybrien@googlemail.com> - 2015-06-06 13:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 14:56 +0000
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-07 10:38 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 08:08 +0000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:01 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:40 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 11:29 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 09:51 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 10:44 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 12:34 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:59 -0700
unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-24 01:39 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-24 14:46 +0200
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:17 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:48 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:15 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 12:35 +0000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 18:16 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 16:17 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 17:16 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 17:50 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 18:47 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 20:01 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:29 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:32 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:03 +0000
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-26 01:10 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:31 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 20:07 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 20:20 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:00 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 02:41 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 14:06 +0000
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-29 17:48 +0200 |
| Message-ID | <55688a2e$0$2840$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39418 |
Anton Ertl wrote: > No, what a comparison operator returns is a (well-formed) flag; and a > well-formed flag has a bit-pattern that can be used as a mask. That is: if you consider a flag not as an abstraction, but as having a concrete value. > BTW, I find your definition of a different, but still documented > numeric value for TRUE in your 4th to be not congruent with your > strongly-typed attitude. The reason for it having the value "1" is simple. It's the smallest datum that does not equal zero. I can do whatever I want with it, it's always preserved. > I see a number of options that are more in > your spirit. > 1) Static type checking. Yuk. Sounds like C. Hate applying casts to prevent warnings. > 2) Dynamic type checking. Sounds like a lot of things I say "yuk" to. > 3) TRUE and FALSE are represented by arbitrary (but different) bit > patterns (possibly different at every session), flags can be combined > only with NOT and your && and || (which only take and only produce > TRUE and FALSE), and IF, UNTIL, etc. work only when you pass them > either TRUE or FALSE; AND OR INVERT 0= cannot be used for flags in > that scheme. Just doesn't sound right. > 4) TRUE and FALSE are arbitrary (but different) bit patterns, where > certain bits are 0 for FALSE and 1 for TRUE, and IF UNTIL etc. check > (only) these bits (the bit patterns and the checked bits may differ > from session to session). In this scheme AND OR INVERT can be used > for flags, but 0= cannot. Doesn't sound much better. Nice argument for a discussion club, but you and I know this is too absurd to be considered. No, 0= is pretty good for my taste. I rather thought of +0<> ( u1 u2 -- f) *0<> ( u1 u2 -- f) : +0<> + 0<> ; : *0<> * 0<> ; Give it any fancy name you like. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-29 02:08 +0200 |
| Message-ID | <mk8ak7$pij$1@dont-email.me> |
| In reply to | #39352 |
Anton Ertl wrote: > With that you can write >CHAR as follows: > > : >char ( u -- c ) > dup '0' [ 'A' 10 - ] literal rot 9 > select + ; For the sake of completeness, we have recently introduced both SELECT and MUX, which differ in so far that MUX is bitwise, and you could define : SELECT ( x1 x2 n -- x3 ) 0<> MUX ; so it's forming a propper flag. If your CPU has a conditional move, SELECT will be branchless, but MUX will always be branchless. You can use MUX to mix parts of two numbers with a selector mask. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-29 08:25 +0000 |
| Message-ID | <2015May29.102527@mips.complang.tuwien.ac.at> |
| In reply to | #39395 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> With that you can write >CHAR as follows:
>>
>> : >char ( u -- c )
>> dup '0' [ 'A' 10 - ] literal rot 9 > select + ;
>
>For the sake of completeness, we have recently introduced both SELECT and
>MUX, which differ in so far that MUX is bitwise, and you could define
>
>: SELECT ( x1 x2 n -- x3 ) 0<> MUX ;
>
>so it's forming a propper flag.
>
>If your CPU has a conditional move, SELECT will be branchless, but MUX will
>always be branchless.
Of course, with the definition above, SELECT will be branchless if 0<>
is. But yes, the way we implement SELECT, it may contain a branch.
And you could use MUX instead if SELECT in the code above, but I think
SELECT is clearer.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-29 12:40 +0100 |
| Message-ID | <mk9j64$hkq$1@dont-email.me> |
| In reply to | #39400 |
on 29/05/2015 09:25:29, wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Anton Ertl wrote:
>>> With that you can write >CHAR as follows:
>>>
>>> : >char ( u -- c )
>>> dup '0' [ 'A' 10 - ] literal rot 9 > select + ;
>>
>>For the sake of completeness, we have recently introduced both SELECT and
>>MUX, which differ in so far that MUX is bitwise, and you could define
>>
>>: SELECT ( x1 x2 n -- x3 ) 0<> MUX ;
>>
>>so it's forming a propper flag.
>>
>>If your CPU has a conditional move, SELECT will be branchless, but MUX will
>>always be branchless.
>
> Of course, with the definition above, SELECT will be branchless if 0<>
> is. But yes, the way we implement SELECT, it may contain a branch. And
> you could use MUX instead if SELECT in the code above, but I think
> SELECT is clearer.
>
> - anton
For Intel x86 assuming eax=TOS;
code 0<> ( x -- f1 )
add eax -1
sbb eax eax
Equivalently
code 0= ( x -- f1 )
sub eax 1
sbb eax eax
Both generate well formed flags.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-29 13:16 +0000 |
| Message-ID | <2015May29.151627@mips.complang.tuwien.ac.at> |
| In reply to | #39408 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 29/05/2015 09:25:29, wrote:
>> Of course, with the definition above, SELECT will be branchless if 0<>
>> is.
...
>For Intel x86 assuming eax=TOS;
>
>code 0<> ( x -- f1 )
> add eax -1
> sbb eax eax
Here's what is generated by gcc-2.95.1:
( $804BC63 ) xor eax , eax \ $31 $C0
( $804BC65 ) test ecx , ecx \ $85 $C9
( $804BC67 ) je 804BC6E \ $74 $5
( $804BC69 ) mov eax , # FFFFFFFF \ $B8 $FF $FF $FF $FF
( $804BC6E ) add ebx , # 4 \ $83 $C3 $4 NEXT
( $804BC71 ) mov ecx , eax \ $89 $C1
( $804BC73 ) jmp dword ptr FC [ebx] \ $FF $63 $FC NEXT
And that's with the primitive defined with code like:
f1 = -(x!=0);
But other gcc versions are less happy to introduce branches; gcc-4.3.4:
0x0000000000405403 <gforth_engine+4307>: add $0x8,%rbx NEXT
0x0000000000405407 <gforth_engine+4311>: test %r14,%r14
0x000000000040540a <gforth_engine+4314>: setne %r14b
0x000000000040540e <gforth_engine+4318>: shl $0x3f,%r14
0x0000000000405412 <gforth_engine+4322>: sar $0x3f,%r14
0x0000000000405416 <gforth_engine+4326>: mov -0x8(%rbx),%rbp NEXT
0x000000000040541a <gforth_engine+4330>: mov %rbp,%rax NEXT
0x000000000040541d <gforth_engine+4333>: jmpq *%rax NEXT
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-29 18:43 +0000 |
| Message-ID | <5568b351$0$23252$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #39408 |
In article <mk9j64$hkq$1@dont-email.me>,
Alex McDonald <blog@rivadpm.com> wrote:
>on 29/05/2015 09:25:29, wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>> With that you can write >CHAR as follows:
>>>>
>>>> : >char ( u -- c )
>>>> dup '0' [ 'A' 10 - ] literal rot 9 > select + ;
>>>
>>>For the sake of completeness, we have recently introduced both SELECT and
>>>MUX, which differ in so far that MUX is bitwise, and you could define
>>>
>>>: SELECT ( x1 x2 n -- x3 ) 0<> MUX ;
>>>
>>>so it's forming a propper flag.
>>>
>>>If your CPU has a conditional move, SELECT will be branchless, but MUX will
>>>always be branchless.
>>
>> Of course, with the definition above, SELECT will be branchless if 0<>
>> is. But yes, the way we implement SELECT, it may contain a branch. And
>> you could use MUX instead if SELECT in the code above, but I think
>> SELECT is clearer.
>>
>> - anton
>
>For Intel x86 assuming eax=TOS;
>
>code 0<> ( x -- f1 )
> add eax -1
> sbb eax eax
Or
neg ax
sbb ax ax
To avoid potentially large immediate data.
(dec ax doesn't affect the carry flag).
>
>Equivalently
>
>code 0= ( x -- f1 )
> sub eax 1
> sbb eax eax
>
>Both generate well formed flags.
neg ax
cmc
sbb ax ax
(Got those from Coos Haak I guess.)
--
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]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-29 20:08 +0100 |
| Message-ID | <mkadds$o9s$1@dont-email.me> |
| In reply to | #39431 |
on 29/05/2015 19:43:32, wrote: > > Or > neg ax > sbb ax ax > > To avoid potentially large immediate data. > (dec ax doesn't affect the carry flag). > The 1 byte immediate is 3 bytes. Your version is 1 byte shorter. ( $0 ) add eax $-1 \ 83C0FF
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-06-05 09:42 +0200 |
| Subject | x86 tricks |
| Message-ID | <86k2visit2.fsf_-_@vps34351.public.cloudvps.com> |
| In reply to | #39431 |
Albert van der Horst wrote: > Alex McDonald wrote: >>For Intel x86 assuming eax=TOS; >> >>code 0<> ( x -- f1 ) >> add eax -1 >> sbb eax eax > > Or > neg ax > sbb ax ax > > To avoid potentially large immediate data. > (dec ax doesn't affect the carry flag). > >>Equivalently >> >>code 0= ( x -- f1 ) >> sub eax 1 >> sbb eax eax >> >>Both generate well formed flags. > > neg ax > cmc > sbb ax ax > > (Got those from Coos Haak I guess.) Love it! What other x86 assembler tricks do you have up your sleeves? How do you allocate registers to SP/RP/TOS/IP? What's the fastest NEXT in ITC or DTC? Do you use special instructions like LODSD?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-06-05 09:32 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <55716cc9$0$3042$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #39565 |
In article <86k2visit2.fsf_-_@vps34351.public.cloudvps.com>, Lars Brinkhoff <lars.spam@nocrew.org> wrote: >Albert van der Horst wrote: >> Alex McDonald wrote: >>>For Intel x86 assuming eax=TOS; >>> >>>code 0<> ( x -- f1 ) >>> add eax -1 >>> sbb eax eax >> >> Or >> neg ax >> sbb ax ax >> >> To avoid potentially large immediate data. >> (dec ax doesn't affect the carry flag). >> >>>Equivalently >>> >>>code 0= ( x -- f1 ) >>> sub eax 1 >>> sbb eax eax >>> >>>Both generate well formed flags. >> >> neg ax >> cmc >> sbb ax ax >> >> (Got those from Coos Haak I guess.) > >Love it! > >What other x86 assembler tricks do you have up your sleeves? How do you >allocate registers to SP/RP/TOS/IP? What's the fastest NEXT in ITC or >DTC? Do you use special instructions like LODSD? Once I've identified a task I try to find the most efficient way. My concerns with Forth are teachibility (yourforth) and transparancy (introspectibility) not: speed out of the box. On my website there is information about syntax coloring (lina.html) and optimising (main page -> lectures -> lecture 5) which indicates the direction I take. E.g. Top of stack in register only confuses an optimiser. Stack juggling: OVER is pop a, pop b, push b, push a, push b cause the pop's and push's can be optimised away and they can be more easily so than more complicated things. Next is the least of my worries. 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-05 09:40 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <2015Jun5.114020@mips.complang.tuwien.ac.at> |
| In reply to | #39565 |
Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Albert van der Horst wrote:
>> Alex McDonald wrote:
>>>For Intel x86 assuming eax=TOS;
>>>
>>>code 0<> ( x -- f1 )
>>> add eax -1
>>> sbb eax eax
>>
>> Or
>> neg ax
>> sbb ax ax
>>
>> To avoid potentially large immediate data.
>> (dec ax doesn't affect the carry flag).
>>
>>>Equivalently
>>>
>>>code 0= ( x -- f1 )
>>> sub eax 1
>>> sbb eax eax
>>>
>>>Both generate well formed flags.
>>
>> neg ax
>> cmc
>> sbb ax ax
>>
>> (Got those from Coos Haak I guess.)
>
>Love it!
Note that, e.g., Nehalem can process just one SBB every two cycles
(and probably nothing in the same cyles), compared to 3 SUBs every
cycle (with 1 cycle latency). For Sandy Bridge, Ivy Bridge, and
Haswell, this improves to one SBB per cycle, still with two cycles
latency (and four SUBs with 1-cycle latency).
Source: http://www.agner.org/optimize/instruction_tables.pdf
So, while these tricks are cute, they may also be slow. Alternatives
like the following may be faster (one would need to time them to know
for sure):
test eax, eax
sete al \ for 0=, setne for 0<>
movzx eax, al
neg eax
or
test eax, eax
sete al \ for 0=, setne for 0<>
shl eax, 31
sar eax, 31
or
xor ebx,ebx
test eax, eax
setne bl \ for 0=, setne for 0<>
xor eax, eax
sub eax, ebx
>What's the fastest NEXT in ITC or
>DTC? Do you use special instructions like LODSD?
In the 486 days LODSD for NEXT was slower than the equivalent sequence
of simple instructions, this may have changed, but I doubt that it is
faster.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-06-05 11:17 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <55718554$0$23270$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #39568 |
In article <2015Jun5.114020@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Lars Brinkhoff <lars.spam@nocrew.org> writes: >>Albert van der Horst wrote: >>> Alex McDonald wrote: >>>>For Intel x86 assuming eax=TOS; >>>> >>>>code 0<> ( x -- f1 ) >>>> add eax -1 >>>> sbb eax eax >>> >>> Or >>> neg ax >>> sbb ax ax >>> >>> To avoid potentially large immediate data. >>> (dec ax doesn't affect the carry flag). >>> >>>>Equivalently >>>> >>>>code 0= ( x -- f1 ) >>>> sub eax 1 >>>> sbb eax eax >>>> >>>>Both generate well formed flags. >>> >>> neg ax >>> cmc >>> sbb ax ax >>> >>> (Got those from Coos Haak I guess.) >> >>Love it! > >Note that, e.g., Nehalem can process just one SBB every two cycles >(and probably nothing in the same cyles), compared to 3 SUBs every >cycle (with 1 cycle latency). For Sandy Bridge, Ivy Bridge, and >Haswell, this improves to one SBB per cycle, still with two cycles >latency (and four SUBs with 1-cycle latency). > >Source: http://www.agner.org/optimize/instruction_tables.pdf > >So, while these tricks are cute, they may also be slow. Alternatives >like the following may be faster (one would need to time them to know >for sure): Did you say tricks? I hate that. I just use the instruction set to optimal effect. What I want is to minimize the number of instructions without heading the urban legends like LODS is slow etc. I leave it to the Intel engineers to make those instruction sequences that make sense also fast. I leave it to the c-compiler writers to adapt the compiler every time a new processor arrives with different trade offs. <SNIP> >In the 486 days LODSD for NEXT was slower than the equivalent sequence >of simple instructions, this may have changed, but I doubt that it is >faster. It is shorter and it makes next standout in assembly. > >- anton -- 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-05 15:49 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <2015Jun5.174917@mips.complang.tuwien.ac.at> |
| In reply to | #39570 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>Did you say tricks? I hate that. I just use the instruction set to
>optimal effect. What I want is to minimize the number of instructions
>without heading the urban legends like LODS is slow etc.
It's not an urban legend, it's a fact; look in the 486 timing tables.
Bernd Beuster switched from LODS to MOV/ADD, resulting in a speedup.
>It is shorter and it makes next standout in assembly.
An indirect jump also stands out in assembly (especially in AT&T
syntax), no need for a LODSD.
If shortness and standing out are the only requirements, then the best
NEXT is RET (requires using ESP as IP and direct-threaded code). On
CPUs with a return stack (everything since the Pentium 4) using RET
for threaded code is dog-slow, however, because all the RETs will
mispredict (about 50% or lower mispredictions with indirect jumps in
threaded 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-05 17:45 +0100 |
| Subject | Re: x86 tricks |
| Message-ID | <mksjkj$iaa$1@dont-email.me> |
| In reply to | #39586 |
on 05/06/2015 16:49:17, wrote: > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>Did you say tricks? I hate that. I just use the instruction set to >>optimal effect. What I want is to minimize the number of instructions >>without heading the urban legends like LODS is slow etc. > > It's not an urban legend, it's a fact; look in the 486 timing tables. > Bernd Beuster switched from LODS to MOV/ADD, resulting in a speedup. Intel Core i7 2.6GHz; PUSH and POP on my limited tests are the same speed when using EBP and MOV/ADD and MOV/SUB. I was mildly surprised.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-05 16:53 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <2015Jun5.185315@mips.complang.tuwien.ac.at> |
| In reply to | #39588 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 05/06/2015 16:49:17, wrote:
>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>Did you say tricks? I hate that. I just use the instruction set to
>>>optimal effect. What I want is to minimize the number of instructions
>>>without heading the urban legends like LODS is slow etc.
>>
>> It's not an urban legend, it's a fact; look in the 486 timing tables.
>> Bernd Beuster switched from LODS to MOV/ADD, resulting in a speedup.
>
>Intel Core i7 2.6GHz; PUSH and POP on my limited tests are the same speed
>when using EBP and MOV/ADD and MOV/SUB. I was mildly surprised.
Sequences of PUSH are so frequent (because of the calling conventions
on IA-32) that the CPU designers added special hardware optimizations
for them pretty long ago. This was widely publicized at the time, but
I do not find that right now.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-06-07 13:20 -0400 |
| Subject | Re: x86 tricks |
| Message-ID | <ml1ueh$h2b$3@dont-email.me> |
| In reply to | #39590 |
On 6/5/2015 12:53 PM, Anton Ertl wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >> on 05/06/2015 16:49:17, wrote: >>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>>> Did you say tricks? I hate that. I just use the instruction set to >>>> optimal effect. What I want is to minimize the number of instructions >>>> without heading the urban legends like LODS is slow etc. >>> >>> It's not an urban legend, it's a fact; look in the 486 timing tables. >>> Bernd Beuster switched from LODS to MOV/ADD, resulting in a speedup. >> >> Intel Core i7 2.6GHz; PUSH and POP on my limited tests are the same speed >> when using EBP and MOV/ADD and MOV/SUB. I was mildly surprised. > > Sequences of PUSH are so frequent (because of the calling conventions > on IA-32) that the CPU designers added special hardware optimizations > for them pretty long ago. This was widely publicized at the time, but > I do not find that right now. I recall someone talking about that. It is a stack cache of some 8 levels deep or so. Is that what you mean? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-08 07:18 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <2015Jun8.091814@mips.complang.tuwien.ac.at> |
| In reply to | #39619 |
rickman <gnuarm@gmail.com> writes:
>On 6/5/2015 12:53 PM, Anton Ertl wrote:
>> Sequences of PUSH are so frequent (because of the calling conventions
>> on IA-32) that the CPU designers added special hardware optimizations
>> for them pretty long ago. This was widely publicized at the time, but
>> I do not find that right now.
>
>I recall someone talking about that. It is a stack cache of some 8
>levels deep or so. Is that what you mean?
No, never heard of that for PUSH; sounds more like the return address
stack (for predicting the target of RET) to me.
No, the problem with PUSH sequences I remember is this: If the
hardware simply decomposes it to MOV and ADD (or SUB), the sequence
becomes
mov -4[esp], reg
add esp, -4
mov -4[esp], reg
add esp, -4
mov -4[esp], reg
add esp, -4
The second MOV and second add would depend on the first add, the third
MOV on the second add, which depends on the first add, the CALL also
depends on ESP and changes ESP, and the parameter accesses in the
called code also depend on ESP. So you get long sequences of
dependences through esp, and very likely much in the called function
depends on that, so this would restrict instruction-level parallelism.
So they built a hardware optimization that combines the ESP updates in
a sequence of PUSHes (not sure about POPs), and thus shortens the
chain of dependences.
I guess they did this in the Pentium, which could do PUSH and POP in
both pipelines (and which was in-order, exacerbating the problem).
Interestingly, the AMD K7 and K8, which can also do two MOVs per cycle
does not have this optimization (according to Agner Fog's timings, it
can only do one PUSH per cycle), but it was added in the K10. The
Pentium 4 (all variants) can do only one store or push every two
cycles, so I guess the latency of the ESP updates was a minor
bottleneck. The Pentium Pro family up to Nehalem can do one load or
pop or store or push per cycle, so you cannot tell from Agner Fog's
data if it has this optimization; Sandy Bridge-Haswell can do two
loads or pops per cycle, so apparently it optimizes the ESP updates
for POP (and therefore probably for PUSH, too).
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-08 17:18 +0200 |
| Subject | Re: x86 tricks |
| Message-ID | <ml4bm4$6sm$2@dont-email.me> |
| In reply to | #39590 |
Anton Ertl wrote: > Sequences of PUSH are so frequent (because of the calling conventions > on IA-32) that the CPU designers added special hardware optimizations > for them pretty long ago. This was widely publicized at the time, but > I do not find that right now. The original Pentium could combine two pushs or pops into one cycle. Nowadays, they have forgotten about that, and each push or pop causes an AGI stall (2 cycles!), so you better store all the values with an address+offset of the SP, and then adjust the stack pointer. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Tessa Bonting <tessa.bonting@gmail.com> |
|---|---|
| Date | 2015-06-08 08:42 -0700 |
| Subject | Re: x86 tricks |
| Message-ID | <59d4a1de-2404-4f55-8812-72d0da8dbb0b@googlegroups.com> |
| In reply to | #39636 |
Op maandag 8 juni 2015 17:18:41 UTC+2 schreef Bernd Paysan: > Anton Ertl wrote: > > Sequences of PUSH are so frequent (because of the calling conventions > > on IA-32) that the CPU designers added special hardware optimizations > > for them pretty long ago. This was widely publicized at the time, but > > I do not find that right now. > > The original Pentium could combine two pushs or pops into one cycle. > Nowadays, they have forgotten about that, and each push or pop causes an AGI > stall (2 cycles!), so you better store all the values with an address+offset > of the SP, and then adjust the stack pointer. > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself" > net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* > http://bernd-paysan.de/ Sorry but this is not true for the newer 64 bit processor. The problem was that a pop or push needed two uops and there is just one 2 to 4 uops instruction port, the other can only handle 1 uops instructions. I do not know exactly from wich processor and up it is changed, but a push or pop is now handled as one alu and one write/read instruction and so the alu instrcution is handled in the 1 uops port and the write/read in the store/fetch port. So now you can have three push or pop instructions in one cycle, if one of the 48/32 buffers is free to handle the write/read.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-06-06 09:47 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <5572c19c$0$21278$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #39586 |
In article <2015Jun5.174917@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>Did you say tricks? I hate that. I just use the instruction set to >>optimal effect. What I want is to minimize the number of instructions >>without heading the urban legends like LODS is slow etc. > >It's not an urban legend, it's a fact; look in the 486 timing tables. >Bernd Beuster switched from LODS to MOV/ADD, resulting in a speedup. I call it an urban myth because one never knows when it were true or is true. There is some truth about vampires having light skin and can't stand sunlight. This goes back to a relation that has been noticed about redheads. Its scientific value is dubious. > >>It is shorter and it makes next standout in assembly. > >An indirect jump also stands out in assembly (especially in AT&T >syntax), no need for a LODSD. My LODS are followed by an indirect jump -> next. Otherwise -> LIT > >If shortness and standing out are the only requirements, then the best >NEXT is RET (requires using ESP as IP and direct-threaded code). On >CPUs with a return stack (everything since the Pentium 4) using RET Threaded code is dog-slow, however, because all the RETs will >mispredict (about 50% or lower mispredictions with indirect jumps in >threaded code). My primary requirement is that I don't want to care unless necessary. Speed is so overrated. I've slowed down my system from 2.8 Ghz to 1 Ghz because of hardware problems. It doesn't make a difference for the Euler problems whether a solution is feasible or not. I thought about using RET for next too, but of course, unless the system is sophisticated, this plays havoc with interrupts, so I never even tried an experiment with it. (Those microprocessors, say a Z80, would not predict or mispredict anything though.) > >- 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-07 15:05 +0000 |
| Subject | Re: x86 tricks |
| Message-ID | <2015Jun7.170536@mips.complang.tuwien.ac.at> |
| In reply to | #39606 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2015Jun5.174917@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>Did you say tricks? I hate that. I just use the instruction set to
>>>optimal effect. What I want is to minimize the number of instructions
>>>without heading the urban legends like LODS is slow etc.
>>
>>It's not an urban legend, it's a fact; look in the 486 timing tables.
>>Bernd Beuster switched from LODS to MOV/ADD, resulting in a speedup.
>
>I call it an urban myth because one never knows when it were
>true or is true.
Sure, you measure your Forth system with a NEXT using LODSD, and with
a NEXT using MOV and ADD, and compare the performance on the hardware
you are interested in. Then you know. On the 486 LODSD was slower,
as shown by Bernd Beuster.
>Speed is so overrated. I've slowed down my system from 2.8 Ghz to
>1 Ghz because of hardware problems.
If speed is overrated, why did you pay more for a 2.8GHz processor
then? An Atom-based system or the system you had before would have
been sufficient, no?
>I thought about using RET for next too, but
>of course, unless the system is sophisticated, this plays havoc
>with interrupts, so I never even tried an experiment with it.
>(Those microprocessors, say a Z80, would not predict or mispredict
>anything though.)
How does a Z80 come into play in a thread about "x86 tricks"?
On IA-32 or AMD64 hardware, nowadays you usually run a protected-mode
OS, and user space does not normally see interrupts, so RET is safe to
use. For Unix signal handlers (the closest that Unix has to
interrupts), you can set up the stack for use by the signal handlers
with sigaltstack(). Windows experts can fill in how this might be
done in Windows.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web