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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: dkristol@see-my.sig (David Kristola) Subject: Re: Memory mapped registers (was Re: Cachi Date: 1999/09/14 Message-ID: <7rkkk6$iog2@svlss.lmms.lmco.com>#1/1 X-Deja-AN: 524771802 Distribution: world References: <7r8beg$aji$1@nnrp1.deja.com> Organization: heaps of stacks Reply-To: dkristol@see-my.sig Newsgroups: comp.lang.ada Date: 1999-09-14T00:00:00+00:00 List-Id: In article 1@nnrp1.deja.com, Robert Dewar () writes: >In article <7r7ljl$sdi6@svlss.lmms.lmco.com>, > dkristol@see-my.sig wrote: >> 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! True. Now the question becomes "how do we programmers identify non-portable code?" The record with a rep clause carefully laying out the fields and placing it at the correct address seemed quite portable. It just didn't work correctly. >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. I agree with this. >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. There are assumptions and there are assumptions. Someone once told me that they never make any assumptions. But i went for a ride with them once, and they did not stop at green lights (they assumed the cross traffic was stopping). The problem is defining "unwarranted". I still prefer the idea of mapping an appropriately sized integer to the memory mapped register then using unchecked conversion to turn the data into a proper record for that register. I think it is reasonable to assume that all compilers will use the appropriate load and store instructions under these circumstances. This should also prove to be more portable than machine code insertion (which is implementation dependent). If i had a register that crossed several memory cells, and they had to be referenced in a specific order, then i would resort to a low level solution, and not expect it to be portable to a new compiler (and flag it as such). >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 :-) I always aim to improve my code. Sometimes i miss. If someone can point out a better way of doing something, then i will learn a new trick. That is a good day. --djk, keeper of arcane lore & trivial fluff Home: David95037 at aol dot com Spam: goto.hades@welovespam.com