comp.lang.ada
 help / color / mirror / Atom feed
From: "Jeff Creem" <jeff@thecreems.com>
Subject: Re: Pragma Volatile
Date: Tue, 02 Oct 2001 10:59:23 GMT
Date: 2001-10-02T10:59:23+00:00	[thread overview]
Message-ID: <f6hu7.65977$vq.12158890@typhoon.ne.mediaone.net> (raw)
In-Reply-To: fVfu7.147$jc1.20018@news.xtra.co.nz


"AG" <ang@xtra.co.nz> wrote in message
news:fVfu7.147$jc1.20018@news.xtra.co.nz...
>
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0109300510.71255128@posting.google.com...
>
> >
> > I often find people making this kind of assumption, and
> > in the case of reads I saw one awful bug caused by this:
> >
> >
> >     type R is array (natural range <>) of Boolean;
> >     pragma Pack (R);
> >
> >     Register : R (1 .. 32);
> >     for Register'Address use ...
> >
> >     ...
> >
> >     B := Register (3);
> >
> > one compiler generated a word load, and extracted bit 3.
> > another compiler generated a byte load, and extracted bit 3 from the
> > byte.
> >
> > Both code sequences are perfectly valid, and just as
> > efficient as one another. But the hardware had been
> > build to require word loads, and byte loads were don't
> > care and put the hardware into some obscure state.
> >
>
> Isn't it true that a compiler that puts it's target machine into
> some obscure state can't be called perfectly valid? After all,
> it is the job of the compiler to either produce a valid code or
> reject what isn't possible. Can you really call a code sequence
> (generated by a compiler with no control by the programmer)
> "perfectly valid" if it sends the target machine from here to
> "some obscure state"?
>
> > But of course the real bug is in the implicit assumption
> > in the code.
>
> Well, that may be a bug in the assumptions in the code, but
> it also looks like a compiler bug in so far that it accepted and
> (mis)implemented those assumptions.
>
>
>

No it is not a compiler bug for cases like this. It is not that the compiler
puts
the target into an obscure state. Cases like this arise when you have some
specific hardware that you are address mapping to where that hardware does
not
allow certain addressing modes that ARE perfectly valid for the architecture
of the processor.

One could only say this is a compiler problem if the compiler was some
strange compiler that
was build to know about the specific hardware that you are interfacing to.
(Like some magic gcc build built with)
./configure --target=power-pc-with-some-custom-hardware-at-address-0x404040-
to0x505055-that-requires-longword-access-even-though-this-processor-is-byte-
addressable

(sorry for the 80 col violation but I was trying to get the point across).


To put it another way, the code that the compiler generated would be fine if
the address of
the variable Register was in normal system RAM but falls apart when the
address is mapped
to some hardware that only allows longword (or some other specific) access.






  reply	other threads:[~2001-10-02 10:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-25 14:07 Pragma Volatile Jon R. Harshaw
2001-09-25 14:23 ` David C. Hoos
2001-09-25 14:38 ` Marin David Condic
2001-09-25 23:03 ` Mark Johnson
2001-09-29 17:38   ` Tucker Taft
2001-09-29 18:22     ` minyard
2001-09-29 22:28       ` Jeffrey Carter
2001-09-30 13:10         ` Robert Dewar
2001-09-30 21:19           ` Jeffrey Carter
2001-10-01  2:58             ` minyard
2001-10-02  9:38           ` AG
2001-10-02 10:59             ` Jeff Creem [this message]
2001-09-30  2:03       ` DuckE
2001-09-30 13:01       ` Robert Dewar
2001-09-30 20:12         ` minyard
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox