Sparc-Constants - Using as
Description: Using as

Next: Sparc-Relocs, Previous: Sparc-Regs, Up: Sparc-Syntax

##### 9.36.3.3 Constants

Several Sparc instructions take an immediate operand field for which mnemonic names exist. Two such examples are ‘`membar`’ and ‘`prefetch`’. Another example are the set of V9 memory access instruction that allow specification of an address space identifier.

The ‘`membar`’ instruction specifies a memory barrier that is the defined by the operand which is a bitmask. The supported mask mnemonics are:

- ‘`#Sync`’ requests that all operations (including nonmemory reference operations) appearing prior to the `membar` must have been performed and the effects of any exceptions become visible before any instructions after the `membar` may be initiated. This corresponds to `membar` cmask field bit 2.
- ‘`#MemIssue`’ requests that all memory reference operations appearing prior to the `membar` must have been performed before any memory operation after the `membar` may be initiated. This corresponds to `membar` cmask field bit 1.
- ‘`#Lookaside`’ requests that a store appearing prior to the `membar` must complete before any load following the `membar` referencing the same address can be initiated. This corresponds to `membar` cmask field bit 0.
- ‘`#StoreStore`’ defines that the effects of all stores appearing prior to the `membar` instruction must be visible to all processors before the effect of any stores following the `membar`. Equivalent to the deprecated `stbar` instruction. This corresponds to `membar` mmask field bit 3.
- ‘`#LoadStore`’ defines all loads appearing prior to the `membar` instruction must have been performed before the effect of any stores following the `membar` is visible to any other processor. This corresponds to `membar` mmask field bit 2.
- ‘`#StoreLoad`’ defines that the effects of all stores appearing prior to the `membar` instruction must be visible to all processors before loads following the `membar` may be performed. This corresponds to `membar` mmask field bit 1.
- ‘`#LoadLoad`’ defines that all loads appearing prior to the `membar` instruction must have been performed before any loads following the `membar` may be performed. This corresponds to `membar` mmask field bit 0.

These values can be ored together, for example:

         membar #Sync
         membar #StoreLoad | #LoadLoad
         membar #StoreLoad | #StoreStore

The `prefetch` and `prefetcha` instructions take a prefetch function code. The following prefetch function code constant mnemonics are available:

- ‘`#n_reads`’ requests a prefetch for several reads, and corresponds to a prefetch function code of 0.

  ‘`#one_read`’ requests a prefetch for one read, and corresponds to a prefetch function code of 1.

  ‘`#n_writes`’ requests a prefetch for several writes (and possibly reads), and corresponds to a prefetch function code of 2.

  ‘`#one_write`’ requests a prefetch for one write, and corresponds to a prefetch function code of 3.

  ‘`#page`’ requests a prefetch page, and corresponds to a prefetch function code of 4.

  ‘`#invalidate`’ requests a prefetch invalidate, and corresponds to a prefetch function code of 16.

  ‘`#unified`’ requests a prefetch to the nearest unified cache, and corresponds to a prefetch function code of 17.

  ‘`#n_reads_strong`’ requests a strong prefetch for several reads, and corresponds to a prefetch function code of 20.

  ‘`#one_read_strong`’ requests a strong prefetch for one read, and corresponds to a prefetch function code of 21.

  ‘`#n_writes_strong`’ requests a strong prefetch for several writes, and corresponds to a prefetch function code of 22.

  ‘`#one_write_strong`’ requests a strong prefetch for one write, and corresponds to a prefetch function code of 23.

  Onle one prefetch code may be specified. Here are some examples:

                prefetch  [%l0 + %l2], #one_read
                prefetch  [%g2 + 8], #n_writes
                prefetcha [%g1] 0x8, #unified
                prefetcha [%o0 + 0x10] %asi, #n_reads

  The actual behavior of a given prefetch function code is processor specific. If a processor does not implement a given prefetch function code, it will treat the prefetch instruction as a nop.

  For instructions that accept an immediate address space identifier, `as` provides many mnemonics corresponding to V9 defined as well as UltraSPARC and Niagara extended values. For example, ‘`#ASI_P`’ and ‘`#ASI_BLK_INIT_QUAD_LDD_AIUS`’. See the V9 and processor specific manuals for details.