Re: Memory mapped registers (was Re: Cachi

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

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.