From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e0e1d3b3f7c994b8 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!2g2000hsn.googlegroups.com!not-for-mail From: gpriv@axonx.com Newsgroups: comp.lang.ada Subject: Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing! Date: Fri, 14 Mar 2008 19:29:27 -0700 (PDT) Organization: http://groups.google.com Message-ID: <97488937-7c9d-433b-9871-2e6fd0663073@2g2000hsn.googlegroups.com> References: <13t4b2kkjem20f3@corp.supernews.com> <33557da4-e4ba-4c75-9a55-4b7eb5fdad3b@i12g2000prf.googlegroups.com> <44104211-afd5-4cf7-8467-90471d4afd1b@f63g2000hsf.googlegroups.com> <2c2989ba-a109-40d6-b0a3-f91d94a2d291@a1g2000hsb.googlegroups.com> <9e12a297-599c-48e5-a5f9-5d6dee70e8dc@59g2000hsb.googlegroups.com> <4bf50326-6ebf-455d-b54f-e1e75f265f50@d62g2000hsf.googlegroups.com> NNTP-Posting-Host: 69.250.188.114 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1205548167 8043 127.0.0.1 (15 Mar 2008 02:29:27 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 15 Mar 2008 02:29:27 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 2g2000hsn.googlegroups.com; posting-host=69.250.188.114; posting-account=YaY8rAoAAAAAnFXOECY3BGVJsrvFJCgy User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20405 Date: 2008-03-14T19:29:27-07:00 List-Id: On Mar 14, 5:54 pm, Simon Wright wrote: > gp...@axonx.com writes: > > On Mar 13, 6:25 pm, Maciej Sobczak wrote: > >> On 13 Mar, 17:16, gp...@axonx.com wrote: > > >> > So if you write to IO through volatile and later read from it, you may > >> > get the same value fetched back by "smart" CPU. > > >> I would expect that I/O is realized within the range of memory > >> addresses that is excluded from the "smart" handling (your BIOS setup > > > I would expect that too, but not sure that "compatitive" compiler > > vendors will share my/your beliefs. > > I think that 'volatile' is only a way to tell the compiler that this > object must be read/written directly each time; don't copy it to a > register and manipulate values there. > > Likewise 'atomic' says to read/write the whole thing with one machine > operation. Probably because that's what the IO hardware requires; eg, > you must write all 32 bits at once, not just the only byte you've > changed.. > > The only time this makes sense is with memory-mapped IO where the > system must be designed so that this is sensible. > > If you try it with memory with varying levels of hardware cache and > with multiple cores you are going to be disappointed, I think. IMHO it should not be keeping compiler designers from flushing the contents of the registers down to lowest level, which I believe some compilers do. Performance penalties should not be a cover for not doing this. What also seems to be alarming is proliferation of architecture specificity into the programming techniques. On device level it is unavoidable, but on general systems level inexcusable. What will happen when architecture change? C started as a language for very simple microprocessor architecture language. Now architectures outgrew what the language was originally designed for. Practitioners are simply patching things up trying to make 12-year's old pants to fit on 16-years old boy. G.