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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,251afb8f1c322bf0 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Memory mapped registers (was Re: Caching & Annex C.6) Date: 1999/09/09 Message-ID: <7r8beg$aji$1@nnrp1.deja.com>#1/1 X-Deja-AN: 522918638 References: <7r5mb7$c4d$1@nnrp1.deja.com> <7r7ljl$sdi6@svlss.lmms.lmco.com> X-Http-Proxy: 1.0 x39.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Thu Sep 09 13:07:37 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-09-09T00:00:00+00:00 List-Id: In article <7r7ljl$sdi6@svlss.lmms.lmco.com>, dkristol@see-my.sig wrote: > A 32 bit record was located on a proper word boundary, > and the compiler generated (MIPS) instructions to read > 4 bytes from two different words (LWL, LWR if i remember > the mnemonic correctly) so that it could save a shift > to get to the bit it was interested in (it shifted the > address instead). It may not have been an optimization. > As far as i could tell, it was a less efficient way to > get the desired bit from and then back out to memory. The LWL/LWR sequence is used when the compiler does not know that a word is located on a proper word boundary, and is typically the most efficient sequence in this case. Now the issue of *why* the compiler did not know is an interesting one, but that's the point, you should not be worrying at this level. In fact it sounds like this was not an optimization, but a LACK of an optimization that caused you trouble. > The name and purpose of the package would give away > the fact that it is not portable code. How many > serial I/O boards (made for our program's concept of > RS-422) are made equal? Ah ha! But what if you switch to another compiler. The issue is not porting to other targets, but other compilers. We have seen issues like this come up all the time! > > Porting code is usually not an issue. There aren't too > many uses for the special software/hardware that gets > developed around here. I think an awful lot of code is developed under this assumption, and then it turns out, for example, that there is a decision to switch to Ada 95, and suddenly you are in the porting business. Remember, I did not say that it was wrong to write non-portable code, that is often completely justified. What I said was that non-portable code should be clearly identified. Code that depends on the particular code generation behavior of the compiler is particularly brittle, because even a new version or minor update of a compiler can change the generated code in what should be a harmless manner, but which may not be if the code has made unwarranted assumptions. Some of the early Linux kernel code made this mistake (and depended on the exact sequence of code generated by gcc, resulting in continued discussions over whether gcc was doing the right thing -- in some cases, it was, but it still broke the kernel). This is now all fixed nicely in Linux. You should aim at fixing similar code you have in your applications :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.