public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
* Inquiry about brl statement
@ 2007-04-27 15:16 Christian Kandeler
  2007-04-27 16:18 ` David Mosberger-Tang
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Christian Kandeler @ 2007-04-27 15:16 UTC (permalink / raw)
  To: linux-ia64

Hello, 

in the definition of the BRL_COND_FSYS_BUBBLE_DOWN macro in 
arch/ia64/kernel/gate.S, shouldn't there be a stop bit after the brl.cond 
instruction? According to the Intel specs, the current definition (which has 
no stop bit) triggers undefined behavior.


Regards,
Christian Kandeler

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Inquiry about brl statement
  2007-04-27 15:16 Inquiry about brl statement Christian Kandeler
@ 2007-04-27 16:18 ` David Mosberger-Tang
  2007-04-27 18:49 ` Luck, Tony
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: David Mosberger-Tang @ 2007-04-27 16:18 UTC (permalink / raw)
  To: linux-ia64

As I remember it, a taken branch acts as a stop whereas a non-taken
branch doesn't (so if no explicit stop bit is following a branch, then
it must be OK for the entire group to be executed in parallel).  I
suppose it's possible the definition changed or that my (admittedly
bad) memory is playing tricks on me. ;-)

  --david

On 4/27/07, Christian Kandeler <christian.kandeler@hob.de> wrote:
> Hello,
>
> in the definition of the BRL_COND_FSYS_BUBBLE_DOWN macro in
> arch/ia64/kernel/gate.S, shouldn't there be a stop bit after the brl.cond
> instruction? According to the Intel specs, the current definition (which has
> no stop bit) triggers undefined behavior.
>
>
> Regards,
> Christian Kandeler
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Inquiry about brl statement
  2007-04-27 15:16 Inquiry about brl statement Christian Kandeler
  2007-04-27 16:18 ` David Mosberger-Tang
@ 2007-04-27 18:49 ` Luck, Tony
  2007-04-27 20:00 ` David Mosberger-Tang
  2007-04-28  0:20 ` Jim Hull
  3 siblings, 0 replies; 5+ messages in thread
From: Luck, Tony @ 2007-04-27 18:49 UTC (permalink / raw)
  To: linux-ia64

> As I remember it, a taken branch acts as a stop whereas a non-taken
> branch doesn't (so if no explicit stop bit is following a branch, then
> it must be OK for the entire group to be executed in parallel).  I
> suppose it's possible the definition changed or that my (admittedly
> bad) memory is playing tricks on me. ;-)

The SDM page for "brl" doesn't look to have any get-out-of stop-bits-free
option.  It says:

 "This instruction must be immediately followed by a stop; otherwise
  its behaviour is undefined."

-Tony

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Inquiry about brl statement
  2007-04-27 15:16 Inquiry about brl statement Christian Kandeler
  2007-04-27 16:18 ` David Mosberger-Tang
  2007-04-27 18:49 ` Luck, Tony
@ 2007-04-27 20:00 ` David Mosberger-Tang
  2007-04-28  0:20 ` Jim Hull
  3 siblings, 0 replies; 5+ messages in thread
From: David Mosberger-Tang @ 2007-04-27 20:00 UTC (permalink / raw)
  To: linux-ia64

Tony,

I'm sure I missed that point about brl.  I probably just assumed it
would have the same behavior as regular branches.  Thanks for catching
that.

  --david

On 4/27/07, Luck, Tony <tony.luck@intel.com> wrote:
> > As I remember it, a taken branch acts as a stop whereas a non-taken
> > branch doesn't (so if no explicit stop bit is following a branch, then
> > it must be OK for the entire group to be executed in parallel).  I
> > suppose it's possible the definition changed or that my (admittedly
> > bad) memory is playing tricks on me. ;-)
>
> The SDM page for "brl" doesn't look to have any get-out-of stop-bits-free
> option.  It says:
>
>  "This instruction must be immediately followed by a stop; otherwise
>   its behaviour is undefined."
>
> -Tony
>


-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Inquiry about brl statement
  2007-04-27 15:16 Inquiry about brl statement Christian Kandeler
                   ` (2 preceding siblings ...)
  2007-04-27 20:00 ` David Mosberger-Tang
@ 2007-04-28  0:20 ` Jim Hull
  3 siblings, 0 replies; 5+ messages in thread
From: Jim Hull @ 2007-04-28  0:20 UTC (permalink / raw)
  To: linux-ia64

David:

If brl had existed from the beginning, then its stop-bit requirements would
have matched those of regular branches.  However, it was added after Merced
could no longer be changed, and because of where it is encoded, and the
desire to enable an OS to emulate it on Merced, it had to have the
must-always-be-followed-by-a-stop-bit rule.

 -- Jim 

> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org 
> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of David 
> Mosberger-Tang
> Sent: Friday, April 27, 2007 1:01 PM
> To: Luck, Tony
> Cc: Christian Kandeler; linux-ia64@vger.kernel.org
> Subject: Re: Inquiry about brl statement
> 
> Tony,
> 
> I'm sure I missed that point about brl.  I probably just assumed it
> would have the same behavior as regular branches.  Thanks for catching
> that.
> 
>   --david
> 
> On 4/27/07, Luck, Tony <tony.luck@intel.com> wrote:
> > > As I remember it, a taken branch acts as a stop whereas a 
> non-taken
> > > branch doesn't (so if no explicit stop bit is following a 
> branch, then
> > > it must be OK for the entire group to be executed in parallel).  I
> > > suppose it's possible the definition changed or that my 
> (admittedly
> > > bad) memory is playing tricks on me. ;-)
> >
> > The SDM page for "brl" doesn't look to have any get-out-of 
> stop-bits-free
> > option.  It says:
> >
> >  "This instruction must be immediately followed by a stop; otherwise
> >   its behaviour is undefined."
> >
> > -Tony
> >
> 
> 
> -- 
> Mosberger Consulting LLC, http://www.mosberger-consulting.com/
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-04-28  0:20 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-27 15:16 Inquiry about brl statement Christian Kandeler
2007-04-27 16:18 ` David Mosberger-Tang
2007-04-27 18:49 ` Luck, Tony
2007-04-27 20:00 ` David Mosberger-Tang
2007-04-28  0:20 ` Jim Hull

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