arch/m68k/math-emu/fp_decode.h
Source file repositories/reference/linux-study-clean/arch/m68k/math-emu/fp_decode.h
File Facts
- System
- Linux kernel
- Corpus path
arch/m68k/math-emu/fp_decode.h- Extension
.h- Size
- 10284 bytes
- Lines
- 418
- Domain
- Architecture Layer
- Bucket
- arch/m68k
- 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.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#ifndef _FP_DECODE_H
#define _FP_DECODE_H
/* These macros do the dirty work of the instr decoding, several variables
* can be defined in the source file to modify the work of these macros,
* currently the following variables are used:
* ...
* The register usage:
* d0 - will contain source operand for data direct mode,
* otherwise scratch register
* d1 - upper 16bit are reserved for caller
* lower 16bit may contain further arguments,
* is destroyed during decoding
* d2 - contains first two instruction words,
* first word will be used for extension word
* a0 - will point to source/dest operand for any indirect mode
* otherwise scratch register
* a1 - scratch register
* a2 - base addr to the task structure
*
* the current implementation doesn't check for every disallowed
* addressing mode (e.g. pc relative modes as destination), as long
* as it only means a new addressing mode, which should not appear
* in a program and that doesn't crash the emulation, I think it's
* not a problem to allow these modes.
*/
do_fmovem=0
do_fmovem_cr=0
do_no_pc_mode=0
do_fscc=0
| first decoding of the instr type
| this separates the conditional instr
.macro fp_decode_cond_instr_type
bfextu %d2{#8,#2},%d0
jmp ([0f:w,%pc,%d0*4])
.align 4
0:
| .long "f<op>","fscc/fdbcc"
| .long "fbccw","fbccl"
.endm
| second decoding of the instr type
| this separates most move instr
.macro fp_decode_move_instr_type
bfextu %d2{#16,#3},%d0
jmp ([0f:w,%pc,%d0*4])
.align 4
0:
| .long "f<op> fpx,fpx","invalid instr"
| .long "f<op> <ea>,fpx","fmove fpx,<ea>"
| .long "fmovem <ea>,fpcr","fmovem <ea>,fpx"
| .long "fmovem fpcr,<ea>","fmovem fpx,<ea>"
.endm
| extract the source specifier, specifies
| either source fp register or data format
.macro fp_decode_sourcespec
bfextu %d2{#19,#3},%d0
.endm
| decode destination format for fmove reg,ea
.macro fp_decode_dest_format
bfextu %d2{#19,#3},%d0
.endm
| decode source register for fmove reg,ea
.macro fp_decode_src_reg
bfextu %d2{#22,#3},%d0
.endm
| extract the addressing mode
| it depends on the instr which of the modes is valid
.macro fp_decode_addr_mode
bfextu %d2{#10,#3},%d0
jmp ([0f:w,%pc,%d0*4])
.align 4
0:
| .long "data register direct","addr register direct"
| .long "addr register indirect"
| .long "addr register indirect postincrement"
| .long "addr register indirect predecrement"
| .long "addr register + index16"
| .long "extension mode1","extension mode2"
.endm
Annotation
- Atlas domain: Architecture Layer / arch/m68k.
- 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.