Re: Memory mapped registers (was Re: Cachi

[dkristol@see-my.sig (David Kristola)]

In article 1@nnrp1.deja.com, Robert Dewar <robert_dewar@my-deja.com> () 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