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!d62g2000hsf.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: Thu, 13 Mar 2008 19:07:11 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4bf50326-6ebf-455d-b54f-e1e75f265f50@d62g2000hsf.googlegroups.com> References: <13t4b2kkjem20f3@corp.supernews.com> <114f711c-9cf8-4fdb-8f11-77667afb8719@c33g2000hsd.googlegroups.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> 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 1205460432 1791 127.0.0.1 (14 Mar 2008 02:07:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 14 Mar 2008 02:07:12 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d62g2000hsf.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:20361 Date: 2008-03-13T19:07:11-07:00 List-Id: 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. > can even allow setting this - I remember seeing it somewhere). In any > case, it is the implementation in its entirety that has to handle it - > somehow. We don't need to bother how it's done. > The full meaning of volatile is defined in terms of its relation to so > called sequence points and program side-effects. There is some place > left just for "magic". "Magic" not a good way to define an algorithmic language. > > The problem is that when you make something volatile in your program, > it has no special meaning to CPU and is therefore subject to "smart" > optimization. Than why this keyword is still there, just drop it and issue warning "volatile obsolete and no longer supported"? > > I have seen once a very interesting model for memory in multi-core and > multi-cpu machines. Imagine that each thread (or tasks in Ada) has its > own private memory. There is also one "global" memory area. There is > some "magic" that makes random bits of private memory propagate at > random times to the global part and another that makes random bits of > global memory propagate at random times to private parts of each > thread (task). This model can sound completely crazy, but actually > foresees all bad things that can happen in MT program - including > reordering. What would it take to enforce the code that ensures memory writes and flushes the L1 cache. That should be enough to make clear implementation of volatile (as defined by the standard). The performance penalty should not be that significant (in most cases) since flush is DMA process (?). An again, the standard warns about those performance penalties so who gives the right to compiler implementers to decide for us what is good or not? > There are some system-level mechanisms that help control all this mess > and that force the memory blocks to synchronize - these include > mutexes, condvars and membars with release-acquire consistency (in > Ada, you get them with protected objects, entry barriers, etc.). > You should write your program with this crazy model in mind. If you > can make it correct, it will work everywhere. > > -- > Maciej Sobczak *www.msobczak.com*www.inspirel.com Anyways, that sounds like total chaos. When investing in code development clarity and predictability is not the last items on my list. Our C++ activity nowadays is limited to embedded DSP platforms and you helped me to appreciate the simplicity and predictability of architecture that we use (TI DM642). I am convinced to use C++ no further than this device (not even floating point supported), given that we have no other choice anyways, and have no time neither desire or reasonable justification to get into details that you just described. With the general purpose programming, it is also a convincing argument for using Ada as a first choice - the decision that we made months ago. Finally, I think we got carried away with C/C+ + issues that are totally foreign to Ada while being in Ada forum and are somewhat rude to others. So let's leave it at that before getting shout at (Although Ada folks are much more tolerant then C++ crowd on off-topic issues). Regards, George..