arch/arm/include/asm/opcodes.h
Source file repositories/reference/linux-study-clean/arch/arm/include/asm/opcodes.h
File Facts
- System
- Linux kernel
- Corpus path
arch/arm/include/asm/opcodes.h- Extension
.h- Size
- 8255 bytes
- Lines
- 234
- Domain
- Architecture Layer
- Bucket
- arch/arm
- Inferred role
- Architecture Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/linkage.hlinux/types.hlinux/swab.hlinux/stringify.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#ifndef __ASM_ARM_OPCODES_H
#define __ASM_ARM_OPCODES_H
#ifndef __ASSEMBLY__
#include <linux/linkage.h>
extern asmlinkage unsigned int arm_check_condition(u32 opcode, u32 psr);
#endif
#define ARM_OPCODE_CONDTEST_FAIL 0
#define ARM_OPCODE_CONDTEST_PASS 1
#define ARM_OPCODE_CONDTEST_UNCOND 2
/*
* Assembler opcode byteswap helpers.
* These are only intended for use by this header: don't use them directly,
* because they will be suboptimal in most cases.
*/
#define ___asm_opcode_swab32(x) ( \
(((x) << 24) & 0xFF000000) \
| (((x) << 8) & 0x00FF0000) \
| (((x) >> 8) & 0x0000FF00) \
| (((x) >> 24) & 0x000000FF) \
)
#define ___asm_opcode_swab16(x) ( \
(((x) << 8) & 0xFF00) \
| (((x) >> 8) & 0x00FF) \
)
#define ___asm_opcode_swahb32(x) ( \
(((x) << 8) & 0xFF00FF00) \
| (((x) >> 8) & 0x00FF00FF) \
)
#define ___asm_opcode_swahw32(x) ( \
(((x) << 16) & 0xFFFF0000) \
| (((x) >> 16) & 0x0000FFFF) \
)
#define ___asm_opcode_identity32(x) ((x) & 0xFFFFFFFF)
#define ___asm_opcode_identity16(x) ((x) & 0xFFFF)
/*
* Opcode byteswap helpers
*
* These macros help with converting instructions between a canonical integer
* format and in-memory representation, in an endianness-agnostic manner.
*
* __mem_to_opcode_*() convert from in-memory representation to canonical form.
* __opcode_to_mem_*() convert from canonical form to in-memory representation.
*
*
* Canonical instruction representation:
*
* ARM: 0xKKLLMMNN
* Thumb 16-bit: 0x0000KKLL, where KK < 0xE8
* Thumb 32-bit: 0xKKLLMMNN, where KK >= 0xE8
*
* There is no way to distinguish an ARM instruction in canonical representation
* from a Thumb instruction (just as these cannot be distinguished in memory).
* Where this distinction is important, it needs to be tracked separately.
*
* Note that values in the range 0x0000E800..0xE7FFFFFF intentionally do not
* represent any valid Thumb-2 instruction. For this range,
* __opcode_is_thumb32() and __opcode_is_thumb16() will both be false.
*
* The ___asm variants are intended only for use by this header, in situations
* involving inline assembler. For .S files, the normal __opcode_*() macros
* should do the right thing.
*/
#ifdef __ASSEMBLY__
#define ___opcode_swab32(x) ___asm_opcode_swab32(x)
#define ___opcode_swab16(x) ___asm_opcode_swab16(x)
#define ___opcode_swahb32(x) ___asm_opcode_swahb32(x)
#define ___opcode_swahw32(x) ___asm_opcode_swahw32(x)
#define ___opcode_identity32(x) ___asm_opcode_identity32(x)
#define ___opcode_identity16(x) ___asm_opcode_identity16(x)
#else /* ! __ASSEMBLY__ */
#include <linux/types.h>
#include <linux/swab.h>
#define ___opcode_swab32(x) swab32(x)
#define ___opcode_swab16(x) swab16(x)
#define ___opcode_swahb32(x) swahb32(x)
#define ___opcode_swahw32(x) swahw32(x)
#define ___opcode_identity32(x) ((u32)(x))
#define ___opcode_identity16(x) ((u16)(x))
#endif /* ! __ASSEMBLY__ */
Annotation
- Immediate include surface: `linux/linkage.h`, `linux/types.h`, `linux/swab.h`, `linux/stringify.h`.
- Atlas domain: Architecture Layer / arch/arm.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.