Re: Memory mapped registers (was Re: Caching & Annex C.6)

[Robert Dewar <robert_dewar@my-deja.com>]

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.