Re: mspgcc "undefines" too-many-bits shifts in weird way

Changes to mspgcc are/were driven by tickets filed on the SF bug tracker.
If you'd like this change made after reading the material below, please
file a ticket there.  mspgcc evolution/maintenance is not funded at this
time and the issue is below the threshold that I consider critical enough
to donate time, so the ticket will remain open until somebody takes over
such maintenance.

For the record, I've reconstructed my reasoning from two years ago, which
makes explicit the point Przemek made.  It's not worth the research to
prove it, but again this was justified by similar practices in other gcc
back-ends, even if not x86.

First, the value of a shift expression should be the same whether it is
computed at compile time or at runtime.  I.e., 1 << 16 should produce the
same value as 1 << v when v has the value 16.

Second, the base MSP430 ISA does not have a multi-position shift operation
like x86 does.  It can shift only one bit position at a time.  Variable
shifts must be translated into loops with the iteration count provided at
runtime.  (Second-prime: use of MSP430X which has a limited version of such
instructions should also not result in a change of the value of the shift
expression.)

Third, it is unreasonable when v has the value 63532 to stall the processor
for 65532 iterations of a loop calculating 1 << v.  Instead the runtime
code should limit the iteration count.  Since the maximum number of
iterations before the expression value becomes a constant (i.e., the number
of bits in the expression value) will always be a known power of two,
masking the iteration count to preserve only the low bits from 0 to that
number is the simplest solution.

This is the behavior mspgcc currently uses.  To accommodate your request a
test would have to be added at runtime to see whether the iteration count
is equal to or greater than the number of bits in the expression value, and
if so to substitute the constant (0 or ~0) that would have resulted from
the shift operation.  This introduces code bloat, as in the vast majority
of cases people will not be using a shift count that is large enough to
trigger the conditional.

In my opinion increasing generated code size just to accommodate a practice
that is explicitly undefined behavior is a poor use of resources and
improperly encourages a misunderstanding of how C treats this situation.
Having considered the arguments, no, the behavior will not be changed.

Please note that the new back end under development by Red Hat may have
different behavior.

Peter


On Sun, Apr 21, 2013 at 6:10 PM, Paul Sokolovsky <[email protected]> wrote:

> Hello,
>
> On Sun, 21 Apr 2013 17:06:51 -0500
> Peter Bigot <[email protected]> wrote:
>
> > This decision was intentional, as documented in
> > https://sourceforge.net/p/mspgcc/bugs/118/.  My recollection is that
> > the choice of how to make things consistent was informed by similar
> > behavior in the contemporaneous gcc for x86 or at least one other
> > target architecture.
>
> Thanks for the reference. So, I tested it with x86 gcc 4.4, 4.5, 4.6,
> 4.7 (packages as shipped by Ubuntu), all of them produce mathematically
> expected result. msp430-gcc 4.5.3, 4.7.0 both produce unexpected result.
>
> > As you say, the behavior is undefined.  Anybody who expects any
> > particular behavior for this situation is confused about how C works
> > and should take the issue up with JTC1/SC22/WG14.
>
> That's why I wrote so many words in the original mail. Yes, in small
> world of JTC1/SC22/WG14 C standard the behavior is undefined. But in
> much bigger world of: mathematics, well-known gcc targets, user
> expectations, principle of least surprise, etc. - it's all pretty well
> defined. So, when something is undefined in small area, it's still
> a good idea to have affinity towards how it's done/expected in wider
> areas. So, the request is just that - please kindly consider changing
> that behavior ;-).
>
> >
> > Peter
> >
>
> --
> Best regards,
>  Paul                          mailto:[email protected]
>

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users