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: Cachi Date: 1999/09/14 Message-ID: <7rlc8g$cj8$1@nnrp1.deja.com>#1/1 X-Deja-AN: 524819071 References: <7r8beg$aji$1@nnrp1.deja.com> <7rkkk6$iog2@svlss.lmms.lmco.com> X-Http-Proxy: 1.0 x37.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: Tue Sep 14 11:41:06 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-14T00:00:00+00:00 List-Id: In article <7rkkk6$iog2@svlss.lmms.lmco.com>, dkristol@see-my.sig wrote: > 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. Seemed quite portable? What does that mean? That the syntax was right, and the compiler did not reject it, and it worked? But that's not good enough! You need to *know* what is and what is not defined in the language, and the only way to know this is to read the definition of the language, and really know the definition well. This is a hard task for many programmers, and is the most common failure that results in non-portable code. > >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". Nope! There is no problem whatsoever in defining unwarranted. The definition of the language tells you quite precisely what you can and cannot count on, and any time you rely on behavior that is described as one of the following unspecified erroneous implementation dependent implementation defined bounded error you should document the fact, and similarly if you rely on behavior of the compiler that is nowhere guaranteed in the RM, e.g. performance requirements or, as in this case, specific generated code sequences, you also need to carefully document the non-portability. > 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. Neither is portable > I think it is reasonable to assume that all > compilers will use the appropriate load and store > instructions under these circumstances. Why is this a reasonable assumption? If you need an "appropriate" load/store instruction, then why not write the instruction you need explicitly! For example if you write: A := B; and these are 32-bit integers, it is quite fine on some machines to use a 32-bit floating load and store, to save integer register pressure. Furthermore, a clever compiler might be able to use a 64-bit floating load and get two loads for the price of one! > This > should also prove to be more portable than machine > code insertion (which is implementation > dependent). Well it is not portable, more portable means that you may get away with not having to rewrite it for a given port, but the huge danger, as apparently in this case, is that the potential non-portability does not get flagged. By using a machine code insertion, you definitely flag this as something that needs looking at in a port. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.