Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52476 > unrolled thread
| Started by | trans <transfire@gmail.com> |
|---|---|
| First post | 2016-11-08 22:03 -0800 |
| Last post | 2016-11-11 15:54 -0800 |
| Articles | 20 on this page of 97 — 21 participants |
Back to article view | Back to comp.lang.forth
Average swaps per word? trans <transfire@gmail.com> - 2016-11-08 22:03 -0800
Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-08 20:20 -1000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-09 08:16 +0000
Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-09 03:34 -0500
Re: Average swaps per word? trans <transfire@gmail.com> - 2016-11-09 02:53 -0800
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-09 11:50 -0500
Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-09 18:37 +0000
Re: Average swaps per word? Harold <hzrabbie@gmail.com> - 2016-11-10 16:28 -0800
Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-11 17:51 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 12:23 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:09 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-13 14:55 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-13 20:34 +0100
Re: Average swaps per word? Paul Rubin <no.email@nospam.invalid> - 2016-11-13 11:43 -0800
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-13 16:58 -0800
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-14 16:41 +0100
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-14 16:38 -0800
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:42 +0000
Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-14 16:39 -0500
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:40 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:10 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:14 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-20 18:16 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 10:29 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-22 15:54 +0100
Re: Average swaps per word? James Kuyper <jameskuyper@verizon.net> - 2016-11-22 11:50 -0500
Re: Average swaps per word? raltbos@xs4all.nl (Richard Bos) - 2016-11-24 17:27 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-15 03:55 -0600
Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-15 17:49 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-16 02:59 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 13:07 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-16 22:57 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-17 03:12 -0600
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 12:32 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:02 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 13:23 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-17 08:54 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:54 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-18 12:37 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:32 +0000
Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 02:09 -0800
Re: Average swaps per word? jim <anon@example.com> - 2016-11-15 10:44 +0000
Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 03:12 -0800
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-15 13:01 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:51 +0000
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-17 14:02 +0000
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-17 14:06 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:26 +0000
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-18 18:33 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-19 03:32 -0600
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:29 +0100
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 13:51 +0100
Re: Average swaps per word? jim <anon@example.com> - 2016-11-15 13:01 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:46 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:16 +0100
Re: Average swaps per word? Harold <hzrabbie@gmail.com> - 2016-11-13 11:08 -0800
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:08 +0000
Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 02:04 -0800
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 14:04 +0100
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 14:05 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:58 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 15:16 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:41 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-20 18:12 +0100
Re: Average swaps per word? minforth@arcor.de - 2016-11-09 03:15 -0800
Re: Average swaps per word? trans <transfire@gmail.com> - 2016-11-09 11:22 -0800
Re: Average swaps per word? "HAA" <someone@microsoft.com> - 2016-11-10 12:20 +1100
Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-09 21:04 -1000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 03:45 -0600
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 11:52 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 11:42 -0600
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 13:34 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 12:54 -0600
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 16:33 -0500
Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-10 15:56 -1000
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 21:30 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-11 03:04 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 13:25 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-14 03:34 -0600
Re: Average swaps per word? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-11 10:41 +0000
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 16:45 -0800
Re: Average swaps per word? jim <anon@example.com> - 2016-11-10 11:17 +0000
Re: Average swaps per word? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-11-10 04:34 -0800
Re: Average swaps per word? jim <anon@example.com> - 2016-11-10 12:44 +0000
Re: Average swaps per word? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-11-10 07:27 -0800
Re: Average swaps per word? Ron Aaron <rambamist@gmail.com> - 2016-11-10 18:26 +0200
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-10 16:05 +0000
Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-10 14:55 +0000
Re: Average swaps per word? "HAA" <someone@microsoft.com> - 2016-11-12 11:36 +1100
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 16:56 -0800
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:14 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 12:14 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:16 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-13 14:51 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-13 20:41 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-10 14:42 +0000
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 15:54 -0800
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | trans <transfire@gmail.com> |
|---|---|
| Date | 2016-11-08 22:03 -0800 |
| Subject | Average swaps per word? |
| Message-ID | <5352ea02-4942-40bf-8c92-e5012aae1807@googlegroups.com> |
Are there any statistics on the average swaps per word in Forth code?
[toc] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-08 20:20 -1000 |
| Message-ID | <FOidnTSOrdGwXb_FnZ2dnUU7-dHNnZ2d@supernews.com> |
| In reply to | #52476 |
On 11/8/16 8:03 PM, trans wrote: > Are there any statistics on the average swaps per word in Forth code? > No, but in my experience maybe one or fewer. With experience, one learns to design words such that stack arguments fall in useful patterns. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-09 08:16 +0000 |
| Message-ID | <2016Nov9.091656@mips.complang.tuwien.ac.at> |
| In reply to | #52476 |
trans <transfire@gmail.com> writes:
>Are there any statistics on the average swaps per word in Forth code?
You can derive them from the statistics in [gregg+01euroforth].
Figure 4 shows that 1.35%-2.14% of the static primitives in the
programs (excluding pentomino) are SWAP and 7.47%-10.22% are ;s (";"
or EXIT), resulting in 0.15-0.23 SWAPs/;s. Multiply this by 1+x,
where x is the number of EXIT's per word.
@InProceedings{gregg+01euroforth,
author = {David Gregg and M. Anton Ertl and John Waldron},
title = {The Common Case in {Forth} Programs},
booktitle = {EuroForth 2001 Conference Proceedings},
pages = {63--70},
year = {2001},
url1 = {http://www.cs.tcd.ie/David.Gregg/euroforth01.ps.gz},
url = {http://www.complang.tuwien.ac.at/papers/gregg+01euroforth.ps.gz},
abstract = {Identifying common features in Forth programs is
important for those designing Forth machines and
optimisers. In this paper we measure the behaviour
of six large Forth programs and four small ones. We
look at the ratio of user to system code, basic
block lengths, common instructions, and common
sequences of instructions. Our most important
finding is that for most large programs, many
(38.4\%--47.6\% statically and 21.8\%--40.9\%
dynamically) basic blocks consist of only a single
instruction, which hinders optimisation. We also
show static measures of frequent instructions and
sequences of instructions are more consistent across
programs, and may be a better predictor of the
behaviour of other programs than dynamic measures.}
}
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-11-09 03:34 -0500 |
| Message-ID | <20161109033429.75b93326@_> |
| In reply to | #52476 |
On Tue, 8 Nov 2016 22:03:01 -0800 (PST) trans <transfire@gmail.com> wrote: > Are there any statistics on the average swaps per word in Forth code? : AAA SWAP SWAP ; : BBB AAA AAA ; AAA would report two. Would BBB report zero or four? I.e., are you wanting to know the "static" SWAPs (typed) or the "dynamic" SWAPs (executed)? The terms "static" and "dynamic" are used by by Philip Koopman, Jr in his book "Stack Computers." Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | trans <transfire@gmail.com> |
|---|---|
| Date | 2016-11-09 02:53 -0800 |
| Message-ID | <d811e3fa-6243-48e6-a5c0-b989daca5127@googlegroups.com> |
| In reply to | #52479 |
On Wednesday, November 9, 2016 at 3:34:02 AM UTC-5, Rod Pemberton wrote: > > : AAA SWAP SWAP ; > : BBB AAA AAA ; > > AAA would report two. Would BBB report zero or four? > > I.e., are you wanting to know the "static" SWAPs (typed) or the > "dynamic" SWAPs (executed)? The terms "static" and "dynamic" > are used by by Philip Koopman, Jr in his book "Stack Computers." > Static
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-09 11:50 -0500 |
| Message-ID | <nvvk2q$nch$3@dont-email.me> |
| In reply to | #52481 |
On 11/9/2016 5:53 AM, trans wrote: > On Wednesday, November 9, 2016 at 3:34:02 AM UTC-5, Rod Pemberton wrote: >> >> : AAA SWAP SWAP ; >> : BBB AAA AAA ; >> >> AAA would report two. Would BBB report zero or four? >> >> I.e., are you wanting to know the "static" SWAPs (typed) or the >> "dynamic" SWAPs (executed)? The terms "static" and "dynamic" >> are used by by Philip Koopman, Jr in his book "Stack Computers." >> > > Static The static number impacts code size. The dynamic number measures the impact on run time speed. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-09 18:37 +0000 |
| Message-ID | <58236c98.176487035@news.eternal-september.org> |
| In reply to | #52486 |
On Wed, 9 Nov 2016 11:50:01 -0500, rickman <gnuarm@gmail.com> wrote: >On 11/9/2016 5:53 AM, trans wrote: >> On Wednesday, November 9, 2016 at 3:34:02 AM UTC-5, Rod Pemberton wrote: >>> >>> : AAA SWAP SWAP ; >>> : BBB AAA AAA ; >>> >>> AAA would report two. Would BBB report zero or four? >>> >>> I.e., are you wanting to know the "static" SWAPs (typed) or the >>> "dynamic" SWAPs (executed)? The terms "static" and "dynamic" >>> are used by by Philip Koopman, Jr in his book "Stack Computers." >>> >> >> Static > >The static number impacts code size. The dynamic number measures the >impact on run time speed. VFX Forth: : AAA SWAP SWAP ; ok : BBB AAA AAA ; ok dis bbb BBB ( 004CBF10 C3 ) NEXT, ( 1 bytes, 1 instructions ) ok Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Harold <hzrabbie@gmail.com> |
|---|---|
| Date | 2016-11-10 16:28 -0800 |
| Message-ID | <81df7e62-3f3e-4571-821c-218f9abee4ed@googlegroups.com> |
| In reply to | #52489 |
On Wednesday, November 9, 2016 at 10:37:38 AM UTC-8, Stephen Pelc wrote: > > VFX Forth: > > : AAA SWAP SWAP ; ok > : BBB AAA AAA ; ok > dis bbb > BBB > ( 004CBF10 C3 ) NEXT, > ( 1 bytes, 1 instructions ) > ok > > Stephen What kind of optimization is a compiler allowed to perform? Must the compiler generate a load or store for every occurrence of @ or ! ? For example, an embedded system might include the following word to pulse a memory-mapped device register : pulse-register ( reg-addr -- ) DUP 1 SWAP ! 0 SWAP ! ; Is an optimizing compiler allowed to replace this with 0 SWAP ! since the end result is the same? Other languages have the concept of a volatile variable type qualifier to allow the programmer to prevent this sort of optimization. Are all non-stack memory accesses in Forth considered to be volatile? I couldn't find any mention of this topic in the 2012 standard. A similar issue arises in multi-threaded environments with shared-memory locks. -- Harold
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-11-11 17:51 +0000 |
| Message-ID | <5825fc8b.136308759@news.eternal-september.org> |
| In reply to | #52522 |
On Thu, 10 Nov 2016 16:28:34 -0800 (PST), Harold <hzrabbie@gmail.com> wrote: >What kind of optimization is a compiler allowed to perform? Must the compi= >ler generate a load or store for every occurrence of @ or ! ? > >For example, an embedded system might include the following word to pulse a= > memory-mapped device register > >: pulse-register ( reg-addr -- ) > DUP 1 SWAP ! 0 SWAP ! For embedded system compilers, MPE keeps all stores and fetches. On desktops, especially x86, which has a separate I/O space, phrases of the form @ drop are removed unless you use @ [o/f] drop where [o/f] is an immediate word that flushes the optimiser. However, stores are still kept. >Is an optimizing compiler allowed to replace this with > 0 SWAP ! >since the end result is the same? No. But that's my opinion. Forth has always relied to some extent on the idea that you get what you programmed. >Other languages have the concept of a volatile variable type qualifier to a= >llow the programmer to prevent this sort of optimization. Are all non-stac= >k memory accesses in Forth considered to be volatile? I couldn't find any = >mention of this topic in the 2012 standard. It's not covered, but should be. Thanks for pointing it out. >A similar issue arises in multi-threaded environments with shared-memory >locks. With modern CPUs such as the Cortex-M3/4/7 and the Cortex-A/R here are exclusive-access instructions. which lead to fairly straight-forward sequences. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-12 12:23 +0000 |
| Message-ID | <2016Nov12.132348@mips.complang.tuwien.ac.at> |
| In reply to | #52522 |
Harold <hzrabbie@gmail.com> writes:
>What kind of optimization is a compiler allowed to perform? Must the compi=
>ler generate a load or store for every occurrence of @ or ! ?
If it changes the user-visible behaviour of the program, yes.
>For example, an embedded system might include the following word to pulse a=
> memory-mapped device register
>
>: pulse-register ( reg-addr -- )
> DUP 1 SWAP ! 0 SWAP !
>;
>
>Is an optimizing compiler allowed to replace this with
>
> 0 SWAP !
>
>since the end result is the same?
Obviously, the user-visble behaviour changes in this case, so if the
program runs in an environment where you can store to such devices,
the compiler must not optimize any of these stores away unless it can
prove that the stores are not to such a device. On the practical
side, it is pretty difficult to optimize stores away in useful code
anyway (even if you know that you are not storing to such a device),
so I don't expect the compiler to do it, and I would not go for it as
a compiler writer.
A more problematic issue is fetches from I/O devices which may have a
side effect; e.g., a serial chip where you can get the next byte of
the data with each c@. If you want to ignore a byte of input, you
might write
... input-port c@ drop ...
Optimizing the whole sequence away is a pretty natural thing for an
analytic compiler to do, but of course it would be wrong in this case.
AFAIK VFX optimizes such a @ DROP sequence (but, trying it out now,
not C@ DROP) away in the PC version, but leaves it alone in the
embedded version.
But even if the PC version left it alone, too, that would slow down
real-world code by exactly 0%, because you don't write @ DROP unless
you want the side effect.
A bigger problem is
... @ ... @ ...
You may want to reorder the fetches (if your compiler does instruction
scheduling) if the result of the second fetch is needed more urgently
than the result of the first. Or
begin
... A @ ...
repeat
Here the compiler may want to pull the A @ out of the loop (and the
alternative of doing it manually is particularly unattractive because
it complicates the stack), but of course that's only allowed in
certain environments.
At the moment the mainstream Forth compilers are not sophisticated
enough to try such things, though.
>Other languages have the concept of a volatile variable type qualifier to a=
>llow the programmer to prevent this sort of optimization. Are all non-stac=
>k memory accesses in Forth considered to be volatile? I couldn't find any =
>mention of this topic in the 2012 standard.
It's not specified in the standard. It depends on the environment in
which the program is run. If all the program can do is access RAM
that is not shared with other processes or threads, the compiler can
perform more optimizations than otherwise.
One could add @/! variants for non-shared RAM, shared RAM,
write-combining, write-through, and non-cached I/O areas (you may not
need all of these variants) to allow some of these optimizations in
some cases, but that would lead to an explosion of word names, and
probably buys little, so I lean towards just leaving these
optimizations to the programmer.
E.g., for the loop case above the programmer can use a local to avoid
the stack complication:
a @ {: a@ :} begin
... a@ ...
repeat
Another alternative would be to turn A into a UVALUE (thread-local
VALUE), but that assumes the presence of UVALUEs in the system, and
that the compiler is sophisticated enough to move loop-invariant code
out of loops.
>A similar issue arises in multi-threaded environments with shared-memory lo=
>cks.
Well, that's not standardized yet, although it is on the agenda.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-12 16:09 +0100 |
| Message-ID | <o07bak$ru0$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52554 |
In article <2016Nov12.132348@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Harold <hzrabbie@gmail.com> writes:
>>What kind of optimization is a compiler allowed to perform? Must the compi=
>>ler generate a load or store for every occurrence of @ or ! ?
>
>If it changes the user-visible behaviour of the program, yes.
I don't think we must be more strict about @/! then about the stack.
Optimisation is important for turn key programs. If at the exit
of the program the content of a memory place doesn't have side effects
(i.e. in fact output), it is allowed to leave out the last `! .
If there is no `@ between consequitive `! the first `! may be left out.
If `@ and `! themselves have a side effect, they are not in fact memory
accesses and should be named `P@ and `P! in the program (Port fetch
and port store) to tip of the optimiser.
>
>>For example, an embedded system might include the following word to pulse a=
>> memory-mapped device register
>>
>>: pulse-register ( reg-addr -- )
>> DUP 1 SWAP ! 0 SWAP !
>>;
>>
>>Is an optimizing compiler allowed to replace this with
>>
>> 0 SWAP !
>>
>>since the end result is the same?
>
>Obviously, the user-visble behaviour changes in this case, so if the
>program runs in an environment where you can store to such devices,
>the compiler must not optimize any of these stores away unless it can
>prove that the stores are not to such a device. On the practical
>side, it is pretty difficult to optimize stores away in useful code
>anyway (even if you know that you are not storing to such a device),
>so I don't expect the compiler to do it, and I would not go for it as
>a compiler writer.
These are not stores, but port accesses, but the compiler can't know.
>
>A more problematic issue is fetches from I/O devices which may have a
>side effect; e.g., a serial chip where you can get the next byte of
>the data with each c@. If you want to ignore a byte of input, you
>might write
>
>... input-port c@ drop ...
>
>Optimizing the whole sequence away is a pretty natural thing for an
>analytic compiler to do, but of course it would be wrong in this case.
>AFAIK VFX optimizes such a @ DROP sequence (but, trying it out now,
>not C@ DROP) away in the PC version, but leaves it alone in the
>embedded version.
These are not fetches, but port accesses, but the compiler can't know.
>
>But even if the PC version left it alone, too, that would slow down
>real-world code by exactly 0%, because you don't write @ DROP unless
>you want the side effect.
>
>A bigger problem is
>
> ... @ ... @ ...
>
>You may want to reorder the fetches (if your compiler does instruction
>scheduling) if the result of the second fetch is needed more urgently
>than the result of the first. Or
>
>begin
> ... A @ ...
>repeat
>
>Here the compiler may want to pull the A @ out of the loop (and the
>alternative of doing it manually is particularly unattractive because
>it complicates the stack), but of course that's only allowed in
>certain environments.
>
>At the moment the mainstream Forth compilers are not sophisticated
>enough to try such things, though.
>
>>Other languages have the concept of a volatile variable type qualifier to a=
>>llow the programmer to prevent this sort of optimization. Are all non-stac=
>>k memory accesses in Forth considered to be volatile? I couldn't find any =
>>mention of this topic in the 2012 standard.
>
>It's not specified in the standard. It depends on the environment in
>which the program is run. If all the program can do is access RAM
>that is not shared with other processes or threads, the compiler can
>perform more optimizations than otherwise.
>
>One could add @/! variants for non-shared RAM, shared RAM,
>write-combining, write-through, and non-cached I/O areas (you may not
>need all of these variants) to allow some of these optimizations in
>some cases, but that would lead to an explosion of word names, and
>probably buys little, so I lean towards just leaving these
>optimizations to the programmer.
>
>E.g., for the loop case above the programmer can use a local to avoid
>the stack complication:
>
>a @ {: a@ :} begin
> ... a@ ...
>repeat
>
>Another alternative would be to turn A into a UVALUE (thread-local
>VALUE), but that assumes the presence of UVALUEs in the system, and
>that the compiler is sophisticated enough to move loop-invariant code
>out of loops.
>
>>A similar issue arises in multi-threaded environments with shared-memory lo=
>>cks.
>
>Well, that's not standardized yet, although it is on the agenda.
>
The only conclusion is that we must tip of the compiler.
For VALUE's besides VARIABLE's we need PTO besides P! and
what is worse we have to call ports PVALUE's because the
fetches are implicit.
(Which supports my conviction that VALUE's besides VARIABLE's
is a bad idea. In this case we can get by by insisting that
VALUEs never ever can be io ports.)
>- 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 | 2016-11-13 14:55 +0000 |
| Message-ID | <2016Nov13.155518@mips.complang.tuwien.ac.at> |
| In reply to | #52557 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Nov12.132348@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Harold <hzrabbie@gmail.com> writes:
>>>What kind of optimization is a compiler allowed to perform? Must the compi=
>>>ler generate a load or store for every occurrence of @ or ! ?
>>
>>If it changes the user-visible behaviour of the program, yes.
>
>I don't think we must be more strict about @/! then about the stack.
Not sure what you mean by that.
>Optimisation is important for turn key programs. If at the exit
>of the program the content of a memory place doesn't have side effects
>(i.e. in fact output), it is allowed to leave out the last `! .
In the usual case there will by @s after the last !, and if you cannot
determine that they read the memory that the last ! stores, you cannot
leave it out.
Otherwise, sure, you can optimize all the !s after the last @ in a
process away. Is this an optimization that is going to save a
significant amount of time? I doubt it.
On a related note, gcc likes to delete stores (including memset()) to
memory that is deallocated afterwards, based on the theory that it
would be undefined to read that memory afterwards, and that this
therefore cannot happen. That was one of the contributing factors to
the Heartbleed vulnerability: The programmers had defensively used
memset() to erase the secrets after using them, that memory was then
deallocated, and gcc therefore "optimized" the memset() away. And
while the following read from that memory (due to a buffer overflow)
was undefined behaviour, it still happened, revealing the secret to
the attacker.
>If `@ and `! themselves have a side effect, they are not in fact memory
>accesses and should be named `P@ and `P! in the program (Port fetch
>and port store) to tip of the optimiser.
Current IA-32 and AMD64 CPUs have memory-type range registers (MTRRs)
and page attribute tables (PATs), and the memory types they support
are uncached, write-through, write-combining, and write-back. And
even with write-back memory, you might want to differentiate between
memory shared between threads and unshared memory. Different
optimizations can be applied for different memory types. Does it pay
off? I suspect not.
>The only conclusion is that we must tip of the compiler.
>For VALUE's besides VARIABLE's we need PTO besides P! and
>what is worse we have to call ports PVALUE's because the
>fetches are implicit.
Given that for a port you want to provide the address (unlike for
VALUE), needing a different word for ports is pretty natural:
0 value x
$dc04 port timera
Concerning TO, we use TO for FVALUEs, 2VALUEs and locals, so it's
pretty natural to also use TO for such PORTs.
>(Which supports my conviction that VALUE's besides VARIABLE's
>is a bad idea. In this case we can get by by insisting that
>VALUEs never ever can be io ports.)
Wrt optimization VALUEs are easier to deal with than VARIABLEs: you
know that the only thing that changes a VALUE is a TO VALUE (at least
if you don't support ADDR v (for a VALUE v)).
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-13 20:34 +0100 |
| Message-ID | <o0af90$5sf$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52585 |
In article <2016Nov13.155518@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>I don't think we must be more strict about @/! then about the stack.
>
>Not sure what you mean by that.
>
>>Optimisation is important for turn key programs. If at the exit
>>of the program the content of a memory place doesn't have side effects
>>(i.e. in fact output), it is allowed to leave out the last `! .
>
>In the usual case there will by @s after the last !, and if you cannot
>determine that they read the memory that the last ! stores, you cannot
>leave it out.
I was assuming that the @ were already optimised away because we were
keeping the value in a register, but I didn't tell you that.
Sorry.
>On a related note, gcc likes to delete stores (including memset()) to
>memory that is deallocated afterwards, based on the theory that it
>would be undefined to read that memory afterwards, and that this
>therefore cannot happen. That was one of the contributing factors to
>the Heartbleed vulnerability: The programmers had defensively used
>memset() to erase the secrets after using them, that memory was then
>deallocated, and gcc therefore "optimized" the memset() away. And
>while the following read from that memory (due to a buffer overflow)
>was undefined behaviour, it still happened, revealing the secret to
>the attacker.
They should have checked what happens while optimising. Failing that
they shouldn't have optimised.
>
>>If `@ and `! themselves have a side effect, they are not in fact memory
>>accesses and should be named `P@ and `P! in the program (Port fetch
>>and port store) to tip of the optimiser.
>
>Current IA-32 and AMD64 CPUs have memory-type range registers (MTRRs)
>and page attribute tables (PATs), and the memory types they support
>are uncached, write-through, write-combining, and write-back. And
>even with write-back memory, you might want to differentiate between
>memory shared between threads and unshared memory. Different
>optimizations can be applied for different memory types. Does it pay
>off? I suspect not.
It certainly pays off to mark memory places as "no hanky panky".
If you mean that you must create all kinds of cases for what can
be done and what not, I would say, don't go there.
>
>>The only conclusion is that we must tip of the compiler.
>>For VALUE's besides VARIABLE's we need PTO besides P! and
>>what is worse we have to call ports PVALUE's because the
>>fetches are implicit.
>
>Given that for a port you want to provide the address (unlike for
>VALUE), needing a different word for ports is pretty natural:
>
>0 value x
>$dc04 port timera
My comment about PVALUE's was nonsense as you point out that
the address can't be forced.
If you use VALUE's you would do
$dc04 value timerport
17 timerport !
Groetjes Albert
>
>Concerning TO, we use TO for FVALUEs, 2VALUEs and locals, so it's
>pretty natural to also use TO for such PORTs.
>
>>(Which supports my conviction that VALUE's besides VARIABLE's
>>is a bad idea. In this case we can get by by insisting that
>>VALUEs never ever can be io ports.)
>
>Wrt optimization VALUEs are easier to deal with than VARIABLEs: you
>know that the only thing that changes a VALUE is a TO VALUE (at least
>if you don't support ADDR v (for a VALUE v)).
>
>- 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 2016: http://www.euroforth.org/ef16/
--
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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-11-13 11:43 -0800 |
| Message-ID | <871syff9mv.fsf@nightsong.com> |
| In reply to | #52589 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>and gcc therefore "optimized" the memset() away. And >>while the following read from that memory (due to a buffer overflow) > They should have checked what happens while optimising. Failing that > they shouldn't have optimised. The right way to do that in C is with a volatile cast. Maybe Forth could use something similar.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-13 16:58 -0800 |
| Message-ID | <e042242c-ea0f-4759-a3a7-75df8c8ee405@googlegroups.com> |
| In reply to | #52591 |
On Sunday, November 13, 2016 at 12:43:53 PM UTC-7, Paul Rubin wrote: > albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > >>and gcc therefore "optimized" the memset() away. And > >>while the following read from that memory (due to a buffer overflow) > > They should have checked what happens while optimising. Failing that > > they shouldn't have optimised. > > The right way to do that in C is with a volatile cast. Maybe Forth > could use something similar. C's VOLATILE is useful for systems programming, which is what C was designed for and continues to be used primarily for. I'm not really thinking of Straight Forth as being a systems language --- it is possible though --- I will have to think about what, if any, support I want to provide for systems programming.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-14 16:41 +0100 |
| Message-ID | <o0cm05$d6v$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52594 |
In article <e042242c-ea0f-4759-a3a7-75df8c8ee405@googlegroups.com>, <hughaguilar96@gmail.com> wrote: >On Sunday, November 13, 2016 at 12:43:53 PM UTC-7, Paul Rubin wrote: >> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >> >>and gcc therefore "optimized" the memset() away. And >> >>while the following read from that memory (due to a buffer overflow) >> > They should have checked what happens while optimising. Failing that >> > they shouldn't have optimised. >> >> The right way to do that in C is with a volatile cast. Maybe Forth >> could use something similar. > >C's VOLATILE is useful for systems programming, which is what C was designed for and continues to be used primarily for. > >I'm not really thinking of Straight Forth as being a systems language --- it is possible though --- I will have to think about what, if any, support I want to provide for systems programming. The question is do you want to do such things as reading out an Analog to Digital convertor, closing curtains, dousing the light in a fish tank. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-11-14 16:38 -0800 |
| Message-ID | <22df1836-a6b2-46de-929d-7d80600f0631@googlegroups.com> |
| In reply to | #52617 |
On Monday, November 14, 2016 at 8:31:51 AM UTC-7, Albert van der Horst wrote: > In article <e042242c-ea0f-4759-a3a7-75df8c8ee405@googlegroups.com>, > <hughaguilar96@gmail.com> wrote: > >On Sunday, November 13, 2016 at 12:43:53 PM UTC-7, Paul Rubin wrote: > >> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > >> >>and gcc therefore "optimized" the memset() away. And > >> >>while the following read from that memory (due to a buffer overflow) > >> > They should have checked what happens while optimising. Failing that > >> > they shouldn't have optimised. > >> > >> The right way to do that in C is with a volatile cast. Maybe Forth > >> could use something similar. > > > >C's VOLATILE is useful for systems programming, which is what C was designed for and continues to be used primarily for. > > > >I'm not really thinking of Straight Forth as being a systems language --- it is possible though --- I will have to think about what, if any, support I want to provide for systems programming. > > The question is do you want to do such things as reading out an > Analog to Digital convertor, closing curtains, dousing the light > in a fish tank. How many people want to use their 64-bit desktop-computer as a micro-controller? I would think that it would be less expensive to build a micro-controller board based on some small processor such as the MSP-430 or PIC24 ---have it communicate with the desktop-computer over USB --- if you use TCP/IP then you can open your curtains etc. from the other side of the planet. Most of the time, the environment doesn't allow a desktop-computer. For example, this kind of thing is done for providing water and feed to livestock automatically, but the envirnoment (a barn) is dusty so the electronics have to be enclosed. Another issue is power-consumption --- a well providing water to cattle on BLM land is going to have only solar power available. All in all, I don't think a desktop-computer is a very good micro-controller --- this was done in the 1980s when desktop-computers used the same processor (the 6502) as a micro-controller would use --- it wasn't all that good of an idea then either though.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-14 17:42 +0000 |
| Message-ID | <2016Nov14.184256@mips.complang.tuwien.ac.at> |
| In reply to | #52591 |
Paul Rubin <no.email@nospam.invalid> writes:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>and gcc therefore "optimized" the memset() away. And
>>>while the following read from that memory (due to a buffer overflow)
>> They should have checked what happens while optimising. Failing that
>> they shouldn't have optimised.
>
>The right way to do that in C is with a volatile cast.
Is it? Other people tell me it's memset_s. Looking at the C11
standard for memset_s, I did not see anything that would keep a
sufficiently adverserial compiler writer from optimizing it away. It
says:
|Unlike memset, any call to the memset_s function shall be evaluated
|strictly according to the rules of the abstract machine as described
|in (5.1.2.3). That is, any call to the memset_s function shall assume
|that the memory indicated by s and n may be accessible in the future
|and thus must contain the values indicated by c.
Now, everything else (including memset()) in the standard also is
evaluated according to the rules of the abstract machine, and the
"optimization" comes in afterwards, applies the as-if rule, and poof,
memset() is gone, and so is memset_s(). From what I read, "volatile"
is not specified very clearly, so it probably has this problem and
more.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-11-14 16:39 -0500 |
| Message-ID | <20161114163948.63e4da69@_> |
| In reply to | #52627 |
On Mon, 14 Nov 2016 17:42:56 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Paul Rubin <no.email@nospam.invalid> writes: > >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > >>>and gcc therefore "optimized" the memset() away. And > >>>while the following read from that memory (due to a buffer > >>>overflow) > >> > >> They should have checked what happens while optimising. Failing > >> that they shouldn't have optimised. > > > >The right way to do that in C is with a volatile cast. > > Is it? I haven't read the C specification on "volatile" in a while, but "volatile" is supposed to prevent optimizing away reads or writes to memory or ports. "volatile" is used to tell the compiler that something outside the context of the compiled C code is modifying memory locations or updating values, e.g., ports, such as from hardware or another program. Of course, casting an integer to a memory or port address is undefined behavior in C, or compiler defined behavior. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-17 12:40 +0000 |
| Message-ID | <2016Nov17.134040@mips.complang.tuwien.ac.at> |
| In reply to | #52633 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes:
>I haven't read the C specification on "volatile" in a while, but
>"volatile" is supposed to prevent optimizing away reads or writes to
>memory or ports.
And memset() is specified to write over a block of memory. That has
not kept "optimizing" C compilers from "optimizing" it away.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web