' + doc.html for doc in docs])
+
+ # Put the actual documentation first, then the links
+ combined_html = ''
+ if html_parts:
+ combined_html = f"{'\n'.join(html_parts)}\n"
+
+ combined_html += f'For more information, visit {", ".join(links)}.'
+
+ return tooltip_txt, combined_html
def main():
@@ -62,57 +95,228 @@ def main():
print(f"Called with: {args}")
# get PTX docs
- r = requests.get('https://docs.nvidia.com/cuda/parallel-thread-execution/index.html')
+ r = requests.get(PTX_DOCS_BASE_URL, timeout=30)
r.encoding = 'utf-8'
soup = BeautifulSoup(r.text, 'html.parser')
symbol_to_fullname_frag0: defaultdict[str, list[tuple[str, str]]] = collections.defaultdict(list)
- for links, anchor_text_sep in [
- (soup.find('a', class_='reference internal', href='#instruction-set').parent.find_all('a'), 'Instructions: '),
- (soup.find('a', class_='reference internal', href='#directives').parent.find_all('a'), 'Directives: '),
- (soup.find('a', class_='reference internal', href='#special-registers').parent.find_all('a'),
- 'Special Registers: ')]:
- for link in links:
- if anchor_text_sep in link.string:
- topic, instructions0 = link.string.split(anchor_text_sep)
- instructions: list[str] = instructions0.replace(' / ', ', ').split(', ')
- href: str = link.get('href')
- assert href.startswith('#')
- frag = href[1:]
- for instr in instructions:
- if not instr.startswith('@') and ' ' not in instr and instr != '{}':
- instr_fullname = instr.lstrip('.').lstrip('%')
- symbol_to_fullname_frag0[instr_fullname.split('.', 1)[0]].append((instr_fullname, frag))
+
+ # Find all sections with instruction documentation structure
+ all_sections = soup.find_all(['section', 'div'], id=lambda x: x and '-instructions-' in x)
+
+ # Helper to check if a section is a valid instruction section
+ def is_valid_instruction_section(section_id):
+ if '-' not in section_id:
+ return False
+ last_part = section_id.rsplit('-', 1)[-1]
+ # Skip non-instruction sections and composite instructions
+ if last_part in ['restrictions', 'mechanisms', 'smem', 'notes'] or '-' in last_part:
+ return False
+ # Also skip sections that end with "mechanisms-mbarrier" etc
+ if 'mechanisms' in section_id or 'restrictions' in section_id:
+ return False
+ return True
+
+ # Define section preference order (most preferred first)
+ SECTION_PREFERENCE = [
+ 'integer-arithmetic-instructions',
+ 'floating-point-instructions',
+ 'half-precision-floating-point-instructions',
+ 'extended-precision-arithmetic-instructions',
+ 'comparison-and-selection-instructions',
+ 'logical-instructions',
+ 'data-movement-and-conversion-instructions',
+ 'texture-instructions',
+ 'surface-instructions',
+ ]
+
+ # Track which instructions we've already documented
+ seen_instructions = {}
+
+ # First, group sections by their preference order
+ sections_by_preference = {pref: [] for pref in SECTION_PREFERENCE}
+ sections_other = []
+
+ for section in all_sections:
+ section_id = section.get('id', '')
+
+ if not is_valid_instruction_section(section_id):
+ continue
+
+ # Check if this section has the standard instruction documentation structure
+ rubrics = section.find_all('p', class_='rubric')
+ rubric_texts = [r.get_text(strip=True) for r in rubrics]
+
+ # Only process sections with proper instruction documentation structure
+ if not any(r in rubric_texts for r in DOC_RUBRIC_TYPES):
+ continue
+
+ # Categorize by preference
+ categorized = False
+ for pref in SECTION_PREFERENCE:
+ if pref in section_id:
+ sections_by_preference[pref].append(section)
+ categorized = True
+ break
+ if not categorized:
+ sections_other.append(section)
+
+ # Process sections in preference order
+ for pref in SECTION_PREFERENCE:
+ for section in sections_by_preference[pref]:
+ section_id = section.get('id', '')
+
+ # Get actual instruction name from first code element
+ first_code = section.find('code')
+ if not first_code:
+ continue
+
+ fullname = first_code.get_text(strip=True).lstrip('.').lstrip('%')
+ # Extract base instruction name (before first dot or space)
+ base_instruction = fullname.split('.')[0].split()[0]
+
+ # Only add if we haven't seen this base instruction before
+ if base_instruction not in seen_instructions:
+ seen_instructions[base_instruction] = (fullname, section_id)
+ symbol_to_fullname_frag0[base_instruction].append((fullname, section_id))
+
+ # Process remaining sections
+ for section in sections_other:
+ section_id = section.get('id', '')
+ first_code = section.find('code')
+ if not first_code:
+ continue
+
+ fullname = first_code.get_text(strip=True).lstrip('.').lstrip('%')
+ base_instruction = fullname.split('.')[0].split()[0]
+
+ if base_instruction not in seen_instructions:
+ seen_instructions[base_instruction] = (fullname, section_id)
+ symbol_to_fullname_frag0[base_instruction].append((fullname, section_id))
+
+ # Collect instruction variants (e.g., add.s32, add.f32)
+ for section in all_sections:
+ section_id = section.get('id', '')
+
+ if not is_valid_instruction_section(section_id):
+ continue
+
+ # Check structure
+ rubrics = section.find_all('p', class_='rubric')
+ rubric_texts = [r.get_text(strip=True) for r in rubrics]
+ if not any(r in rubric_texts for r in DOC_RUBRIC_TYPES):
+ continue
+
+ # Look for instruction variants in syntax section
+ syntax_rubric = section.find('p', class_='rubric', string='Syntax')
+ if syntax_rubric:
+ # Find the syntax block (usually next sibling)
+ next_elem = syntax_rubric.find_next_sibling()
+ if next_elem:
+ # Look for code elements that are instruction variants
+ codes = next_elem.find_all('code') if next_elem.name == 'div' else section.find_all('code')[:10]
+ for code in codes:
+ text = code.get_text(strip=True).lstrip('.').lstrip('%')
+ # Check if this looks like an instruction (not an operand)
+ if text and not text.startswith(('d,', 'a,', 'b,', 'c,')) and len(text) < 40:
+ parts = text.split()
+ if parts: # Has content
+ instruction = parts[0]
+ if '.' in instruction: # It's a variant
+ base = instruction.split('.')[0]
+ # Only add variants for instructions we're documenting
+ if base in seen_instructions and (instruction, section_id) not in symbol_to_fullname_frag0[base]:
+ symbol_to_fullname_frag0[base].append((instruction, section_id))
+
+ # Remove duplicates and sort
symbol_to_fullname_frag: list[tuple[str, list[tuple[str, str]]]] = sorted(
- (instr, sorted(set(fullname_frags))) for instr, fullname_frags in symbol_to_fullname_frag0.items())
+ (instr, sorted(set(fullname_frags))) for instr, fullname_frags in symbol_to_fullname_frag0.items()
+ if fullname_frags) # Only include if we have fragments
+
+ # Fail loudly if no instructions were found
+ if not symbol_to_fullname_frag:
+ print("ERROR: No PTX instructions found in documentation!")
+ print("The website structure may have changed.")
+ print("Please update the docenizer-ptx-sass.py script to handle the new format.")
+ sys.exit(1)
def get_doc(fragment: str) -> Doc:
- article = copy.copy(soup.find(id=fragment))
- txt0 = article.text.replace('\n\n', '\n').replace('\n\n', '\n')
- title, _, txt = txt0.split(' ', 1)[1].split('\n', 2)
+ # Find the section
+ article = soup.find(id=fragment)
+ if not article:
+ raise ValueError(f"Documentation section not found for fragment: {fragment}")
+
+ # Get the title from the first header we find
+ title = fragment.replace('-', ' ').title() # Default to formatted fragment id
for i in range(2, 6):
- if h := article.find(f'h{i}'):
- h.decompose()
+ h = article.find(f'h{i}')
+ if h:
+ title = h.get_text(strip=True)
break
+
+ # First, try to find the short description that appears between instruction name and Syntax
+ short_desc = None
+ instruction_rubric = article.find('p', class_='rubric') # First rubric is usually instruction name
+ if instruction_rubric:
+ next_p = instruction_rubric.find_next_sibling('p')
+ if next_p and 'rubric' not in next_p.get('class', []):
+ short_desc_text = next_p.get_text(strip=True)
+ if short_desc_text and len(short_desc_text) < 100: # Short descriptions are typically brief
+ short_desc = short_desc_text
+
+ # Get description from Description rubric (all PTX instructions have this)
+ desc_rubric = article.find('p', class_='rubric', string='Description')
+ if not desc_rubric:
+ raise ValueError(f"No Description rubric found for {fragment}")
+
+ # Description can be in either a
or
element
+ next_elem = desc_rubric.find_next_sibling(['p', 'dl'])
+ if not next_elem:
+ raise ValueError(f"No description element found after Description rubric for {fragment}")
+
+ # If it's a
, check it's not another rubric
+ if next_elem.name == 'p' and 'rubric' in next_elem.get('class', []):
+ raise ValueError(f"No description content found after Description rubric for {fragment}")
+
+ if not next_elem.get_text(strip=True):
+ raise ValueError(f"Empty description after Description rubric for {fragment}")
+
+ html = str(next_elem)
+
+ # Tooltip text: Use short description if available, otherwise truncate detailed description.
+ # This fallback is necessary because some PTX instructions don't have short summaries -
+ # they jump straight to Syntax or have descriptions > 100 chars (e.g., mad, mov, set).
+ if short_desc:
+ txt = short_desc
else:
- print("=====")
- print(article)
- raise AssertionError
- article.p.decompose() # remove the instruction name
- return Doc(title.rstrip(''), txt, str(article))
-
+ detailed_desc = next_elem.get_text(strip=True)
+ txt = truncate_text(detailed_desc, 200)
+
+ return Doc(title, txt, html)
+
symbol_to_doc: list[tuple[str, str, str, list[tuple[str, str]]]] = []
for symbol, fullname_fragments in symbol_to_fullname_frag:
- docs = [get_doc(fragment) for _, fragment in fullname_fragments]
- symbol_to_doc.append((symbol, *combine_docs(docs, fullname_fragments), fullname_fragments))
-
+ docs = []
+ for fullname, fragment in fullname_fragments:
+ docs.append(get_doc(fragment))
+
+ if docs:
+ symbol_to_doc.append((symbol, *combine_docs(docs, fullname_fragments), fullname_fragments))
+ else:
+ raise ValueError(f"No documentation could be parsed for instruction: {symbol}")
+
# get SASS docs
- tables = pd.read_html('https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html', match='Opcode')
- sass_docs = sorted(dict(pd.concat(tables).dropna().itertuples(index=False)).items())
+ tables = pd.read_html(CUDA_BINARY_UTILS_URL, match='Opcode')
+ sass_docs = sorted(
+ (opcode, description)
+ for (opcode, description) in pd.concat(tables).dropna().drop_duplicates(["Opcode"], keep="last").itertuples(index=False)
+ if opcode != description
+ )
- with open( args.outputfolder + '/asm-docs-ptx.ts', 'w') as f:
+ output_dir = Path(args.outputfolder)
+ with (output_dir / 'asm-docs-ptx.ts').open('w') as f:
f.write("""
- import {AssemblyInstructionInfo} from '../base.js';
+ import type {AssemblyInstructionInfo} from '../../../types/assembly-docs.interfaces.js';
export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInfo | undefined {
if (!opcode) return;
@@ -125,15 +329,15 @@ def get_doc(fragment: str) -> Doc:
"tooltip": tooltip.replace('\n', '\n\n'),
"html": body,
# there can be multiple doc links for a single instruction
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#" + fullname_fragments[0][1]
+ "url": f"{PTX_DOCS_BASE_URL}#{fullname_fragments[0][1]}"
}, indent=16, separators=(',', ': '), sort_keys=True))[:-1] + ' };\n\n')
f.write("""
}
}
""")
- with open(args.outputfolder + '/asm-docs-sass.ts', 'w') as f:
+ with (output_dir / 'asm-docs-sass.ts').open('w') as f:
f.write("""
- import {AssemblyInstructionInfo} from '../base.js';
+ import type {AssemblyInstructionInfo} from '../../../types/assembly-docs.interfaces.js';
export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInfo | undefined {
if (!opcode) return;
@@ -141,15 +345,15 @@ def get_doc(fragment: str) -> Doc:
""".lstrip())
# SASS
for name, description in sass_docs:
+ url = f"{CUDA_BINARY_UTILS_URL}#instruction-set-reference"
f.write(f' case "{name}":\n')
f.write(' return {}'.format(json.dumps({
"tooltip": description,
- "html": description +
- f'
For more information, visit '
+ f'CUDA Binary Utilities'
+ f' documentation .',
+ "url": url
}, indent=16, separators=(',', ': '), sort_keys=True))[:-1] + ' };\n\n')
f.write("""
@@ -158,4 +362,4 @@ def get_doc(fragment: str) -> Doc:
""")
if __name__ == '__main__':
- main()
\ No newline at end of file
+ main()
diff --git a/etc/scripts/docenizers/docenizer-python.py b/etc/scripts/docenizers/docenizer-python.py
index 1a5963cd0ed..4d2fe1c41f9 100755
--- a/etc/scripts/docenizers/docenizer-python.py
+++ b/etc/scripts/docenizers/docenizer-python.py
@@ -132,7 +132,7 @@ def main():
print(f"Writing {len(instructions)} instructions")
with open(args.outputpath, 'w') as f:
f.write("""
-import {AssemblyInstructionInfo} from '../base.js';
+import type {AssemblyInstructionInfo} from '../../../types/assembly-docs.interfaces.js';
export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInfo | undefined {
if (!opcode) return;
diff --git a/etc/scripts/docenizers/docenizer-riscv64.py b/etc/scripts/docenizers/docenizer-riscv64.py
index a95c2ff8b01..35a10b523ef 100755
--- a/etc/scripts/docenizers/docenizer-riscv64.py
+++ b/etc/scripts/docenizers/docenizer-riscv64.py
@@ -117,7 +117,7 @@ def __str__(self):
with open(args.outputpath, "w") as output:
output.write("""
-import {AssemblyInstructionInfo} from '../base.js';
+import type {AssemblyInstructionInfo} from '../../../types/assembly-docs.interfaces.js';
export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInfo | undefined {
if (!opcode) return;
diff --git a/etc/scripts/docenizers/pyproject.toml b/etc/scripts/docenizers/pyproject.toml
new file mode 100644
index 00000000000..df3e715a62d
--- /dev/null
+++ b/etc/scripts/docenizers/pyproject.toml
@@ -0,0 +1,29 @@
+[project]
+name = "compiler-explorer-docenizers"
+version = "0.0.1"
+description = "Assembly documentation generators for Compiler Explorer"
+requires-python = ">=3.12"
+dependencies = [
+ "beautifulsoup4>=4.12.0",
+ "lxml>=5.0.0",
+ "pandas>=2.2.0",
+ "pdfminer.six>=20231228",
+ "PyYAML>=6.0",
+ "requests>=2.32.0",
+]
+
+[tool.ruff]
+line-length = 120
+target-version = "py312"
+
+[tool.ruff.lint]
+select = [
+ "E", # pycodestyle errors
+ "W", # pycodestyle warnings
+ "F", # pyflake
+ "I", # isort
+ "UP", # pyupgrade
+]
+ignore = [
+ "E501", # line length
+]
\ No newline at end of file
diff --git a/etc/scripts/docenizers/uv.lock b/etc/scripts/docenizers/uv.lock
new file mode 100644
index 00000000000..90b271b9240
--- /dev/null
+++ b/etc/scripts/docenizers/uv.lock
@@ -0,0 +1,518 @@
+version = 1
+revision = 3
+requires-python = ">=3.12"
+
+[[package]]
+name = "beautifulsoup4"
+version = "4.13.5"
+source = { registry = "https://pypi.org/simple" }
+dependencies = [
+ { name = "soupsieve" },
+ { name = "typing-extensions" },
+]
+sdist = { url = "https://files.pythonhosted.org/packages/85/2e/3e5079847e653b1f6dc647aa24549d68c6addb4c595cc0d902d1b19308ad/beautifulsoup4-4.13.5.tar.gz", hash = "sha256:5e70131382930e7c3de33450a2f54a63d5e4b19386eab43a5b34d594268f3695", size = 622954, upload-time = "2025-08-24T14:06:13.168Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/04/eb/f4151e0c7377a6e08a38108609ba5cede57986802757848688aeedd1b9e8/beautifulsoup4-4.13.5-py3-none-any.whl", hash = "sha256:642085eaa22233aceadff9c69651bc51e8bf3f874fb6d7104ece2beb24b47c4a", size = 105113, upload-time = "2025-08-24T14:06:14.884Z" },
+]
+
+[[package]]
+name = "certifi"
+version = "2025.8.3"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/dc/67/960ebe6bf230a96cda2e0abcf73af550ec4f090005363542f0765df162e0/certifi-2025.8.3.tar.gz", hash = "sha256:e564105f78ded564e3ae7c923924435e1daa7463faeab5bb932bc53ffae63407", size = 162386, upload-time = "2025-08-03T03:07:47.08Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/e5/48/1549795ba7742c948d2ad169c1c8cdbae65bc450d6cd753d124b17c8cd32/certifi-2025.8.3-py3-none-any.whl", hash = "sha256:f6c12493cfb1b06ba2ff328595af9350c65d6644968e5d3a2ffd78699af217a5", size = 161216, upload-time = "2025-08-03T03:07:45.777Z" },
+]
+
+[[package]]
+name = "cffi"
+version = "2.0.0"
+source = { registry = "https://pypi.org/simple" }
+dependencies = [
+ { name = "pycparser", marker = "implementation_name != 'PyPy'" },
+]
+sdist = { url = "https://files.pythonhosted.org/packages/eb/56/b1ba7935a17738ae8453301356628e8147c79dbb825bcbc73dc7401f9846/cffi-2.0.0.tar.gz", hash = "sha256:44d1b5909021139fe36001ae048dbdde8214afa20200eda0f64c068cac5d5529", size = 523588, upload-time = "2025-09-08T23:24:04.541Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/ea/47/4f61023ea636104d4f16ab488e268b93008c3d0bb76893b1b31db1f96802/cffi-2.0.0-cp312-cp312-macosx_10_13_x86_64.whl", hash = "sha256:6d02d6655b0e54f54c4ef0b94eb6be0607b70853c45ce98bd278dc7de718be5d", size = 185271, upload-time = "2025-09-08T23:22:44.795Z" },
+ { url = "https://files.pythonhosted.org/packages/df/a2/781b623f57358e360d62cdd7a8c681f074a71d445418a776eef0aadb4ab4/cffi-2.0.0-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:8eca2a813c1cb7ad4fb74d368c2ffbbb4789d377ee5bb8df98373c2cc0dee76c", size = 181048, upload-time = "2025-09-08T23:22:45.938Z" },
+ { url = "https://files.pythonhosted.org/packages/ff/df/a4f0fbd47331ceeba3d37c2e51e9dfc9722498becbeec2bd8bc856c9538a/cffi-2.0.0-cp312-cp312-manylinux1_i686.manylinux2014_i686.manylinux_2_17_i686.manylinux_2_5_i686.whl", hash = "sha256:21d1152871b019407d8ac3985f6775c079416c282e431a4da6afe7aefd2bccbe", size = 212529, upload-time = "2025-09-08T23:22:47.349Z" },
+ { url = "https://files.pythonhosted.org/packages/d5/72/12b5f8d3865bf0f87cf1404d8c374e7487dcf097a1c91c436e72e6badd83/cffi-2.0.0-cp312-cp312-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:b21e08af67b8a103c71a250401c78d5e0893beff75e28c53c98f4de42f774062", size = 220097, upload-time = "2025-09-08T23:22:48.677Z" },
+ { url = "https://files.pythonhosted.org/packages/c2/95/7a135d52a50dfa7c882ab0ac17e8dc11cec9d55d2c18dda414c051c5e69e/cffi-2.0.0-cp312-cp312-manylinux2014_ppc64le.manylinux_2_17_ppc64le.whl", hash = "sha256:1e3a615586f05fc4065a8b22b8152f0c1b00cdbc60596d187c2a74f9e3036e4e", size = 207983, upload-time = "2025-09-08T23:22:50.06Z" },
+ { url = "https://files.pythonhosted.org/packages/3a/c8/15cb9ada8895957ea171c62dc78ff3e99159ee7adb13c0123c001a2546c1/cffi-2.0.0-cp312-cp312-manylinux2014_s390x.manylinux_2_17_s390x.whl", hash = "sha256:81afed14892743bbe14dacb9e36d9e0e504cd204e0b165062c488942b9718037", size = 206519, upload-time = "2025-09-08T23:22:51.364Z" },
+ { url = "https://files.pythonhosted.org/packages/78/2d/7fa73dfa841b5ac06c7b8855cfc18622132e365f5b81d02230333ff26e9e/cffi-2.0.0-cp312-cp312-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:3e17ed538242334bf70832644a32a7aae3d83b57567f9fd60a26257e992b79ba", size = 219572, upload-time = "2025-09-08T23:22:52.902Z" },
+ { url = "https://files.pythonhosted.org/packages/07/e0/267e57e387b4ca276b90f0434ff88b2c2241ad72b16d31836adddfd6031b/cffi-2.0.0-cp312-cp312-musllinux_1_2_aarch64.whl", hash = "sha256:3925dd22fa2b7699ed2617149842d2e6adde22b262fcbfada50e3d195e4b3a94", size = 222963, upload-time = "2025-09-08T23:22:54.518Z" },
+ { url = "https://files.pythonhosted.org/packages/b6/75/1f2747525e06f53efbd878f4d03bac5b859cbc11c633d0fb81432d98a795/cffi-2.0.0-cp312-cp312-musllinux_1_2_x86_64.whl", hash = "sha256:2c8f814d84194c9ea681642fd164267891702542f028a15fc97d4674b6206187", size = 221361, upload-time = "2025-09-08T23:22:55.867Z" },
+ { url = "https://files.pythonhosted.org/packages/7b/2b/2b6435f76bfeb6bbf055596976da087377ede68df465419d192acf00c437/cffi-2.0.0-cp312-cp312-win32.whl", hash = "sha256:da902562c3e9c550df360bfa53c035b2f241fed6d9aef119048073680ace4a18", size = 172932, upload-time = "2025-09-08T23:22:57.188Z" },
+ { url = "https://files.pythonhosted.org/packages/f8/ed/13bd4418627013bec4ed6e54283b1959cf6db888048c7cf4b4c3b5b36002/cffi-2.0.0-cp312-cp312-win_amd64.whl", hash = "sha256:da68248800ad6320861f129cd9c1bf96ca849a2771a59e0344e88681905916f5", size = 183557, upload-time = "2025-09-08T23:22:58.351Z" },
+ { url = "https://files.pythonhosted.org/packages/95/31/9f7f93ad2f8eff1dbc1c3656d7ca5bfd8fb52c9d786b4dcf19b2d02217fa/cffi-2.0.0-cp312-cp312-win_arm64.whl", hash = "sha256:4671d9dd5ec934cb9a73e7ee9676f9362aba54f7f34910956b84d727b0d73fb6", size = 177762, upload-time = "2025-09-08T23:22:59.668Z" },
+ { url = "https://files.pythonhosted.org/packages/4b/8d/a0a47a0c9e413a658623d014e91e74a50cdd2c423f7ccfd44086ef767f90/cffi-2.0.0-cp313-cp313-macosx_10_13_x86_64.whl", hash = "sha256:00bdf7acc5f795150faa6957054fbbca2439db2f775ce831222b66f192f03beb", size = 185230, upload-time = "2025-09-08T23:23:00.879Z" },
+ { url = "https://files.pythonhosted.org/packages/4a/d2/a6c0296814556c68ee32009d9c2ad4f85f2707cdecfd7727951ec228005d/cffi-2.0.0-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:45d5e886156860dc35862657e1494b9bae8dfa63bf56796f2fb56e1679fc0bca", size = 181043, upload-time = "2025-09-08T23:23:02.231Z" },
+ { url = "https://files.pythonhosted.org/packages/b0/1e/d22cc63332bd59b06481ceaac49d6c507598642e2230f201649058a7e704/cffi-2.0.0-cp313-cp313-manylinux1_i686.manylinux2014_i686.manylinux_2_17_i686.manylinux_2_5_i686.whl", hash = "sha256:07b271772c100085dd28b74fa0cd81c8fb1a3ba18b21e03d7c27f3436a10606b", size = 212446, upload-time = "2025-09-08T23:23:03.472Z" },
+ { url = "https://files.pythonhosted.org/packages/a9/f5/a2c23eb03b61a0b8747f211eb716446c826ad66818ddc7810cc2cc19b3f2/cffi-2.0.0-cp313-cp313-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:d48a880098c96020b02d5a1f7d9251308510ce8858940e6fa99ece33f610838b", size = 220101, upload-time = "2025-09-08T23:23:04.792Z" },
+ { url = "https://files.pythonhosted.org/packages/f2/7f/e6647792fc5850d634695bc0e6ab4111ae88e89981d35ac269956605feba/cffi-2.0.0-cp313-cp313-manylinux2014_ppc64le.manylinux_2_17_ppc64le.whl", hash = "sha256:f93fd8e5c8c0a4aa1f424d6173f14a892044054871c771f8566e4008eaa359d2", size = 207948, upload-time = "2025-09-08T23:23:06.127Z" },
+ { url = "https://files.pythonhosted.org/packages/cb/1e/a5a1bd6f1fb30f22573f76533de12a00bf274abcdc55c8edab639078abb6/cffi-2.0.0-cp313-cp313-manylinux2014_s390x.manylinux_2_17_s390x.whl", hash = "sha256:dd4f05f54a52fb558f1ba9f528228066954fee3ebe629fc1660d874d040ae5a3", size = 206422, upload-time = "2025-09-08T23:23:07.753Z" },
+ { url = "https://files.pythonhosted.org/packages/98/df/0a1755e750013a2081e863e7cd37e0cdd02664372c754e5560099eb7aa44/cffi-2.0.0-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:c8d3b5532fc71b7a77c09192b4a5a200ea992702734a2e9279a37f2478236f26", size = 219499, upload-time = "2025-09-08T23:23:09.648Z" },
+ { url = "https://files.pythonhosted.org/packages/50/e1/a969e687fcf9ea58e6e2a928ad5e2dd88cc12f6f0ab477e9971f2309b57c/cffi-2.0.0-cp313-cp313-musllinux_1_2_aarch64.whl", hash = "sha256:d9b29c1f0ae438d5ee9acb31cadee00a58c46cc9c0b2f9038c6b0b3470877a8c", size = 222928, upload-time = "2025-09-08T23:23:10.928Z" },
+ { url = "https://files.pythonhosted.org/packages/36/54/0362578dd2c9e557a28ac77698ed67323ed5b9775ca9d3fe73fe191bb5d8/cffi-2.0.0-cp313-cp313-musllinux_1_2_x86_64.whl", hash = "sha256:6d50360be4546678fc1b79ffe7a66265e28667840010348dd69a314145807a1b", size = 221302, upload-time = "2025-09-08T23:23:12.42Z" },
+ { url = "https://files.pythonhosted.org/packages/eb/6d/bf9bda840d5f1dfdbf0feca87fbdb64a918a69bca42cfa0ba7b137c48cb8/cffi-2.0.0-cp313-cp313-win32.whl", hash = "sha256:74a03b9698e198d47562765773b4a8309919089150a0bb17d829ad7b44b60d27", size = 172909, upload-time = "2025-09-08T23:23:14.32Z" },
+ { url = "https://files.pythonhosted.org/packages/37/18/6519e1ee6f5a1e579e04b9ddb6f1676c17368a7aba48299c3759bbc3c8b3/cffi-2.0.0-cp313-cp313-win_amd64.whl", hash = "sha256:19f705ada2530c1167abacb171925dd886168931e0a7b78f5bffcae5c6b5be75", size = 183402, upload-time = "2025-09-08T23:23:15.535Z" },
+ { url = "https://files.pythonhosted.org/packages/cb/0e/02ceeec9a7d6ee63bb596121c2c8e9b3a9e150936f4fbef6ca1943e6137c/cffi-2.0.0-cp313-cp313-win_arm64.whl", hash = "sha256:256f80b80ca3853f90c21b23ee78cd008713787b1b1e93eae9f3d6a7134abd91", size = 177780, upload-time = "2025-09-08T23:23:16.761Z" },
+ { url = "https://files.pythonhosted.org/packages/92/c4/3ce07396253a83250ee98564f8d7e9789fab8e58858f35d07a9a2c78de9f/cffi-2.0.0-cp314-cp314-macosx_10_13_x86_64.whl", hash = "sha256:fc33c5141b55ed366cfaad382df24fe7dcbc686de5be719b207bb248e3053dc5", size = 185320, upload-time = "2025-09-08T23:23:18.087Z" },
+ { url = "https://files.pythonhosted.org/packages/59/dd/27e9fa567a23931c838c6b02d0764611c62290062a6d4e8ff7863daf9730/cffi-2.0.0-cp314-cp314-macosx_11_0_arm64.whl", hash = "sha256:c654de545946e0db659b3400168c9ad31b5d29593291482c43e3564effbcee13", size = 181487, upload-time = "2025-09-08T23:23:19.622Z" },
+ { url = "https://files.pythonhosted.org/packages/d6/43/0e822876f87ea8a4ef95442c3d766a06a51fc5298823f884ef87aaad168c/cffi-2.0.0-cp314-cp314-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:24b6f81f1983e6df8db3adc38562c83f7d4a0c36162885ec7f7b77c7dcbec97b", size = 220049, upload-time = "2025-09-08T23:23:20.853Z" },
+ { url = "https://files.pythonhosted.org/packages/b4/89/76799151d9c2d2d1ead63c2429da9ea9d7aac304603de0c6e8764e6e8e70/cffi-2.0.0-cp314-cp314-manylinux2014_ppc64le.manylinux_2_17_ppc64le.whl", hash = "sha256:12873ca6cb9b0f0d3a0da705d6086fe911591737a59f28b7936bdfed27c0d47c", size = 207793, upload-time = "2025-09-08T23:23:22.08Z" },
+ { url = "https://files.pythonhosted.org/packages/bb/dd/3465b14bb9e24ee24cb88c9e3730f6de63111fffe513492bf8c808a3547e/cffi-2.0.0-cp314-cp314-manylinux2014_s390x.manylinux_2_17_s390x.whl", hash = "sha256:d9b97165e8aed9272a6bb17c01e3cc5871a594a446ebedc996e2397a1c1ea8ef", size = 206300, upload-time = "2025-09-08T23:23:23.314Z" },
+ { url = "https://files.pythonhosted.org/packages/47/d9/d83e293854571c877a92da46fdec39158f8d7e68da75bf73581225d28e90/cffi-2.0.0-cp314-cp314-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:afb8db5439b81cf9c9d0c80404b60c3cc9c3add93e114dcae767f1477cb53775", size = 219244, upload-time = "2025-09-08T23:23:24.541Z" },
+ { url = "https://files.pythonhosted.org/packages/2b/0f/1f177e3683aead2bb00f7679a16451d302c436b5cbf2505f0ea8146ef59e/cffi-2.0.0-cp314-cp314-musllinux_1_2_aarch64.whl", hash = "sha256:737fe7d37e1a1bffe70bd5754ea763a62a066dc5913ca57e957824b72a85e205", size = 222828, upload-time = "2025-09-08T23:23:26.143Z" },
+ { url = "https://files.pythonhosted.org/packages/c6/0f/cafacebd4b040e3119dcb32fed8bdef8dfe94da653155f9d0b9dc660166e/cffi-2.0.0-cp314-cp314-musllinux_1_2_x86_64.whl", hash = "sha256:38100abb9d1b1435bc4cc340bb4489635dc2f0da7456590877030c9b3d40b0c1", size = 220926, upload-time = "2025-09-08T23:23:27.873Z" },
+ { url = "https://files.pythonhosted.org/packages/3e/aa/df335faa45b395396fcbc03de2dfcab242cd61a9900e914fe682a59170b1/cffi-2.0.0-cp314-cp314-win32.whl", hash = "sha256:087067fa8953339c723661eda6b54bc98c5625757ea62e95eb4898ad5e776e9f", size = 175328, upload-time = "2025-09-08T23:23:44.61Z" },
+ { url = "https://files.pythonhosted.org/packages/bb/92/882c2d30831744296ce713f0feb4c1cd30f346ef747b530b5318715cc367/cffi-2.0.0-cp314-cp314-win_amd64.whl", hash = "sha256:203a48d1fb583fc7d78a4c6655692963b860a417c0528492a6bc21f1aaefab25", size = 185650, upload-time = "2025-09-08T23:23:45.848Z" },
+ { url = "https://files.pythonhosted.org/packages/9f/2c/98ece204b9d35a7366b5b2c6539c350313ca13932143e79dc133ba757104/cffi-2.0.0-cp314-cp314-win_arm64.whl", hash = "sha256:dbd5c7a25a7cb98f5ca55d258b103a2054f859a46ae11aaf23134f9cc0d356ad", size = 180687, upload-time = "2025-09-08T23:23:47.105Z" },
+ { url = "https://files.pythonhosted.org/packages/3e/61/c768e4d548bfa607abcda77423448df8c471f25dbe64fb2ef6d555eae006/cffi-2.0.0-cp314-cp314t-macosx_10_13_x86_64.whl", hash = "sha256:9a67fc9e8eb39039280526379fb3a70023d77caec1852002b4da7e8b270c4dd9", size = 188773, upload-time = "2025-09-08T23:23:29.347Z" },
+ { url = "https://files.pythonhosted.org/packages/2c/ea/5f76bce7cf6fcd0ab1a1058b5af899bfbef198bea4d5686da88471ea0336/cffi-2.0.0-cp314-cp314t-macosx_11_0_arm64.whl", hash = "sha256:7a66c7204d8869299919db4d5069a82f1561581af12b11b3c9f48c584eb8743d", size = 185013, upload-time = "2025-09-08T23:23:30.63Z" },
+ { url = "https://files.pythonhosted.org/packages/be/b4/c56878d0d1755cf9caa54ba71e5d049479c52f9e4afc230f06822162ab2f/cffi-2.0.0-cp314-cp314t-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:7cc09976e8b56f8cebd752f7113ad07752461f48a58cbba644139015ac24954c", size = 221593, upload-time = "2025-09-08T23:23:31.91Z" },
+ { url = "https://files.pythonhosted.org/packages/e0/0d/eb704606dfe8033e7128df5e90fee946bbcb64a04fcdaa97321309004000/cffi-2.0.0-cp314-cp314t-manylinux2014_ppc64le.manylinux_2_17_ppc64le.whl", hash = "sha256:92b68146a71df78564e4ef48af17551a5ddd142e5190cdf2c5624d0c3ff5b2e8", size = 209354, upload-time = "2025-09-08T23:23:33.214Z" },
+ { url = "https://files.pythonhosted.org/packages/d8/19/3c435d727b368ca475fb8742ab97c9cb13a0de600ce86f62eab7fa3eea60/cffi-2.0.0-cp314-cp314t-manylinux2014_s390x.manylinux_2_17_s390x.whl", hash = "sha256:b1e74d11748e7e98e2f426ab176d4ed720a64412b6a15054378afdb71e0f37dc", size = 208480, upload-time = "2025-09-08T23:23:34.495Z" },
+ { url = "https://files.pythonhosted.org/packages/d0/44/681604464ed9541673e486521497406fadcc15b5217c3e326b061696899a/cffi-2.0.0-cp314-cp314t-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:28a3a209b96630bca57cce802da70c266eb08c6e97e5afd61a75611ee6c64592", size = 221584, upload-time = "2025-09-08T23:23:36.096Z" },
+ { url = "https://files.pythonhosted.org/packages/25/8e/342a504ff018a2825d395d44d63a767dd8ebc927ebda557fecdaca3ac33a/cffi-2.0.0-cp314-cp314t-musllinux_1_2_aarch64.whl", hash = "sha256:7553fb2090d71822f02c629afe6042c299edf91ba1bf94951165613553984512", size = 224443, upload-time = "2025-09-08T23:23:37.328Z" },
+ { url = "https://files.pythonhosted.org/packages/e1/5e/b666bacbbc60fbf415ba9988324a132c9a7a0448a9a8f125074671c0f2c3/cffi-2.0.0-cp314-cp314t-musllinux_1_2_x86_64.whl", hash = "sha256:6c6c373cfc5c83a975506110d17457138c8c63016b563cc9ed6e056a82f13ce4", size = 223437, upload-time = "2025-09-08T23:23:38.945Z" },
+ { url = "https://files.pythonhosted.org/packages/a0/1d/ec1a60bd1a10daa292d3cd6bb0b359a81607154fb8165f3ec95fe003b85c/cffi-2.0.0-cp314-cp314t-win32.whl", hash = "sha256:1fc9ea04857caf665289b7a75923f2c6ed559b8298a1b8c49e59f7dd95c8481e", size = 180487, upload-time = "2025-09-08T23:23:40.423Z" },
+ { url = "https://files.pythonhosted.org/packages/bf/41/4c1168c74fac325c0c8156f04b6749c8b6a8f405bbf91413ba088359f60d/cffi-2.0.0-cp314-cp314t-win_amd64.whl", hash = "sha256:d68b6cef7827e8641e8ef16f4494edda8b36104d79773a334beaa1e3521430f6", size = 191726, upload-time = "2025-09-08T23:23:41.742Z" },
+ { url = "https://files.pythonhosted.org/packages/ae/3a/dbeec9d1ee0844c679f6bb5d6ad4e9f198b1224f4e7a32825f47f6192b0c/cffi-2.0.0-cp314-cp314t-win_arm64.whl", hash = "sha256:0a1527a803f0a659de1af2e1fd700213caba79377e27e4693648c2923da066f9", size = 184195, upload-time = "2025-09-08T23:23:43.004Z" },
+]
+
+[[package]]
+name = "charset-normalizer"
+version = "3.4.3"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/83/2d/5fd176ceb9b2fc619e63405525573493ca23441330fcdaee6bef9460e924/charset_normalizer-3.4.3.tar.gz", hash = "sha256:6fce4b8500244f6fcb71465d4a4930d132ba9ab8e71a7859e6a5d59851068d14", size = 122371, upload-time = "2025-08-09T07:57:28.46Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/e9/5e/14c94999e418d9b87682734589404a25854d5f5d0408df68bc15b6ff54bb/charset_normalizer-3.4.3-cp312-cp312-macosx_10_13_universal2.whl", hash = "sha256:e28e334d3ff134e88989d90ba04b47d84382a828c061d0d1027b1b12a62b39b1", size = 205655, upload-time = "2025-08-09T07:56:08.475Z" },
+ { url = "https://files.pythonhosted.org/packages/7d/a8/c6ec5d389672521f644505a257f50544c074cf5fc292d5390331cd6fc9c3/charset_normalizer-3.4.3-cp312-cp312-manylinux2014_aarch64.manylinux_2_17_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:0cacf8f7297b0c4fcb74227692ca46b4a5852f8f4f24b3c766dd94a1075c4884", size = 146223, upload-time = "2025-08-09T07:56:09.708Z" },
+ { url = "https://files.pythonhosted.org/packages/fc/eb/a2ffb08547f4e1e5415fb69eb7db25932c52a52bed371429648db4d84fb1/charset_normalizer-3.4.3-cp312-cp312-manylinux2014_ppc64le.manylinux_2_17_ppc64le.manylinux_2_28_ppc64le.whl", hash = "sha256:c6fd51128a41297f5409deab284fecbe5305ebd7e5a1f959bee1c054622b7018", size = 159366, upload-time = "2025-08-09T07:56:11.326Z" },
+ { url = "https://files.pythonhosted.org/packages/82/10/0fd19f20c624b278dddaf83b8464dcddc2456cb4b02bb902a6da126b87a1/charset_normalizer-3.4.3-cp312-cp312-manylinux2014_s390x.manylinux_2_17_s390x.manylinux_2_28_s390x.whl", hash = "sha256:3cfb2aad70f2c6debfbcb717f23b7eb55febc0bb23dcffc0f076009da10c6392", size = 157104, upload-time = "2025-08-09T07:56:13.014Z" },
+ { url = "https://files.pythonhosted.org/packages/16/ab/0233c3231af734f5dfcf0844aa9582d5a1466c985bbed6cedab85af9bfe3/charset_normalizer-3.4.3-cp312-cp312-manylinux2014_x86_64.manylinux_2_17_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:1606f4a55c0fd363d754049cdf400175ee96c992b1f8018b993941f221221c5f", size = 151830, upload-time = "2025-08-09T07:56:14.428Z" },
+ { url = "https://files.pythonhosted.org/packages/ae/02/e29e22b4e02839a0e4a06557b1999d0a47db3567e82989b5bb21f3fbbd9f/charset_normalizer-3.4.3-cp312-cp312-musllinux_1_2_aarch64.whl", hash = "sha256:027b776c26d38b7f15b26a5da1044f376455fb3766df8fc38563b4efbc515154", size = 148854, upload-time = "2025-08-09T07:56:16.051Z" },
+ { url = "https://files.pythonhosted.org/packages/05/6b/e2539a0a4be302b481e8cafb5af8792da8093b486885a1ae4d15d452bcec/charset_normalizer-3.4.3-cp312-cp312-musllinux_1_2_ppc64le.whl", hash = "sha256:42e5088973e56e31e4fa58eb6bd709e42fc03799c11c42929592889a2e54c491", size = 160670, upload-time = "2025-08-09T07:56:17.314Z" },
+ { url = "https://files.pythonhosted.org/packages/31/e7/883ee5676a2ef217a40ce0bffcc3d0dfbf9e64cbcfbdf822c52981c3304b/charset_normalizer-3.4.3-cp312-cp312-musllinux_1_2_s390x.whl", hash = "sha256:cc34f233c9e71701040d772aa7490318673aa7164a0efe3172b2981218c26d93", size = 158501, upload-time = "2025-08-09T07:56:18.641Z" },
+ { url = "https://files.pythonhosted.org/packages/c1/35/6525b21aa0db614cf8b5792d232021dca3df7f90a1944db934efa5d20bb1/charset_normalizer-3.4.3-cp312-cp312-musllinux_1_2_x86_64.whl", hash = "sha256:320e8e66157cc4e247d9ddca8e21f427efc7a04bbd0ac8a9faf56583fa543f9f", size = 153173, upload-time = "2025-08-09T07:56:20.289Z" },
+ { url = "https://files.pythonhosted.org/packages/50/ee/f4704bad8201de513fdc8aac1cabc87e38c5818c93857140e06e772b5892/charset_normalizer-3.4.3-cp312-cp312-win32.whl", hash = "sha256:fb6fecfd65564f208cbf0fba07f107fb661bcd1a7c389edbced3f7a493f70e37", size = 99822, upload-time = "2025-08-09T07:56:21.551Z" },
+ { url = "https://files.pythonhosted.org/packages/39/f5/3b3836ca6064d0992c58c7561c6b6eee1b3892e9665d650c803bd5614522/charset_normalizer-3.4.3-cp312-cp312-win_amd64.whl", hash = "sha256:86df271bf921c2ee3818f0522e9a5b8092ca2ad8b065ece5d7d9d0e9f4849bcc", size = 107543, upload-time = "2025-08-09T07:56:23.115Z" },
+ { url = "https://files.pythonhosted.org/packages/65/ca/2135ac97709b400c7654b4b764daf5c5567c2da45a30cdd20f9eefe2d658/charset_normalizer-3.4.3-cp313-cp313-macosx_10_13_universal2.whl", hash = "sha256:14c2a87c65b351109f6abfc424cab3927b3bdece6f706e4d12faaf3d52ee5efe", size = 205326, upload-time = "2025-08-09T07:56:24.721Z" },
+ { url = "https://files.pythonhosted.org/packages/71/11/98a04c3c97dd34e49c7d247083af03645ca3730809a5509443f3c37f7c99/charset_normalizer-3.4.3-cp313-cp313-manylinux2014_aarch64.manylinux_2_17_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:41d1fc408ff5fdfb910200ec0e74abc40387bccb3252f3f27c0676731df2b2c8", size = 146008, upload-time = "2025-08-09T07:56:26.004Z" },
+ { url = "https://files.pythonhosted.org/packages/60/f5/4659a4cb3c4ec146bec80c32d8bb16033752574c20b1252ee842a95d1a1e/charset_normalizer-3.4.3-cp313-cp313-manylinux2014_ppc64le.manylinux_2_17_ppc64le.manylinux_2_28_ppc64le.whl", hash = "sha256:1bb60174149316da1c35fa5233681f7c0f9f514509b8e399ab70fea5f17e45c9", size = 159196, upload-time = "2025-08-09T07:56:27.25Z" },
+ { url = "https://files.pythonhosted.org/packages/86/9e/f552f7a00611f168b9a5865a1414179b2c6de8235a4fa40189f6f79a1753/charset_normalizer-3.4.3-cp313-cp313-manylinux2014_s390x.manylinux_2_17_s390x.manylinux_2_28_s390x.whl", hash = "sha256:30d006f98569de3459c2fc1f2acde170b7b2bd265dc1943e87e1a4efe1b67c31", size = 156819, upload-time = "2025-08-09T07:56:28.515Z" },
+ { url = "https://files.pythonhosted.org/packages/7e/95/42aa2156235cbc8fa61208aded06ef46111c4d3f0de233107b3f38631803/charset_normalizer-3.4.3-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:416175faf02e4b0810f1f38bcb54682878a4af94059a1cd63b8747244420801f", size = 151350, upload-time = "2025-08-09T07:56:29.716Z" },
+ { url = "https://files.pythonhosted.org/packages/c2/a9/3865b02c56f300a6f94fc631ef54f0a8a29da74fb45a773dfd3dcd380af7/charset_normalizer-3.4.3-cp313-cp313-musllinux_1_2_aarch64.whl", hash = "sha256:6aab0f181c486f973bc7262a97f5aca3ee7e1437011ef0c2ec04b5a11d16c927", size = 148644, upload-time = "2025-08-09T07:56:30.984Z" },
+ { url = "https://files.pythonhosted.org/packages/77/d9/cbcf1a2a5c7d7856f11e7ac2d782aec12bdfea60d104e60e0aa1c97849dc/charset_normalizer-3.4.3-cp313-cp313-musllinux_1_2_ppc64le.whl", hash = "sha256:fdabf8315679312cfa71302f9bd509ded4f2f263fb5b765cf1433b39106c3cc9", size = 160468, upload-time = "2025-08-09T07:56:32.252Z" },
+ { url = "https://files.pythonhosted.org/packages/f6/42/6f45efee8697b89fda4d50580f292b8f7f9306cb2971d4b53f8914e4d890/charset_normalizer-3.4.3-cp313-cp313-musllinux_1_2_s390x.whl", hash = "sha256:bd28b817ea8c70215401f657edef3a8aa83c29d447fb0b622c35403780ba11d5", size = 158187, upload-time = "2025-08-09T07:56:33.481Z" },
+ { url = "https://files.pythonhosted.org/packages/70/99/f1c3bdcfaa9c45b3ce96f70b14f070411366fa19549c1d4832c935d8e2c3/charset_normalizer-3.4.3-cp313-cp313-musllinux_1_2_x86_64.whl", hash = "sha256:18343b2d246dc6761a249ba1fb13f9ee9a2bcd95decc767319506056ea4ad4dc", size = 152699, upload-time = "2025-08-09T07:56:34.739Z" },
+ { url = "https://files.pythonhosted.org/packages/a3/ad/b0081f2f99a4b194bcbb1934ef3b12aa4d9702ced80a37026b7607c72e58/charset_normalizer-3.4.3-cp313-cp313-win32.whl", hash = "sha256:6fb70de56f1859a3f71261cbe41005f56a7842cc348d3aeb26237560bfa5e0ce", size = 99580, upload-time = "2025-08-09T07:56:35.981Z" },
+ { url = "https://files.pythonhosted.org/packages/9a/8f/ae790790c7b64f925e5c953b924aaa42a243fb778fed9e41f147b2a5715a/charset_normalizer-3.4.3-cp313-cp313-win_amd64.whl", hash = "sha256:cf1ebb7d78e1ad8ec2a8c4732c7be2e736f6e5123a4146c5b89c9d1f585f8cef", size = 107366, upload-time = "2025-08-09T07:56:37.339Z" },
+ { url = "https://files.pythonhosted.org/packages/8e/91/b5a06ad970ddc7a0e513112d40113e834638f4ca1120eb727a249fb2715e/charset_normalizer-3.4.3-cp314-cp314-macosx_10_13_universal2.whl", hash = "sha256:3cd35b7e8aedeb9e34c41385fda4f73ba609e561faedfae0a9e75e44ac558a15", size = 204342, upload-time = "2025-08-09T07:56:38.687Z" },
+ { url = "https://files.pythonhosted.org/packages/ce/ec/1edc30a377f0a02689342f214455c3f6c2fbedd896a1d2f856c002fc3062/charset_normalizer-3.4.3-cp314-cp314-manylinux2014_aarch64.manylinux_2_17_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:b89bc04de1d83006373429975f8ef9e7932534b8cc9ca582e4db7d20d91816db", size = 145995, upload-time = "2025-08-09T07:56:40.048Z" },
+ { url = "https://files.pythonhosted.org/packages/17/e5/5e67ab85e6d22b04641acb5399c8684f4d37caf7558a53859f0283a650e9/charset_normalizer-3.4.3-cp314-cp314-manylinux2014_ppc64le.manylinux_2_17_ppc64le.manylinux_2_28_ppc64le.whl", hash = "sha256:2001a39612b241dae17b4687898843f254f8748b796a2e16f1051a17078d991d", size = 158640, upload-time = "2025-08-09T07:56:41.311Z" },
+ { url = "https://files.pythonhosted.org/packages/f1/e5/38421987f6c697ee3722981289d554957c4be652f963d71c5e46a262e135/charset_normalizer-3.4.3-cp314-cp314-manylinux2014_s390x.manylinux_2_17_s390x.manylinux_2_28_s390x.whl", hash = "sha256:8dcfc373f888e4fb39a7bc57e93e3b845e7f462dacc008d9749568b1c4ece096", size = 156636, upload-time = "2025-08-09T07:56:43.195Z" },
+ { url = "https://files.pythonhosted.org/packages/a0/e4/5a075de8daa3ec0745a9a3b54467e0c2967daaaf2cec04c845f73493e9a1/charset_normalizer-3.4.3-cp314-cp314-manylinux2014_x86_64.manylinux_2_17_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:18b97b8404387b96cdbd30ad660f6407799126d26a39ca65729162fd810a99aa", size = 150939, upload-time = "2025-08-09T07:56:44.819Z" },
+ { url = "https://files.pythonhosted.org/packages/02/f7/3611b32318b30974131db62b4043f335861d4d9b49adc6d57c1149cc49d4/charset_normalizer-3.4.3-cp314-cp314-musllinux_1_2_aarch64.whl", hash = "sha256:ccf600859c183d70eb47e05a44cd80a4ce77394d1ac0f79dbd2dd90a69a3a049", size = 148580, upload-time = "2025-08-09T07:56:46.684Z" },
+ { url = "https://files.pythonhosted.org/packages/7e/61/19b36f4bd67f2793ab6a99b979b4e4f3d8fc754cbdffb805335df4337126/charset_normalizer-3.4.3-cp314-cp314-musllinux_1_2_ppc64le.whl", hash = "sha256:53cd68b185d98dde4ad8990e56a58dea83a4162161b1ea9272e5c9182ce415e0", size = 159870, upload-time = "2025-08-09T07:56:47.941Z" },
+ { url = "https://files.pythonhosted.org/packages/06/57/84722eefdd338c04cf3030ada66889298eaedf3e7a30a624201e0cbe424a/charset_normalizer-3.4.3-cp314-cp314-musllinux_1_2_s390x.whl", hash = "sha256:30a96e1e1f865f78b030d65241c1ee850cdf422d869e9028e2fc1d5e4db73b92", size = 157797, upload-time = "2025-08-09T07:56:49.756Z" },
+ { url = "https://files.pythonhosted.org/packages/72/2a/aff5dd112b2f14bcc3462c312dce5445806bfc8ab3a7328555da95330e4b/charset_normalizer-3.4.3-cp314-cp314-musllinux_1_2_x86_64.whl", hash = "sha256:d716a916938e03231e86e43782ca7878fb602a125a91e7acb8b5112e2e96ac16", size = 152224, upload-time = "2025-08-09T07:56:51.369Z" },
+ { url = "https://files.pythonhosted.org/packages/b7/8c/9839225320046ed279c6e839d51f028342eb77c91c89b8ef2549f951f3ec/charset_normalizer-3.4.3-cp314-cp314-win32.whl", hash = "sha256:c6dbd0ccdda3a2ba7c2ecd9d77b37f3b5831687d8dc1b6ca5f56a4880cc7b7ce", size = 100086, upload-time = "2025-08-09T07:56:52.722Z" },
+ { url = "https://files.pythonhosted.org/packages/ee/7a/36fbcf646e41f710ce0a563c1c9a343c6edf9be80786edeb15b6f62e17db/charset_normalizer-3.4.3-cp314-cp314-win_amd64.whl", hash = "sha256:73dc19b562516fc9bcf6e5d6e596df0b4eb98d87e4f79f3ae71840e6ed21361c", size = 107400, upload-time = "2025-08-09T07:56:55.172Z" },
+ { url = "https://files.pythonhosted.org/packages/8a/1f/f041989e93b001bc4e44bb1669ccdcf54d3f00e628229a85b08d330615c5/charset_normalizer-3.4.3-py3-none-any.whl", hash = "sha256:ce571ab16d890d23b5c278547ba694193a45011ff86a9162a71307ed9f86759a", size = 53175, upload-time = "2025-08-09T07:57:26.864Z" },
+]
+
+[[package]]
+name = "compiler-explorer-docenizers"
+version = "0.0.1"
+source = { virtual = "." }
+dependencies = [
+ { name = "beautifulsoup4" },
+ { name = "lxml" },
+ { name = "pandas" },
+ { name = "pdfminer-six" },
+ { name = "pyyaml" },
+ { name = "requests" },
+]
+
+[package.metadata]
+requires-dist = [
+ { name = "beautifulsoup4", specifier = ">=4.12.0" },
+ { name = "lxml", specifier = ">=5.0.0" },
+ { name = "pandas", specifier = ">=2.2.0" },
+ { name = "pdfminer-six", specifier = ">=20231228" },
+ { name = "pyyaml", specifier = ">=6.0" },
+ { name = "requests", specifier = ">=2.32.0" },
+]
+
+[[package]]
+name = "cryptography"
+version = "46.0.1"
+source = { registry = "https://pypi.org/simple" }
+dependencies = [
+ { name = "cffi", marker = "platform_python_implementation != 'PyPy'" },
+]
+sdist = { url = "https://files.pythonhosted.org/packages/a9/62/e3664e6ffd7743e1694b244dde70b43a394f6f7fbcacf7014a8ff5197c73/cryptography-46.0.1.tar.gz", hash = "sha256:ed570874e88f213437f5cf758f9ef26cbfc3f336d889b1e592ee11283bb8d1c7", size = 749198, upload-time = "2025-09-17T00:10:35.797Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/4c/8c/44ee01267ec01e26e43ebfdae3f120ec2312aa72fa4c0507ebe41a26739f/cryptography-46.0.1-cp311-abi3-macosx_10_9_universal2.whl", hash = "sha256:1cd6d50c1a8b79af1a6f703709d8973845f677c8e97b1268f5ff323d38ce8475", size = 7285044, upload-time = "2025-09-17T00:08:36.807Z" },
+ { url = "https://files.pythonhosted.org/packages/22/59/9ae689a25047e0601adfcb159ec4f83c0b4149fdb5c3030cc94cd218141d/cryptography-46.0.1-cp311-abi3-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:0ff483716be32690c14636e54a1f6e2e1b7bf8e22ca50b989f88fa1b2d287080", size = 4308182, upload-time = "2025-09-17T00:08:39.388Z" },
+ { url = "https://files.pythonhosted.org/packages/c4/ee/ca6cc9df7118f2fcd142c76b1da0f14340d77518c05b1ebfbbabca6b9e7d/cryptography-46.0.1-cp311-abi3-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:9873bf7c1f2a6330bdfe8621e7ce64b725784f9f0c3a6a55c3047af5849f920e", size = 4572393, upload-time = "2025-09-17T00:08:41.663Z" },
+ { url = "https://files.pythonhosted.org/packages/7f/a3/0f5296f63815d8e985922b05c31f77ce44787b3127a67c0b7f70f115c45f/cryptography-46.0.1-cp311-abi3-manylinux_2_28_aarch64.whl", hash = "sha256:0dfb7c88d4462a0cfdd0d87a3c245a7bc3feb59de101f6ff88194f740f72eda6", size = 4308400, upload-time = "2025-09-17T00:08:43.559Z" },
+ { url = "https://files.pythonhosted.org/packages/5d/8c/74fcda3e4e01be1d32775d5b4dd841acaac3c1b8fa4d0774c7ac8d52463d/cryptography-46.0.1-cp311-abi3-manylinux_2_28_armv7l.manylinux_2_31_armv7l.whl", hash = "sha256:e22801b61613ebdebf7deb18b507919e107547a1d39a3b57f5f855032dd7cfb8", size = 4015786, upload-time = "2025-09-17T00:08:45.758Z" },
+ { url = "https://files.pythonhosted.org/packages/dc/b8/85d23287baeef273b0834481a3dd55bbed3a53587e3b8d9f0898235b8f91/cryptography-46.0.1-cp311-abi3-manylinux_2_28_ppc64le.whl", hash = "sha256:757af4f6341ce7a1e47c326ca2a81f41d236070217e5fbbad61bbfe299d55d28", size = 4982606, upload-time = "2025-09-17T00:08:47.602Z" },
+ { url = "https://files.pythonhosted.org/packages/e5/d3/de61ad5b52433b389afca0bc70f02a7a1f074651221f599ce368da0fe437/cryptography-46.0.1-cp311-abi3-manylinux_2_28_x86_64.whl", hash = "sha256:f7a24ea78de345cfa7f6a8d3bde8b242c7fac27f2bd78fa23474ca38dfaeeab9", size = 4604234, upload-time = "2025-09-17T00:08:49.879Z" },
+ { url = "https://files.pythonhosted.org/packages/dc/1f/dbd4d6570d84748439237a7478d124ee0134bf166ad129267b7ed8ea6d22/cryptography-46.0.1-cp311-abi3-manylinux_2_34_aarch64.whl", hash = "sha256:9e8776dac9e660c22241b6587fae51a67b4b0147daa4d176b172c3ff768ad736", size = 4307669, upload-time = "2025-09-17T00:08:52.321Z" },
+ { url = "https://files.pythonhosted.org/packages/ec/fd/ca0a14ce7f0bfe92fa727aacaf2217eb25eb7e4ed513b14d8e03b26e63ed/cryptography-46.0.1-cp311-abi3-manylinux_2_34_ppc64le.whl", hash = "sha256:9f40642a140c0c8649987027867242b801486865277cbabc8c6059ddef16dc8b", size = 4947579, upload-time = "2025-09-17T00:08:54.697Z" },
+ { url = "https://files.pythonhosted.org/packages/89/6b/09c30543bb93401f6f88fce556b3bdbb21e55ae14912c04b7bf355f5f96c/cryptography-46.0.1-cp311-abi3-manylinux_2_34_x86_64.whl", hash = "sha256:449ef2b321bec7d97ef2c944173275ebdab78f3abdd005400cc409e27cd159ab", size = 4603669, upload-time = "2025-09-17T00:08:57.16Z" },
+ { url = "https://files.pythonhosted.org/packages/23/9a/38cb01cb09ce0adceda9fc627c9cf98eb890fc8d50cacbe79b011df20f8a/cryptography-46.0.1-cp311-abi3-musllinux_1_2_aarch64.whl", hash = "sha256:2dd339ba3345b908fa3141ddba4025568fa6fd398eabce3ef72a29ac2d73ad75", size = 4435828, upload-time = "2025-09-17T00:08:59.606Z" },
+ { url = "https://files.pythonhosted.org/packages/0f/53/435b5c36a78d06ae0bef96d666209b0ecd8f8181bfe4dda46536705df59e/cryptography-46.0.1-cp311-abi3-musllinux_1_2_x86_64.whl", hash = "sha256:7411c910fb2a412053cf33cfad0153ee20d27e256c6c3f14d7d7d1d9fec59fd5", size = 4709553, upload-time = "2025-09-17T00:09:01.832Z" },
+ { url = "https://files.pythonhosted.org/packages/f5/c4/0da6e55595d9b9cd3b6eb5dc22f3a07ded7f116a3ea72629cab595abb804/cryptography-46.0.1-cp311-abi3-win32.whl", hash = "sha256:cbb8e769d4cac884bb28e3ff620ef1001b75588a5c83c9c9f1fdc9afbe7f29b0", size = 3058327, upload-time = "2025-09-17T00:09:03.726Z" },
+ { url = "https://files.pythonhosted.org/packages/95/0f/cd29a35e0d6e78a0ee61793564c8cff0929c38391cb0de27627bdc7525aa/cryptography-46.0.1-cp311-abi3-win_amd64.whl", hash = "sha256:92e8cfe8bd7dd86eac0a677499894862cd5cc2fd74de917daa881d00871ac8e7", size = 3523893, upload-time = "2025-09-17T00:09:06.272Z" },
+ { url = "https://files.pythonhosted.org/packages/f2/dd/eea390f3e78432bc3d2f53952375f8b37cb4d37783e626faa6a51e751719/cryptography-46.0.1-cp311-abi3-win_arm64.whl", hash = "sha256:db5597a4c7353b2e5fb05a8e6cb74b56a4658a2b7bf3cb6b1821ae7e7fd6eaa0", size = 2932145, upload-time = "2025-09-17T00:09:08.568Z" },
+ { url = "https://files.pythonhosted.org/packages/0a/fb/c73588561afcd5e24b089952bd210b14676c0c5bf1213376350ae111945c/cryptography-46.0.1-cp314-cp314t-macosx_10_9_universal2.whl", hash = "sha256:4c49eda9a23019e11d32a0eb51a27b3e7ddedde91e099c0ac6373e3aacc0d2ee", size = 7193928, upload-time = "2025-09-17T00:09:10.595Z" },
+ { url = "https://files.pythonhosted.org/packages/26/34/0ff0bb2d2c79f25a2a63109f3b76b9108a906dd2a2eb5c1d460b9938adbb/cryptography-46.0.1-cp314-cp314t-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:9babb7818fdd71394e576cf26c5452df77a355eac1a27ddfa24096665a27f8fd", size = 4293515, upload-time = "2025-09-17T00:09:12.861Z" },
+ { url = "https://files.pythonhosted.org/packages/df/b7/d4f848aee24ecd1be01db6c42c4a270069a4f02a105d9c57e143daf6cf0f/cryptography-46.0.1-cp314-cp314t-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:9f2c4cc63be3ef43c0221861177cee5d14b505cd4d4599a89e2cd273c4d3542a", size = 4545619, upload-time = "2025-09-17T00:09:15.397Z" },
+ { url = "https://files.pythonhosted.org/packages/44/a5/42fedefc754fd1901e2d95a69815ea4ec8a9eed31f4c4361fcab80288661/cryptography-46.0.1-cp314-cp314t-manylinux_2_28_aarch64.whl", hash = "sha256:41c281a74df173876da1dc9a9b6953d387f06e3d3ed9284e3baae3ab3f40883a", size = 4299160, upload-time = "2025-09-17T00:09:17.155Z" },
+ { url = "https://files.pythonhosted.org/packages/86/a1/cd21174f56e769c831fbbd6399a1b7519b0ff6280acec1b826d7b072640c/cryptography-46.0.1-cp314-cp314t-manylinux_2_28_armv7l.manylinux_2_31_armv7l.whl", hash = "sha256:0a17377fa52563d730248ba1f68185461fff36e8bc75d8787a7dd2e20a802b7a", size = 3994491, upload-time = "2025-09-17T00:09:18.971Z" },
+ { url = "https://files.pythonhosted.org/packages/8d/2f/a8cbfa1c029987ddc746fd966711d4fa71efc891d37fbe9f030fe5ab4eec/cryptography-46.0.1-cp314-cp314t-manylinux_2_28_ppc64le.whl", hash = "sha256:0d1922d9280e08cde90b518a10cd66831f632960a8d08cb3418922d83fce6f12", size = 4960157, upload-time = "2025-09-17T00:09:20.923Z" },
+ { url = "https://files.pythonhosted.org/packages/67/ae/63a84e6789e0d5a2502edf06b552bcb0fa9ff16147265d5c44a211942abe/cryptography-46.0.1-cp314-cp314t-manylinux_2_28_x86_64.whl", hash = "sha256:af84e8e99f1a82cea149e253014ea9dc89f75b82c87bb6c7242203186f465129", size = 4577263, upload-time = "2025-09-17T00:09:23.356Z" },
+ { url = "https://files.pythonhosted.org/packages/ef/8f/1b9fa8e92bd9cbcb3b7e1e593a5232f2c1e6f9bd72b919c1a6b37d315f92/cryptography-46.0.1-cp314-cp314t-manylinux_2_34_aarch64.whl", hash = "sha256:ef648d2c690703501714588b2ba640facd50fd16548133b11b2859e8655a69da", size = 4298703, upload-time = "2025-09-17T00:09:25.566Z" },
+ { url = "https://files.pythonhosted.org/packages/c3/af/bb95db070e73fea3fae31d8a69ac1463d89d1c084220f549b00dd01094a8/cryptography-46.0.1-cp314-cp314t-manylinux_2_34_ppc64le.whl", hash = "sha256:e94eb5fa32a8a9f9bf991f424f002913e3dd7c699ef552db9b14ba6a76a6313b", size = 4926363, upload-time = "2025-09-17T00:09:27.451Z" },
+ { url = "https://files.pythonhosted.org/packages/f5/3b/d8fb17ffeb3a83157a1cc0aa5c60691d062aceecba09c2e5e77ebfc1870c/cryptography-46.0.1-cp314-cp314t-manylinux_2_34_x86_64.whl", hash = "sha256:534b96c0831855e29fc3b069b085fd185aa5353033631a585d5cd4dd5d40d657", size = 4576958, upload-time = "2025-09-17T00:09:29.924Z" },
+ { url = "https://files.pythonhosted.org/packages/d9/46/86bc3a05c10c8aa88c8ae7e953a8b4e407c57823ed201dbcba55c4d655f4/cryptography-46.0.1-cp314-cp314t-musllinux_1_2_aarch64.whl", hash = "sha256:f9b55038b5c6c47559aa33626d8ecd092f354e23de3c6975e4bb205df128a2a0", size = 4422507, upload-time = "2025-09-17T00:09:32.222Z" },
+ { url = "https://files.pythonhosted.org/packages/a8/4e/387e5a21dfd2b4198e74968a541cfd6128f66f8ec94ed971776e15091ac3/cryptography-46.0.1-cp314-cp314t-musllinux_1_2_x86_64.whl", hash = "sha256:ec13b7105117dbc9afd023300fb9954d72ca855c274fe563e72428ece10191c0", size = 4683964, upload-time = "2025-09-17T00:09:34.118Z" },
+ { url = "https://files.pythonhosted.org/packages/25/a3/f9f5907b166adb8f26762071474b38bbfcf89858a5282f032899075a38a1/cryptography-46.0.1-cp314-cp314t-win32.whl", hash = "sha256:504e464944f2c003a0785b81668fe23c06f3b037e9cb9f68a7c672246319f277", size = 3029705, upload-time = "2025-09-17T00:09:36.381Z" },
+ { url = "https://files.pythonhosted.org/packages/12/66/4d3a4f1850db2e71c2b1628d14b70b5e4c1684a1bd462f7fffb93c041c38/cryptography-46.0.1-cp314-cp314t-win_amd64.whl", hash = "sha256:c52fded6383f7e20eaf70a60aeddd796b3677c3ad2922c801be330db62778e05", size = 3502175, upload-time = "2025-09-17T00:09:38.261Z" },
+ { url = "https://files.pythonhosted.org/packages/52/c7/9f10ad91435ef7d0d99a0b93c4360bea3df18050ff5b9038c489c31ac2f5/cryptography-46.0.1-cp314-cp314t-win_arm64.whl", hash = "sha256:9495d78f52c804b5ec8878b5b8c7873aa8e63db9cd9ee387ff2db3fffe4df784", size = 2912354, upload-time = "2025-09-17T00:09:40.078Z" },
+ { url = "https://files.pythonhosted.org/packages/98/e5/fbd632385542a3311915976f88e0dfcf09e62a3fc0aff86fb6762162a24d/cryptography-46.0.1-cp38-abi3-macosx_10_9_universal2.whl", hash = "sha256:d84c40bdb8674c29fa192373498b6cb1e84f882889d21a471b45d1f868d8d44b", size = 7255677, upload-time = "2025-09-17T00:09:42.407Z" },
+ { url = "https://files.pythonhosted.org/packages/56/3e/13ce6eab9ad6eba1b15a7bd476f005a4c1b3f299f4c2f32b22408b0edccf/cryptography-46.0.1-cp38-abi3-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:9ed64e5083fa806709e74fc5ea067dfef9090e5b7a2320a49be3c9df3583a2d8", size = 4301110, upload-time = "2025-09-17T00:09:45.614Z" },
+ { url = "https://files.pythonhosted.org/packages/a2/67/65dc233c1ddd688073cf7b136b06ff4b84bf517ba5529607c9d79720fc67/cryptography-46.0.1-cp38-abi3-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:341fb7a26bc9d6093c1b124b9f13acc283d2d51da440b98b55ab3f79f2522ead", size = 4562369, upload-time = "2025-09-17T00:09:47.601Z" },
+ { url = "https://files.pythonhosted.org/packages/17/db/d64ae4c6f4e98c3dac5bf35dd4d103f4c7c345703e43560113e5e8e31b2b/cryptography-46.0.1-cp38-abi3-manylinux_2_28_aarch64.whl", hash = "sha256:6ef1488967e729948d424d09c94753d0167ce59afba8d0f6c07a22b629c557b2", size = 4302126, upload-time = "2025-09-17T00:09:49.335Z" },
+ { url = "https://files.pythonhosted.org/packages/3d/19/5f1eea17d4805ebdc2e685b7b02800c4f63f3dd46cfa8d4c18373fea46c8/cryptography-46.0.1-cp38-abi3-manylinux_2_28_armv7l.manylinux_2_31_armv7l.whl", hash = "sha256:7823bc7cdf0b747ecfb096d004cc41573c2f5c7e3a29861603a2871b43d3ef32", size = 4009431, upload-time = "2025-09-17T00:09:51.239Z" },
+ { url = "https://files.pythonhosted.org/packages/81/b5/229ba6088fe7abccbfe4c5edb96c7a5ad547fac5fdd0d40aa6ea540b2985/cryptography-46.0.1-cp38-abi3-manylinux_2_28_ppc64le.whl", hash = "sha256:f736ab8036796f5a119ff8211deda416f8c15ce03776db704a7a4e17381cb2ef", size = 4980739, upload-time = "2025-09-17T00:09:54.181Z" },
+ { url = "https://files.pythonhosted.org/packages/3a/9c/50aa38907b201e74bc43c572f9603fa82b58e831bd13c245613a23cff736/cryptography-46.0.1-cp38-abi3-manylinux_2_28_x86_64.whl", hash = "sha256:e46710a240a41d594953012213ea8ca398cd2448fbc5d0f1be8160b5511104a0", size = 4592289, upload-time = "2025-09-17T00:09:56.731Z" },
+ { url = "https://files.pythonhosted.org/packages/5a/33/229858f8a5bb22f82468bb285e9f4c44a31978d5f5830bb4ea1cf8a4e454/cryptography-46.0.1-cp38-abi3-manylinux_2_34_aarch64.whl", hash = "sha256:84ef1f145de5aee82ea2447224dc23f065ff4cc5791bb3b506615957a6ba8128", size = 4301815, upload-time = "2025-09-17T00:09:58.548Z" },
+ { url = "https://files.pythonhosted.org/packages/52/cb/b76b2c87fbd6ed4a231884bea3ce073406ba8e2dae9defad910d33cbf408/cryptography-46.0.1-cp38-abi3-manylinux_2_34_ppc64le.whl", hash = "sha256:9394c7d5a7565ac5f7d9ba38b2617448eba384d7b107b262d63890079fad77ca", size = 4943251, upload-time = "2025-09-17T00:10:00.475Z" },
+ { url = "https://files.pythonhosted.org/packages/94/0f/f66125ecf88e4cb5b8017ff43f3a87ede2d064cb54a1c5893f9da9d65093/cryptography-46.0.1-cp38-abi3-manylinux_2_34_x86_64.whl", hash = "sha256:ed957044e368ed295257ae3d212b95456bd9756df490e1ac4538857f67531fcc", size = 4591247, upload-time = "2025-09-17T00:10:02.874Z" },
+ { url = "https://files.pythonhosted.org/packages/f6/22/9f3134ae436b63b463cfdf0ff506a0570da6873adb4bf8c19b8a5b4bac64/cryptography-46.0.1-cp38-abi3-musllinux_1_2_aarch64.whl", hash = "sha256:f7de12fa0eee6234de9a9ce0ffcfa6ce97361db7a50b09b65c63ac58e5f22fc7", size = 4428534, upload-time = "2025-09-17T00:10:04.994Z" },
+ { url = "https://files.pythonhosted.org/packages/89/39/e6042bcb2638650b0005c752c38ea830cbfbcbb1830e4d64d530000aa8dc/cryptography-46.0.1-cp38-abi3-musllinux_1_2_x86_64.whl", hash = "sha256:7fab1187b6c6b2f11a326f33b036f7168f5b996aedd0c059f9738915e4e8f53a", size = 4699541, upload-time = "2025-09-17T00:10:06.925Z" },
+ { url = "https://files.pythonhosted.org/packages/68/46/753d457492d15458c7b5a653fc9a84a1c9c7a83af6ebdc94c3fc373ca6e8/cryptography-46.0.1-cp38-abi3-win32.whl", hash = "sha256:45f790934ac1018adeba46a0f7289b2b8fe76ba774a88c7f1922213a56c98bc1", size = 3043779, upload-time = "2025-09-17T00:10:08.951Z" },
+ { url = "https://files.pythonhosted.org/packages/2f/50/b6f3b540c2f6ee712feeb5fa780bb11fad76634e71334718568e7695cb55/cryptography-46.0.1-cp38-abi3-win_amd64.whl", hash = "sha256:7176a5ab56fac98d706921f6416a05e5aff7df0e4b91516f450f8627cda22af3", size = 3517226, upload-time = "2025-09-17T00:10:10.769Z" },
+ { url = "https://files.pythonhosted.org/packages/ff/e8/77d17d00981cdd27cc493e81e1749a0b8bbfb843780dbd841e30d7f50743/cryptography-46.0.1-cp38-abi3-win_arm64.whl", hash = "sha256:efc9e51c3e595267ff84adf56e9b357db89ab2279d7e375ffcaf8f678606f3d9", size = 2923149, upload-time = "2025-09-17T00:10:13.236Z" },
+]
+
+[[package]]
+name = "idna"
+version = "3.10"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/f1/70/7703c29685631f5a7590aa73f1f1d3fa9a380e654b86af429e0934a32f7d/idna-3.10.tar.gz", hash = "sha256:12f65c9b470abda6dc35cf8e63cc574b1c52b11df2c86030af0ac09b01b13ea9", size = 190490, upload-time = "2024-09-15T18:07:39.745Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/76/c6/c88e154df9c4e1a2a66ccf0005a88dfb2650c1dffb6f5ce603dfbd452ce3/idna-3.10-py3-none-any.whl", hash = "sha256:946d195a0d259cbba61165e88e65941f16e9b36ea6ddb97f00452bae8b1287d3", size = 70442, upload-time = "2024-09-15T18:07:37.964Z" },
+]
+
+[[package]]
+name = "lxml"
+version = "6.0.2"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/aa/88/262177de60548e5a2bfc46ad28232c9e9cbde697bd94132aeb80364675cb/lxml-6.0.2.tar.gz", hash = "sha256:cd79f3367bd74b317dda655dc8fcfa304d9eb6e4fb06b7168c5cf27f96e0cd62", size = 4073426, upload-time = "2025-09-22T04:04:59.287Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/f3/c8/8ff2bc6b920c84355146cd1ab7d181bc543b89241cfb1ebee824a7c81457/lxml-6.0.2-cp312-cp312-macosx_10_13_universal2.whl", hash = "sha256:a59f5448ba2ceccd06995c95ea59a7674a10de0810f2ce90c9006f3cbc044456", size = 8661887, upload-time = "2025-09-22T04:01:17.265Z" },
+ { url = "https://files.pythonhosted.org/packages/37/6f/9aae1008083bb501ef63284220ce81638332f9ccbfa53765b2b7502203cf/lxml-6.0.2-cp312-cp312-macosx_10_13_x86_64.whl", hash = "sha256:e8113639f3296706fbac34a30813929e29247718e88173ad849f57ca59754924", size = 4667818, upload-time = "2025-09-22T04:01:19.688Z" },
+ { url = "https://files.pythonhosted.org/packages/f1/ca/31fb37f99f37f1536c133476674c10b577e409c0a624384147653e38baf2/lxml-6.0.2-cp312-cp312-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:a8bef9b9825fa8bc816a6e641bb67219489229ebc648be422af695f6e7a4fa7f", size = 4950807, upload-time = "2025-09-22T04:01:21.487Z" },
+ { url = "https://files.pythonhosted.org/packages/da/87/f6cb9442e4bada8aab5ae7e1046264f62fdbeaa6e3f6211b93f4c0dd97f1/lxml-6.0.2-cp312-cp312-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:65ea18d710fd14e0186c2f973dc60bb52039a275f82d3c44a0e42b43440ea534", size = 5109179, upload-time = "2025-09-22T04:01:23.32Z" },
+ { url = "https://files.pythonhosted.org/packages/c8/20/a7760713e65888db79bbae4f6146a6ae5c04e4a204a3c48896c408cd6ed2/lxml-6.0.2-cp312-cp312-manylinux_2_26_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:c371aa98126a0d4c739ca93ceffa0fd7a5d732e3ac66a46e74339acd4d334564", size = 5023044, upload-time = "2025-09-22T04:01:25.118Z" },
+ { url = "https://files.pythonhosted.org/packages/a2/b0/7e64e0460fcb36471899f75831509098f3fd7cd02a3833ac517433cb4f8f/lxml-6.0.2-cp312-cp312-manylinux_2_26_i686.manylinux_2_28_i686.whl", hash = "sha256:700efd30c0fa1a3581d80a748157397559396090a51d306ea59a70020223d16f", size = 5359685, upload-time = "2025-09-22T04:01:27.398Z" },
+ { url = "https://files.pythonhosted.org/packages/b9/e1/e5df362e9ca4e2f48ed6411bd4b3a0ae737cc842e96877f5bf9428055ab4/lxml-6.0.2-cp312-cp312-manylinux_2_26_ppc64le.manylinux_2_28_ppc64le.whl", hash = "sha256:c33e66d44fe60e72397b487ee92e01da0d09ba2d66df8eae42d77b6d06e5eba0", size = 5654127, upload-time = "2025-09-22T04:01:29.629Z" },
+ { url = "https://files.pythonhosted.org/packages/c6/d1/232b3309a02d60f11e71857778bfcd4acbdb86c07db8260caf7d008b08f8/lxml-6.0.2-cp312-cp312-manylinux_2_26_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:90a345bbeaf9d0587a3aaffb7006aa39ccb6ff0e96a57286c0cb2fd1520ea192", size = 5253958, upload-time = "2025-09-22T04:01:31.535Z" },
+ { url = "https://files.pythonhosted.org/packages/35/35/d955a070994725c4f7d80583a96cab9c107c57a125b20bb5f708fe941011/lxml-6.0.2-cp312-cp312-manylinux_2_31_armv7l.whl", hash = "sha256:064fdadaf7a21af3ed1dcaa106b854077fbeada827c18f72aec9346847cd65d0", size = 4711541, upload-time = "2025-09-22T04:01:33.801Z" },
+ { url = "https://files.pythonhosted.org/packages/1e/be/667d17363b38a78c4bd63cfd4b4632029fd68d2c2dc81f25ce9eb5224dd5/lxml-6.0.2-cp312-cp312-manylinux_2_38_riscv64.manylinux_2_39_riscv64.whl", hash = "sha256:fbc74f42c3525ac4ffa4b89cbdd00057b6196bcefe8bce794abd42d33a018092", size = 5267426, upload-time = "2025-09-22T04:01:35.639Z" },
+ { url = "https://files.pythonhosted.org/packages/ea/47/62c70aa4a1c26569bc958c9ca86af2bb4e1f614e8c04fb2989833874f7ae/lxml-6.0.2-cp312-cp312-musllinux_1_2_aarch64.whl", hash = "sha256:6ddff43f702905a4e32bc24f3f2e2edfe0f8fde3277d481bffb709a4cced7a1f", size = 5064917, upload-time = "2025-09-22T04:01:37.448Z" },
+ { url = "https://files.pythonhosted.org/packages/bd/55/6ceddaca353ebd0f1908ef712c597f8570cc9c58130dbb89903198e441fd/lxml-6.0.2-cp312-cp312-musllinux_1_2_armv7l.whl", hash = "sha256:6da5185951d72e6f5352166e3da7b0dc27aa70bd1090b0eb3f7f7212b53f1bb8", size = 4788795, upload-time = "2025-09-22T04:01:39.165Z" },
+ { url = "https://files.pythonhosted.org/packages/cf/e8/fd63e15da5e3fd4c2146f8bbb3c14e94ab850589beab88e547b2dbce22e1/lxml-6.0.2-cp312-cp312-musllinux_1_2_ppc64le.whl", hash = "sha256:57a86e1ebb4020a38d295c04fc79603c7899e0df71588043eb218722dabc087f", size = 5676759, upload-time = "2025-09-22T04:01:41.506Z" },
+ { url = "https://files.pythonhosted.org/packages/76/47/b3ec58dc5c374697f5ba37412cd2728f427d056315d124dd4b61da381877/lxml-6.0.2-cp312-cp312-musllinux_1_2_riscv64.whl", hash = "sha256:2047d8234fe735ab77802ce5f2297e410ff40f5238aec569ad7c8e163d7b19a6", size = 5255666, upload-time = "2025-09-22T04:01:43.363Z" },
+ { url = "https://files.pythonhosted.org/packages/19/93/03ba725df4c3d72afd9596eef4a37a837ce8e4806010569bedfcd2cb68fd/lxml-6.0.2-cp312-cp312-musllinux_1_2_x86_64.whl", hash = "sha256:6f91fd2b2ea15a6800c8e24418c0775a1694eefc011392da73bc6cef2623b322", size = 5277989, upload-time = "2025-09-22T04:01:45.215Z" },
+ { url = "https://files.pythonhosted.org/packages/c6/80/c06de80bfce881d0ad738576f243911fccf992687ae09fd80b734712b39c/lxml-6.0.2-cp312-cp312-win32.whl", hash = "sha256:3ae2ce7d6fedfb3414a2b6c5e20b249c4c607f72cb8d2bb7cc9c6ec7c6f4e849", size = 3611456, upload-time = "2025-09-22T04:01:48.243Z" },
+ { url = "https://files.pythonhosted.org/packages/f7/d7/0cdfb6c3e30893463fb3d1e52bc5f5f99684a03c29a0b6b605cfae879cd5/lxml-6.0.2-cp312-cp312-win_amd64.whl", hash = "sha256:72c87e5ee4e58a8354fb9c7c84cbf95a1c8236c127a5d1b7683f04bed8361e1f", size = 4011793, upload-time = "2025-09-22T04:01:50.042Z" },
+ { url = "https://files.pythonhosted.org/packages/ea/7b/93c73c67db235931527301ed3785f849c78991e2e34f3fd9a6663ffda4c5/lxml-6.0.2-cp312-cp312-win_arm64.whl", hash = "sha256:61cb10eeb95570153e0c0e554f58df92ecf5109f75eacad4a95baa709e26c3d6", size = 3672836, upload-time = "2025-09-22T04:01:52.145Z" },
+ { url = "https://files.pythonhosted.org/packages/53/fd/4e8f0540608977aea078bf6d79f128e0e2c2bba8af1acf775c30baa70460/lxml-6.0.2-cp313-cp313-macosx_10_13_universal2.whl", hash = "sha256:9b33d21594afab46f37ae58dfadd06636f154923c4e8a4d754b0127554eb2e77", size = 8648494, upload-time = "2025-09-22T04:01:54.242Z" },
+ { url = "https://files.pythonhosted.org/packages/5d/f4/2a94a3d3dfd6c6b433501b8d470a1960a20ecce93245cf2db1706adf6c19/lxml-6.0.2-cp313-cp313-macosx_10_13_x86_64.whl", hash = "sha256:6c8963287d7a4c5c9a432ff487c52e9c5618667179c18a204bdedb27310f022f", size = 4661146, upload-time = "2025-09-22T04:01:56.282Z" },
+ { url = "https://files.pythonhosted.org/packages/25/2e/4efa677fa6b322013035d38016f6ae859d06cac67437ca7dc708a6af7028/lxml-6.0.2-cp313-cp313-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:1941354d92699fb5ffe6ed7b32f9649e43c2feb4b97205f75866f7d21aa91452", size = 4946932, upload-time = "2025-09-22T04:01:58.989Z" },
+ { url = "https://files.pythonhosted.org/packages/ce/0f/526e78a6d38d109fdbaa5049c62e1d32fdd70c75fb61c4eadf3045d3d124/lxml-6.0.2-cp313-cp313-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:bb2f6ca0ae2d983ded09357b84af659c954722bbf04dea98030064996d156048", size = 5100060, upload-time = "2025-09-22T04:02:00.812Z" },
+ { url = "https://files.pythonhosted.org/packages/81/76/99de58d81fa702cc0ea7edae4f4640416c2062813a00ff24bd70ac1d9c9b/lxml-6.0.2-cp313-cp313-manylinux_2_26_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:eb2a12d704f180a902d7fa778c6d71f36ceb7b0d317f34cdc76a5d05aa1dd1df", size = 5019000, upload-time = "2025-09-22T04:02:02.671Z" },
+ { url = "https://files.pythonhosted.org/packages/b5/35/9e57d25482bc9a9882cb0037fdb9cc18f4b79d85df94fa9d2a89562f1d25/lxml-6.0.2-cp313-cp313-manylinux_2_26_i686.manylinux_2_28_i686.whl", hash = "sha256:6ec0e3f745021bfed19c456647f0298d60a24c9ff86d9d051f52b509663feeb1", size = 5348496, upload-time = "2025-09-22T04:02:04.904Z" },
+ { url = "https://files.pythonhosted.org/packages/a6/8e/cb99bd0b83ccc3e8f0f528e9aa1f7a9965dfec08c617070c5db8d63a87ce/lxml-6.0.2-cp313-cp313-manylinux_2_26_ppc64le.manylinux_2_28_ppc64le.whl", hash = "sha256:846ae9a12d54e368933b9759052d6206a9e8b250291109c48e350c1f1f49d916", size = 5643779, upload-time = "2025-09-22T04:02:06.689Z" },
+ { url = "https://files.pythonhosted.org/packages/d0/34/9e591954939276bb679b73773836c6684c22e56d05980e31d52a9a8deb18/lxml-6.0.2-cp313-cp313-manylinux_2_26_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:ef9266d2aa545d7374938fb5c484531ef5a2ec7f2d573e62f8ce722c735685fd", size = 5244072, upload-time = "2025-09-22T04:02:08.587Z" },
+ { url = "https://files.pythonhosted.org/packages/8d/27/b29ff065f9aaca443ee377aff699714fcbffb371b4fce5ac4ca759e436d5/lxml-6.0.2-cp313-cp313-manylinux_2_31_armv7l.whl", hash = "sha256:4077b7c79f31755df33b795dc12119cb557a0106bfdab0d2c2d97bd3cf3dffa6", size = 4718675, upload-time = "2025-09-22T04:02:10.783Z" },
+ { url = "https://files.pythonhosted.org/packages/2b/9f/f756f9c2cd27caa1a6ef8c32ae47aadea697f5c2c6d07b0dae133c244fbe/lxml-6.0.2-cp313-cp313-manylinux_2_38_riscv64.manylinux_2_39_riscv64.whl", hash = "sha256:a7c5d5e5f1081955358533be077166ee97ed2571d6a66bdba6ec2f609a715d1a", size = 5255171, upload-time = "2025-09-22T04:02:12.631Z" },
+ { url = "https://files.pythonhosted.org/packages/61/46/bb85ea42d2cb1bd8395484fd72f38e3389611aa496ac7772da9205bbda0e/lxml-6.0.2-cp313-cp313-musllinux_1_2_aarch64.whl", hash = "sha256:8f8d0cbd0674ee89863a523e6994ac25fd5be9c8486acfc3e5ccea679bad2679", size = 5057175, upload-time = "2025-09-22T04:02:14.718Z" },
+ { url = "https://files.pythonhosted.org/packages/95/0c/443fc476dcc8e41577f0af70458c50fe299a97bb6b7505bb1ae09aa7f9ac/lxml-6.0.2-cp313-cp313-musllinux_1_2_armv7l.whl", hash = "sha256:2cbcbf6d6e924c28f04a43f3b6f6e272312a090f269eff68a2982e13e5d57659", size = 4785688, upload-time = "2025-09-22T04:02:16.957Z" },
+ { url = "https://files.pythonhosted.org/packages/48/78/6ef0b359d45bb9697bc5a626e1992fa5d27aa3f8004b137b2314793b50a0/lxml-6.0.2-cp313-cp313-musllinux_1_2_ppc64le.whl", hash = "sha256:dfb874cfa53340009af6bdd7e54ebc0d21012a60a4e65d927c2e477112e63484", size = 5660655, upload-time = "2025-09-22T04:02:18.815Z" },
+ { url = "https://files.pythonhosted.org/packages/ff/ea/e1d33808f386bc1339d08c0dcada6e4712d4ed8e93fcad5f057070b7988a/lxml-6.0.2-cp313-cp313-musllinux_1_2_riscv64.whl", hash = "sha256:fb8dae0b6b8b7f9e96c26fdd8121522ce5de9bb5538010870bd538683d30e9a2", size = 5247695, upload-time = "2025-09-22T04:02:20.593Z" },
+ { url = "https://files.pythonhosted.org/packages/4f/47/eba75dfd8183673725255247a603b4ad606f4ae657b60c6c145b381697da/lxml-6.0.2-cp313-cp313-musllinux_1_2_x86_64.whl", hash = "sha256:358d9adae670b63e95bc59747c72f4dc97c9ec58881d4627fe0120da0f90d314", size = 5269841, upload-time = "2025-09-22T04:02:22.489Z" },
+ { url = "https://files.pythonhosted.org/packages/76/04/5c5e2b8577bc936e219becb2e98cdb1aca14a4921a12995b9d0c523502ae/lxml-6.0.2-cp313-cp313-win32.whl", hash = "sha256:e8cd2415f372e7e5a789d743d133ae474290a90b9023197fd78f32e2dc6873e2", size = 3610700, upload-time = "2025-09-22T04:02:24.465Z" },
+ { url = "https://files.pythonhosted.org/packages/fe/0a/4643ccc6bb8b143e9f9640aa54e38255f9d3b45feb2cbe7ae2ca47e8782e/lxml-6.0.2-cp313-cp313-win_amd64.whl", hash = "sha256:b30d46379644fbfc3ab81f8f82ae4de55179414651f110a1514f0b1f8f6cb2d7", size = 4010347, upload-time = "2025-09-22T04:02:26.286Z" },
+ { url = "https://files.pythonhosted.org/packages/31/ef/dcf1d29c3f530577f61e5fe2f1bd72929acf779953668a8a47a479ae6f26/lxml-6.0.2-cp313-cp313-win_arm64.whl", hash = "sha256:13dcecc9946dca97b11b7c40d29fba63b55ab4170d3c0cf8c0c164343b9bfdcf", size = 3671248, upload-time = "2025-09-22T04:02:27.918Z" },
+ { url = "https://files.pythonhosted.org/packages/03/15/d4a377b385ab693ce97b472fe0c77c2b16ec79590e688b3ccc71fba19884/lxml-6.0.2-cp314-cp314-macosx_10_13_universal2.whl", hash = "sha256:b0c732aa23de8f8aec23f4b580d1e52905ef468afb4abeafd3fec77042abb6fe", size = 8659801, upload-time = "2025-09-22T04:02:30.113Z" },
+ { url = "https://files.pythonhosted.org/packages/c8/e8/c128e37589463668794d503afaeb003987373c5f94d667124ffd8078bbd9/lxml-6.0.2-cp314-cp314-macosx_10_13_x86_64.whl", hash = "sha256:4468e3b83e10e0317a89a33d28f7aeba1caa4d1a6fd457d115dd4ffe90c5931d", size = 4659403, upload-time = "2025-09-22T04:02:32.119Z" },
+ { url = "https://files.pythonhosted.org/packages/00/ce/74903904339decdf7da7847bb5741fc98a5451b42fc419a86c0c13d26fe2/lxml-6.0.2-cp314-cp314-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:abd44571493973bad4598a3be7e1d807ed45aa2adaf7ab92ab7c62609569b17d", size = 4966974, upload-time = "2025-09-22T04:02:34.155Z" },
+ { url = "https://files.pythonhosted.org/packages/1f/d3/131dec79ce61c5567fecf82515bd9bc36395df42501b50f7f7f3bd065df0/lxml-6.0.2-cp314-cp314-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:370cd78d5855cfbffd57c422851f7d3864e6ae72d0da615fca4dad8c45d375a5", size = 5102953, upload-time = "2025-09-22T04:02:36.054Z" },
+ { url = "https://files.pythonhosted.org/packages/3a/ea/a43ba9bb750d4ffdd885f2cd333572f5bb900cd2408b67fdda07e85978a0/lxml-6.0.2-cp314-cp314-manylinux_2_26_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:901e3b4219fa04ef766885fb40fa516a71662a4c61b80c94d25336b4934b71c0", size = 5055054, upload-time = "2025-09-22T04:02:38.154Z" },
+ { url = "https://files.pythonhosted.org/packages/60/23/6885b451636ae286c34628f70a7ed1fcc759f8d9ad382d132e1c8d3d9bfd/lxml-6.0.2-cp314-cp314-manylinux_2_26_i686.manylinux_2_28_i686.whl", hash = "sha256:a4bf42d2e4cf52c28cc1812d62426b9503cdb0c87a6de81442626aa7d69707ba", size = 5352421, upload-time = "2025-09-22T04:02:40.413Z" },
+ { url = "https://files.pythonhosted.org/packages/48/5b/fc2ddfc94ddbe3eebb8e9af6e3fd65e2feba4967f6a4e9683875c394c2d8/lxml-6.0.2-cp314-cp314-manylinux_2_26_ppc64le.manylinux_2_28_ppc64le.whl", hash = "sha256:b2c7fdaa4d7c3d886a42534adec7cfac73860b89b4e5298752f60aa5984641a0", size = 5673684, upload-time = "2025-09-22T04:02:42.288Z" },
+ { url = "https://files.pythonhosted.org/packages/29/9c/47293c58cc91769130fbf85531280e8cc7868f7fbb6d92f4670071b9cb3e/lxml-6.0.2-cp314-cp314-manylinux_2_26_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:98a5e1660dc7de2200b00d53fa00bcd3c35a3608c305d45a7bbcaf29fa16e83d", size = 5252463, upload-time = "2025-09-22T04:02:44.165Z" },
+ { url = "https://files.pythonhosted.org/packages/9b/da/ba6eceb830c762b48e711ded880d7e3e89fc6c7323e587c36540b6b23c6b/lxml-6.0.2-cp314-cp314-manylinux_2_31_armv7l.whl", hash = "sha256:dc051506c30b609238d79eda75ee9cab3e520570ec8219844a72a46020901e37", size = 4698437, upload-time = "2025-09-22T04:02:46.524Z" },
+ { url = "https://files.pythonhosted.org/packages/a5/24/7be3f82cb7990b89118d944b619e53c656c97dc89c28cfb143fdb7cd6f4d/lxml-6.0.2-cp314-cp314-manylinux_2_38_riscv64.manylinux_2_39_riscv64.whl", hash = "sha256:8799481bbdd212470d17513a54d568f44416db01250f49449647b5ab5b5dccb9", size = 5269890, upload-time = "2025-09-22T04:02:48.812Z" },
+ { url = "https://files.pythonhosted.org/packages/1b/bd/dcfb9ea1e16c665efd7538fc5d5c34071276ce9220e234217682e7d2c4a5/lxml-6.0.2-cp314-cp314-musllinux_1_2_aarch64.whl", hash = "sha256:9261bb77c2dab42f3ecd9103951aeca2c40277701eb7e912c545c1b16e0e4917", size = 5097185, upload-time = "2025-09-22T04:02:50.746Z" },
+ { url = "https://files.pythonhosted.org/packages/21/04/a60b0ff9314736316f28316b694bccbbabe100f8483ad83852d77fc7468e/lxml-6.0.2-cp314-cp314-musllinux_1_2_armv7l.whl", hash = "sha256:65ac4a01aba353cfa6d5725b95d7aed6356ddc0a3cd734de00124d285b04b64f", size = 4745895, upload-time = "2025-09-22T04:02:52.968Z" },
+ { url = "https://files.pythonhosted.org/packages/d6/bd/7d54bd1846e5a310d9c715921c5faa71cf5c0853372adf78aee70c8d7aa2/lxml-6.0.2-cp314-cp314-musllinux_1_2_ppc64le.whl", hash = "sha256:b22a07cbb82fea98f8a2fd814f3d1811ff9ed76d0fc6abc84eb21527596e7cc8", size = 5695246, upload-time = "2025-09-22T04:02:54.798Z" },
+ { url = "https://files.pythonhosted.org/packages/fd/32/5643d6ab947bc371da21323acb2a6e603cedbe71cb4c99c8254289ab6f4e/lxml-6.0.2-cp314-cp314-musllinux_1_2_riscv64.whl", hash = "sha256:d759cdd7f3e055d6bc8d9bec3ad905227b2e4c785dc16c372eb5b5e83123f48a", size = 5260797, upload-time = "2025-09-22T04:02:57.058Z" },
+ { url = "https://files.pythonhosted.org/packages/33/da/34c1ec4cff1eea7d0b4cd44af8411806ed943141804ac9c5d565302afb78/lxml-6.0.2-cp314-cp314-musllinux_1_2_x86_64.whl", hash = "sha256:945da35a48d193d27c188037a05fec5492937f66fb1958c24fc761fb9d40d43c", size = 5277404, upload-time = "2025-09-22T04:02:58.966Z" },
+ { url = "https://files.pythonhosted.org/packages/82/57/4eca3e31e54dc89e2c3507e1cd411074a17565fa5ffc437c4ae0a00d439e/lxml-6.0.2-cp314-cp314-win32.whl", hash = "sha256:be3aaa60da67e6153eb15715cc2e19091af5dc75faef8b8a585aea372507384b", size = 3670072, upload-time = "2025-09-22T04:03:38.05Z" },
+ { url = "https://files.pythonhosted.org/packages/e3/e0/c96cf13eccd20c9421ba910304dae0f619724dcf1702864fd59dd386404d/lxml-6.0.2-cp314-cp314-win_amd64.whl", hash = "sha256:fa25afbadead523f7001caf0c2382afd272c315a033a7b06336da2637d92d6ed", size = 4080617, upload-time = "2025-09-22T04:03:39.835Z" },
+ { url = "https://files.pythonhosted.org/packages/d5/5d/b3f03e22b3d38d6f188ef044900a9b29b2fe0aebb94625ce9fe244011d34/lxml-6.0.2-cp314-cp314-win_arm64.whl", hash = "sha256:063eccf89df5b24e361b123e257e437f9e9878f425ee9aae3144c77faf6da6d8", size = 3754930, upload-time = "2025-09-22T04:03:41.565Z" },
+ { url = "https://files.pythonhosted.org/packages/5e/5c/42c2c4c03554580708fc738d13414801f340c04c3eff90d8d2d227145275/lxml-6.0.2-cp314-cp314t-macosx_10_13_universal2.whl", hash = "sha256:6162a86d86893d63084faaf4ff937b3daea233e3682fb4474db07395794fa80d", size = 8910380, upload-time = "2025-09-22T04:03:01.645Z" },
+ { url = "https://files.pythonhosted.org/packages/bf/4f/12df843e3e10d18d468a7557058f8d3733e8b6e12401f30b1ef29360740f/lxml-6.0.2-cp314-cp314t-macosx_10_13_x86_64.whl", hash = "sha256:414aaa94e974e23a3e92e7ca5b97d10c0cf37b6481f50911032c69eeb3991bba", size = 4775632, upload-time = "2025-09-22T04:03:03.814Z" },
+ { url = "https://files.pythonhosted.org/packages/e4/0c/9dc31e6c2d0d418483cbcb469d1f5a582a1cd00a1f4081953d44051f3c50/lxml-6.0.2-cp314-cp314t-manylinux2014_aarch64.manylinux_2_17_aarch64.whl", hash = "sha256:48461bd21625458dd01e14e2c38dd0aea69addc3c4f960c30d9f59d7f93be601", size = 4975171, upload-time = "2025-09-22T04:03:05.651Z" },
+ { url = "https://files.pythonhosted.org/packages/e7/2b/9b870c6ca24c841bdd887504808f0417aa9d8d564114689266f19ddf29c8/lxml-6.0.2-cp314-cp314t-manylinux2014_x86_64.manylinux_2_17_x86_64.whl", hash = "sha256:25fcc59afc57d527cfc78a58f40ab4c9b8fd096a9a3f964d2781ffb6eb33f4ed", size = 5110109, upload-time = "2025-09-22T04:03:07.452Z" },
+ { url = "https://files.pythonhosted.org/packages/bf/0c/4f5f2a4dd319a178912751564471355d9019e220c20d7db3fb8307ed8582/lxml-6.0.2-cp314-cp314t-manylinux_2_26_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:5179c60288204e6ddde3f774a93350177e08876eaf3ab78aa3a3649d43eb7d37", size = 5041061, upload-time = "2025-09-22T04:03:09.297Z" },
+ { url = "https://files.pythonhosted.org/packages/12/64/554eed290365267671fe001a20d72d14f468ae4e6acef1e179b039436967/lxml-6.0.2-cp314-cp314t-manylinux_2_26_i686.manylinux_2_28_i686.whl", hash = "sha256:967aab75434de148ec80597b75062d8123cadf2943fb4281f385141e18b21338", size = 5306233, upload-time = "2025-09-22T04:03:11.651Z" },
+ { url = "https://files.pythonhosted.org/packages/7a/31/1d748aa275e71802ad9722df32a7a35034246b42c0ecdd8235412c3396ef/lxml-6.0.2-cp314-cp314t-manylinux_2_26_ppc64le.manylinux_2_28_ppc64le.whl", hash = "sha256:d100fcc8930d697c6561156c6810ab4a508fb264c8b6779e6e61e2ed5e7558f9", size = 5604739, upload-time = "2025-09-22T04:03:13.592Z" },
+ { url = "https://files.pythonhosted.org/packages/8f/41/2c11916bcac09ed561adccacceaedd2bf0e0b25b297ea92aab99fd03d0fa/lxml-6.0.2-cp314-cp314t-manylinux_2_26_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:2ca59e7e13e5981175b8b3e4ab84d7da57993eeff53c07764dcebda0d0e64ecd", size = 5225119, upload-time = "2025-09-22T04:03:15.408Z" },
+ { url = "https://files.pythonhosted.org/packages/99/05/4e5c2873d8f17aa018e6afde417c80cc5d0c33be4854cce3ef5670c49367/lxml-6.0.2-cp314-cp314t-manylinux_2_31_armv7l.whl", hash = "sha256:957448ac63a42e2e49531b9d6c0fa449a1970dbc32467aaad46f11545be9af1d", size = 4633665, upload-time = "2025-09-22T04:03:17.262Z" },
+ { url = "https://files.pythonhosted.org/packages/0f/c9/dcc2da1bebd6275cdc723b515f93edf548b82f36a5458cca3578bc899332/lxml-6.0.2-cp314-cp314t-manylinux_2_38_riscv64.manylinux_2_39_riscv64.whl", hash = "sha256:b7fc49c37f1786284b12af63152fe1d0990722497e2d5817acfe7a877522f9a9", size = 5234997, upload-time = "2025-09-22T04:03:19.14Z" },
+ { url = "https://files.pythonhosted.org/packages/9c/e2/5172e4e7468afca64a37b81dba152fc5d90e30f9c83c7c3213d6a02a5ce4/lxml-6.0.2-cp314-cp314t-musllinux_1_2_aarch64.whl", hash = "sha256:e19e0643cc936a22e837f79d01a550678da8377d7d801a14487c10c34ee49c7e", size = 5090957, upload-time = "2025-09-22T04:03:21.436Z" },
+ { url = "https://files.pythonhosted.org/packages/a5/b3/15461fd3e5cd4ddcb7938b87fc20b14ab113b92312fc97afe65cd7c85de1/lxml-6.0.2-cp314-cp314t-musllinux_1_2_armv7l.whl", hash = "sha256:1db01e5cf14345628e0cbe71067204db658e2fb8e51e7f33631f5f4735fefd8d", size = 4764372, upload-time = "2025-09-22T04:03:23.27Z" },
+ { url = "https://files.pythonhosted.org/packages/05/33/f310b987c8bf9e61c4dd8e8035c416bd3230098f5e3cfa69fc4232de7059/lxml-6.0.2-cp314-cp314t-musllinux_1_2_ppc64le.whl", hash = "sha256:875c6b5ab39ad5291588aed6925fac99d0097af0dd62f33c7b43736043d4a2ec", size = 5634653, upload-time = "2025-09-22T04:03:25.767Z" },
+ { url = "https://files.pythonhosted.org/packages/70/ff/51c80e75e0bc9382158133bdcf4e339b5886c6ee2418b5199b3f1a61ed6d/lxml-6.0.2-cp314-cp314t-musllinux_1_2_riscv64.whl", hash = "sha256:cdcbed9ad19da81c480dfd6dd161886db6096083c9938ead313d94b30aadf272", size = 5233795, upload-time = "2025-09-22T04:03:27.62Z" },
+ { url = "https://files.pythonhosted.org/packages/56/4d/4856e897df0d588789dd844dbed9d91782c4ef0b327f96ce53c807e13128/lxml-6.0.2-cp314-cp314t-musllinux_1_2_x86_64.whl", hash = "sha256:80dadc234ebc532e09be1975ff538d154a7fa61ea5031c03d25178855544728f", size = 5257023, upload-time = "2025-09-22T04:03:30.056Z" },
+ { url = "https://files.pythonhosted.org/packages/0f/85/86766dfebfa87bea0ab78e9ff7a4b4b45225df4b4d3b8cc3c03c5cd68464/lxml-6.0.2-cp314-cp314t-win32.whl", hash = "sha256:da08e7bb297b04e893d91087df19638dc7a6bb858a954b0cc2b9f5053c922312", size = 3911420, upload-time = "2025-09-22T04:03:32.198Z" },
+ { url = "https://files.pythonhosted.org/packages/fe/1a/b248b355834c8e32614650b8008c69ffeb0ceb149c793961dd8c0b991bb3/lxml-6.0.2-cp314-cp314t-win_amd64.whl", hash = "sha256:252a22982dca42f6155125ac76d3432e548a7625d56f5a273ee78a5057216eca", size = 4406837, upload-time = "2025-09-22T04:03:34.027Z" },
+ { url = "https://files.pythonhosted.org/packages/92/aa/df863bcc39c5e0946263454aba394de8a9084dbaff8ad143846b0d844739/lxml-6.0.2-cp314-cp314t-win_arm64.whl", hash = "sha256:bb4c1847b303835d89d785a18801a883436cdfd5dc3d62947f9c49e24f0f5a2c", size = 3822205, upload-time = "2025-09-22T04:03:36.249Z" },
+]
+
+[[package]]
+name = "numpy"
+version = "2.3.3"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/d0/19/95b3d357407220ed24c139018d2518fab0a61a948e68286a25f1a4d049ff/numpy-2.3.3.tar.gz", hash = "sha256:ddc7c39727ba62b80dfdbedf400d1c10ddfa8eefbd7ec8dcb118be8b56d31029", size = 20576648, upload-time = "2025-09-09T16:54:12.543Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/51/5d/bb7fc075b762c96329147799e1bcc9176ab07ca6375ea976c475482ad5b3/numpy-2.3.3-cp312-cp312-macosx_10_13_x86_64.whl", hash = "sha256:cfdd09f9c84a1a934cde1eec2267f0a43a7cd44b2cca4ff95b7c0d14d144b0bf", size = 20957014, upload-time = "2025-09-09T15:56:29.966Z" },
+ { url = "https://files.pythonhosted.org/packages/6b/0e/c6211bb92af26517acd52125a237a92afe9c3124c6a68d3b9f81b62a0568/numpy-2.3.3-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:cb32e3cf0f762aee47ad1ddc6672988f7f27045b0783c887190545baba73aa25", size = 14185220, upload-time = "2025-09-09T15:56:32.175Z" },
+ { url = "https://files.pythonhosted.org/packages/22/f2/07bb754eb2ede9073f4054f7c0286b0d9d2e23982e090a80d478b26d35ca/numpy-2.3.3-cp312-cp312-macosx_14_0_arm64.whl", hash = "sha256:396b254daeb0a57b1fe0ecb5e3cff6fa79a380fa97c8f7781a6d08cd429418fe", size = 5113918, upload-time = "2025-09-09T15:56:34.175Z" },
+ { url = "https://files.pythonhosted.org/packages/81/0a/afa51697e9fb74642f231ea36aca80fa17c8fb89f7a82abd5174023c3960/numpy-2.3.3-cp312-cp312-macosx_14_0_x86_64.whl", hash = "sha256:067e3d7159a5d8f8a0b46ee11148fc35ca9b21f61e3c49fbd0a027450e65a33b", size = 6647922, upload-time = "2025-09-09T15:56:36.149Z" },
+ { url = "https://files.pythonhosted.org/packages/5d/f5/122d9cdb3f51c520d150fef6e87df9279e33d19a9611a87c0d2cf78a89f4/numpy-2.3.3-cp312-cp312-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:1c02d0629d25d426585fb2e45a66154081b9fa677bc92a881ff1d216bc9919a8", size = 14281991, upload-time = "2025-09-09T15:56:40.548Z" },
+ { url = "https://files.pythonhosted.org/packages/51/64/7de3c91e821a2debf77c92962ea3fe6ac2bc45d0778c1cbe15d4fce2fd94/numpy-2.3.3-cp312-cp312-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:d9192da52b9745f7f0766531dcfa978b7763916f158bb63bdb8a1eca0068ab20", size = 16641643, upload-time = "2025-09-09T15:56:43.343Z" },
+ { url = "https://files.pythonhosted.org/packages/30/e4/961a5fa681502cd0d68907818b69f67542695b74e3ceaa513918103b7e80/numpy-2.3.3-cp312-cp312-musllinux_1_2_aarch64.whl", hash = "sha256:cd7de500a5b66319db419dc3c345244404a164beae0d0937283b907d8152e6ea", size = 16056787, upload-time = "2025-09-09T15:56:46.141Z" },
+ { url = "https://files.pythonhosted.org/packages/99/26/92c912b966e47fbbdf2ad556cb17e3a3088e2e1292b9833be1dfa5361a1a/numpy-2.3.3-cp312-cp312-musllinux_1_2_x86_64.whl", hash = "sha256:93d4962d8f82af58f0b2eb85daaf1b3ca23fe0a85d0be8f1f2b7bb46034e56d7", size = 18579598, upload-time = "2025-09-09T15:56:49.844Z" },
+ { url = "https://files.pythonhosted.org/packages/17/b6/fc8f82cb3520768718834f310c37d96380d9dc61bfdaf05fe5c0b7653e01/numpy-2.3.3-cp312-cp312-win32.whl", hash = "sha256:5534ed6b92f9b7dca6c0a19d6df12d41c68b991cef051d108f6dbff3babc4ebf", size = 6320800, upload-time = "2025-09-09T15:56:52.499Z" },
+ { url = "https://files.pythonhosted.org/packages/32/ee/de999f2625b80d043d6d2d628c07d0d5555a677a3cf78fdf868d409b8766/numpy-2.3.3-cp312-cp312-win_amd64.whl", hash = "sha256:497d7cad08e7092dba36e3d296fe4c97708c93daf26643a1ae4b03f6294d30eb", size = 12786615, upload-time = "2025-09-09T15:56:54.422Z" },
+ { url = "https://files.pythonhosted.org/packages/49/6e/b479032f8a43559c383acb20816644f5f91c88f633d9271ee84f3b3a996c/numpy-2.3.3-cp312-cp312-win_arm64.whl", hash = "sha256:ca0309a18d4dfea6fc6262a66d06c26cfe4640c3926ceec90e57791a82b6eee5", size = 10195936, upload-time = "2025-09-09T15:56:56.541Z" },
+ { url = "https://files.pythonhosted.org/packages/7d/b9/984c2b1ee61a8b803bf63582b4ac4242cf76e2dbd663efeafcb620cc0ccb/numpy-2.3.3-cp313-cp313-macosx_10_13_x86_64.whl", hash = "sha256:f5415fb78995644253370985342cd03572ef8620b934da27d77377a2285955bf", size = 20949588, upload-time = "2025-09-09T15:56:59.087Z" },
+ { url = "https://files.pythonhosted.org/packages/a6/e4/07970e3bed0b1384d22af1e9912527ecbeb47d3b26e9b6a3bced068b3bea/numpy-2.3.3-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:d00de139a3324e26ed5b95870ce63be7ec7352171bc69a4cf1f157a48e3eb6b7", size = 14177802, upload-time = "2025-09-09T15:57:01.73Z" },
+ { url = "https://files.pythonhosted.org/packages/35/c7/477a83887f9de61f1203bad89cf208b7c19cc9fef0cebef65d5a1a0619f2/numpy-2.3.3-cp313-cp313-macosx_14_0_arm64.whl", hash = "sha256:9dc13c6a5829610cc07422bc74d3ac083bd8323f14e2827d992f9e52e22cd6a6", size = 5106537, upload-time = "2025-09-09T15:57:03.765Z" },
+ { url = "https://files.pythonhosted.org/packages/52/47/93b953bd5866a6f6986344d045a207d3f1cfbad99db29f534ea9cee5108c/numpy-2.3.3-cp313-cp313-macosx_14_0_x86_64.whl", hash = "sha256:d79715d95f1894771eb4e60fb23f065663b2298f7d22945d66877aadf33d00c7", size = 6640743, upload-time = "2025-09-09T15:57:07.921Z" },
+ { url = "https://files.pythonhosted.org/packages/23/83/377f84aaeb800b64c0ef4de58b08769e782edcefa4fea712910b6f0afd3c/numpy-2.3.3-cp313-cp313-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:952cfd0748514ea7c3afc729a0fc639e61655ce4c55ab9acfab14bda4f402b4c", size = 14278881, upload-time = "2025-09-09T15:57:11.349Z" },
+ { url = "https://files.pythonhosted.org/packages/9a/a5/bf3db6e66c4b160d6ea10b534c381a1955dfab34cb1017ea93aa33c70ed3/numpy-2.3.3-cp313-cp313-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:5b83648633d46f77039c29078751f80da65aa64d5622a3cd62aaef9d835b6c93", size = 16636301, upload-time = "2025-09-09T15:57:14.245Z" },
+ { url = "https://files.pythonhosted.org/packages/a2/59/1287924242eb4fa3f9b3a2c30400f2e17eb2707020d1c5e3086fe7330717/numpy-2.3.3-cp313-cp313-musllinux_1_2_aarch64.whl", hash = "sha256:b001bae8cea1c7dfdb2ae2b017ed0a6f2102d7a70059df1e338e307a4c78a8ae", size = 16053645, upload-time = "2025-09-09T15:57:16.534Z" },
+ { url = "https://files.pythonhosted.org/packages/e6/93/b3d47ed882027c35e94ac2320c37e452a549f582a5e801f2d34b56973c97/numpy-2.3.3-cp313-cp313-musllinux_1_2_x86_64.whl", hash = "sha256:8e9aced64054739037d42fb84c54dd38b81ee238816c948c8f3ed134665dcd86", size = 18578179, upload-time = "2025-09-09T15:57:18.883Z" },
+ { url = "https://files.pythonhosted.org/packages/20/d9/487a2bccbf7cc9d4bfc5f0f197761a5ef27ba870f1e3bbb9afc4bbe3fcc2/numpy-2.3.3-cp313-cp313-win32.whl", hash = "sha256:9591e1221db3f37751e6442850429b3aabf7026d3b05542d102944ca7f00c8a8", size = 6312250, upload-time = "2025-09-09T15:57:21.296Z" },
+ { url = "https://files.pythonhosted.org/packages/1b/b5/263ebbbbcede85028f30047eab3d58028d7ebe389d6493fc95ae66c636ab/numpy-2.3.3-cp313-cp313-win_amd64.whl", hash = "sha256:f0dadeb302887f07431910f67a14d57209ed91130be0adea2f9793f1a4f817cf", size = 12783269, upload-time = "2025-09-09T15:57:23.034Z" },
+ { url = "https://files.pythonhosted.org/packages/fa/75/67b8ca554bbeaaeb3fac2e8bce46967a5a06544c9108ec0cf5cece559b6c/numpy-2.3.3-cp313-cp313-win_arm64.whl", hash = "sha256:3c7cf302ac6e0b76a64c4aecf1a09e51abd9b01fc7feee80f6c43e3ab1b1dbc5", size = 10195314, upload-time = "2025-09-09T15:57:25.045Z" },
+ { url = "https://files.pythonhosted.org/packages/11/d0/0d1ddec56b162042ddfafeeb293bac672de9b0cfd688383590090963720a/numpy-2.3.3-cp313-cp313t-macosx_10_13_x86_64.whl", hash = "sha256:eda59e44957d272846bb407aad19f89dc6f58fecf3504bd144f4c5cf81a7eacc", size = 21048025, upload-time = "2025-09-09T15:57:27.257Z" },
+ { url = "https://files.pythonhosted.org/packages/36/9e/1996ca6b6d00415b6acbdd3c42f7f03ea256e2c3f158f80bd7436a8a19f3/numpy-2.3.3-cp313-cp313t-macosx_11_0_arm64.whl", hash = "sha256:823d04112bc85ef5c4fda73ba24e6096c8f869931405a80aa8b0e604510a26bc", size = 14301053, upload-time = "2025-09-09T15:57:30.077Z" },
+ { url = "https://files.pythonhosted.org/packages/05/24/43da09aa764c68694b76e84b3d3f0c44cb7c18cdc1ba80e48b0ac1d2cd39/numpy-2.3.3-cp313-cp313t-macosx_14_0_arm64.whl", hash = "sha256:40051003e03db4041aa325da2a0971ba41cf65714e65d296397cc0e32de6018b", size = 5229444, upload-time = "2025-09-09T15:57:32.733Z" },
+ { url = "https://files.pythonhosted.org/packages/bc/14/50ffb0f22f7218ef8af28dd089f79f68289a7a05a208db9a2c5dcbe123c1/numpy-2.3.3-cp313-cp313t-macosx_14_0_x86_64.whl", hash = "sha256:6ee9086235dd6ab7ae75aba5662f582a81ced49f0f1c6de4260a78d8f2d91a19", size = 6738039, upload-time = "2025-09-09T15:57:34.328Z" },
+ { url = "https://files.pythonhosted.org/packages/55/52/af46ac0795e09657d45a7f4db961917314377edecf66db0e39fa7ab5c3d3/numpy-2.3.3-cp313-cp313t-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:94fcaa68757c3e2e668ddadeaa86ab05499a70725811e582b6a9858dd472fb30", size = 14352314, upload-time = "2025-09-09T15:57:36.255Z" },
+ { url = "https://files.pythonhosted.org/packages/a7/b1/dc226b4c90eb9f07a3fff95c2f0db3268e2e54e5cce97c4ac91518aee71b/numpy-2.3.3-cp313-cp313t-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:da1a74b90e7483d6ce5244053399a614b1d6b7bc30a60d2f570e5071f8959d3e", size = 16701722, upload-time = "2025-09-09T15:57:38.622Z" },
+ { url = "https://files.pythonhosted.org/packages/9d/9d/9d8d358f2eb5eced14dba99f110d83b5cd9a4460895230f3b396ad19a323/numpy-2.3.3-cp313-cp313t-musllinux_1_2_aarch64.whl", hash = "sha256:2990adf06d1ecee3b3dcbb4977dfab6e9f09807598d647f04d385d29e7a3c3d3", size = 16132755, upload-time = "2025-09-09T15:57:41.16Z" },
+ { url = "https://files.pythonhosted.org/packages/b6/27/b3922660c45513f9377b3fb42240bec63f203c71416093476ec9aa0719dc/numpy-2.3.3-cp313-cp313t-musllinux_1_2_x86_64.whl", hash = "sha256:ed635ff692483b8e3f0fcaa8e7eb8a75ee71aa6d975388224f70821421800cea", size = 18651560, upload-time = "2025-09-09T15:57:43.459Z" },
+ { url = "https://files.pythonhosted.org/packages/5b/8e/3ab61a730bdbbc201bb245a71102aa609f0008b9ed15255500a99cd7f780/numpy-2.3.3-cp313-cp313t-win32.whl", hash = "sha256:a333b4ed33d8dc2b373cc955ca57babc00cd6f9009991d9edc5ddbc1bac36bcd", size = 6442776, upload-time = "2025-09-09T15:57:45.793Z" },
+ { url = "https://files.pythonhosted.org/packages/1c/3a/e22b766b11f6030dc2decdeff5c2fb1610768055603f9f3be88b6d192fb2/numpy-2.3.3-cp313-cp313t-win_amd64.whl", hash = "sha256:4384a169c4d8f97195980815d6fcad04933a7e1ab3b530921c3fef7a1c63426d", size = 12927281, upload-time = "2025-09-09T15:57:47.492Z" },
+ { url = "https://files.pythonhosted.org/packages/7b/42/c2e2bc48c5e9b2a83423f99733950fbefd86f165b468a3d85d52b30bf782/numpy-2.3.3-cp313-cp313t-win_arm64.whl", hash = "sha256:75370986cc0bc66f4ce5110ad35aae6d182cc4ce6433c40ad151f53690130bf1", size = 10265275, upload-time = "2025-09-09T15:57:49.647Z" },
+ { url = "https://files.pythonhosted.org/packages/6b/01/342ad585ad82419b99bcf7cebe99e61da6bedb89e213c5fd71acc467faee/numpy-2.3.3-cp314-cp314-macosx_10_13_x86_64.whl", hash = "sha256:cd052f1fa6a78dee696b58a914b7229ecfa41f0a6d96dc663c1220a55e137593", size = 20951527, upload-time = "2025-09-09T15:57:52.006Z" },
+ { url = "https://files.pythonhosted.org/packages/ef/d8/204e0d73fc1b7a9ee80ab1fe1983dd33a4d64a4e30a05364b0208e9a241a/numpy-2.3.3-cp314-cp314-macosx_11_0_arm64.whl", hash = "sha256:414a97499480067d305fcac9716c29cf4d0d76db6ebf0bf3cbce666677f12652", size = 14186159, upload-time = "2025-09-09T15:57:54.407Z" },
+ { url = "https://files.pythonhosted.org/packages/22/af/f11c916d08f3a18fb8ba81ab72b5b74a6e42ead4c2846d270eb19845bf74/numpy-2.3.3-cp314-cp314-macosx_14_0_arm64.whl", hash = "sha256:50a5fe69f135f88a2be9b6ca0481a68a136f6febe1916e4920e12f1a34e708a7", size = 5114624, upload-time = "2025-09-09T15:57:56.5Z" },
+ { url = "https://files.pythonhosted.org/packages/fb/11/0ed919c8381ac9d2ffacd63fd1f0c34d27e99cab650f0eb6f110e6ae4858/numpy-2.3.3-cp314-cp314-macosx_14_0_x86_64.whl", hash = "sha256:b912f2ed2b67a129e6a601e9d93d4fa37bef67e54cac442a2f588a54afe5c67a", size = 6642627, upload-time = "2025-09-09T15:57:58.206Z" },
+ { url = "https://files.pythonhosted.org/packages/ee/83/deb5f77cb0f7ba6cb52b91ed388b47f8f3c2e9930d4665c600408d9b90b9/numpy-2.3.3-cp314-cp314-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:9e318ee0596d76d4cb3d78535dc005fa60e5ea348cd131a51e99d0bdbe0b54fe", size = 14296926, upload-time = "2025-09-09T15:58:00.035Z" },
+ { url = "https://files.pythonhosted.org/packages/77/cc/70e59dcb84f2b005d4f306310ff0a892518cc0c8000a33d0e6faf7ca8d80/numpy-2.3.3-cp314-cp314-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:ce020080e4a52426202bdb6f7691c65bb55e49f261f31a8f506c9f6bc7450421", size = 16638958, upload-time = "2025-09-09T15:58:02.738Z" },
+ { url = "https://files.pythonhosted.org/packages/b6/5a/b2ab6c18b4257e099587d5b7f903317bd7115333ad8d4ec4874278eafa61/numpy-2.3.3-cp314-cp314-musllinux_1_2_aarch64.whl", hash = "sha256:e6687dc183aa55dae4a705b35f9c0f8cb178bcaa2f029b241ac5356221d5c021", size = 16071920, upload-time = "2025-09-09T15:58:05.029Z" },
+ { url = "https://files.pythonhosted.org/packages/b8/f1/8b3fdc44324a259298520dd82147ff648979bed085feeacc1250ef1656c0/numpy-2.3.3-cp314-cp314-musllinux_1_2_x86_64.whl", hash = "sha256:d8f3b1080782469fdc1718c4ed1d22549b5fb12af0d57d35e992158a772a37cf", size = 18577076, upload-time = "2025-09-09T15:58:07.745Z" },
+ { url = "https://files.pythonhosted.org/packages/f0/a1/b87a284fb15a42e9274e7fcea0dad259d12ddbf07c1595b26883151ca3b4/numpy-2.3.3-cp314-cp314-win32.whl", hash = "sha256:cb248499b0bc3be66ebd6578b83e5acacf1d6cb2a77f2248ce0e40fbec5a76d0", size = 6366952, upload-time = "2025-09-09T15:58:10.096Z" },
+ { url = "https://files.pythonhosted.org/packages/70/5f/1816f4d08f3b8f66576d8433a66f8fa35a5acfb3bbd0bf6c31183b003f3d/numpy-2.3.3-cp314-cp314-win_amd64.whl", hash = "sha256:691808c2b26b0f002a032c73255d0bd89751425f379f7bcd22d140db593a96e8", size = 12919322, upload-time = "2025-09-09T15:58:12.138Z" },
+ { url = "https://files.pythonhosted.org/packages/8c/de/072420342e46a8ea41c324a555fa90fcc11637583fb8df722936aed1736d/numpy-2.3.3-cp314-cp314-win_arm64.whl", hash = "sha256:9ad12e976ca7b10f1774b03615a2a4bab8addce37ecc77394d8e986927dc0dfe", size = 10478630, upload-time = "2025-09-09T15:58:14.64Z" },
+ { url = "https://files.pythonhosted.org/packages/d5/df/ee2f1c0a9de7347f14da5dd3cd3c3b034d1b8607ccb6883d7dd5c035d631/numpy-2.3.3-cp314-cp314t-macosx_10_13_x86_64.whl", hash = "sha256:9cc48e09feb11e1db00b320e9d30a4151f7369afb96bd0e48d942d09da3a0d00", size = 21047987, upload-time = "2025-09-09T15:58:16.889Z" },
+ { url = "https://files.pythonhosted.org/packages/d6/92/9453bdc5a4e9e69cf4358463f25e8260e2ffc126d52e10038b9077815989/numpy-2.3.3-cp314-cp314t-macosx_11_0_arm64.whl", hash = "sha256:901bf6123879b7f251d3631967fd574690734236075082078e0571977c6a8e6a", size = 14301076, upload-time = "2025-09-09T15:58:20.343Z" },
+ { url = "https://files.pythonhosted.org/packages/13/77/1447b9eb500f028bb44253105bd67534af60499588a5149a94f18f2ca917/numpy-2.3.3-cp314-cp314t-macosx_14_0_arm64.whl", hash = "sha256:7f025652034199c301049296b59fa7d52c7e625017cae4c75d8662e377bf487d", size = 5229491, upload-time = "2025-09-09T15:58:22.481Z" },
+ { url = "https://files.pythonhosted.org/packages/3d/f9/d72221b6ca205f9736cb4b2ce3b002f6e45cd67cd6a6d1c8af11a2f0b649/numpy-2.3.3-cp314-cp314t-macosx_14_0_x86_64.whl", hash = "sha256:533ca5f6d325c80b6007d4d7fb1984c303553534191024ec6a524a4c92a5935a", size = 6737913, upload-time = "2025-09-09T15:58:24.569Z" },
+ { url = "https://files.pythonhosted.org/packages/3c/5f/d12834711962ad9c46af72f79bb31e73e416ee49d17f4c797f72c96b6ca5/numpy-2.3.3-cp314-cp314t-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl", hash = "sha256:0edd58682a399824633b66885d699d7de982800053acf20be1eaa46d92009c54", size = 14352811, upload-time = "2025-09-09T15:58:26.416Z" },
+ { url = "https://files.pythonhosted.org/packages/a1/0d/fdbec6629d97fd1bebed56cd742884e4eead593611bbe1abc3eb40d304b2/numpy-2.3.3-cp314-cp314t-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl", hash = "sha256:367ad5d8fbec5d9296d18478804a530f1191e24ab4d75ab408346ae88045d25e", size = 16702689, upload-time = "2025-09-09T15:58:28.831Z" },
+ { url = "https://files.pythonhosted.org/packages/9b/09/0a35196dc5575adde1eb97ddfbc3e1687a814f905377621d18ca9bc2b7dd/numpy-2.3.3-cp314-cp314t-musllinux_1_2_aarch64.whl", hash = "sha256:8f6ac61a217437946a1fa48d24c47c91a0c4f725237871117dea264982128097", size = 16133855, upload-time = "2025-09-09T15:58:31.349Z" },
+ { url = "https://files.pythonhosted.org/packages/7a/ca/c9de3ea397d576f1b6753eaa906d4cdef1bf97589a6d9825a349b4729cc2/numpy-2.3.3-cp314-cp314t-musllinux_1_2_x86_64.whl", hash = "sha256:179a42101b845a816d464b6fe9a845dfaf308fdfc7925387195570789bb2c970", size = 18652520, upload-time = "2025-09-09T15:58:33.762Z" },
+ { url = "https://files.pythonhosted.org/packages/fd/c2/e5ed830e08cd0196351db55db82f65bc0ab05da6ef2b72a836dcf1936d2f/numpy-2.3.3-cp314-cp314t-win32.whl", hash = "sha256:1250c5d3d2562ec4174bce2e3a1523041595f9b651065e4a4473f5f48a6bc8a5", size = 6515371, upload-time = "2025-09-09T15:58:36.04Z" },
+ { url = "https://files.pythonhosted.org/packages/47/c7/b0f6b5b67f6788a0725f744496badbb604d226bf233ba716683ebb47b570/numpy-2.3.3-cp314-cp314t-win_amd64.whl", hash = "sha256:b37a0b2e5935409daebe82c1e42274d30d9dd355852529eab91dab8dcca7419f", size = 13112576, upload-time = "2025-09-09T15:58:37.927Z" },
+ { url = "https://files.pythonhosted.org/packages/06/b9/33bba5ff6fb679aa0b1f8a07e853f002a6b04b9394db3069a1270a7784ca/numpy-2.3.3-cp314-cp314t-win_arm64.whl", hash = "sha256:78c9f6560dc7e6b3990e32df7ea1a50bbd0e2a111e05209963f5ddcab7073b0b", size = 10545953, upload-time = "2025-09-09T15:58:40.576Z" },
+]
+
+[[package]]
+name = "pandas"
+version = "2.3.2"
+source = { registry = "https://pypi.org/simple" }
+dependencies = [
+ { name = "numpy" },
+ { name = "python-dateutil" },
+ { name = "pytz" },
+ { name = "tzdata" },
+]
+sdist = { url = "https://files.pythonhosted.org/packages/79/8e/0e90233ac205ad182bd6b422532695d2b9414944a280488105d598c70023/pandas-2.3.2.tar.gz", hash = "sha256:ab7b58f8f82706890924ccdfb5f48002b83d2b5a3845976a9fb705d36c34dcdb", size = 4488684, upload-time = "2025-08-21T10:28:29.257Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/ec/db/614c20fb7a85a14828edd23f1c02db58a30abf3ce76f38806155d160313c/pandas-2.3.2-cp312-cp312-macosx_10_13_x86_64.whl", hash = "sha256:3fbb977f802156e7a3f829e9d1d5398f6192375a3e2d1a9ee0803e35fe70a2b9", size = 11587652, upload-time = "2025-08-21T10:27:15.888Z" },
+ { url = "https://files.pythonhosted.org/packages/99/b0/756e52f6582cade5e746f19bad0517ff27ba9c73404607c0306585c201b3/pandas-2.3.2-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:1b9b52693123dd234b7c985c68b709b0b009f4521000d0525f2b95c22f15944b", size = 10717686, upload-time = "2025-08-21T10:27:18.486Z" },
+ { url = "https://files.pythonhosted.org/packages/37/4c/dd5ccc1e357abfeee8353123282de17997f90ff67855f86154e5a13b81e5/pandas-2.3.2-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:0bd281310d4f412733f319a5bc552f86d62cddc5f51d2e392c8787335c994175", size = 11278722, upload-time = "2025-08-21T10:27:21.149Z" },
+ { url = "https://files.pythonhosted.org/packages/d3/a4/f7edcfa47e0a88cda0be8b068a5bae710bf264f867edfdf7b71584ace362/pandas-2.3.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:96d31a6b4354e3b9b8a2c848af75d31da390657e3ac6f30c05c82068b9ed79b9", size = 11987803, upload-time = "2025-08-21T10:27:23.767Z" },
+ { url = "https://files.pythonhosted.org/packages/f6/61/1bce4129f93ab66f1c68b7ed1c12bac6a70b1b56c5dab359c6bbcd480b52/pandas-2.3.2-cp312-cp312-musllinux_1_2_aarch64.whl", hash = "sha256:df4df0b9d02bb873a106971bb85d448378ef14b86ba96f035f50bbd3688456b4", size = 12766345, upload-time = "2025-08-21T10:27:26.6Z" },
+ { url = "https://files.pythonhosted.org/packages/8e/46/80d53de70fee835531da3a1dae827a1e76e77a43ad22a8cd0f8142b61587/pandas-2.3.2-cp312-cp312-musllinux_1_2_x86_64.whl", hash = "sha256:213a5adf93d020b74327cb2c1b842884dbdd37f895f42dcc2f09d451d949f811", size = 13439314, upload-time = "2025-08-21T10:27:29.213Z" },
+ { url = "https://files.pythonhosted.org/packages/28/30/8114832daff7489f179971dbc1d854109b7f4365a546e3ea75b6516cea95/pandas-2.3.2-cp312-cp312-win_amd64.whl", hash = "sha256:8c13b81a9347eb8c7548f53fd9a4f08d4dfe996836543f805c987bafa03317ae", size = 10983326, upload-time = "2025-08-21T10:27:31.901Z" },
+ { url = "https://files.pythonhosted.org/packages/27/64/a2f7bf678af502e16b472527735d168b22b7824e45a4d7e96a4fbb634b59/pandas-2.3.2-cp313-cp313-macosx_10_13_x86_64.whl", hash = "sha256:0c6ecbac99a354a051ef21c5307601093cb9e0f4b1855984a084bfec9302699e", size = 11531061, upload-time = "2025-08-21T10:27:34.647Z" },
+ { url = "https://files.pythonhosted.org/packages/54/4c/c3d21b2b7769ef2f4c2b9299fcadd601efa6729f1357a8dbce8dd949ed70/pandas-2.3.2-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:c6f048aa0fd080d6a06cc7e7537c09b53be6642d330ac6f54a600c3ace857ee9", size = 10668666, upload-time = "2025-08-21T10:27:37.203Z" },
+ { url = "https://files.pythonhosted.org/packages/50/e2/f775ba76ecfb3424d7f5862620841cf0edb592e9abd2d2a5387d305fe7a8/pandas-2.3.2-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:0064187b80a5be6f2f9c9d6bdde29372468751dfa89f4211a3c5871854cfbf7a", size = 11332835, upload-time = "2025-08-21T10:27:40.188Z" },
+ { url = "https://files.pythonhosted.org/packages/8f/52/0634adaace9be2d8cac9ef78f05c47f3a675882e068438b9d7ec7ef0c13f/pandas-2.3.2-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:4ac8c320bded4718b298281339c1a50fb00a6ba78cb2a63521c39bec95b0209b", size = 12057211, upload-time = "2025-08-21T10:27:43.117Z" },
+ { url = "https://files.pythonhosted.org/packages/0b/9d/2df913f14b2deb9c748975fdb2491da1a78773debb25abbc7cbc67c6b549/pandas-2.3.2-cp313-cp313-musllinux_1_2_aarch64.whl", hash = "sha256:114c2fe4f4328cf98ce5716d1532f3ab79c5919f95a9cfee81d9140064a2e4d6", size = 12749277, upload-time = "2025-08-21T10:27:45.474Z" },
+ { url = "https://files.pythonhosted.org/packages/87/af/da1a2417026bd14d98c236dba88e39837182459d29dcfcea510b2ac9e8a1/pandas-2.3.2-cp313-cp313-musllinux_1_2_x86_64.whl", hash = "sha256:48fa91c4dfb3b2b9bfdb5c24cd3567575f4e13f9636810462ffed8925352be5a", size = 13415256, upload-time = "2025-08-21T10:27:49.885Z" },
+ { url = "https://files.pythonhosted.org/packages/22/3c/f2af1ce8840ef648584a6156489636b5692c162771918aa95707c165ad2b/pandas-2.3.2-cp313-cp313-win_amd64.whl", hash = "sha256:12d039facec710f7ba305786837d0225a3444af7bbd9c15c32ca2d40d157ed8b", size = 10982579, upload-time = "2025-08-21T10:28:08.435Z" },
+ { url = "https://files.pythonhosted.org/packages/f3/98/8df69c4097a6719e357dc249bf437b8efbde808038268e584421696cbddf/pandas-2.3.2-cp313-cp313t-macosx_10_13_x86_64.whl", hash = "sha256:c624b615ce97864eb588779ed4046186f967374185c047070545253a52ab2d57", size = 12028163, upload-time = "2025-08-21T10:27:52.232Z" },
+ { url = "https://files.pythonhosted.org/packages/0e/23/f95cbcbea319f349e10ff90db488b905c6883f03cbabd34f6b03cbc3c044/pandas-2.3.2-cp313-cp313t-macosx_11_0_arm64.whl", hash = "sha256:0cee69d583b9b128823d9514171cabb6861e09409af805b54459bd0c821a35c2", size = 11391860, upload-time = "2025-08-21T10:27:54.673Z" },
+ { url = "https://files.pythonhosted.org/packages/ad/1b/6a984e98c4abee22058aa75bfb8eb90dce58cf8d7296f8bc56c14bc330b0/pandas-2.3.2-cp313-cp313t-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:2319656ed81124982900b4c37f0e0c58c015af9a7bbc62342ba5ad07ace82ba9", size = 11309830, upload-time = "2025-08-21T10:27:56.957Z" },
+ { url = "https://files.pythonhosted.org/packages/15/d5/f0486090eb18dd8710bf60afeaf638ba6817047c0c8ae5c6a25598665609/pandas-2.3.2-cp313-cp313t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:b37205ad6f00d52f16b6d09f406434ba928c1a1966e2771006a9033c736d30d2", size = 11883216, upload-time = "2025-08-21T10:27:59.302Z" },
+ { url = "https://files.pythonhosted.org/packages/10/86/692050c119696da19e20245bbd650d8dfca6ceb577da027c3a73c62a047e/pandas-2.3.2-cp313-cp313t-musllinux_1_2_aarch64.whl", hash = "sha256:837248b4fc3a9b83b9c6214699a13f069dc13510a6a6d7f9ba33145d2841a012", size = 12699743, upload-time = "2025-08-21T10:28:02.447Z" },
+ { url = "https://files.pythonhosted.org/packages/cd/d7/612123674d7b17cf345aad0a10289b2a384bff404e0463a83c4a3a59d205/pandas-2.3.2-cp313-cp313t-musllinux_1_2_x86_64.whl", hash = "sha256:d2c3554bd31b731cd6490d94a28f3abb8dd770634a9e06eb6d2911b9827db370", size = 13186141, upload-time = "2025-08-21T10:28:05.377Z" },
+]
+
+[[package]]
+name = "pdfminer-six"
+version = "20250506"
+source = { registry = "https://pypi.org/simple" }
+dependencies = [
+ { name = "charset-normalizer" },
+ { name = "cryptography" },
+]
+sdist = { url = "https://files.pythonhosted.org/packages/78/46/5223d613ac4963e1f7c07b2660fe0e9e770102ec6bda8c038400113fb215/pdfminer_six-20250506.tar.gz", hash = "sha256:b03cc8df09cf3c7aba8246deae52e0bca7ebb112a38895b5e1d4f5dd2b8ca2e7", size = 7387678, upload-time = "2025-05-06T16:17:00.787Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/73/16/7a432c0101fa87457e75cb12c879e1749c5870a786525e2e0f42871d6462/pdfminer_six-20250506-py3-none-any.whl", hash = "sha256:d81ad173f62e5f841b53a8ba63af1a4a355933cfc0ffabd608e568b9193909e3", size = 5620187, upload-time = "2025-05-06T16:16:58.669Z" },
+]
+
+[[package]]
+name = "pycparser"
+version = "2.23"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/fe/cf/d2d3b9f5699fb1e4615c8e32ff220203e43b248e1dfcc6736ad9057731ca/pycparser-2.23.tar.gz", hash = "sha256:78816d4f24add8f10a06d6f05b4d424ad9e96cfebf68a4ddc99c65c0720d00c2", size = 173734, upload-time = "2025-09-09T13:23:47.91Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/a0/e3/59cd50310fc9b59512193629e1984c1f95e5c8ae6e5d8c69532ccc65a7fe/pycparser-2.23-py3-none-any.whl", hash = "sha256:e5c6e8d3fbad53479cab09ac03729e0a9faf2bee3db8208a550daf5af81a5934", size = 118140, upload-time = "2025-09-09T13:23:46.651Z" },
+]
+
+[[package]]
+name = "python-dateutil"
+version = "2.9.0.post0"
+source = { registry = "https://pypi.org/simple" }
+dependencies = [
+ { name = "six" },
+]
+sdist = { url = "https://files.pythonhosted.org/packages/66/c0/0c8b6ad9f17a802ee498c46e004a0eb49bc148f2fd230864601a86dcf6db/python-dateutil-2.9.0.post0.tar.gz", hash = "sha256:37dd54208da7e1cd875388217d5e00ebd4179249f90fb72437e91a35459a0ad3", size = 342432, upload-time = "2024-03-01T18:36:20.211Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/ec/57/56b9bcc3c9c6a792fcbaf139543cee77261f3651ca9da0c93f5c1221264b/python_dateutil-2.9.0.post0-py2.py3-none-any.whl", hash = "sha256:a8b2bc7bffae282281c8140a97d3aa9c14da0b136dfe83f850eea9a5f7470427", size = 229892, upload-time = "2024-03-01T18:36:18.57Z" },
+]
+
+[[package]]
+name = "pytz"
+version = "2025.2"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/f8/bf/abbd3cdfb8fbc7fb3d4d38d320f2441b1e7cbe29be4f23797b4a2b5d8aac/pytz-2025.2.tar.gz", hash = "sha256:360b9e3dbb49a209c21ad61809c7fb453643e048b38924c765813546746e81c3", size = 320884, upload-time = "2025-03-25T02:25:00.538Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/81/c4/34e93fe5f5429d7570ec1fa436f1986fb1f00c3e0f43a589fe2bbcd22c3f/pytz-2025.2-py2.py3-none-any.whl", hash = "sha256:5ddf76296dd8c44c26eb8f4b6f35488f3ccbf6fbbd7adee0b7262d43f0ec2f00", size = 509225, upload-time = "2025-03-25T02:24:58.468Z" },
+]
+
+[[package]]
+name = "pyyaml"
+version = "6.0.2"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/54/ed/79a089b6be93607fa5cdaedf301d7dfb23af5f25c398d5ead2525b063e17/pyyaml-6.0.2.tar.gz", hash = "sha256:d584d9ec91ad65861cc08d42e834324ef890a082e591037abe114850ff7bbc3e", size = 130631, upload-time = "2024-08-06T20:33:50.674Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/86/0c/c581167fc46d6d6d7ddcfb8c843a4de25bdd27e4466938109ca68492292c/PyYAML-6.0.2-cp312-cp312-macosx_10_9_x86_64.whl", hash = "sha256:c70c95198c015b85feafc136515252a261a84561b7b1d51e3384e0655ddf25ab", size = 183873, upload-time = "2024-08-06T20:32:25.131Z" },
+ { url = "https://files.pythonhosted.org/packages/a8/0c/38374f5bb272c051e2a69281d71cba6fdb983413e6758b84482905e29a5d/PyYAML-6.0.2-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:ce826d6ef20b1bc864f0a68340c8b3287705cae2f8b4b1d932177dcc76721725", size = 173302, upload-time = "2024-08-06T20:32:26.511Z" },
+ { url = "https://files.pythonhosted.org/packages/c3/93/9916574aa8c00aa06bbac729972eb1071d002b8e158bd0e83a3b9a20a1f7/PyYAML-6.0.2-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:1f71ea527786de97d1a0cc0eacd1defc0985dcf6b3f17bb77dcfc8c34bec4dc5", size = 739154, upload-time = "2024-08-06T20:32:28.363Z" },
+ { url = "https://files.pythonhosted.org/packages/95/0f/b8938f1cbd09739c6da569d172531567dbcc9789e0029aa070856f123984/PyYAML-6.0.2-cp312-cp312-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:9b22676e8097e9e22e36d6b7bda33190d0d400f345f23d4065d48f4ca7ae0425", size = 766223, upload-time = "2024-08-06T20:32:30.058Z" },
+ { url = "https://files.pythonhosted.org/packages/b9/2b/614b4752f2e127db5cc206abc23a8c19678e92b23c3db30fc86ab731d3bd/PyYAML-6.0.2-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:80bab7bfc629882493af4aa31a4cfa43a4c57c83813253626916b8c7ada83476", size = 767542, upload-time = "2024-08-06T20:32:31.881Z" },
+ { url = "https://files.pythonhosted.org/packages/d4/00/dd137d5bcc7efea1836d6264f049359861cf548469d18da90cd8216cf05f/PyYAML-6.0.2-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:0833f8694549e586547b576dcfaba4a6b55b9e96098b36cdc7ebefe667dfed48", size = 731164, upload-time = "2024-08-06T20:32:37.083Z" },
+ { url = "https://files.pythonhosted.org/packages/c9/1f/4f998c900485e5c0ef43838363ba4a9723ac0ad73a9dc42068b12aaba4e4/PyYAML-6.0.2-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:8b9c7197f7cb2738065c481a0461e50ad02f18c78cd75775628afb4d7137fb3b", size = 756611, upload-time = "2024-08-06T20:32:38.898Z" },
+ { url = "https://files.pythonhosted.org/packages/df/d1/f5a275fdb252768b7a11ec63585bc38d0e87c9e05668a139fea92b80634c/PyYAML-6.0.2-cp312-cp312-win32.whl", hash = "sha256:ef6107725bd54b262d6dedcc2af448a266975032bc85ef0172c5f059da6325b4", size = 140591, upload-time = "2024-08-06T20:32:40.241Z" },
+ { url = "https://files.pythonhosted.org/packages/0c/e8/4f648c598b17c3d06e8753d7d13d57542b30d56e6c2dedf9c331ae56312e/PyYAML-6.0.2-cp312-cp312-win_amd64.whl", hash = "sha256:7e7401d0de89a9a855c839bc697c079a4af81cf878373abd7dc625847d25cbd8", size = 156338, upload-time = "2024-08-06T20:32:41.93Z" },
+ { url = "https://files.pythonhosted.org/packages/ef/e3/3af305b830494fa85d95f6d95ef7fa73f2ee1cc8ef5b495c7c3269fb835f/PyYAML-6.0.2-cp313-cp313-macosx_10_13_x86_64.whl", hash = "sha256:efdca5630322a10774e8e98e1af481aad470dd62c3170801852d752aa7a783ba", size = 181309, upload-time = "2024-08-06T20:32:43.4Z" },
+ { url = "https://files.pythonhosted.org/packages/45/9f/3b1c20a0b7a3200524eb0076cc027a970d320bd3a6592873c85c92a08731/PyYAML-6.0.2-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:50187695423ffe49e2deacb8cd10510bc361faac997de9efef88badc3bb9e2d1", size = 171679, upload-time = "2024-08-06T20:32:44.801Z" },
+ { url = "https://files.pythonhosted.org/packages/7c/9a/337322f27005c33bcb656c655fa78325b730324c78620e8328ae28b64d0c/PyYAML-6.0.2-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:0ffe8360bab4910ef1b9e87fb812d8bc0a308b0d0eef8c8f44e0254ab3b07133", size = 733428, upload-time = "2024-08-06T20:32:46.432Z" },
+ { url = "https://files.pythonhosted.org/packages/a3/69/864fbe19e6c18ea3cc196cbe5d392175b4cf3d5d0ac1403ec3f2d237ebb5/PyYAML-6.0.2-cp313-cp313-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:17e311b6c678207928d649faa7cb0d7b4c26a0ba73d41e99c4fff6b6c3276484", size = 763361, upload-time = "2024-08-06T20:32:51.188Z" },
+ { url = "https://files.pythonhosted.org/packages/04/24/b7721e4845c2f162d26f50521b825fb061bc0a5afcf9a386840f23ea19fa/PyYAML-6.0.2-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:70b189594dbe54f75ab3a1acec5f1e3faa7e8cf2f1e08d9b561cb41b845f69d5", size = 759523, upload-time = "2024-08-06T20:32:53.019Z" },
+ { url = "https://files.pythonhosted.org/packages/2b/b2/e3234f59ba06559c6ff63c4e10baea10e5e7df868092bf9ab40e5b9c56b6/PyYAML-6.0.2-cp313-cp313-musllinux_1_1_aarch64.whl", hash = "sha256:41e4e3953a79407c794916fa277a82531dd93aad34e29c2a514c2c0c5fe971cc", size = 726660, upload-time = "2024-08-06T20:32:54.708Z" },
+ { url = "https://files.pythonhosted.org/packages/fe/0f/25911a9f080464c59fab9027482f822b86bf0608957a5fcc6eaac85aa515/PyYAML-6.0.2-cp313-cp313-musllinux_1_1_x86_64.whl", hash = "sha256:68ccc6023a3400877818152ad9a1033e3db8625d899c72eacb5a668902e4d652", size = 751597, upload-time = "2024-08-06T20:32:56.985Z" },
+ { url = "https://files.pythonhosted.org/packages/14/0d/e2c3b43bbce3cf6bd97c840b46088a3031085179e596d4929729d8d68270/PyYAML-6.0.2-cp313-cp313-win32.whl", hash = "sha256:bc2fa7c6b47d6bc618dd7fb02ef6fdedb1090ec036abab80d4681424b84c1183", size = 140527, upload-time = "2024-08-06T20:33:03.001Z" },
+ { url = "https://files.pythonhosted.org/packages/fa/de/02b54f42487e3d3c6efb3f89428677074ca7bf43aae402517bc7cca949f3/PyYAML-6.0.2-cp313-cp313-win_amd64.whl", hash = "sha256:8388ee1976c416731879ac16da0aff3f63b286ffdd57cdeb95f3f2e085687563", size = 156446, upload-time = "2024-08-06T20:33:04.33Z" },
+]
+
+[[package]]
+name = "requests"
+version = "2.32.5"
+source = { registry = "https://pypi.org/simple" }
+dependencies = [
+ { name = "certifi" },
+ { name = "charset-normalizer" },
+ { name = "idna" },
+ { name = "urllib3" },
+]
+sdist = { url = "https://files.pythonhosted.org/packages/c9/74/b3ff8e6c8446842c3f5c837e9c3dfcfe2018ea6ecef224c710c85ef728f4/requests-2.32.5.tar.gz", hash = "sha256:dbba0bac56e100853db0ea71b82b4dfd5fe2bf6d3754a8893c3af500cec7d7cf", size = 134517, upload-time = "2025-08-18T20:46:02.573Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/1e/db/4254e3eabe8020b458f1a747140d32277ec7a271daf1d235b70dc0b4e6e3/requests-2.32.5-py3-none-any.whl", hash = "sha256:2462f94637a34fd532264295e186976db0f5d453d1cdd31473c85a6a161affb6", size = 64738, upload-time = "2025-08-18T20:46:00.542Z" },
+]
+
+[[package]]
+name = "six"
+version = "1.17.0"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/94/e7/b2c673351809dca68a0e064b6af791aa332cf192da575fd474ed7d6f16a2/six-1.17.0.tar.gz", hash = "sha256:ff70335d468e7eb6ec65b95b99d3a2836546063f63acc5171de367e834932a81", size = 34031, upload-time = "2024-12-04T17:35:28.174Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/b7/ce/149a00dd41f10bc29e5921b496af8b574d8413afcd5e30dfa0ed46c2cc5e/six-1.17.0-py2.py3-none-any.whl", hash = "sha256:4721f391ed90541fddacab5acf947aa0d3dc7d27b2e1e8eda2be8970586c3274", size = 11050, upload-time = "2024-12-04T17:35:26.475Z" },
+]
+
+[[package]]
+name = "soupsieve"
+version = "2.8"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/6d/e6/21ccce3262dd4889aa3332e5a119a3491a95e8f60939870a3a035aabac0d/soupsieve-2.8.tar.gz", hash = "sha256:e2dd4a40a628cb5f28f6d4b0db8800b8f581b65bb380b97de22ba5ca8d72572f", size = 103472, upload-time = "2025-08-27T15:39:51.78Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/14/a0/bb38d3b76b8cae341dad93a2dd83ab7462e6dbcdd84d43f54ee60a8dc167/soupsieve-2.8-py3-none-any.whl", hash = "sha256:0cc76456a30e20f5d7f2e14a98a4ae2ee4e5abdc7c5ea0aafe795f344bc7984c", size = 36679, upload-time = "2025-08-27T15:39:50.179Z" },
+]
+
+[[package]]
+name = "typing-extensions"
+version = "4.15.0"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/72/94/1a15dd82efb362ac84269196e94cf00f187f7ed21c242792a923cdb1c61f/typing_extensions-4.15.0.tar.gz", hash = "sha256:0cea48d173cc12fa28ecabc3b837ea3cf6f38c6d1136f85cbaaf598984861466", size = 109391, upload-time = "2025-08-25T13:49:26.313Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/18/67/36e9267722cc04a6b9f15c7f3441c2363321a3ea07da7ae0c0707beb2a9c/typing_extensions-4.15.0-py3-none-any.whl", hash = "sha256:f0fa19c6845758ab08074a0cfa8b7aecb71c999ca73d62883bc25cc018c4e548", size = 44614, upload-time = "2025-08-25T13:49:24.86Z" },
+]
+
+[[package]]
+name = "tzdata"
+version = "2025.2"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/95/32/1a225d6164441be760d75c2c42e2780dc0873fe382da3e98a2e1e48361e5/tzdata-2025.2.tar.gz", hash = "sha256:b60a638fcc0daffadf82fe0f57e53d06bdec2f36c4df66280ae79bce6bd6f2b9", size = 196380, upload-time = "2025-03-23T13:54:43.652Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/5c/23/c7abc0ca0a1526a0774eca151daeb8de62ec457e77262b66b359c3c7679e/tzdata-2025.2-py2.py3-none-any.whl", hash = "sha256:1a403fada01ff9221ca8044d701868fa132215d84beb92242d9acd2147f667a8", size = 347839, upload-time = "2025-03-23T13:54:41.845Z" },
+]
+
+[[package]]
+name = "urllib3"
+version = "2.5.0"
+source = { registry = "https://pypi.org/simple" }
+sdist = { url = "https://files.pythonhosted.org/packages/15/22/9ee70a2574a4f4599c47dd506532914ce044817c7752a79b6a51286319bc/urllib3-2.5.0.tar.gz", hash = "sha256:3fc47733c7e419d4bc3f6b3dc2b4f890bb743906a30d56ba4a5bfa4bbff92760", size = 393185, upload-time = "2025-06-18T14:07:41.644Z" }
+wheels = [
+ { url = "https://files.pythonhosted.org/packages/a7/c2/fe1e52489ae3122415c51f387e221dd0773709bad6c6cdaa599e8a2c5185/urllib3-2.5.0-py3-none-any.whl", hash = "sha256:e6b01673c0fa6a13e374b50871808eb3bf7046c4b125b216f6bf1cc604cff0dc", size = 129795, upload-time = "2025-06-18T14:07:40.39Z" },
+]
diff --git a/etc/scripts/generate_site_template_screenshots.ts b/etc/scripts/generate_site_template_screenshots.ts
index b607d457b9b..2510ff15ea9 100644
--- a/etc/scripts/generate_site_template_screenshots.ts
+++ b/etc/scripts/generate_site_template_screenshots.ts
@@ -121,9 +121,9 @@ if (!fss.existsSync(output_dir)) {
await fsp.mkdir(output_dir, {recursive: true});
}
const jobs: (() => void)[] = [];
-for (const {name, reference} of templates) {
+for (const {id, reference} of templates) {
for (const [theme, colourScheme] of themes) {
- const path = `${output_dir}/${name}.${theme}.png`;
+ const path = `${output_dir}/${id}.${theme}.png`;
if (!fss.existsSync(path)) {
jobs.push(() => generateScreenshot(
`${godbolt}/e#${reference}`,
diff --git a/etc/scripts/gh_tool/.gitignore b/etc/scripts/gh_tool/.gitignore
new file mode 100644
index 00000000000..d6e22c73004
--- /dev/null
+++ b/etc/scripts/gh_tool/.gitignore
@@ -0,0 +1,19 @@
+# Python
+__pycache__/
+*.pyc
+*.pyo
+*.pyd
+.Python
+
+# uv
+uv.lock
+.venv/
+*.egg-info/
+
+# IDE
+.vscode/
+.idea/
+*.swp
+
+# Environment
+.env
diff --git a/etc/scripts/gh_tool/README.md b/etc/scripts/gh_tool/README.md
new file mode 100644
index 00000000000..980bf0f1d50
--- /dev/null
+++ b/etc/scripts/gh_tool/README.md
@@ -0,0 +1,125 @@
+# GitHub Tools for Compiler Explorer
+
+CLI tools for automating GitHub repository management tasks.
+
+## Setup
+
+This project uses [`uv`](https://docs.astral.sh/uv/) for Python version and dependency management.
+
+Install dependencies:
+
+```bash
+cd etc/scripts/gh_tool
+uv sync
+```
+
+## Usage
+
+Run from the gh_tool directory:
+
+```bash
+cd etc/scripts/gh_tool
+
+# Get help
+uv run gh_tool --help
+
+# Get help for a specific command
+uv run gh_tool find-duplicates --help
+```
+
+## Commands
+
+### find-duplicates
+
+Finds potential duplicate issues in the compiler-explorer repository using text similarity analysis (difflib.SequenceMatcher).
+
+**Usage:**
+
+```bash
+# Basic usage (checks all open issues)
+uv run gh_tool find-duplicates /tmp/duplicates-report.md
+
+# Check all issues (including closed)
+uv run gh_tool find-duplicates /tmp/all-duplicates.md --state all
+
+# Adjust similarity threshold for higher confidence matches
+uv run gh_tool find-duplicates /tmp/high-confidence.md --threshold 0.85
+
+# Combine options
+uv run gh_tool find-duplicates /tmp/report.md --threshold 0.7 --state all --min-age 30
+
+# Use with a different repository
+uv run gh_tool find-duplicates /tmp/other-repo.md --repo owner/repository
+```
+
+**Arguments:**
+
+- `OUTPUT_FILE` (required) - Path to output markdown file
+
+**Options:**
+
+- `--threshold FLOAT` - Similarity threshold between 0 and 1 (default: 0.6)
+ - 0.6 = 60% similar titles
+ - Higher values = fewer, more confident matches
+- `--state {all,open,closed}` - Which issues to check (default: open)
+- `--min-age DAYS` - Only check issues older than N days (default: 0)
+- `--limit INTEGER` - Maximum number of issues to fetch (default: 1000)
+- `--repo TEXT` - GitHub repository in owner/repo format (default: compiler-explorer/compiler-explorer)
+
+**Example Output:**
+
+```markdown
+# Potential Duplicate Issues
+
+Found 5 potential duplicate groups:
+
+## Group 1 (85% similar)
+- #3201 [LIB REQUEST] numpy (12 comments, created 2021-03-15)
+- #7778 [LIB REQUEST] numpy (0 comments, created 2024-01-10)
+
+## Group 2 (72% similar)
+- #4336 [COMPILER REQUEST]: Groovy (3 comments, created 2022-05-20)
+- #6526 [COMPILER REQUEST]: Groovy (1 comments, created 2023-08-15)
+```
+
+**Performance:**
+
+The duplicate detection algorithm uses O(n²) pairwise comparisons. For reference:
+- ~850 issues: ~362,000 comparisons (~1-2 minutes)
+- ~1,000 issues: ~500,000 comparisons (~2-3 minutes)
+
+A progress bar shows real-time progress during the comparison phase.
+
+**Requirements:**
+
+- `gh` CLI must be installed and authenticated
+- Read access to compiler-explorer/compiler-explorer repository
+
+## Future Tools
+
+This directory is intended to house additional GitHub automation scripts such as:
+
+- Upstream project health checker (detect abandoned compiler/library projects)
+- Label consistency validator
+- Issue template compliance checker
+- Automated triage reports
+
+## Development
+
+Run tests:
+
+```bash
+uv run pytest -v
+```
+
+Run linting:
+
+```bash
+uv run ruff check .
+```
+
+Format code:
+
+```bash
+uv run ruff format .
+```
diff --git a/etc/scripts/gh_tool/docs/PHASE1-FINDINGS.md b/etc/scripts/gh_tool/docs/PHASE1-FINDINGS.md
new file mode 100644
index 00000000000..3cfe3786451
--- /dev/null
+++ b/etc/scripts/gh_tool/docs/PHASE1-FINDINGS.md
@@ -0,0 +1,200 @@
+# Compiler Explorer Issue Analysis - Phase 1 Findings
+**Date:** 2025-10-06
+**Total Open Issues:** 855
+
+## Executive Summary
+
+The issue backlog reveals clear patterns that can guide systematic triage:
+
+- **46% (398) are stale** (>2 years old, <5 comments) - prime candidates for review
+- **35% (297) have zero engagement** - likely duplicates, invalid, or need clarification
+- **48% (412) are poorly labeled** - only generic labels, impeding organization
+- **51% (439) are generic "requests"** - mostly compiler/library additions
+- **28% (239) are bugs** - actual functionality issues
+- **5% (42) marked "probably-wont-happen"** but still open - should be closed kindly
+
+## Key Statistics
+
+### Age Distribution
+```
+>5 years old: 137 (16.0%) ← Ancient, likely obsolete or philosophical
+3-5 years old: 189 (22.1%) ← Old, likely stale
+2-3 years old: 181 (21.2%) ← Getting stale
+1-2 years old: 151 (17.7%)
+6-12 months: 102 (11.9%)
+3-6 months: 53 (6.2%)
+<3 months: 42 (4.9%) ← Recent
+```
+
+**Key Insight:** 59% of issues are >2 years old. This suggests either low prioritization or lack of contributor bandwidth.
+
+### Label Distribution (Top 10)
+```
+request 439 (51.3%) ← Mostly compiler/library requests
+bug 239 (28.0%)
+new-compilers 121 (14.2%)
+new-libs 93 (10.9%)
+enhancement 79 (9.2%)
+ui 51 (6.0%)
+help wanted 44 (5.1%)
+probably-wont-happen 42 (4.9%)
+Status: triaged 35 (4.1%)
+lang-c++ 29 (3.4%)
+```
+
+### Engagement Patterns
+
+**Top 3 Most-Commented:**
+1. #82 (39 comments) - "C(++) Compiler Master List" - META-ISSUE tracking compilers
+2. #891 (37 comments) - "Add pgroup compiler"
+3. #264 (35 comments) - "Add D8 JavaScript assembly output"
+
+**Zero Comments:** 297 issues (35%) have NO engagement whatsoever
+- Many are recent (<6 months) and may just need time
+- Many are 5+ years old and likely forgotten/obsolete
+
+## Critical Findings
+
+### 1. Tracking/Meta Issues
+
+**Issue #82** (10 years old) is a "Master List" with checkboxes tracking compiler support. This was useful historically but now creates confusion:
+- 39 comments of various requests
+- Acts as a catch-all for "add this compiler" requests
+- Should probably be closed with pointer to proper issue templates
+
+### 2. "Probably Won't Happen" Issues (42 total)
+
+These are already flagged but remain open. Examples:
+- #187 (8.9y) - "Add support for MMIX" - niche educational architecture
+- #264 (8.7y) - "Add D8 JavaScript assembly" - 35 comments, out of scope
+- #341 (8.5y) - "classic GCC versions" - limited value vs maintenance cost
+- #514 (8.1y) - "ARM GCC 6.3.0 standard libraries missing" - old compiler version
+
+**Action:** These should be kindly closed with explanations.
+
+### 3. Stale Issues (398 total)
+
+**Criteria:** >2 years old AND <5 comments
+
+These show minimal community interest and are likely:
+- Overtaken by events (e.g., new compiler versions available)
+- Niche requests with no PR momentum
+- Questions that were never answered
+
+**Sample oldest stale issues:**
+- #187 (8.9y, 0 comments) - MMIX support
+- #297 (8.6y, 0 comments) - GCC7 verbose-asm format
+- #341 (8.5y, 0 comments) - Classic GCC versions
+- #425 (8.4y, 0 comments) - libfirm/cparser
+
+### 4. Duplicate/Similar Requests
+
+**GCC versions:** 11 issues requesting various GCC versions/configurations
+**Clang variants:** 9 issues for different Clang forks/versions
+**MSVC versions:** 3+ issues for recent MSVC versions (could be consolidated)
+**ROCm/AMD:** 3 issues about ROCm compiler versions
+
+These could be consolidated into tracking issues or closed as duplicates.
+
+### 5. Poorly Labeled Issues (412 total)
+
+Many issues have only generic labels like "request" or "bug" without specifics:
+- No language tag (lang-c++, lang-rust, etc.)
+- No area tag (ui, compiler-issue, etc.)
+- No priority indication
+
+This makes filtering and prioritization difficult.
+
+## Common Themes in Titles
+
+**Top keywords:**
+- "request" (437) - the label shows up in titles too
+- "compiler" (183)
+- "support" (97)
+- "clang" (62)
+- "library" (35)
+- "msvc" (27)
+
+**Pattern:** Most issues are straightforward "add X compiler" or "add Y library" requests.
+
+## Recommendations for Phase 2
+
+### Immediate Actions
+
+1. **Close "Probably Won't Happen" Issues (42)**
+ - Draft kind, clear explanation template
+ - Close with rationale and link to contribution docs if applicable
+ - Expected impact: -5% issue count
+
+2. **Close Ancient Zero-Comment Issues (estimate ~50-100)**
+ - Issues >5 years old with 0 comments and no activity
+ - Use "stale bot" type reasoning: "no activity, assumed no longer relevant"
+ - Allow 2 weeks for objections before closing
+ - Expected impact: -6-12% issue count
+
+3. **Close Obvious Duplicates (estimate ~20-30)**
+ - Multiple GCC/Clang version requests → consolidate or close with "use latest"
+ - Expected impact: -2-4% issue count
+
+### Medium-Term Actions
+
+4. **Improve Labeling (412 issues)**
+ - Add language-specific labels (lang-*)
+ - Add area labels (ui, execution, api, etc.)
+ - Add priority labels where clear
+ - This enables better filtering and assignment
+
+5. **Create "Good First Issue" Pipeline (~50 issues)**
+ - Review "help wanted" (44 issues) for suitable ones
+ - Look for well-defined, isolated tasks
+ - Add good-first-issue label and mentorship notes
+
+6. **Consolidate Request Tracking**
+ - Create wiki/doc page for "Compiler Request Guidelines"
+ - Explain: how to request, how to contribute, what makes requests likely
+ - Close #82 meta-issue with pointer to new docs
+
+### Long-Term Strategy
+
+7. **Implement Stale Bot**
+ - Auto-label issues >1 year old with no activity
+ - Auto-close after warning period if still no activity
+ - Keep it friendly: "seems resolved, please reopen if still relevant"
+
+8. **Improve Issue Templates**
+ - Separate templates for: compiler requests, library requests, bug reports, feature requests
+ - Require more details (version numbers, error messages, why needed)
+ - Auto-label based on template used
+
+9. **Regular Triage Cadence**
+ - Weekly review of new issues (label, prioritize, close if needed)
+ - Monthly review of old issues (close stale, consolidate duplicates)
+ - Quarterly review of "help wanted" (ensure still relevant)
+
+## Estimated Impact
+
+**Conservative cleanup estimate:**
+- Close "probably-wont-happen": -42 issues
+- Close ancient zero-comment: -50 issues
+- Close duplicates: -20 issues
+- **Total: -112 issues (13% reduction)**
+
+**Aggressive cleanup estimate:**
+- Above plus stale >3 years: -200+ additional
+- **Total: -300+ issues (35% reduction)**
+
+## Next Steps
+
+**Proposed Plan:**
+1. Review sample of "probably-wont-happen" issues together
+2. Draft closure message templates (kind but clear)
+3. Review sample of stale issues together
+4. Implement Phase 2: Systematic triage with your approval
+5. Consider automation (stale bot, better templates)
+
+## Files Generated
+
+- `all-issues-raw.json` - Full issue data from GitHub
+- `issues-summary.json` - Simplified format
+- `full-analysis.txt` - Complete statistical analysis
+- `PHASE1-FINDINGS.md` - This document
diff --git a/etc/scripts/gh_tool/docs/TRIAGE-CRITERIA.md b/etc/scripts/gh_tool/docs/TRIAGE-CRITERIA.md
new file mode 100644
index 00000000000..522c98c260d
--- /dev/null
+++ b/etc/scripts/gh_tool/docs/TRIAGE-CRITERIA.md
@@ -0,0 +1,271 @@
+# Compiler Explorer Issue Triage Criteria
+
+Based on manual review of 22+ issues (October 2025), here are the established triage patterns and decisions.
+
+## Quick Reference: Triage Decisions
+
+| Category | Keep/Close | Labels to Add |
+|----------|-----------|---------------|
+| Active projects (compiler/lib requests) | KEEP | help wanted |
+| Abandoned upstream projects (8+ years) | CLOSE | - |
+| Zero-demand features (7+ years, 0 comments) | CLOSE | - |
+| External tools (already work via API) | CLOSE | - |
+| Stale reminders/TODOs (6+ years) | CLOSE | - |
+| Duplicates | CLOSE newest | - |
+| Related but not duplicates | KEEP both | Link in comments |
+
+---
+
+## 1. Core Principles
+
+### Conservative Approach
+- **Age alone is NOT a proxy for value**
+- Each issue needs explicit review before closing
+- When in doubt, keep it open
+- Look for recent interest (CppCon mentions, user questions, etc.)
+
+### Priority Areas
+1. Close obvious duplicates
+2. Close abandoned/dead projects
+3. Better organize remaining issues with labels
+4. Identify "help wanted" opportunities
+
+---
+
+## 2. Compiler & Library Requests
+
+### KEEP if:
+- ✅ Upstream project is actively maintained (check last commit date)
+- ✅ Project has legitimate use cases
+- ✅ Zero comments but project is real/active (just needs contributor)
+
+### CLOSE if:
+- ❌ Upstream project is abandoned (8+ years with no activity)
+- ❌ Author confirmed they don't have patches/support for newer versions
+- ❌ Project was experimental and never went mainstream
+
+### Examples:
+
+**KEEP:**
+- #425 (libfirm/cparser) - Active: cparser updated Jan 2025, libfirm March 2025
+- #1232 (PCL Point Cloud Library) - Active, legitimate library
+- #503 (Cython) - Active project, add "help wanted"
+- #341 (classic GCC versions) - User interest confirmed at CppCon
+
+**CLOSE:**
+- #2063 (static_print GCC) - Abandoned (last commit 2017), author has no patches
+- #1018 (clang-contracts) - CE already has alternative contract compilers
+
+---
+
+## 3. Feature Requests
+
+### KEEP if:
+- ✅ Technically feasible
+- ✅ Aligns with CE's mission
+- ✅ Recent interest or discussion
+- ✅ "Probably-wont-happen" but PRs would be accepted
+
+### CLOSE if:
+- ❌ Implementation complexity outweighs value
+- ❌ Encourages bad practices (e.g., #797 BUILT_ON_COMPILER_EXPLORER macro)
+- ❌ Tool already exists externally and works via CE's API
+
+### Examples:
+
+**KEEP:**
+- #297 (-fverbose-asm filtering bug) - Real usability issue, fixable
+- #1004 (verbose-asm UI button) - Related to #297, useful convenience
+- #187 (MMIX) - Recent CppCon interest
+
+**CLOSE:**
+- #547 (FXC shader compiler) - Not a good fit for CE
+- #797 (BUILT_ON_COMPILER_EXPLORER macro) - Encourages bad practices
+- #1203 (SIMD-Visualiser integration) - Already works externally via API
+
+---
+
+## 4. Bugs & Issues
+
+### Bug Validation Process:
+1. Test if bug still reproduces using Compiler Explorer MCP
+2. Read ALL comments, not just the first one
+3. Check if workarounds exist
+4. Verify affected compiler versions still exist in CE
+
+### KEEP if:
+- ✅ Bug still reproduces
+- ✅ Affects multiple compiler versions
+- ✅ No reasonable workaround exists
+
+### Examples:
+
+**KEEP:**
+- #514 (ARM GCC hard float) - Tested, still fails with `-mfloat-abi=hard` on 6 ARM GCC versions
+
+**CLOSE:**
+- Issues that were already fixed but not closed
+- Issues with trivial workarounds
+
+---
+
+## 5. Internal Tasks & Reminders
+
+### CLOSE if:
+- ❌ 6+ year old reminder with no action taken
+- ❌ Decision was implicitly made (kept the code/feature)
+- ❌ No longer relevant to current codebase
+
+### Examples:
+
+**CLOSE:**
+- #1357 (binutils-multi reminder) - 6.5 years old, still installed, serves a purpose
+- Accidental duplicates from batch operations
+
+---
+
+## 6. Related vs Duplicate Issues
+
+### Not Duplicates if:
+- Issues address different aspects of the same problem
+- One is prerequisite for the other
+- Different implementation approaches
+
+### Duplicates if:
+- Identical title and description
+- Same request posted multiple times
+- Accidental double-posts
+
+### Examples:
+
+**Related (NOT duplicates):**
+- #297 (fix filter bug) + #1004 (add UI button) - Related but distinct
+
+**Duplicates (CLOSE):**
+- #3201, #7778, #8111 - All requesting NumPy
+- #4336, #6526 - Both requesting Groovy
+- #3426, #5972 - Both requesting OpenBLAS
+- #7601, #7602 - Accidental double-post
+
+---
+
+## 7. Labeling Strategy
+
+### Add "help wanted" when:
+- Valid request but maintainer doesn't have time
+- Clear scope, would accept PRs
+- Not marked "probably-wont-happen"
+
+### Keep "probably-wont-happen" when:
+- Low priority but PRs would still be accepted
+- Niche use case
+- High complexity/low demand
+
+### Remove "probably-wont-happen" when:
+- Recent interest or demand emerges
+- Project confirmed active and relevant
+- Better candidate for "help wanted"
+
+---
+
+## 8. Label Changes Made
+
+### Reviewed Issues - Actions Taken:
+
+| Issue | Action | Labels | Reason |
+|-------|--------|--------|--------|
+| #264 | KEEP | Remove probably-wont-happen | CE supports interpreted languages |
+| #187 | KEEP | Add help wanted | Recent CppCon interest |
+| #503 | KEEP | Add help wanted | Active project, PRs welcome |
+| #341 | KEEP | Add help wanted | User interest confirmed |
+| #514 | KEEP | Remove probably-wont-happen | Bug still exists, affects 6 versions |
+| #547 | CLOSE | - | Not a good fit |
+| #797 | CLOSE | - | Encourages bad practices |
+| #297 | KEEP | Add bug/usability | Filter breaks verbose-asm |
+| #1004 | KEEP | Link to #297 | UI convenience, related to #297 |
+| #1018 | CLOSE | - | Satisfied by alternative compilers |
+| #2063 | CLOSE | - | Abandoned upstream |
+| #425 | KEEP | Add help wanted | Active project |
+| #668 | CLOSE | - | Zero demand, very niche |
+| #1203 | CLOSE | - | Works externally already |
+| #1232 | KEEP | Add help wanted | Legitimate library |
+| #1357 | CLOSE | - | Stale reminder, implicitly resolved |
+| #7778 | CLOSE | Duplicate of #3201 | NumPy duplicate |
+| #8111 | CLOSE | Duplicate of #3201 | NumPy duplicate |
+| #5972 | CLOSE | Duplicate of #3426 | OpenBLAS duplicate |
+| #6526 | CLOSE | Duplicate of #4336 | Groovy duplicate |
+| #7601 | CLOSE | Duplicate of #7602 | Accidental duplicate |
+
+---
+
+## 9. Triage Process Recommendations
+
+### Monthly Triage Workflow:
+1. **Identify duplicates** (automated similarity matching)
+2. **Check upstream status** for compiler/library requests (last commit date)
+3. **Test bugs** using Compiler Explorer MCP
+4. **Review engagement** (comments, reactions, recent activity)
+5. **Apply labels** (help wanted, good first issue, etc.)
+6. **Close obvious cases** (duplicates, abandoned projects, stale reminders)
+
+### Tools Used:
+- GitHub API for bulk data extraction
+- Python scripts for similarity analysis
+- Compiler Explorer MCP for live testing
+- Web search for upstream project status
+
+---
+
+## 10. Communication Templates
+
+### Closing Duplicates:
+```
+Closing as duplicate of #XXXX which has more discussion/history.
+Please follow that issue for updates.
+```
+
+### Closing Abandoned Projects:
+```
+Closing as the upstream project appears abandoned (last commit [date]).
+If the project becomes active again, please feel free to reopen or create a new issue.
+```
+
+### Closing External Tools:
+```
+Closing as this tool already works externally using Compiler Explorer's public API.
+Integration would not provide significant additional value.
+See: [tool URL]
+```
+
+### Keeping with "help wanted":
+```
+This is a valid request but requires a contributor with expertise in [area].
+Marking as "help wanted" - PRs are welcome!
+```
+
+---
+
+## Statistics from This Triage Session
+
+- **Issues reviewed**: 22
+- **Issues to close**: 12 (5 duplicates + 7 other)
+- **Issues to keep**: 10
+- **"help wanted" added**: 5
+- **Relationships identified**: 1 pair (#297 + #1004)
+
+**Impact**:
+- Closed duplicates: -5 issues
+- Closed abandoned/unviable: -7 issues
+- Net reduction: -12 issues (~1.4% of 855 total)
+- Better organized: 10 issues now have clearer status
+
+---
+
+## Next Steps
+
+1. Apply label changes to reviewed issues
+2. Close duplicates with appropriate comments
+3. Close abandoned/stale issues with appropriate comments
+4. Link related issues (#297 ↔ #1004)
+5. Continue triage with next batch of issues
+6. Update this document as new patterns emerge
diff --git a/etc/scripts/gh_tool/pyproject.toml b/etc/scripts/gh_tool/pyproject.toml
new file mode 100644
index 00000000000..3968cec9249
--- /dev/null
+++ b/etc/scripts/gh_tool/pyproject.toml
@@ -0,0 +1,38 @@
+[build-system]
+requires = ["setuptools>=61.0"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "compiler-explorer-gh-tool"
+version = "0.0.1"
+description = "GitHub automation tool for Compiler Explorer"
+requires-python = ">=3.12"
+dependencies = [
+ "anthropic>=0.40.0",
+ "click>=8.1.0",
+ "pytest>=8.0.0",
+ "python-dotenv>=1.0.0",
+ "ruff>=0.8.0",
+]
+
+[project.scripts]
+gh_tool = "gh_tool.cli:main"
+
+[tool.uv]
+package = true
+
+[tool.ruff]
+line-length = 120
+target-version = "py312"
+
+[tool.ruff.lint]
+select = [
+ "E", # pycodestyle errors
+ "W", # pycodestyle warnings
+ "F", # pyflake
+ "I", # isort
+ "UP", # pyupgrade
+]
+ignore = [
+ "E501", # line length
+]
diff --git a/etc/scripts/gh_tool/src/gh_tool/__init__.py b/etc/scripts/gh_tool/src/gh_tool/__init__.py
new file mode 100644
index 00000000000..1b917703e7f
--- /dev/null
+++ b/etc/scripts/gh_tool/src/gh_tool/__init__.py
@@ -0,0 +1,3 @@
+"""GitHub automation tools for Compiler Explorer."""
+
+__version__ = "0.0.1"
diff --git a/etc/scripts/gh_tool/src/gh_tool/ai_duplicate_analyzer.py b/etc/scripts/gh_tool/src/gh_tool/ai_duplicate_analyzer.py
new file mode 100644
index 00000000000..ad56339ac74
--- /dev/null
+++ b/etc/scripts/gh_tool/src/gh_tool/ai_duplicate_analyzer.py
@@ -0,0 +1,148 @@
+"""AI-powered duplicate issue detection using Claude."""
+
+import os
+from typing import Any
+
+import click
+from anthropic import Anthropic
+from dotenv import load_dotenv
+
+# Load environment variables from .env file
+load_dotenv()
+
+
+def get_anthropic_client() -> Anthropic | None:
+ """Get Anthropic client if API key is available."""
+ api_key = os.getenv("ANTHROPIC_API_KEY")
+ if not api_key:
+ return None
+ return Anthropic(api_key=api_key)
+
+
+def analyze_duplicate_group(issues: list[dict[str, Any]], client: Anthropic) -> dict[str, Any]:
+ """Use AI to determine if a group of issues are truly duplicates.
+
+ Args:
+ issues: List of issue dictionaries with at least 'number' and 'title' fields
+ client: Anthropic client instance
+
+ Returns:
+ dict with:
+ - is_duplicate: bool - whether issues are duplicates
+ - confidence: float - confidence score 0-1
+ - reasoning: str - explanation of the decision
+ """
+ # Format issues for the prompt
+ issue_list = "\n".join(f"- Issue #{issue['number']}: {issue['title']}" for issue in issues)
+
+ prompt = f"""You are analyzing GitHub issues to determine if they are EXACT duplicates.
+
+Issues to analyze:
+{issue_list}
+
+STRICT RULES for duplicates:
+1. Different named tools/libraries are DIFFERENT: "fasm" ≠ "YASM" ≠ "AsmX" (even if all assemblers)
+2. Similar categories are NOT duplicates: requesting different compilers/libraries/languages is NOT a duplicate
+3. Related features are NOT duplicates: "language tooltips" ≠ "language detection" (different features)
+4. Only spelling/capitalization variants are duplicates: "NumPy" = "numpy", "Forth" = "FORTH"
+
+EXAMPLES:
+✓ DUPLICATE: "Add NumPy" + "Add numpy" (same library, different case)
+✓ DUPLICATE: "GCC 13" + "GCC 13.1" (same compiler, version variants)
+✗ NOT DUPLICATE: "fasm" + "YASM" (different assemblers, even though both are assemblers)
+✗ NOT DUPLICATE: "OpenBLAS" + "OpenSSL" (different libraries starting with "Open")
+✗ NOT DUPLICATE: "ARM execution" + "EWARM execution" (EWARM is specific toolchain, not general ARM)
+✗ NOT DUPLICATE: "language tooltips" + "language detection" (different features in same domain)
+
+Be VERY strict. Only mark as duplicate if they request the EXACT SAME thing with minor spelling/version variations.
+
+Respond in JSON format:
+{{
+ "is_duplicate": true/false,
+ "confidence": 0.0-1.0,
+ "reasoning": "brief explanation"
+}}"""
+
+ try:
+ response = client.messages.create(
+ model="claude-sonnet-4-20250514",
+ max_tokens=2000,
+ messages=[{"role": "user", "content": prompt}],
+ )
+
+ # Parse the response
+ content = response.content[0].text.strip()
+
+ # Debug logging for empty responses
+ if not content:
+ click.echo(f" Warning: Empty response from AI for group with {len(issues)} issues", err=True)
+ return {"is_duplicate": False, "confidence": 0.0, "reasoning": "Empty AI response"}
+
+ # Try to extract JSON from the response
+ import json
+
+ # Find JSON block if wrapped in markdown
+ if "```json" in content:
+ content = content.split("```json")[1].split("```")[0].strip()
+ elif "```" in content:
+ content = content.split("```")[1].split("```")[0].strip()
+
+ result = json.loads(content)
+ return {
+ "is_duplicate": result.get("is_duplicate", False),
+ "confidence": result.get("confidence", 0.0),
+ "reasoning": result.get("reasoning", ""),
+ }
+
+ except json.JSONDecodeError as e:
+ click.echo(f" Warning: Invalid JSON from AI (group size: {len(issues)})", err=True)
+ click.echo(f" First 200 chars of response: {content[:200] if content else '(empty)'}...", err=True)
+ return {"is_duplicate": False, "confidence": 0.0, "reasoning": f"JSON parse error: {e}"}
+ except Exception as e:
+ click.echo(f" Warning: AI analysis failed: {e}", err=True)
+ # On error, assume it's not a duplicate to avoid false positives
+ return {"is_duplicate": False, "confidence": 0.0, "reasoning": f"Error: {e}"}
+
+
+def filter_groups_with_ai(groups: list[dict[str, Any]], min_confidence: float = 0.7) -> list[dict[str, Any]]:
+ """Filter duplicate groups using AI analysis.
+
+ Args:
+ groups: List of duplicate groups from broadphase detection
+ min_confidence: Minimum confidence score to keep a group (default 0.7)
+
+ Returns:
+ Filtered list of groups that AI confirms are duplicates
+ """
+ client = get_anthropic_client()
+ if not client:
+ click.echo("Warning: ANTHROPIC_API_KEY not found in environment or .env file", err=True)
+ click.echo("Skipping AI analysis, returning all groups", err=True)
+ return groups
+
+ click.echo(f"Analyzing {len(groups)} groups with AI...", err=True)
+
+ filtered_groups = []
+ for idx, group in enumerate(groups, 1):
+ num_issues = len(group["issues"])
+ click.echo(f" Analyzing group {idx}/{len(groups)} ({num_issues} issues)...", err=True)
+
+ # Warn about very large groups
+ if num_issues > 20:
+ click.echo(f" ⚠ Large group ({num_issues} issues) - this may be expensive", err=True)
+
+ result = analyze_duplicate_group(group["issues"], client)
+
+ if result["is_duplicate"] and result["confidence"] >= min_confidence:
+ # Add AI metadata to the group
+ group["ai_analysis"] = result
+ filtered_groups.append(group)
+ click.echo(f" ✓ Duplicate (confidence: {result['confidence']:.2f})", err=True)
+ else:
+ click.echo(
+ f" ✗ Not duplicate (confidence: {result['confidence']:.2f}): {result['reasoning']}",
+ err=True,
+ )
+
+ click.echo(f"AI filtering: {len(groups)} → {len(filtered_groups)} groups", err=True)
+ return filtered_groups
diff --git a/etc/scripts/gh_tool/src/gh_tool/cli.py b/etc/scripts/gh_tool/src/gh_tool/cli.py
new file mode 100644
index 00000000000..188632d752f
--- /dev/null
+++ b/etc/scripts/gh_tool/src/gh_tool/cli.py
@@ -0,0 +1,96 @@
+#!/usr/bin/env python3
+"""CLI for GitHub automation tools for Compiler Explorer."""
+
+import click
+
+from gh_tool.ai_duplicate_analyzer import filter_groups_with_ai
+from gh_tool.duplicate_finder import fetch_issues, find_duplicates, generate_report
+
+
+@click.group()
+def main():
+ """GitHub automation tools for Compiler Explorer."""
+ pass
+
+
+@main.command("find-duplicates")
+@click.argument("output_file", type=click.Path())
+@click.option(
+ "--threshold",
+ default=0.6,
+ type=click.FloatRange(0, 1),
+ help="Similarity threshold between 0 and 1 (default: 0.6)",
+)
+@click.option(
+ "--state",
+ type=click.Choice(["all", "open", "closed"]),
+ default="open",
+ help="Issue state to check (default: open)",
+)
+@click.option(
+ "--min-age",
+ default=0,
+ type=int,
+ help="Only check issues older than N days (default: 0)",
+)
+@click.option(
+ "--limit",
+ default=1000,
+ type=int,
+ help="Maximum number of issues to fetch (default: 1000)",
+)
+@click.option(
+ "--repo",
+ default="compiler-explorer/compiler-explorer",
+ type=str,
+ help="GitHub repository in owner/repo format (default: compiler-explorer/compiler-explorer)",
+)
+@click.option(
+ "--use-ai",
+ is_flag=True,
+ help="Use AI to refine duplicate detection (requires ANTHROPIC_API_KEY in .env)",
+)
+@click.option(
+ "--ai-confidence",
+ default=0.7,
+ type=click.FloatRange(0, 1),
+ help="Minimum AI confidence score to keep a group (default: 0.7)",
+)
+def find_duplicates_cmd(output_file, threshold, state, min_age, limit, repo, use_ai, ai_confidence):
+ """Find potential duplicate issues in the compiler-explorer repository.
+
+ OUTPUT_FILE is the path where the markdown report will be saved.
+
+ Examples:
+
+ \b
+ # Find duplicates in open issues
+ gh_tool find-duplicates /tmp/duplicates.md
+
+ \b
+ # High confidence matches only
+ gh_tool find-duplicates /tmp/report.md --threshold 0.85
+
+ \b
+ # Check all issues (including closed)
+ gh_tool find-duplicates /tmp/all.md --state all
+ """
+ # Fetch issues
+ click.echo(f"Fetching {state} issues...", err=True)
+ issues = fetch_issues(state, limit, repo)
+
+ # Find duplicates (broadphase)
+ click.echo(f"Analyzing {len(issues)} issues with threshold {threshold}...", err=True)
+ groups = find_duplicates(issues, threshold, min_age)
+
+ # Refine with AI if requested
+ if use_ai:
+ groups = filter_groups_with_ai(groups, ai_confidence)
+
+ # Generate report
+ generate_report(groups, output_file)
+ click.echo(f"Found {len(groups)} potential duplicate groups", err=True)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/etc/scripts/gh_tool/src/gh_tool/duplicate_finder.py b/etc/scripts/gh_tool/src/gh_tool/duplicate_finder.py
new file mode 100755
index 00000000000..84ed2326047
--- /dev/null
+++ b/etc/scripts/gh_tool/src/gh_tool/duplicate_finder.py
@@ -0,0 +1,163 @@
+"""Find potential duplicate issues in the compiler-explorer repository using text similarity."""
+
+import json
+import re
+import subprocess
+import sys
+from datetime import UTC, datetime, timedelta
+from difflib import SequenceMatcher
+from typing import Any
+
+import click
+
+# Compiled regex to strip [TAGS] from issue titles
+TAG_PATTERN = re.compile(r"\[.*?\]\s*")
+
+
+def fetch_issues(
+ state: str = "open", limit: int = 1000, repo: str = "compiler-explorer/compiler-explorer"
+) -> list[dict[str, Any]]:
+ """Fetch issues from GitHub using gh CLI."""
+ click.echo(f"Fetching {state} issues from {repo}...", err=True)
+
+ cmd = [
+ "gh",
+ "issue",
+ "list",
+ "--repo",
+ repo,
+ "--state",
+ state,
+ "--limit",
+ str(limit),
+ "--json",
+ "number,title,createdAt,updatedAt,state,labels,comments",
+ ]
+
+ try:
+ result = subprocess.run(cmd, capture_output=True, text=True, check=True)
+ issues = json.loads(result.stdout)
+ click.echo(f"Fetched {len(issues)} issues", err=True)
+ return issues
+ except subprocess.CalledProcessError as e:
+ click.echo(f"Error fetching issues: {e.stderr}", err=True)
+ raise click.Abort()
+ except json.JSONDecodeError as e:
+ click.echo(f"Error parsing JSON: {e}", err=True)
+ raise click.Abort()
+
+
+def calculate_similarity(title1: str, title2: str) -> float:
+ """Calculate similarity ratio between two titles using SequenceMatcher.
+
+ Strips [TAGS] before comparing to avoid false positives from shared prefixes
+ like [LIB REQUEST], [COMPILER REQUEST], etc.
+ """
+ clean_title1 = TAG_PATTERN.sub("", title1)
+ clean_title2 = TAG_PATTERN.sub("", title2)
+ return SequenceMatcher(None, clean_title1.lower(), clean_title2.lower()).ratio()
+
+
+def find_duplicates(
+ issues: list[dict[str, Any]], threshold: float = 0.6, min_age_days: int = 0
+) -> list[dict[str, Any]]:
+ """Find potential duplicate issues based on title similarity."""
+ # Filter issues by age if requested
+ if min_age_days > 0:
+ cutoff_date = datetime.now(UTC) - timedelta(days=min_age_days)
+ issues = [
+ issue for issue in issues if datetime.fromisoformat(issue["createdAt"].replace("Z", "+00:00")) < cutoff_date
+ ]
+ click.echo(f"Filtered to {len(issues)} issues older than {min_age_days} days", err=True)
+
+ # Find similar pairs
+ duplicates: list[dict[str, Any]] = []
+ seen: set[tuple[int, int]] = set()
+ total_comparisons = len(issues) * (len(issues) - 1) // 2
+
+ click.echo(f"Comparing {len(issues)} issues ({total_comparisons:,} comparisons)...", err=True)
+
+ with click.progressbar(length=total_comparisons, label="Finding duplicates", file=sys.stderr) as bar:
+ for i, issue1 in enumerate(issues):
+ for j, issue2 in enumerate(issues[i + 1 :], start=i + 1):
+ bar.update(1)
+
+ # Skip if already grouped
+ pair = tuple(sorted([issue1["number"], issue2["number"]]))
+ if pair in seen:
+ continue
+
+ similarity = calculate_similarity(issue1["title"], issue2["title"])
+
+ if similarity >= threshold:
+ duplicates.append({"similarity": similarity, "issues": [issue1, issue2]})
+ seen.add(pair)
+
+ # Group similar issues together
+ groups: list[dict[str, Any]] = []
+
+ for dup in sorted(duplicates, key=lambda x: x["similarity"], reverse=True):
+ issue1, issue2 = dup["issues"]
+ num1, num2 = issue1["number"], issue2["number"]
+
+ # Find existing group containing either issue
+ found_group = None
+ for group in groups:
+ if num1 in [i["number"] for i in group["issues"]] or num2 in [i["number"] for i in group["issues"]]:
+ found_group = group
+ break
+
+ if found_group:
+ # Add to existing group if not already there
+ for issue in [issue1, issue2]:
+ if issue["number"] not in [i["number"] for i in found_group["issues"]]:
+ found_group["issues"].append(issue)
+ found_group["max_similarity"] = max(found_group["max_similarity"], dup["similarity"])
+ else:
+ # Create new group
+ groups.append({"issues": [issue1, issue2], "max_similarity": dup["similarity"]})
+
+ return groups
+
+
+def format_issue(issue: dict[str, Any]) -> str:
+ """Format issue for display."""
+ created = issue["createdAt"][:10]
+ state = issue["state"]
+ comment_count = len(issue.get("comments", []))
+
+ return f"- #{issue['number']} {issue['title']} ({comment_count} comments, {state}, created {created})"
+
+
+def generate_report(groups: list[dict[str, Any]], output_file: str) -> None:
+ """Generate markdown report of duplicate groups."""
+ output: list[str] = []
+ output.append("# Potential Duplicate Issues\n")
+
+ if not groups:
+ output.append("No potential duplicates found.\n")
+ else:
+ output.append(f"Found {len(groups)} potential duplicate groups:\n")
+
+ for idx, group in enumerate(sorted(groups, key=lambda x: x["max_similarity"], reverse=True), 1):
+ similarity_pct = int(group["max_similarity"] * 100)
+
+ # Add AI analysis if available
+ if "ai_analysis" in group:
+ ai = group["ai_analysis"]
+ confidence_pct = int(ai["confidence"] * 100)
+ output.append(f"## Group {idx} ({similarity_pct}% similar) - AI Confidence: {confidence_pct}%\n")
+ output.append(f"\n**AI Analysis:** {ai['reasoning']}\n")
+ else:
+ output.append(f"## Group {idx} ({similarity_pct}% similar)\n")
+
+ for issue in sorted(group["issues"], key=lambda x: x["createdAt"]):
+ output.append(format_issue(issue) + "\n")
+
+ output.append("\n")
+
+ report = "\n".join(output)
+
+ with open(output_file, "w") as f:
+ f.write(report)
+ click.echo(f"Report saved to {output_file}", err=True)
diff --git a/etc/scripts/gh_tool/tests/test_duplicate_finder.py b/etc/scripts/gh_tool/tests/test_duplicate_finder.py
new file mode 100644
index 00000000000..e57810eb98e
--- /dev/null
+++ b/etc/scripts/gh_tool/tests/test_duplicate_finder.py
@@ -0,0 +1,192 @@
+# Copyright (c) 2025, Compiler Explorer Authors
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# * Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+
+import tempfile
+from datetime import UTC, datetime, timedelta
+from pathlib import Path
+
+import pytest
+
+from gh_tool.duplicate_finder import calculate_similarity, find_duplicates, generate_report
+
+
+def make_issue(number, title, created_at=None, comments=None):
+ """Helper to create test issue data."""
+ if created_at is None:
+ created_at = datetime.now(UTC).isoformat()
+ if comments is None:
+ comments = []
+
+ return {
+ "number": number,
+ "title": title,
+ "createdAt": created_at,
+ "updatedAt": created_at,
+ "state": "open",
+ "labels": [],
+ "comments": comments,
+ }
+
+
+class TestCalculateSimilarity:
+ @pytest.mark.parametrize(
+ "title1,title2,expected_min,expected_max",
+ [
+ # Identical strings
+ ("Add GCC 13", "Add GCC 13", 1.0, 1.0),
+ # Case insensitive
+ ("Add GCC 13", "add gcc 13", 1.0, 1.0),
+ # Completely different
+ ("Add GCC 13", "Python bug", 0.0, 0.3),
+ # Similar titles with different case
+ ("[LIB REQUEST] numpy", "[LIB REQUEST] NumPy", 0.9, 1.0),
+ # Partial similarity
+ ("Add GCC 13 support", "Add GCC 14 support", 0.7, 1.0),
+ # Different request types but same content (tags stripped)
+ ("[COMPILER REQUEST] foo", "[LIB REQUEST] foo", 1.0, 1.0),
+ ],
+ )
+ def test_similarity_calculation(self, title1, title2, expected_min, expected_max):
+ similarity = calculate_similarity(title1, title2)
+ assert expected_min <= similarity <= expected_max
+
+
+class TestFindDuplicates:
+ def test_no_duplicates(self):
+ issues = [
+ make_issue(1, "Add GCC 13"),
+ make_issue(2, "Fix Python bug"),
+ make_issue(3, "Update documentation"),
+ ]
+ groups = find_duplicates(issues, threshold=0.6)
+ assert len(groups) == 0
+
+ def test_simple_duplicate_pair(self):
+ issues = [
+ make_issue(1, "Add NumPy library"),
+ make_issue(2, "Add numpy library"),
+ ]
+ groups = find_duplicates(issues, threshold=0.8)
+ assert len(groups) == 1
+ assert len(groups[0]["issues"]) == 2
+ assert groups[0]["issues"][0]["number"] in [1, 2]
+ assert groups[0]["issues"][1]["number"] in [1, 2]
+
+ def test_multiple_duplicate_groups(self):
+ issues = [
+ make_issue(1, "Add GCC 13"),
+ make_issue(2, "Add gcc 13"),
+ make_issue(3, "Add Clang 17"),
+ make_issue(4, "Add clang 17"),
+ make_issue(5, "Fix bug"),
+ ]
+ groups = find_duplicates(issues, threshold=0.85)
+ assert len(groups) == 2
+
+ def test_transitive_grouping(self):
+ # If A~B and B~C, they should all be in one group
+ issues = [
+ make_issue(1, "Add NumPy"),
+ make_issue(2, "Add numpy"),
+ make_issue(3, "Add NumPy library"),
+ ]
+ groups = find_duplicates(issues, threshold=0.7)
+ # Should be grouped together transitively
+ assert len(groups) >= 1
+ # At least one group should have all 3 issues
+ max_group_size = max(len(g["issues"]) for g in groups)
+ assert max_group_size >= 2
+
+ def test_age_filtering(self):
+ now = datetime.now(UTC)
+ old_date = (now - timedelta(days=100)).isoformat()
+ recent_date = (now - timedelta(days=5)).isoformat()
+
+ issues = [
+ make_issue(1, "Add NumPy", created_at=old_date),
+ make_issue(2, "Add numpy", created_at=recent_date),
+ ]
+
+ # Filter to only old issues (>30 days)
+ groups = find_duplicates(issues, threshold=0.8, min_age_days=30)
+ # Should only have one issue in the comparison, so no duplicates found
+ assert len(groups) == 0
+
+ # No age filter should find the duplicate
+ groups = find_duplicates(issues, threshold=0.8, min_age_days=0)
+ assert len(groups) == 1
+
+ def test_threshold_sensitivity(self):
+ issues = [
+ make_issue(1, "Add GCC 13 compiler"),
+ make_issue(2, "Add GCC 14 compiler"),
+ ]
+
+ # Low threshold should find similarity
+ groups = find_duplicates(issues, threshold=0.6)
+ assert len(groups) == 1
+
+ # Very high threshold should not
+ groups = find_duplicates(issues, threshold=0.99)
+ assert len(groups) == 0
+
+
+class TestGenerateReport:
+ def test_empty_report(self):
+ with tempfile.NamedTemporaryFile(mode="w", delete=False, suffix=".md") as f:
+ output_file = f.name
+
+ try:
+ generate_report([], output_file)
+ content = Path(output_file).read_text()
+ assert "No potential duplicates found" in content
+ finally:
+ Path(output_file).unlink()
+
+ def test_report_with_groups(self):
+ groups = [
+ {
+ "issues": [
+ make_issue(1, "Add NumPy", created_at="2020-01-01T00:00:00Z"),
+ make_issue(2, "Add numpy", created_at="2020-01-02T00:00:00Z"),
+ ],
+ "max_similarity": 0.95,
+ }
+ ]
+
+ with tempfile.NamedTemporaryFile(mode="w", delete=False, suffix=".md") as f:
+ output_file = f.name
+
+ try:
+ generate_report(groups, output_file)
+ content = Path(output_file).read_text()
+
+ assert "# Potential Duplicate Issues" in content
+ assert "Found 1 potential duplicate groups" in content
+ assert "## Group 1 (95% similar)" in content
+ assert "#1" in content
+ assert "#2" in content
+ assert "numpy" in content.lower()
+ finally:
+ Path(output_file).unlink()
diff --git a/etc/scripts/helion_wrapper.py b/etc/scripts/helion_wrapper.py
new file mode 100644
index 00000000000..fe56f03880b
--- /dev/null
+++ b/etc/scripts/helion_wrapper.py
@@ -0,0 +1,94 @@
+# Copyright (c) 2025, Compiler Explorer Authors
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# * Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+
+from __future__ import annotations
+
+import argparse
+import contextlib
+import importlib.util
+import sys
+
+
+def main() -> None:
+ parser = argparse.ArgumentParser(description="Output Triton code from public Helion kernels.")
+ parser.add_argument("--inputfile", required=True)
+ parser.add_argument("--outputfile", required=True)
+ args = parser.parse_args()
+
+ try:
+ import helion
+ from helion.runtime.kernel import Kernel
+
+ compiled_kernels: list[tuple[Kernel, object, str]] = []
+
+ # Patch kernel decorator to set autotune_effort='none' by default
+ original_kernel = helion.kernel
+
+ def patched_kernel(*args, **kwargs):
+ if 'config' not in kwargs and 'autotune_effort' not in kwargs:
+ kwargs['autotune_effort'] = 'none'
+ return original_kernel(*args, **kwargs)
+
+ helion.kernel = patched_kernel
+
+ original_call = Kernel.__call__
+
+ def patched_call(self, *call_args, **call_kwargs):
+ result = original_call(self, *call_args, **call_kwargs)
+
+ try:
+ bound = self.bind(call_args)
+ cfg = bound.config_spec.default_config()
+ triton_code = bound.to_triton_code(cfg)
+ compiled_kernels.append((self, call_args, triton_code))
+ except Exception:
+ pass
+
+ return result
+
+ Kernel.__call__ = patched_call
+
+ spec = importlib.util.spec_from_file_location("example", args.inputfile)
+ assert spec is not None and spec.loader is not None
+ mod = importlib.util.module_from_spec(spec)
+ spec.loader.exec_module(mod)
+
+ Kernel.__call__ = original_call
+
+ with open(args.outputfile, "w", encoding="utf-8") as out:
+ for kernel, args_used, triton_code in compiled_kernels:
+ out.write(triton_code)
+ out.write("\n\n")
+
+ except Exception as error:
+ messages = [m for m in (getattr(error, "args", None) or [str(error)])]
+ with contextlib.suppress(Exception):
+ sys.stderr.writelines([str(m) + "\n" for m in messages])
+ sys.exit(255)
+
+
+if __name__ == "__main__":
+ main()
+
+
diff --git a/etc/scripts/parsed-pug/package.json b/etc/scripts/parsed-pug/package.json
deleted file mode 100644
index 5bbefffbabe..00000000000
--- a/etc/scripts/parsed-pug/package.json
+++ /dev/null
@@ -1,3 +0,0 @@
-{
- "type": "commonjs"
-}
diff --git a/etc/scripts/shortlinkmigration/README.md b/etc/scripts/shortlinkmigration/README.md
new file mode 100644
index 00000000000..222ea944a3f
--- /dev/null
+++ b/etc/scripts/shortlinkmigration/README.md
@@ -0,0 +1,96 @@
+# Shortlink Migration Script
+
+This script migrates Compiler Explorer shortlinks from local file storage to AWS S3/DynamoDB.
+
+## Prerequisites
+
+- Python 3.8+
+- Poetry (for dependency management)
+- AWS credentials configured (via AWS CLI, environment variables, or IAM role)
+
+## Installation
+
+Install dependencies using Poetry:
+
+```bash
+cd etc/scripts/shortlinkmigration
+poetry install
+```
+
+## Usage
+
+### Dry Run (recommended first)
+```bash
+poetry run python migrate_shortlinks.py \
+ --local-storage-dir ./lib/storage/data/ \
+ --s3-bucket storage.godbolt.org \
+ --s3-prefix ce/ \
+ --dynamodb-table links \
+ --aws-region us-east-1 \
+ --dry-run
+```
+
+### Actual Migration
+```bash
+poetry run python migrate_shortlinks.py \
+ --local-storage-dir ./lib/storage/data/ \
+ --s3-bucket storage.godbolt.org \
+ --s3-prefix ce/ \
+ --dynamodb-table links \
+ --aws-region us-east-1
+```
+
+### With Verification
+```bash
+poetry run python migrate_shortlinks.py \
+ --local-storage-dir ./lib/storage/data/ \
+ --s3-bucket storage.godbolt.org \
+ --s3-prefix ce/ \
+ --dynamodb-table links \
+ --aws-region us-east-1 \
+ --verify \
+ --verify-sample-size 20
+```
+
+## Options
+
+- `--local-storage-dir`: Path to local storage directory (required)
+- `--s3-bucket`: S3 bucket name (required)
+- `--s3-prefix`: S3 key prefix (optional, default: '')
+- `--dynamodb-table`: DynamoDB table name (required)
+- `--aws-region`: AWS region (required)
+- `--batch-size`: Number of files to process in each batch (default: 100)
+- `--verify`: Run verification after migration
+- `--verify-sample-size`: Number of random samples to verify (default: 10)
+- `--dry-run`: Simulate migration without making changes
+- `--verbose`: Enable detailed logging
+
+## How it Works
+
+1. **Loading**: Reads all files from local storage directory
+2. **Sorting**: Sorts files by creation time to preserve chronological order
+3. **Deduplication**: Checks if content already exists in DynamoDB
+4. **Collision Handling**: Extends subhash length if collisions occur (local uses 6+ chars, S3 uses 9+ chars)
+5. **Migration**:
+ - Uploads config to S3: `{prefix}/{fullHash}`
+ - Creates DynamoDB entry with metadata
+6. **Verification**: Optionally verifies random samples
+
+## Migration Details
+
+### Local Storage Structure
+- Files named by their unique subhash (minimum 6 characters)
+- Each file contains: `{prefix, uniqueSubHash, fullHash, config}`
+
+### S3/DynamoDB Structure
+- S3 key: `{s3_prefix}{6-char-prefix}/{fullHash}`
+- DynamoDB partition key: 6-character prefix
+- DynamoDB sort key: unique_subhash (minimum 9 characters)
+
+## Notes
+
+- The script preserves creation timestamps from file metadata
+- Existing entries are skipped (deduplication)
+- Collision resolution may result in longer subhashes
+- Progress is logged every batch_size entries
+- Errors are logged but don't stop the migration
\ No newline at end of file
diff --git a/etc/scripts/shortlinkmigration/migrate_shortlinks.py b/etc/scripts/shortlinkmigration/migrate_shortlinks.py
new file mode 100755
index 00000000000..6da30741c53
--- /dev/null
+++ b/etc/scripts/shortlinkmigration/migrate_shortlinks.py
@@ -0,0 +1,330 @@
+#!/usr/bin/env python3
+"""
+Migrate Compiler Explorer shortlinks from local storage to AWS S3/DynamoDB.
+
+Usage:
+ python migrate_shortlinks.py \
+ --local-storage-dir ./lib/storage/data/ \
+ --s3-bucket storage.godbolt.org \
+ --s3-prefix ce/ \
+ --dynamodb-table links \
+ --aws-region us-east-1 \
+ --dry-run
+"""
+
+import os
+import json
+import argparse
+import logging
+from datetime import datetime
+from pathlib import Path
+from typing import Dict, List, Tuple, Optional, Set
+import boto3
+from boto3.dynamodb.conditions import Key
+from dataclasses import dataclass
+from collections import defaultdict
+
+# Constants matching the TypeScript implementation
+PREFIX_LENGTH = 6 # NEVER CHANGE - DynamoDB partition key
+MIN_STORED_ID_LENGTH_S3 = 9 # Minimum for S3 storage
+MIN_STORED_ID_LENGTH_LOCAL = 6 # Minimum for local storage
+
+@dataclass
+class LocalShortlink:
+ """Represents a shortlink from local storage."""
+ file_path: Path
+ unique_subhash: str # The filename
+ full_hash: str
+ config: str
+ prefix: str
+ creation_time: datetime
+
+@dataclass
+class MigrationStats:
+ """Track migration statistics."""
+ total_files: int = 0
+ migrated: int = 0
+ already_exists: int = 0
+ collisions_resolved: int = 0
+ errors: int = 0
+ skipped: int = 0
+
+class ShortlinkMigrator:
+ def __init__(self, s3_bucket: str, s3_prefix: str, dynamodb_table: str,
+ region: str, dry_run: bool = False):
+ self.s3_bucket = s3_bucket
+ self.s3_prefix = s3_prefix.rstrip('/') + '/' if s3_prefix else ''
+ self.dynamodb_table = dynamodb_table
+ self.dry_run = dry_run
+ self.stats = MigrationStats()
+
+ if not dry_run:
+ self.s3_client = boto3.client('s3', region_name=region)
+ self.dynamodb = boto3.resource('dynamodb', region_name=region)
+ self.table = self.dynamodb.Table(dynamodb_table)
+
+ self.logger = logging.getLogger(__name__)
+
+ def load_local_shortlinks(self, storage_dir: Path) -> List[LocalShortlink]:
+ """Load all shortlinks from local storage, sorted by creation time."""
+ shortlinks = []
+
+ for file_path in storage_dir.iterdir():
+ if not file_path.is_file():
+ continue
+
+ try:
+ with open(file_path, 'r') as f:
+ data = json.load(f)
+
+ # Get file creation time
+ stat = file_path.stat()
+ creation_time = datetime.fromtimestamp(stat.st_ctime)
+
+ # The filename IS the uniqueSubHash
+ filename = file_path.name
+
+ # Validate that the stored uniqueSubHash matches filename
+ if data.get('uniqueSubHash') != filename:
+ self.logger.warning(
+ f"Filename {filename} doesn't match stored uniqueSubHash {data.get('uniqueSubHash')}"
+ )
+
+ shortlink = LocalShortlink(
+ file_path=file_path,
+ unique_subhash=filename,
+ full_hash=data['fullHash'],
+ config=data['config'],
+ prefix=data['prefix'],
+ creation_time=creation_time
+ )
+
+ shortlinks.append(shortlink)
+
+ except Exception as e:
+ self.logger.error(f"Error loading {file_path}: {e}")
+ self.stats.errors += 1
+
+ # Sort by creation time to maintain order
+ shortlinks.sort(key=lambda x: x.creation_time)
+ self.stats.total_files = len(shortlinks)
+
+ return shortlinks
+
+ def get_existing_subhashes_for_prefix(self, prefix: str) -> Dict[str, str]:
+ """Query DynamoDB for all existing subhashes with given prefix."""
+ if self.dry_run:
+ return {}
+
+ existing = {}
+ try:
+ response = self.table.query(
+ KeyConditionExpression=Key('prefix').eq(prefix),
+ ProjectionExpression='unique_subhash, full_hash'
+ )
+
+ for item in response.get('Items', []):
+ existing[item['unique_subhash']] = item['full_hash']
+
+ # Handle pagination
+ while 'LastEvaluatedKey' in response:
+ response = self.table.query(
+ KeyConditionExpression=Key('prefix').eq(prefix),
+ ProjectionExpression='unique_subhash, full_hash',
+ ExclusiveStartKey=response['LastEvaluatedKey']
+ )
+ for item in response.get('Items', []):
+ existing[item['unique_subhash']] = item['full_hash']
+
+ except Exception as e:
+ self.logger.error(f"Error querying DynamoDB for prefix {prefix}: {e}")
+
+ return existing
+
+ def find_unique_subhash_for_s3(self, full_hash: str, existing_subhashes: Dict[str, str],
+ original_subhash: str) -> str:
+ """
+ For migration, we must preserve the original subhash to maintain URL compatibility.
+ We only check if it already exists with the same content (deduplication).
+ """
+ # Check if the original subhash already exists
+ if original_subhash in existing_subhashes:
+ if existing_subhashes[original_subhash] == full_hash:
+ # Same content already exists - this is fine
+ return original_subhash
+ else:
+ # Different content with same subhash - this should never happen
+ # as it would mean a hash collision in the original system
+ raise ValueError(f"Hash collision detected for {original_subhash}!")
+
+ # Original subhash is unique, use it as-is
+ return original_subhash
+
+ def migrate_shortlink(self, shortlink: LocalShortlink,
+ prefix_cache: Dict[str, Dict[str, str]]) -> bool:
+ """Migrate a single shortlink to AWS."""
+ try:
+ # S3 storage uses first 6 characters of full hash as prefix
+ s3_prefix = shortlink.full_hash[:PREFIX_LENGTH]
+
+ # Get cached subhashes for this prefix, or query if not cached
+ if s3_prefix not in prefix_cache:
+ prefix_cache[s3_prefix] = self.get_existing_subhashes_for_prefix(s3_prefix)
+
+ existing_subhashes = prefix_cache[s3_prefix]
+
+ # Preserve the original subhash for migration
+ new_subhash = self.find_unique_subhash_for_s3(shortlink.full_hash, existing_subhashes,
+ shortlink.unique_subhash)
+
+ # Check if already exists with same content
+ if new_subhash in existing_subhashes and existing_subhashes[new_subhash] == shortlink.full_hash:
+ self.logger.info(f"Already exists: {shortlink.unique_subhash} -> {new_subhash}")
+ self.stats.already_exists += 1
+ return True
+
+ # Check for hash collision (should never happen in practice)
+ if new_subhash == shortlink.unique_subhash and new_subhash in existing_subhashes:
+ if existing_subhashes[new_subhash] != shortlink.full_hash:
+ self.logger.error(f"Hash collision detected for {new_subhash}")
+ self.stats.errors += 1
+ return False
+
+ # Perform migration
+ if not self.dry_run:
+ # S3 upload
+ s3_key = f"{self.s3_prefix}{shortlink.full_hash}"
+ self.s3_client.put_object(
+ Bucket=self.s3_bucket,
+ Key=s3_key,
+ Body=shortlink.config.encode('utf-8'),
+ ContentType='application/json'
+ )
+
+ # DynamoDB entry
+ self.table.put_item(
+ Item={
+ 'prefix': s3_prefix,
+ 'unique_subhash': new_subhash,
+ 'full_hash': shortlink.full_hash,
+ 'stats': {'clicks': 0},
+ 'creation_ip': 'migrated-from-local',
+ 'creation_date': shortlink.creation_time.isoformat()
+ }
+ )
+
+ # Update cache
+ existing_subhashes[new_subhash] = shortlink.full_hash
+
+ self.logger.info(f"Migrated: {shortlink.unique_subhash} -> {new_subhash}")
+ self.stats.migrated += 1
+ return True
+
+ except Exception as e:
+ self.logger.error(f"Error migrating {shortlink.unique_subhash}: {e}")
+ self.stats.errors += 1
+ return False
+
+ def run_migration(self, storage_dir: Path, batch_size: int = 100):
+ """Run the full migration process."""
+ self.logger.info(f"Starting migration from {storage_dir}")
+
+ # Load all shortlinks
+ shortlinks = self.load_local_shortlinks(storage_dir)
+ self.logger.info(f"Found {len(shortlinks)} shortlinks to migrate")
+
+ # Cache of existing subhashes per prefix to minimize DynamoDB queries
+ prefix_cache = {}
+
+ # Process in batches for logging
+ for i in range(0, len(shortlinks), batch_size):
+ batch = shortlinks[i:i + batch_size]
+ self.logger.info(f"Processing batch {i // batch_size + 1} ({i+1}-{i + len(batch)} of {len(shortlinks)})")
+
+ for shortlink in batch:
+ self.migrate_shortlink(shortlink, prefix_cache)
+
+ # Print summary
+ self.print_summary()
+
+ def verify_migration(self, storage_dir: Path, sample_size: int = 10):
+ """Verify a sample of migrated links."""
+ if self.dry_run:
+ return
+
+ self.logger.info(f"\nVerifying migration (sample size: {sample_size})")
+
+ shortlinks = self.load_local_shortlinks(storage_dir)
+ import random
+ sample = random.sample(shortlinks, min(sample_size, len(shortlinks)))
+
+ verified = 0
+ for shortlink in sample:
+ try:
+ # Check S3
+ s3_key = f"{self.s3_prefix}{shortlink.full_hash}"
+
+ response = self.s3_client.get_object(Bucket=self.s3_bucket, Key=s3_key)
+ s3_config = response['Body'].read().decode('utf-8')
+
+ if s3_config == shortlink.config:
+ self.logger.info(f"✓ Verified {shortlink.unique_subhash}")
+ verified += 1
+ else:
+ self.logger.error(f"✗ Content mismatch for {shortlink.unique_subhash}")
+
+ except Exception as e:
+ self.logger.error(f"✗ Failed to verify {shortlink.unique_subhash}: {e}")
+
+ self.logger.info(f"Verified {verified}/{len(sample)} samples")
+
+ def print_summary(self):
+ """Print migration summary."""
+ print("\n=== Migration Summary ===")
+ print(f"Total files found: {self.stats.total_files}")
+ print(f"Successfully migrated: {self.stats.migrated}")
+ print(f"Already exists: {self.stats.already_exists}")
+ print(f"Collisions resolved: {self.stats.collisions_resolved}")
+ print(f"Errors: {self.stats.errors}")
+ print(f"Skipped: {self.stats.skipped}")
+ print(f"Dry run: {self.dry_run}")
+
+def main():
+ parser = argparse.ArgumentParser(description='Migrate Compiler Explorer shortlinks to AWS')
+ parser.add_argument('--local-storage-dir', required=True, help='Local storage directory')
+ parser.add_argument('--s3-bucket', required=True, help='S3 bucket name')
+ parser.add_argument('--s3-prefix', default='', help='S3 key prefix')
+ parser.add_argument('--dynamodb-table', required=True, help='DynamoDB table name')
+ parser.add_argument('--aws-region', required=True, help='AWS region')
+ parser.add_argument('--batch-size', type=int, default=100, help='Batch size for processing')
+ parser.add_argument('--verify', action='store_true', help='Verify migration with random samples')
+ parser.add_argument('--verify-sample-size', type=int, default=10, help='Number of samples to verify')
+ parser.add_argument('--dry-run', action='store_true', help='Perform dry run without writing')
+ parser.add_argument('--verbose', action='store_true', help='Enable verbose logging')
+
+ args = parser.parse_args()
+
+ # Setup logging
+ logging.basicConfig(
+ level=logging.DEBUG if args.verbose else logging.INFO,
+ format='%(asctime)s - %(levelname)s - %(message)s'
+ )
+
+ # Run migration
+ migrator = ShortlinkMigrator(
+ s3_bucket=args.s3_bucket,
+ s3_prefix=args.s3_prefix,
+ dynamodb_table=args.dynamodb_table,
+ region=args.aws_region,
+ dry_run=args.dry_run
+ )
+
+ storage_dir = Path(args.local_storage_dir)
+ migrator.run_migration(storage_dir, batch_size=args.batch_size)
+
+ # Optional verification
+ if args.verify and not args.dry_run:
+ migrator.verify_migration(storage_dir, args.verify_sample_size)
+
+if __name__ == '__main__':
+ main()
\ No newline at end of file
diff --git a/etc/scripts/shortlinkmigration/poetry.lock b/etc/scripts/shortlinkmigration/poetry.lock
new file mode 100644
index 00000000000..a3907f4e9cb
--- /dev/null
+++ b/etc/scripts/shortlinkmigration/poetry.lock
@@ -0,0 +1,204 @@
+# This file is automatically @generated by Poetry 2.1.3 and should not be changed by hand.
+
+[[package]]
+name = "boto3"
+version = "1.37.38"
+description = "The AWS SDK for Python"
+optional = false
+python-versions = ">=3.8"
+groups = ["main"]
+markers = "python_version < \"3.10\""
+files = [
+ {file = "boto3-1.37.38-py3-none-any.whl", hash = "sha256:b6d42803607148804dff82389757827a24ce9271f0583748853934c86310999f"},
+ {file = "boto3-1.37.38.tar.gz", hash = "sha256:88c02910933ab7777597d1ca7c62375f52822e0aa1a8e0c51b2598a547af42b2"},
+]
+
+[package.dependencies]
+botocore = ">=1.37.38,<1.38.0"
+jmespath = ">=0.7.1,<2.0.0"
+s3transfer = ">=0.11.0,<0.12.0"
+
+[package.extras]
+crt = ["botocore[crt] (>=1.21.0,<2.0a0)"]
+
+[[package]]
+name = "boto3"
+version = "1.39.4"
+description = "The AWS SDK for Python"
+optional = false
+python-versions = ">=3.9"
+groups = ["main"]
+markers = "python_version >= \"3.10\""
+files = [
+ {file = "boto3-1.39.4-py3-none-any.whl", hash = "sha256:f8e9534b429121aa5c5b7c685c6a94dd33edf14f87926e9a182d5b50220ba284"},
+ {file = "boto3-1.39.4.tar.gz", hash = "sha256:6c955729a1d70181bc8368e02a7d3f350884290def63815ebca8408ee6d47571"},
+]
+
+[package.dependencies]
+botocore = ">=1.39.4,<1.40.0"
+jmespath = ">=0.7.1,<2.0.0"
+s3transfer = ">=0.13.0,<0.14.0"
+
+[package.extras]
+crt = ["botocore[crt] (>=1.21.0,<2.0a0)"]
+
+[[package]]
+name = "botocore"
+version = "1.37.38"
+description = "Low-level, data-driven core of boto 3."
+optional = false
+python-versions = ">=3.8"
+groups = ["main"]
+markers = "python_version < \"3.10\""
+files = [
+ {file = "botocore-1.37.38-py3-none-any.whl", hash = "sha256:23b4097780e156a4dcaadfc1ed156ce25cb95b6087d010c4bb7f7f5d9bc9d219"},
+ {file = "botocore-1.37.38.tar.gz", hash = "sha256:c3ea386177171f2259b284db6afc971c959ec103fa2115911c4368bea7cbbc5d"},
+]
+
+[package.dependencies]
+jmespath = ">=0.7.1,<2.0.0"
+python-dateutil = ">=2.1,<3.0.0"
+urllib3 = {version = ">=1.25.4,<1.27", markers = "python_version < \"3.10\""}
+
+[package.extras]
+crt = ["awscrt (==0.23.8)"]
+
+[[package]]
+name = "botocore"
+version = "1.39.4"
+description = "Low-level, data-driven core of boto 3."
+optional = false
+python-versions = ">=3.9"
+groups = ["main"]
+markers = "python_version >= \"3.10\""
+files = [
+ {file = "botocore-1.39.4-py3-none-any.whl", hash = "sha256:c41e167ce01cfd1973c3fa9856ef5244a51ddf9c82cb131120d8617913b6812a"},
+ {file = "botocore-1.39.4.tar.gz", hash = "sha256:e662ac35c681f7942a93f2ec7b4cde8f8b56dd399da47a79fa3e370338521a56"},
+]
+
+[package.dependencies]
+jmespath = ">=0.7.1,<2.0.0"
+python-dateutil = ">=2.1,<3.0.0"
+urllib3 = {version = ">=1.25.4,<2.2.0 || >2.2.0,<3", markers = "python_version >= \"3.10\""}
+
+[package.extras]
+crt = ["awscrt (==0.23.8)"]
+
+[[package]]
+name = "jmespath"
+version = "1.0.1"
+description = "JSON Matching Expressions"
+optional = false
+python-versions = ">=3.7"
+groups = ["main"]
+files = [
+ {file = "jmespath-1.0.1-py3-none-any.whl", hash = "sha256:02e2e4cc71b5bcab88332eebf907519190dd9e6e82107fa7f83b1003a6252980"},
+ {file = "jmespath-1.0.1.tar.gz", hash = "sha256:90261b206d6defd58fdd5e85f478bf633a2901798906be2ad389150c5c60edbe"},
+]
+
+[[package]]
+name = "python-dateutil"
+version = "2.9.0.post0"
+description = "Extensions to the standard Python datetime module"
+optional = false
+python-versions = "!=3.0.*,!=3.1.*,!=3.2.*,>=2.7"
+groups = ["main"]
+files = [
+ {file = "python-dateutil-2.9.0.post0.tar.gz", hash = "sha256:37dd54208da7e1cd875388217d5e00ebd4179249f90fb72437e91a35459a0ad3"},
+ {file = "python_dateutil-2.9.0.post0-py2.py3-none-any.whl", hash = "sha256:a8b2bc7bffae282281c8140a97d3aa9c14da0b136dfe83f850eea9a5f7470427"},
+]
+
+[package.dependencies]
+six = ">=1.5"
+
+[[package]]
+name = "s3transfer"
+version = "0.11.5"
+description = "An Amazon S3 Transfer Manager"
+optional = false
+python-versions = ">=3.8"
+groups = ["main"]
+markers = "python_version < \"3.10\""
+files = [
+ {file = "s3transfer-0.11.5-py3-none-any.whl", hash = "sha256:757af0f2ac150d3c75bc4177a32355c3862a98d20447b69a0161812992fe0bd4"},
+ {file = "s3transfer-0.11.5.tar.gz", hash = "sha256:8c8aad92784779ab8688a61aefff3e28e9ebdce43142808eaa3f0b0f402f68b7"},
+]
+
+[package.dependencies]
+botocore = ">=1.37.4,<2.0a.0"
+
+[package.extras]
+crt = ["botocore[crt] (>=1.37.4,<2.0a.0)"]
+
+[[package]]
+name = "s3transfer"
+version = "0.13.0"
+description = "An Amazon S3 Transfer Manager"
+optional = false
+python-versions = ">=3.9"
+groups = ["main"]
+markers = "python_version >= \"3.10\""
+files = [
+ {file = "s3transfer-0.13.0-py3-none-any.whl", hash = "sha256:0148ef34d6dd964d0d8cf4311b2b21c474693e57c2e069ec708ce043d2b527be"},
+ {file = "s3transfer-0.13.0.tar.gz", hash = "sha256:f5e6db74eb7776a37208001113ea7aa97695368242b364d73e91c981ac522177"},
+]
+
+[package.dependencies]
+botocore = ">=1.37.4,<2.0a.0"
+
+[package.extras]
+crt = ["botocore[crt] (>=1.37.4,<2.0a.0)"]
+
+[[package]]
+name = "six"
+version = "1.17.0"
+description = "Python 2 and 3 compatibility utilities"
+optional = false
+python-versions = "!=3.0.*,!=3.1.*,!=3.2.*,>=2.7"
+groups = ["main"]
+files = [
+ {file = "six-1.17.0-py2.py3-none-any.whl", hash = "sha256:4721f391ed90541fddacab5acf947aa0d3dc7d27b2e1e8eda2be8970586c3274"},
+ {file = "six-1.17.0.tar.gz", hash = "sha256:ff70335d468e7eb6ec65b95b99d3a2836546063f63acc5171de367e834932a81"},
+]
+
+[[package]]
+name = "urllib3"
+version = "1.26.20"
+description = "HTTP library with thread-safe connection pooling, file post, and more."
+optional = false
+python-versions = "!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*,!=3.5.*,>=2.7"
+groups = ["main"]
+markers = "python_version < \"3.10\""
+files = [
+ {file = "urllib3-1.26.20-py2.py3-none-any.whl", hash = "sha256:0ed14ccfbf1c30a9072c7ca157e4319b70d65f623e91e7b32fadb2853431016e"},
+ {file = "urllib3-1.26.20.tar.gz", hash = "sha256:40c2dc0c681e47eb8f90e7e27bf6ff7df2e677421fd46756da1161c39ca70d32"},
+]
+
+[package.extras]
+brotli = ["brotli (==1.0.9) ; os_name != \"nt\" and python_version < \"3\" and platform_python_implementation == \"CPython\"", "brotli (>=1.0.9) ; python_version >= \"3\" and platform_python_implementation == \"CPython\"", "brotlicffi (>=0.8.0) ; (os_name != \"nt\" or python_version >= \"3\") and platform_python_implementation != \"CPython\"", "brotlipy (>=0.6.0) ; os_name == \"nt\" and python_version < \"3\""]
+secure = ["certifi", "cryptography (>=1.3.4)", "idna (>=2.0.0)", "ipaddress ; python_version == \"2.7\"", "pyOpenSSL (>=0.14)", "urllib3-secure-extra"]
+socks = ["PySocks (>=1.5.6,!=1.5.7,<2.0)"]
+
+[[package]]
+name = "urllib3"
+version = "2.5.0"
+description = "HTTP library with thread-safe connection pooling, file post, and more."
+optional = false
+python-versions = ">=3.9"
+groups = ["main"]
+markers = "python_version >= \"3.10\""
+files = [
+ {file = "urllib3-2.5.0-py3-none-any.whl", hash = "sha256:e6b01673c0fa6a13e374b50871808eb3bf7046c4b125b216f6bf1cc604cff0dc"},
+ {file = "urllib3-2.5.0.tar.gz", hash = "sha256:3fc47733c7e419d4bc3f6b3dc2b4f890bb743906a30d56ba4a5bfa4bbff92760"},
+]
+
+[package.extras]
+brotli = ["brotli (>=1.0.9) ; platform_python_implementation == \"CPython\"", "brotlicffi (>=0.8.0) ; platform_python_implementation != \"CPython\""]
+h2 = ["h2 (>=4,<5)"]
+socks = ["pysocks (>=1.5.6,!=1.5.7,<2.0)"]
+zstd = ["zstandard (>=0.18.0)"]
+
+[metadata]
+lock-version = "2.1"
+python-versions = "^3.8"
+content-hash = "4e09272df41ec57d3ddd06955da68869fe8e94f0221623fd07e71d1dea191e76"
diff --git a/etc/scripts/shortlinkmigration/pyproject.toml b/etc/scripts/shortlinkmigration/pyproject.toml
new file mode 100644
index 00000000000..3aadf20bd9d
--- /dev/null
+++ b/etc/scripts/shortlinkmigration/pyproject.toml
@@ -0,0 +1,20 @@
+[tool.poetry]
+name = "shortlink-migration"
+version = "0.1.0"
+description = "Migrate Compiler Explorer shortlinks from local storage to AWS S3/DynamoDB"
+authors = ["Compiler Explorer Team"]
+readme = "README.md"
+package-mode = false
+
+[tool.poetry.dependencies]
+python = "^3.8"
+boto3 = "^1.26.0"
+
+[tool.poetry.group.dev.dependencies]
+
+[build-system]
+requires = ["poetry-core"]
+build-backend = "poetry.core.masonry.api"
+
+[tool.poetry.scripts]
+migrate-shortlinks = "migrate_shortlinks:main"
\ No newline at end of file
diff --git a/etc/scripts/test_triton_wrapper.py b/etc/scripts/test_triton_wrapper.py
new file mode 100644
index 00000000000..0745be87b4b
--- /dev/null
+++ b/etc/scripts/test_triton_wrapper.py
@@ -0,0 +1,156 @@
+# Copyright (c) 2025, Compiler Explorer Authors
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# * Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+
+import subprocess
+import tempfile
+from dataclasses import dataclass
+from pathlib import Path
+from typing import Tuple
+
+import pytest
+
+
+@dataclass(frozen=True)
+class Config:
+ version_tuple: Tuple[int, int, int]
+ backend: str
+ opt_pipeline: bool
+
+ @property
+ def python_path(self) -> Path:
+ version = f"v{'.'.join(str(v) for v in self.version_tuple)}"
+ return Path(f"/opt/compiler-explorer/triton/{version}/bin/python3")
+
+
+CONFIGS = [
+ Config(version_tuple=version_tuple, backend=backend, opt_pipeline=opt_pipeline)
+ for backend in ["cuda", "hip"]
+ for opt_pipeline in [True, False]
+ for version_tuple in [
+ (3, 4, 0),
+ (3, 3, 1),
+ (3, 3, 0),
+ (3, 2, 0),
+ (3, 1, 0),
+ (3, 0, 0),
+ (2, 3, 1),
+ (2, 3, 0),
+ ]
+ if (
+ not any(
+ [
+ # AMD support added in 3.0.0
+ (backend == "hip" and version_tuple < (3, 0, 0)),
+ # Opt pipeline support added in 3.3.0
+ (opt_pipeline and version_tuple < (3, 3, 0)),
+ ]
+ )
+ )
+]
+
+# Simple Triton example code for testing
+KERNEL_NAME = "store_kernel"
+EXAMPLE_CODE = """
+import torch
+import triton
+import triton.language as tl
+
+@triton.jit
+def store_kernel(ptr, val):
+ tl.store(ptr, val)
+
+x = torch.empty(1)
+store_kernel[(1,)](x, 1)
+"""
+
+
+@pytest.mark.parametrize("config", CONFIGS)
+def test_triton_wrapper(config: Config):
+ if not config.python_path.exists():
+ pytest.skip(f"Python interpreter not found: {config.python_path}")
+
+ # Create temporary files for testing
+ with tempfile.TemporaryDirectory() as temp_dir:
+ temp_dir_path = Path(temp_dir)
+
+ # Create example input file
+ input_file = temp_dir_path / "example.py"
+ with open(input_file, "w") as f:
+ f.write(EXAMPLE_CODE)
+
+ # Output files
+ output_file = temp_dir_path / "output.s"
+ opt_pipeline_file = temp_dir_path / "opt_pipeline.txt"
+
+ # Run triton_wrapper.py
+ script_path = Path(__file__).parent / "triton_wrapper.py"
+ cmd = [
+ str(config.python_path),
+ str(script_path),
+ str(input_file),
+ "--output_file",
+ str(output_file),
+ "--backend",
+ config.backend,
+ ]
+
+ if config.opt_pipeline:
+ cmd.append("--opt_pipeline")
+ cmd.append(str(opt_pipeline_file))
+
+ try:
+ subprocess.run(cmd, check=True, timeout=60)
+
+ if config.opt_pipeline:
+ # Check that the opt pipeline file was created
+ assert opt_pipeline_file.exists(), f"Opt pipeline file not created"
+ assert (
+ KERNEL_NAME in opt_pipeline_file.read_text()
+ ), f"Opt pipeline file does not contain kernel name: {KERNEL_NAME}"
+ else:
+ # Check that the output file was created
+ assert output_file.exists(), f"Output file not created"
+
+ # Check that the output file has content
+ output_content = output_file.read_text()
+ assert output_content, f"Output file is empty"
+
+ # Check for auxiliary files
+ files = list(temp_dir_path.iterdir())
+ exts = [".ttir", ".ttgir", ".llir", ".json"]
+ if config.backend == "hip":
+ exts.append(".amdgcn")
+ elif config.backend == "cuda":
+ exts.append(".ptx")
+ for ext in exts:
+ file = next((f for f in files if f.suffix == ext), None)
+ assert file is not None, f"Missing file with extension {ext}"
+ assert (
+ KERNEL_NAME in file.read_text()
+ ), f"File does not contain kernel name: {KERNEL_NAME}"
+
+ except subprocess.CalledProcessError:
+ pytest.fail(f"Error running triton_wrapper.py")
+ except subprocess.TimeoutExpired:
+ pytest.fail(f"Timeout running triton_wrapper.py")
diff --git a/etc/scripts/triton_wrapper.py b/etc/scripts/triton_wrapper.py
new file mode 100644
index 00000000000..8473ea3490e
--- /dev/null
+++ b/etc/scripts/triton_wrapper.py
@@ -0,0 +1,290 @@
+# Copyright (c) 2025, Compiler Explorer Authors
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# * Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+# notice, this list of conditions and the following disclaimer in the
+# documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+
+import argparse
+import importlib.util
+import json
+import os
+from pathlib import Path
+from typing import Dict, Optional, Union
+from unittest.mock import MagicMock
+
+import torch
+import triton
+from torch._subclasses.fake_tensor import FakeTensorMode
+
+
+class MockCacheManager(triton.runtime.cache.CacheManager):
+ """
+ A mock cache manager that dumps the intermediate files to a given output path.
+
+ There are various ways to dump the intermediate files:
+ 1. The most obvious way is to use the `TRITON_KERNEL_DUMP` & ``TRITON_DUMP_DIR`
+ environment variables. e.g.,
+ os.environ["TRITON_KERNEL_DUMP"] = "1"
+ os.environ["TRITON_DUMP_DIR"] = str(output_dir)
+ However, `TRITON_DUMP_DIR` is introduced in Triton v3.2.0 at
+ https://github.com/triton-lang/triton/commit/ca469d7b6b6def316b5f5ee6ad2bd19dcb840bd8,
+ and thus not available in older versions.
+
+ 2. The second attempt is to patch the `default_cache_dir` function. e.g.,
+ triton.runtime.cache.default_cache_dir = MagicMock(return_value=output_dir)
+ This is a bit hacky, and less flexible in terms of controlling the file output.
+ (In fact, Triton dumps the compiled kernels to a folder with a random name.)
+
+ 3. Another option is to use various hooks in Triton. e.g.,
+ triton.knobs.runtime.{jit_post_compile_hook,launch_enter_hook}
+ JITFunction.{compiled_hook,cache_hook}
+ This approach is taken by TritonParse(https://github.com/pytorch-labs/tritonparse),
+ but it does not support older versions of Triton prior to the following commits:
+ https://github.com/triton-lang/triton/commit/0e9267202532ed1709dcc12c636220cf239dc377,
+ https://github.com/triton-lang/triton/commit/850525276426fb9814399a8e0ee8fdf744229b02.
+
+ 4. The current apporach is to mock a `CacheManager` class. This is the most flexible
+ approach, and works for all versions of Triton.
+ """
+
+ output_file: Path
+
+ def __init__(self, key, override=False, dump=False):
+ self.dump = dump
+ # filename -> data
+ self.files = {}
+ # filename -> group dict
+ self.groups = {}
+ # current stage for a given kernel
+ self.stage = 0
+
+ def get_file(self, filename) -> Optional[str]:
+ return self.files.get(filename, None)
+
+ def put(self, data, filename, binary=True) -> str:
+ name = Path(filename).stem
+ suffix = Path(filename).suffix
+ binary = isinstance(data, bytes)
+ if not binary:
+ data = str(data)
+
+ # Write the final file to the output file, so that we can view it in the default assembly view.
+ if suffix in (".ptx", ".amdgcn"):
+ with open(MockCacheManager.output_file, "a") as f:
+ f.write(data)
+ f.write("\n\n")
+
+ # Write intermediate files to the output file, so that we can see them in the Device View.
+ self.stage += 1
+ if suffix == ".json":
+ path = MockCacheManager.output_file.parent / filename
+ with open(path, "w") as fout:
+ json.dump(json.loads(data), fout, indent=2)
+ else:
+ path = (
+ MockCacheManager.output_file.parent
+ / f"{name} [stage {self.stage}]{suffix}"
+ )
+ if not binary:
+ with open(path, "w") as fout:
+ fout.write(data)
+ elif suffix == ".cubin":
+ try:
+ # The try-catch is needed because `disasm` was broken in Triton v3.0.0 and v3.1.0. See
+ # https://github.com/triton-lang/triton/commit/f424f656b3528c47d8c48126cdccafca29e536ae
+ from triton.tools import disasm
+
+ with open(path.with_suffix(".sass"), "w") as fout:
+ fout.write(disasm.get_sass(data))
+ except Exception:
+ pass
+
+ # Write the file to the "cache"
+ self.files[filename] = data
+ return filename
+
+ def get_group(self, filename: str) -> Optional[Dict[str, str]]:
+ self.groups.get(filename, None)
+
+ def put_group(self, filename: str, group: Dict[str, str]):
+ self.groups[filename] = group
+
+
+def setup_triton(
+ output_file: Path,
+ opt_pipeline_file: Path,
+ backend: str,
+ arch: Union[int, str],
+ warp_size: int,
+):
+ """
+ Patch Triton to dump the compiled kernels to output dir without actually running them.
+
+ This is needed because
+ 1. Triton does not easily support such use case. There exists an AOT compiler at
+ https://github.com/triton-lang/triton/blob/main/python/triton/tools/compile.py,
+ but it requires a bunch of boilerplate code and also requires additional user
+ input to specify the kernel name, signature, etc.
+ 2. Even if Triton adds such support, older versions of Triton (e.g., v2.3.x) still
+ requirs such patching to work.
+
+ This function is a collection of hacks. It has been tested to work with Triton versions:
+ 2.3.0, 2.3.1, 3.0.0, 3.1.0, 3.2.0, 3.3.0, 3.3.1, 3.4.0.
+ """
+
+ os.environ["TRITON_ALWAYS_COMPILE"] = "1"
+ if opt_pipeline_file:
+ os.environ["MLIR_ENABLE_DUMP"] = "1"
+ # Supported in Triton v3.3.0 and later since
+ # https://github.com/triton-lang/triton/commit/3d7d9e33e7e4cba17dc366d207af2c657bd4fbd1
+ os.environ["MLIR_DUMP_PATH"] = str(opt_pipeline_file)
+ else:
+ # Disable dumping other files w/ opt_pipeline_file since they race with each other
+ os.environ["TRITON_CACHE_MANAGER"] = "__main__:MockCacheManager"
+ MockCacheManager.output_file = output_file
+
+ # Usually, Triton compiles and run a kernel when we call `kernel[grid](args)`.
+ # However, we want to dump the compiled kernel without actually running it.
+ # The class `CompiledKernel` represents a handle to a compiled kernel,
+ # ready to be launched. We patch it to be a no-op.
+ triton.compiler.compiler.CompiledKernel = MagicMock()
+
+ # We mock a GPU driver to avoid the need to initialize CUDA/ROCm.
+ # The driver is only used in runtime instead of compile time,
+ # so it's safe to do this.
+ def get_current_target():
+ try:
+ from triton.compiler.compiler import GPUTarget
+
+ return GPUTarget(backend=backend, arch=arch, warp_size=warp_size)
+ except ImportError:
+ # For Triton v2.3.x, we don't have GPUTarget
+ return (backend, arch)
+
+ mockGPUDriver = MagicMock(
+ get_current_target=get_current_target,
+ get_benchmarker=lambda: MagicMock(return_value=[0.0]),
+ )
+
+ # Set the active driver to the mocked one.
+ # `DriverConfig` and `triton.runtime.driver.set_active` is introduced in Triton v3.0.0 at
+ # https://github.com/triton-lang/triton/commit/b844d519bc5e86edf00fe6b3c6c2d1badcd509a4
+ # For older versions of Triton, we directly assign to the `_obj` field of `LazyProxy`.
+ try:
+ from triton.runtime.driver import DriverConfig
+
+ triton.runtime.driver.set_active(mockGPUDriver)
+ except ImportError:
+ triton.runtime.driver._obj = mockGPUDriver
+
+ # For Triton v2.3.x, there are some driver code that goes into
+ # the generic code path, so we need to patch it as well.
+ try:
+ from triton.compiler.backends.cuda import CUDABackend
+
+ CUDABackend.make_launcher_stub = MagicMock()
+ except ImportError:
+ pass
+
+ # Triton used to depends on the ld.lld binary, and search for the following paths:
+ # - TRITON_HIP_LLD_PATH (see https://github.com/triton-lang/triton/pull/3917)
+ # - third_party/amd/backend/llvm/bin/ld.lld (see https://github.com/triton-lang/triton/pull/3662)
+ # - /opt/rocm/llvm/bin/ld.lld
+ # - /usr/bin/ld.lld (see https://github.com/triton-lang/triton/pull/3197)
+ # However, none of them are available in the production environment, which causes
+ # Exception: ROCm linker /opt/rocm/llvm/bin/ld.lld not found. Set 'TRITON_HIP_LLD_PATH' to its path.
+ # Since the linker is only used to generate the binary .hsaco file (from the .amdgcn assembly),
+ # we don't really need it. We can just mock it to be a no-op.
+ # Note: Triton no longer depends on the ld.lld binary after v3.4.0 (exclusive) with commit:
+ # https://github.com/triton-lang/triton/pull/7548
+ os.environ["TRITON_HIP_LLD_PATH"] = "/bin/true"
+
+
+def main(
+ input_file: Path,
+ output_file: Path,
+ opt_pipeline_file: Path,
+ backend: str,
+ arch: Union[int, str],
+ warp_size: int,
+):
+ setup_triton(output_file, opt_pipeline_file, backend, arch, warp_size)
+
+ # Run the script by importing it as a module
+ spec = importlib.util.spec_from_file_location("example", input_file)
+ module = importlib.util.module_from_spec(spec)
+ with FakeTensorMode():
+ # Use FakeTensor (developed during Dynamo) to avoid actually creating tensors
+ # See https://docs.pytorch.org/docs/stable/torch.compiler_fake_tensor.html
+ # Also set the data_ptr to 0 to avoid PyTorch warning and make alignment check happy
+ torch._subclasses.FakeTensor.data_ptr = MagicMock(return_value=0)
+ spec.loader.exec_module(module)
+
+
+if __name__ == "__main__":
+ parser = argparse.ArgumentParser(description="Triton wrapper")
+ parser.add_argument(
+ "input_file",
+ type=Path,
+ help="Path to the input Python file",
+ )
+ parser.add_argument(
+ "--output_file",
+ type=Path,
+ required=True,
+ help="Path to the output file",
+ )
+ parser.add_argument(
+ "--opt_pipeline_file",
+ type=Path,
+ help="Path to the output opt pipeline file",
+ )
+ parser.add_argument(
+ "--backend",
+ type=str,
+ default="cuda",
+ choices=["cuda", "hip"],
+ )
+ parser.add_argument(
+ "--arch",
+ type=str,
+ default=None, # Default value set later based on backend
+ )
+ parser.add_argument(
+ "--warp_size",
+ type=int,
+ default=32,
+ )
+
+ args = parser.parse_args()
+
+ # Set some sane defaults for the arch
+ if args.arch is None:
+ if args.backend == "cuda":
+ args.arch = 90
+ elif args.backend == "hip":
+ args.arch = "gfx942"
+
+ # Triton expects the arch to be an int for CUDA and a string for HIP
+ if args.backend == "cuda":
+ args.arch = int(args.arch)
+
+ main(**vars(args))
diff --git a/etc/scripts/util/propscheck.py b/etc/scripts/util/propscheck.py
index 7182e060df0..aeb551941f4 100644
--- a/etc/scripts/util/propscheck.py
+++ b/etc/scripts/util/propscheck.py
@@ -32,6 +32,7 @@
parser = argparse.ArgumentParser(description='Checks for incorrect/suspicious properties.')
parser.add_argument ('--check-suspicious-in-default-prop', required=False, action="store_true")
parser.add_argument ('--config-dir', required=False, default="./etc/config")
+parser.add_argument ('--check-local', required=False, action="store_true")
PROP_RE = re.compile(r'([^# ]*)=(.*)#*')
@@ -108,6 +109,7 @@ def process_file(file: str, args: Namespace):
listed_groups = set()
seen_groups = set()
+ no_compilers_list = set()
listed_compilers = set()
seen_compilers_exe = set()
seen_compilers_id = set()
@@ -134,7 +136,7 @@ def process_file(file: str, args: Namespace):
duplicated_compiler_references = set()
duplicated_group_references = set()
- suspicious_check = args.check_suspicious_in_default_prop or not (file.endswith('.defaults.properties'))
+ suspicious_check = args.check_suspicious_in_default_prop or (not file.endswith('.defaults.properties') and not file.endswith('.local.properties'))
suspicious_path = set()
seen_typo_compilers = set()
@@ -235,7 +237,19 @@ def process_file(file: str, args: Namespace):
bad_tools_exe = listed_tools.symmetric_difference(seen_tools_exe)
bad_tools_id = listed_tools.symmetric_difference(seen_tools_id)
bad_default = default_compiler - listed_compilers
+
+ if len(listed_compilers) == 0 and len(listed_groups) == 0:
+ allowed = ('execution.','compiler-explorer.', 'aws.', 'asm-docs.', 'builtin.', '.defaults.')
+ is_allowed_to_be_empty = False
+ for allow in allowed:
+ if allow in file:
+ is_allowed_to_be_empty = True
+ break
+ if not is_allowed_to_be_empty:
+ no_compilers_list.add(file)
+
return {
+ "no_compilers_list": no_compilers_list,
"not_a_valid_prop": not_a_valid_prop,
"bad_compilers_exe": bad_compilers_exe - disabled,
"bad_compilers_id": bad_compilers_ids - disabled,
@@ -256,11 +270,17 @@ def process_file(file: str, args: Namespace):
}
def process_folder(folder: str, args):
- return [(f, process_file(join(folder, f), args))
- for f in listdir(folder)
- if isfile(join(folder, f))
- and not f.endswith('.local.properties')
- and f.endswith('.properties')]
+ if not args.check_local:
+ return [(f, process_file(join(folder, f), args))
+ for f in listdir(folder)
+ if isfile(join(folder, f))
+ and not f.endswith('.local.properties')
+ and f.endswith('.properties')]
+ else:
+ return [(f, process_file(join(folder, f), args))
+ for f in listdir(folder)
+ if isfile(join(folder, f))
+ and f.endswith('.properties')]
def problems_found(file_result):
return any(len(file_result[r]) > 0 for r in file_result if r != "filename")
@@ -271,9 +291,56 @@ def print_issue(name, result):
print(f"{name}:\n {sep.join(sorted([str(issue) for issue in result]))}")
-def find_orphans(args: Namespace):
+def check_cross_file_duplicates(folder: str):
+ """Check for compiler IDs that are defined in multiple Amazon files"""
+ from collections import defaultdict
+
+ compiler_id_locations = defaultdict(list)
+
+ for filename in listdir(folder):
+ if not filename.endswith('.properties') or filename.endswith('.local.properties'):
+ continue
+ if 'amazon' not in filename.lower():
+ continue
+
+ filepath = join(folder, filename)
+ with open(filepath, 'r') as f:
+ seen_compilers = set()
+
+ for line_num, text in enumerate(f, start=1):
+ text = text.strip()
+ if not text or text.startswith('#'):
+ continue
+
+ # Check for compiler IDs only
+ compiler_match = COMPILER_ID_RE.match(text)
+ if compiler_match:
+ compiler_id = compiler_match.group(1)
+ if compiler_id not in seen_compilers:
+ seen_compilers.add(compiler_id)
+ compiler_id_locations[compiler_id].append((filename, line_num))
+
+ duplicate_compiler_ids = {id: locs for id, locs in compiler_id_locations.items() if len(locs) > 1}
+
+ return duplicate_compiler_ids
+
+def find_orphans_and_duplicates(args: Namespace):
folder = args.config_dir
result = sorted([(f, r) for (f, r) in process_folder(folder, args) if problems_found(r)], key=lambda x: x[0])
+
+ duplicate_compiler_ids = check_cross_file_duplicates(folder)
+
+ has_cross_file_issues = False
+ if duplicate_compiler_ids:
+ has_cross_file_issues = True
+ print("Found duplicate Compiler IDs across Amazon property files:")
+ print("################")
+ for compiler_id, locations in sorted(duplicate_compiler_ids.items()):
+ print(f" {compiler_id}:")
+ for filename, line_num in sorted(locations):
+ print(f" - {filename}:Line {line_num}")
+ print("")
+
if result:
print(f"Found {len(result)} property file(s) with issues:")
for (filename, issues) in result:
@@ -285,12 +352,13 @@ def find_orphans(args: Namespace):
print("To suppress this warning on IDs that are temporally disabled, "
"add one or more comments to each listed file:")
print("# Disabled: id1 id2 ...")
- else:
+ elif not has_cross_file_issues:
print("No configuration mismatches found")
- return result
+
+ return result or has_cross_file_issues
if __name__ == '__main__':
args = parser.parse_args()
- if find_orphans(args):
+ if find_orphans_and_duplicates(args):
sys.exit(1)
diff --git a/etc/scripts/vc19_amd.bat b/etc/scripts/vc19_amd.bat
deleted file mode 100644
index d200b052aff..00000000000
--- a/etc/scripts/vc19_amd.bat
+++ /dev/null
@@ -1,10 +0,0 @@
-@echo off
-rem gotten from something like:
-rem call "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64
-rem set
-rem get out the include/lib/libpath/path
-set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;
-set LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64;
-set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;
-set Path=C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Amazon\cfn-bootstrap\;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Users\Administrator\AppData\Roaming\npm
-cl /nologo %*
diff --git a/etc/scripts/vc19_x86.bat b/etc/scripts/vc19_x86.bat
deleted file mode 100644
index 2199e521ffc..00000000000
--- a/etc/scripts/vc19_x86.bat
+++ /dev/null
@@ -1,10 +0,0 @@
-@echo off
-rem gotten from something like:
-rem call "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
-rem set
-rem get out the include/lib/libpath/path
-set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;
-set LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86;
-set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB;References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;
-set Path=C:\Program Files (x86)\MSBuild\14.0\bin;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Amazon\cfn-bootstrap\;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Users\Administrator\AppData\Roaming\npm
-cl /nologo %*
diff --git a/etc/scripts/parsed-pug/parsed_pug_file.js b/etc/webpack/parsed-pug-loader.js
similarity index 91%
rename from etc/scripts/parsed-pug/parsed_pug_file.js
rename to etc/webpack/parsed-pug-loader.js
index 8f54593cb18..40fa0af1642 100644
--- a/etc/scripts/parsed-pug/parsed_pug_file.js
+++ b/etc/webpack/parsed-pug-loader.js
@@ -1,7 +1,7 @@
-const {execSync} = require('child_process');
-const {getHashDigest} = require('loader-utils');
-const pug = require('pug');
-const path = require('path');
+import {execSync} from 'child_process';
+import {getHashDigest} from 'loader-utils';
+import pug from 'pug';
+import path from 'path';
// If you edit either cookies.pug or privacy.pug be aware this will trigger a popup on the users' next visit.
// Knowing the last versions here helps us be aware when this happens. If you get an error here and you _haven't_
@@ -9,7 +9,7 @@ const path = require('path');
// just update the hash here.
const expectedHashes = {
cookies: '08712179739d3679',
- privacy: 'c0dad1f48a56b761',
+ privacy: '074dd09a246ad6fe',
};
function _execGit(command) {
@@ -20,7 +20,7 @@ function _execGit(command) {
return gitResult.toString();
}
-module.exports = function (content) {
+export default function (content) {
const filePath = this.resourcePath;
const filename = path.basename(filePath, '.pug');
const options = this.getOptions();
diff --git a/etc/webpack/replace-golden-layout-imports.js b/etc/webpack/replace-golden-layout-imports.js
new file mode 100644
index 00000000000..fd407dba320
--- /dev/null
+++ b/etc/webpack/replace-golden-layout-imports.js
@@ -0,0 +1,56 @@
+/**
+ * Simple webpack loader to replace @import statements for golden-layout with actual CSS content
+ * This runs before sass-loader to replace the imports with raw CSS content
+ */
+
+import fs from 'fs';
+import path from 'path';
+import {fileURLToPath} from 'url';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+
+const GOLDEN_LAYOUT_PREFIX = '~golden-layout/';
+
+export default function replaceGoldenLayoutImports(source) {
+ // Only process if it contains golden-layout imports
+ if (!source.includes('@import') || !source.includes('golden-layout')) {
+ return source;
+ }
+
+ // Find all golden-layout @import statements and replace them
+ const importRegex = /@import\s+['"]([^'"]+)['"];?\s*/g;
+
+ return source.replace(importRegex, (match, importPath) => {
+ if (importPath.startsWith(GOLDEN_LAYOUT_PREFIX)) {
+ return replaceGoldenLayoutImport(importPath);
+ }
+
+ // Return other imports unchanged
+ return match;
+ });
+};
+
+function replaceGoldenLayoutImport(importPath) {
+ const goldenLayoutPath = importPath.substring(GOLDEN_LAYOUT_PREFIX.length);
+ const cssContent = readGoldenLayoutCSS(goldenLayoutPath);
+ const fileName = goldenLayoutPath.split('/').pop();
+ const themeName = fileName.replace(/^goldenlayout-/, '').replace(/\.css$/, '');
+
+ return `/* Golden Layout ${themeName} - Inlined */\n${cssContent}\n/* End Golden Layout ${themeName} */`;
+}
+
+function readGoldenLayoutCSS(relativePath) {
+ // Use import.meta.resolve to find the golden-layout package location robustly
+ const packageJsonPath = import.meta.resolve('golden-layout/package.json');
+ const packageDir = path.dirname(fileURLToPath(packageJsonPath));
+
+ // Ensure .css extension if not present
+ const finalPath = relativePath.endsWith('.css') ? relativePath : `${relativePath}.css`;
+ const cssPath = path.join(packageDir, finalPath);
+
+ if (!fs.existsSync(cssPath)) {
+ throw new Error(`Golden Layout CSS file not found: ${cssPath}`);
+ }
+
+ return fs.readFileSync(cssPath, 'utf8');
+}
diff --git a/examples/c++/Max_array.cpp b/examples/c++/Max_array.cpp
index bc2ef879961..45ea1c6a61d 100644
--- a/examples/c++/Max_array.cpp
+++ b/examples/c++/Max_array.cpp
@@ -1,4 +1,4 @@
-void maxArray(double* x, double* y) {
+void maxArray(double* x, const double* y) {
for (int i = 0; i < 65536; i++) {
if (y[i] > x[i]) x[i] = y[i];
}
diff --git a/examples/c++/Max_array_(Optimized).cpp b/examples/c++/Max_array_(Optimized).cpp
index a6256e93f32..aa7dfde1b45 100644
--- a/examples/c++/Max_array_(Optimized).cpp
+++ b/examples/c++/Max_array_(Optimized).cpp
@@ -1,7 +1,7 @@
// Compile with -O3 -march=native to see autovectorization
typedef double *__attribute__((aligned(64))) aligned_double;
-void maxArray(aligned_double __restrict x, aligned_double __restrict y) {
+void maxArray(aligned_double __restrict x, const aligned_double __restrict y) {
for (int i = 0; i < 65536; i++) {
x[i] = ((y[i] > x[i]) ? y[i] : x[i]);
}
diff --git a/examples/c/Max_array.c b/examples/c/Max_array.c
index c1ab7c15b95..e485502c34e 100644
--- a/examples/c/Max_array.c
+++ b/examples/c/Max_array.c
@@ -1,4 +1,4 @@
-void maxArray(double* x, double* y) {
+void maxArray(double* x, const double* y) {
int i;
for (i = 0; i < 65536; i++) {
diff --git a/examples/clojure/default.clj b/examples/clojure/default.clj
new file mode 100644
index 00000000000..b69fba28b01
--- /dev/null
+++ b/examples/clojure/default.clj
@@ -0,0 +1,5 @@
+;; Type your code here, or load an example.
+(ns example)
+
+(defn square [num]
+ (* num num))
diff --git a/examples/go/default.go b/examples/go/default.go
index 3238bce7b6a..9f71fae42b2 100644
--- a/examples/go/default.go
+++ b/examples/go/default.go
@@ -1,9 +1,6 @@
// Type your code here, or load an example.
-// Your function name should start with a capital letter.
-package main
+package p
-func Square(x int) int {
+func square(x int) int {
return x * x
}
-
-func main() {}
diff --git a/examples/helion/default.py b/examples/helion/default.py
new file mode 100644
index 00000000000..d9abe41a5ab
--- /dev/null
+++ b/examples/helion/default.py
@@ -0,0 +1,29 @@
+import torch
+import helion
+import helion.language as hl
+
+
+@helion.kernel(config=helion.Config(
+ block_sizes=[],
+ indexing='pointer',
+ load_eviction_policies=['', ''],
+ num_stages=2,
+ num_warps=4,
+ pid_type='flat',
+ range_flattens=[None],
+ range_multi_buffers=[None],
+ range_num_stages=[0],
+ range_unroll_factors=[0],
+ range_warp_specializes=[]
+), static_shapes=True)
+def add(x: torch.Tensor, y: torch.Tensor, scale: float) -> torch.Tensor:
+ out = torch.empty_like(x)
+ for idx in hl.grid(x.size()):
+ out[idx] = (x[idx] + y[idx]) * scale
+ return out
+
+
+x = torch.rand(1024).cuda()
+y = torch.rand(1024).cuda()
+scale = 2.0
+result = add(x, y, scale)
diff --git a/examples/ispc/default.ispc b/examples/ispc/default.ispc
index 8d8ec61ac82..cef0c92c69d 100644
--- a/examples/ispc/default.ispc
+++ b/examples/ispc/default.ispc
@@ -1,10 +1,6 @@
// Type your code here, or load an example.
varying int square_even(varying int num) {
- if (num % 2 == 0) {
- return num * num;
- } else {
- return num;
- }
+ return (num % 2 == 0)? num * num: num;
}
// Uncomment this if you would like to execute the code
diff --git a/examples/triton/default.py b/examples/triton/default.py
new file mode 100644
index 00000000000..54838b155e3
--- /dev/null
+++ b/examples/triton/default.py
@@ -0,0 +1,28 @@
+import torch
+import triton
+import triton.language as tl
+
+
+@triton.jit
+def add_kernel(
+ x_ptr,
+ y_ptr,
+ output_ptr,
+ n_elements,
+ BLOCK_SIZE: tl.constexpr,
+):
+ pid = tl.program_id(axis=0)
+ block_start = pid * BLOCK_SIZE
+ offsets = block_start + tl.arange(0, BLOCK_SIZE)
+ mask = offsets < n_elements
+ x = tl.load(x_ptr + offsets, mask=mask)
+ y = tl.load(y_ptr + offsets, mask=mask)
+ output = x + y
+ tl.store(output_ptr + offsets, output, mask=mask)
+
+
+x = torch.rand(1024)
+y = torch.rand(1024)
+output = torch.empty(1024)
+n_elements = output.numel()
+add_kernel[(1,)](x, y, output, n_elements, BLOCK_SIZE=1024)
diff --git a/examples/yul/default.yul b/examples/yul/default.yul
new file mode 100644
index 00000000000..eaed17cf2ae
--- /dev/null
+++ b/examples/yul/default.yul
@@ -0,0 +1,43 @@
+object "Square" {
+ code {
+ {
+ let _1 := memoryguard(0x80)
+ mstore(64, _1)
+ if callvalue() { revert(0, 0) }
+ let _2 := datasize("Square_deployed")
+ codecopy(_1, dataoffset("Square_deployed"), _2)
+ return(_1, _2)
+ }
+ }
+ object "Square_deployed" {
+ code {
+ {
+ let _1 := memoryguard(0x80)
+ mstore(64, _1)
+ if iszero(lt(calldatasize(), 4))
+ {
+ if eq(0xd27b3841, shr(224, calldataload(0)))
+ {
+ if callvalue() { revert(0, 0) }
+ if slt(add(calldatasize(), not(3)), 32) { revert(0, 0) }
+ let value := calldataload(4)
+ let _2 := and(value, 0xffffffff)
+ if iszero(eq(value, _2)) { revert(0, 0) }
+ let product_raw := mul(_2, _2)
+ let product := and(product_raw, 0xffffffff)
+ if iszero(eq(product, product_raw))
+ {
+ mstore(0, shl(224, 0x4e487b71))
+ mstore(4, 0x11)
+ revert(0, 0x24)
+ }
+ mstore(_1, product)
+ return(_1, 32)
+ }
+ }
+ revert(0, 0)
+ }
+ }
+ data ".metadata" hex"a26469706673582212209b2b1b86ce0e1a75faa800884ba155bd6bc6a6bc71f210370f818535dcfc5ee364736f6c634300081e0033"
+ }
+}
diff --git a/lib/app.interfaces.ts b/lib/app.interfaces.ts
index 0a4efb13c7d..3c07e223b64 100644
--- a/lib/app.interfaces.ts
+++ b/lib/app.interfaces.ts
@@ -35,6 +35,7 @@ export type AppArguments = {
doCache: boolean;
fetchCompilersFromRemote: boolean;
ensureNoCompilerClash: boolean | undefined;
+ exitOnCompilerFailure?: boolean;
prediscovered?: string;
discoveryOnly?: string;
staticPath?: string;
@@ -45,4 +46,5 @@ export type AppArguments = {
loggingOptions: LoggingOptions;
isWsl: boolean;
devMode: boolean;
+ instanceColor?: string;
};
diff --git a/lib/app/cli.ts b/lib/app/cli.ts
index aed73a2edad..f0d0d57939c 100644
--- a/lib/app/cli.ts
+++ b/lib/app/cli.ts
@@ -64,6 +64,7 @@ export interface CompilerExplorerOptions {
language?: string[];
cache: boolean;
ensureNoIdClash?: boolean;
+ exitOnCompilerFailure?: boolean;
logHost?: string;
logPort?: number;
hostnameForLogging?: string;
@@ -76,6 +77,7 @@ export interface CompilerExplorerOptions {
local: boolean;
version: boolean;
devMode: boolean;
+ instanceColor?: string;
}
/**
@@ -100,6 +102,7 @@ export function parseCommandLine(argv: string[]): CompilerExplorerOptions {
.option('--language ', 'Only load specified languages for faster startup')
.option('--no-cache', 'Do not use caching for compilation results')
.option('--ensure-no-id-clash', "Don't run if compilers have clashing ids")
+ .option('--exit-on-compiler-failure', 'Exit with error code if any compilers fail to initialize')
.option('--logHost, --log-host ', 'Hostname for remote logging')
.option('--logPort, --log-port ', 'Port for remote logging', parsePortNumberForOptions)
.option('--hostnameForLogging, --hostname-for-logging ', 'Hostname to use in logs')
@@ -115,7 +118,8 @@ export function parseCommandLine(argv: string[]): CompilerExplorerOptions {
'--dev-mode',
'Run in dev mode (default if NODE_ENV is not production)',
process.env.NODE_ENV !== 'production',
- );
+ )
+ .option('--instance-color ', 'Instance color (blue or green) for deployment differentiation');
program.parse(argv);
return program.opts() as CompilerExplorerOptions;
@@ -186,6 +190,7 @@ export function convertOptionsToAppArguments(
doCache: options.cache,
fetchCompilersFromRemote: options.remoteFetch,
ensureNoCompilerClash: options.ensureNoIdClash,
+ exitOnCompilerFailure: options.exitOnCompilerFailure,
prediscovered: options.prediscovered,
discoveryOnly: options.discoveryOnly,
staticPath: options.static,
@@ -195,6 +200,7 @@ export function convertOptionsToAppArguments(
tmpDir: options.tmpDir,
isWsl: isWsl,
devMode: options.devMode,
+ instanceColor: options.instanceColor,
loggingOptions: {
debug: options.debug || false,
logHost: options.logHost,
diff --git a/lib/app/compilation-env.ts b/lib/app/compilation-env.ts
index ffe69debef3..043eefdb03f 100644
--- a/lib/app/compilation-env.ts
+++ b/lib/app/compilation-env.ts
@@ -56,7 +56,7 @@ export async function initializeCompilationEnvironment(
appArgs.doCache,
);
- const compileHandler = new CompileHandler(compilationEnvironment, awsProps);
+ const compileHandler = new CompileHandler(compilationEnvironment, awsProps, appArgs);
compilationEnvironment.setCompilerFinder(compileHandler.findCompiler.bind(compileHandler));
return {
diff --git a/lib/app/config.ts b/lib/app/config.ts
index 63188e74137..305c4af596c 100644
--- a/lib/app/config.ts
+++ b/lib/app/config.ts
@@ -169,7 +169,7 @@ export function loadConfiguration(appArgs: AppArguments): AppConfiguration {
const httpRoot = urljoin(ceProps('httpRoot', '/'), '/');
const staticUrl = ceProps('staticUrl');
- const staticRoot = urljoin(staticUrl || urljoin(httpRoot, 'static'), '/');
+ const staticRoot = urljoin(staticUrl || httpRoot, '/');
return {
ceProps,
diff --git a/lib/app/controllers.ts b/lib/app/controllers.ts
index 01022fce6a6..22ccc82d362 100644
--- a/lib/app/controllers.ts
+++ b/lib/app/controllers.ts
@@ -50,6 +50,7 @@ export interface ApiControllers {
* @param compilationQueue - The compilation queue instance
* @param healthCheckFilePath - Optional path to health check file
* @param isExecutionWorker - Whether the server is running as an execution worker
+ * @param isCompilationWorker - Whether the server is running as a compilation worker
* @param formDataHandler - Handler for form data
* @returns Object containing all initialized controllers
*/
@@ -59,6 +60,7 @@ export function setupControllersAndHandlers(
compilationQueue: CompilationQueue,
healthCheckFilePath: string | null,
isExecutionWorker: boolean,
+ isCompilationWorker: boolean,
formDataHandler: express.Handler,
): ApiControllers {
// Initialize API controllers
diff --git a/lib/app/main.ts b/lib/app/main.ts
index ea971066895..b4547417323 100644
--- a/lib/app/main.ts
+++ b/lib/app/main.ts
@@ -26,14 +26,8 @@ import fs from 'node:fs/promises';
import path from 'node:path';
import type {AppArguments} from '../app.interfaces.js';
-import {initializeCompilationEnvironment} from './compilation-env.js';
-import {setupCompilerChangeHandling} from './compiler-changes.js';
-import {discoverCompilers} from './compiler-discovery.js';
-import {setupControllersAndHandlers} from './controllers.js';
-import {setupRoutesAndApi} from './routes-setup.js';
-import {setupTempDir} from './temp-dir.js';
-
import * as aws from '../aws.js';
+import {startCompilationWorkerThread} from '../compilation/sqs-compilation-queue.js';
import {CompilerFinder} from '../compiler-finder.js';
import {startWineInit} from '../exec.js';
import {RemoteExecutionQuery} from '../execution/execution-query.js';
@@ -47,8 +41,14 @@ import {SetupSentry} from '../sentry.js';
import {sources} from '../sources/index.js';
import {loadSponsorsFromString} from '../sponsors.js';
import {getStorageTypeByKey} from '../storage/index.js';
+import {initializeCompilationEnvironment} from './compilation-env.js';
+import {setupCompilerChangeHandling} from './compiler-changes.js';
+import {discoverCompilers} from './compiler-discovery.js';
+import {setupControllersAndHandlers} from './controllers.js';
import {ApplicationOptions, ApplicationResult} from './main.interfaces.js';
+import {setupRoutesAndApi} from './routes-setup.js';
import {setupWebServer, startListening} from './server.js';
+import {setupTempDir} from './temp-dir.js';
/**
* Initialize the Compiler Explorer application
@@ -80,6 +80,7 @@ export async function initialiseApplication(options: ApplicationOptions): Promis
const compilerFinder = new CompilerFinder(compileHandler, compilerProps, appArgs, clientOptionsHandler);
const isExecutionWorker = ceProps('execqueue.is_worker', false);
+ const isCompilationWorker = ceProps('compilequeue.is_worker', false);
const healthCheckFilePath = ceProps('healthCheckFilePath', null) as string | null;
const formDataHandler = createFormDataHandler();
@@ -90,6 +91,7 @@ export async function initialiseApplication(options: ApplicationOptions): Promis
compilationEnvironment.compilationQueue,
healthCheckFilePath,
isExecutionWorker,
+ isCompilationWorker,
formDataHandler,
);
@@ -104,7 +106,7 @@ export async function initialiseApplication(options: ApplicationOptions): Promis
staticRoot: config.staticRoot,
httpRoot: config.httpRoot,
sentrySlowRequestMs: ceProps('sentrySlowRequestMs', 0),
- distPath: distPath,
+ manifestPath: distPath,
extraBodyClass: config.extraBodyClass,
maxUploadSize: config.maxUploadSize,
};
@@ -163,6 +165,10 @@ export async function initialiseApplication(options: ApplicationOptions): Promis
startExecutionWorkerThread(ceProps, awsProps, compilationEnvironment);
}
+ if (isCompilationWorker) {
+ startCompilationWorkerThread(ceProps, awsProps, compilationEnvironment, appArgs);
+ }
+
startListening(webServer, appArgs);
return {webServer};
diff --git a/lib/app/rendering.ts b/lib/app/rendering.ts
index 6307c568af8..903b2e30e75 100644
--- a/lib/app/rendering.ts
+++ b/lib/app/rendering.ts
@@ -25,8 +25,9 @@
import express, {Request, Response} from 'express';
import _ from 'underscore';
-import {GoldenLayoutRootStruct} from '../clientstate-normalizer.js';
+import {AppArguments} from '../app.interfaces.js';
import * as normalizer from '../clientstate-normalizer.js';
+import {GoldenLayoutRootStruct} from '../clientstate-normalizer.js';
import type {ShortLinkMetaData} from '../handlers/handler.interfaces.js';
import * as utils from '../utils.js';
import {
@@ -37,6 +38,7 @@ import {
ServerDependencies,
ServerOptions,
} from './server.interfaces.js';
+import {getFaviconFilename} from './static-assets.js';
import {isMobileViewer} from './url-handlers.js';
/**
@@ -44,12 +46,14 @@ import {isMobileViewer} from './url-handlers.js';
* @param pugRequireHandler - Handler for Pug requires
* @param options - Server options
* @param dependencies - Server dependencies
+ * @param appArgs - App arguments
* @returns Rendering functions
*/
export function createRenderHandlers(
pugRequireHandler: PugRequireHandler,
options: ServerOptions,
dependencies: ServerDependencies,
+ appArgs: AppArguments,
): {
renderConfig: RenderConfigFunction;
renderGoldenLayout: RenderGoldenLayoutHandler;
@@ -80,7 +84,7 @@ export function createRenderHandlers(
allExtraOptions.slides = glnormalizer.generatePresentationModeMobileViewerSlides(clientstate);
}
- const options = _.extend({}, allExtraOptions, clientOptionsHandler.get());
+ const options: RenderConfig = _.extend({}, allExtraOptions, clientOptionsHandler.get());
options.optionsHash = clientOptionsHandler.getHash();
options.compilerExplorerOptions = JSON.stringify(allExtraOptions);
options.extraBodyClass = options.embedded ? 'embedded' : extraBodyClass;
@@ -89,6 +93,7 @@ export function createRenderHandlers(
options.storageSolution = options.storageSolution || storageSolution;
options.require = pugRequireHandler;
options.sponsors = sponsorConfig;
+ options.faviconFilename = getFaviconFilename(appArgs.devMode, appArgs.env);
return options;
};
diff --git a/lib/app/server-config.ts b/lib/app/server-config.ts
index 18758e914bc..6fdc79bb3dc 100644
--- a/lib/app/server-config.ts
+++ b/lib/app/server-config.ts
@@ -24,20 +24,18 @@
import * as Sentry from '@sentry/node';
import compression from 'compression';
-import express from 'express';
import type {NextFunction, Request, Response, Router} from 'express';
+import express from 'express';
import morgan from 'morgan';
import sanitize from 'sanitize-filename';
-import sFavicon from 'serve-favicon';
import {cached, csp} from '../handlers/middleware.js';
import {logger, makeLogStream} from '../logger.js';
import {ClientOptionsSource} from '../options-handler.interfaces.js';
import {PropertyGetter} from '../properties.interfaces.js';
import * as utils from '../utils.js';
-import {ServerOptions} from './server.interfaces.js';
-import {RenderConfigFunction} from './server.interfaces.js';
-import {LegacyGoogleUrlHandler, isMobileViewer} from './url-handlers.js';
+import {RenderConfigFunction, ServerOptions} from './server.interfaces.js';
+import {isMobileViewer, LegacyGoogleUrlHandler} from './url-handlers.js';
/**
* Setup base server configuration
@@ -55,7 +53,6 @@ export function setupBaseServerConfig(
webServer
.set('trust proxy', true)
.set('view engine', 'pug')
- .on('error', err => logger.error('Caught error in web handler; continuing:', err))
.use(
responseTime((req, res, time) => {
if (options.sentrySlowRequestMs > 0 && time >= options.sentrySlowRequestMs) {
@@ -119,25 +116,36 @@ export function setupLoggingMiddleware(isDevMode: boolean, router: Router): void
morgan(morganFormat, {
stream: makeLogStream('info'),
// Skip for non errors (2xx, 3xx)
- skip: (req: Request, res: Response) => res.statusCode >= 400,
+ skip: (req: Request, res: Response) => res.statusCode >= 400 || isFaviconRequest(req),
}),
);
router.use(
morgan(morganFormat, {
stream: makeLogStream('warn'),
// Skip for non user errors (4xx)
- skip: (req: Request, res: Response) => res.statusCode < 400 || res.statusCode >= 500,
+ skip: (req: Request, res: Response) =>
+ res.statusCode < 400 || res.statusCode >= 500 || isFaviconRequest(req),
}),
);
router.use(
morgan(morganFormat, {
stream: makeLogStream('error'),
// Skip for non server errors (5xx)
- skip: (req: Request, res: Response) => res.statusCode < 500,
+ skip: (req: Request, res: Response) => res.statusCode < 500 || isFaviconRequest(req),
}),
);
}
+function isFaviconRequest(req: Request): boolean {
+ return [
+ 'favicon.ico',
+ 'favicon-beta.ico',
+ 'favicon-dev.ico',
+ 'favicon-staging.ico',
+ 'favicon-suspend.ico',
+ ].includes(req.path);
+}
+
/**
* Setup basic routes for the web server
* @param router - Express router
@@ -145,7 +153,6 @@ export function setupLoggingMiddleware(isDevMode: boolean, router: Router): void
* @param embeddedHandler - Handler for embedded mode
* @param ceProps - Compiler Explorer properties
* @param awsProps - AWS properties
- * @param faviconFilename - Favicon filename
* @param options - Server options
* @param clientOptionsHandler - Client options handler
*/
@@ -155,7 +162,6 @@ export function setupBasicRoutes(
embeddedHandler: express.Handler,
ceProps: PropertyGetter,
awsProps: PropertyGetter,
- faviconFilename: string,
options: ServerOptions,
clientOptionsHandler: ClientOptionsSource,
): void {
@@ -199,14 +205,6 @@ export function setupBasicRoutes(
res.render('sitemap');
});
- // Try to add favicon support, but don't fail if it's not available (useful for tests)
- try {
- router.use(sFavicon(utils.resolvePathFromAppRoot('static/favicons', faviconFilename)));
- } catch (err: unknown) {
- const error = err as Error;
- logger.warn(`Could not set up favicon: ${error.message}`);
- }
-
router
.get('/client-options.js', cached, (req, res) => {
res.set('Content-Type', 'application/javascript');
diff --git a/lib/app/server-listening.ts b/lib/app/server-listening.ts
index 7a58f0ae090..b15566195ec 100644
--- a/lib/app/server-listening.ts
+++ b/lib/app/server-listening.ts
@@ -54,7 +54,7 @@ export function startListening(webServer: express.Express, appArgs: AppArguments
function setupSystemdSocketListening(webServer: express.Express, ss: {fd: number}): void {
// ms (5 min default)
const idleTimeout = process.env.IDLE_TIMEOUT;
- const timeout = (idleTimeout === undefined ? 300 : Number.parseInt(idleTimeout)) * 1000;
+ const timeout = (idleTimeout === undefined ? 300 : Number.parseInt(idleTimeout, 10)) * 1000;
if (idleTimeout) {
setupIdleTimeout(webServer, timeout);
logger.info(` IDLE_TIMEOUT: ${idleTimeout}`);
diff --git a/lib/app/server.interfaces.ts b/lib/app/server.interfaces.ts
index ce81a0dff90..fc6b0b7506a 100644
--- a/lib/app/server.interfaces.ts
+++ b/lib/app/server.interfaces.ts
@@ -37,7 +37,7 @@ export interface ServerOptions {
staticRoot: string;
httpRoot: string;
sentrySlowRequestMs: number;
- distPath: string;
+ manifestPath: string;
extraBodyClass: string;
maxUploadSize: string;
}
@@ -57,6 +57,7 @@ export interface RenderConfig extends PugOptions {
readOnly?: boolean;
config?: GoldenLayoutRootStruct;
metadata?: ShortLinkMetaData;
+ faviconFilename: string;
storedStateId?: string | false;
require?: PugRequireHandler;
sponsors?: Sponsors;
diff --git a/lib/app/server.ts b/lib/app/server.ts
index ce7db197e67..e448e37077d 100644
--- a/lib/app/server.ts
+++ b/lib/app/server.ts
@@ -27,14 +27,12 @@ import express from 'express';
import type {AppArguments} from '../app.interfaces.js';
import {logger} from '../logger.js';
import {createRenderHandlers} from './rendering.js';
-import {setupBaseServerConfig, setupBasicRoutes, setupLoggingMiddleware} from './server-config.js';
-import {startListening} from './server-listening.js';
import {ServerDependencies, ServerOptions, WebServerResult} from './server.interfaces.js';
-import {getFaviconFilename, setupStaticMiddleware, setupWebPackDevMiddleware} from './static-assets.js';
-import {isMobileViewer} from './url-handlers.js';
+import {setupBaseServerConfig, setupBasicRoutes, setupLoggingMiddleware} from './server-config.js';
+import {setupStaticMiddleware, setupWebPackDevMiddleware} from './static-assets.js';
-// Re-exporting functions that are used by other modules
-export {getFaviconFilename, isMobileViewer, startListening};
+export {startListening} from './server-listening.js';
+export {isMobileViewer} from './url-handlers.js';
/**
* Configure a web server and its routes
@@ -67,6 +65,7 @@ export async function setupWebServer(
pugRequireHandler,
options,
dependencies,
+ appArgs,
);
// Add healthcheck before logging middleware to prevent excessive log entries
@@ -81,7 +80,6 @@ export async function setupWebServer(
embeddedHandler,
dependencies.ceProps,
dependencies.awsProps,
- getFaviconFilename(appArgs.devMode, appArgs.env),
options,
dependencies.clientOptionsHandler,
);
diff --git a/lib/app/static-assets.ts b/lib/app/static-assets.ts
index bc877ecdcaf..e5ae16fd6cd 100644
--- a/lib/app/static-assets.ts
+++ b/lib/app/static-assets.ts
@@ -24,11 +24,11 @@
import fs from 'node:fs/promises';
import path from 'node:path';
-import express from 'express';
import type {Router} from 'express';
+import express from 'express';
import urljoin from 'url-join';
-import {ElementType} from '../../shared/common-utils.js';
+import {unwrap} from '../assert.js';
import {logger} from '../logger.js';
import {PugRequireHandler, ServerOptions} from './server.interfaces.js';
@@ -43,7 +43,7 @@ export function createDefaultPugRequireHandler(
manifest?: Record,
): PugRequireHandler {
return (path: string) => {
- if (manifest && Object.prototype.hasOwnProperty.call(manifest, path)) {
+ if (manifest && Object.hasOwn(manifest, path)) {
return urljoin(staticRoot, manifest[path]);
}
if (manifest) {
@@ -69,12 +69,10 @@ export async function setupWebPackDevMiddleware(options: ServerOptions, router:
const {default: webpack} = await import('webpack');
/* eslint-enable */
- type WebpackConfiguration = ElementType[0]>;
-
- const webpackCompiler = webpack([webpackConfig as WebpackConfiguration]);
+ const webpackCompiler = unwrap(webpack(webpackConfig));
router.use(
webpackDevMiddleware(webpackCompiler, {
- publicPath: '/static',
+ publicPath: '/',
stats: {
preset: 'errors-only',
timings: true,
@@ -82,7 +80,7 @@ export async function setupWebPackDevMiddleware(options: ServerOptions, router:
}),
);
- return path => urljoin(options.httpRoot, 'static', path);
+ return path => urljoin(options.httpRoot, path);
}
/**
@@ -92,14 +90,14 @@ export async function setupWebPackDevMiddleware(options: ServerOptions, router:
* @returns Function to handle Pug requires
*/
export async function setupStaticMiddleware(options: ServerOptions, router: Router): Promise {
- const staticManifest = JSON.parse(await fs.readFile(path.join(options.distPath, 'manifest.json'), 'utf-8'));
+ const staticManifest = JSON.parse(await fs.readFile(path.join(options.manifestPath, 'manifest.json'), 'utf-8'));
if (options.staticUrl) {
logger.info(` using static files from '${options.staticUrl}'`);
} else {
logger.info(` serving static files from '${options.staticPath}'`);
router.use(
- '/static',
+ '/',
express.static(options.staticPath, {
maxAge: options.staticMaxAgeSecs * 1000,
}),
diff --git a/lib/app/temp-dir.ts b/lib/app/temp-dir.ts
index 1eb1e8b3831..db419d7fbd5 100644
--- a/lib/app/temp-dir.ts
+++ b/lib/app/temp-dir.ts
@@ -49,7 +49,7 @@ export function setupTempDir(tmpDir: string | undefined, isWsl: boolean): void {
const driveLetter = windowsTemp.substring(0, 1).toLowerCase();
const directoryPath = windowsTemp.substring(2).trim();
process.env.TEMP = path.join('/mnt', driveLetter, directoryPath);
- } catch (e) {
+ } catch {
logger.warn('Unable to invoke cmd.exe to get windows %TEMP% path.');
}
}
diff --git a/lib/artifact-utils.ts b/lib/artifact-utils.ts
index d3f1fa43ba3..eceffb7e790 100644
--- a/lib/artifact-utils.ts
+++ b/lib/artifact-utils.ts
@@ -22,9 +22,8 @@
// ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
// POSSIBILITY OF SUCH DAMAGE.
-import path from 'node:path';
-
import fs from 'node:fs/promises';
+import path from 'node:path';
import {BufferOkFunc, BuildResult, CompilationResult} from '../types/compilation/compilation.interfaces.js';
import {Artifact, ArtifactType} from '../types/tool.interfaces.js';
diff --git a/lib/asm-docs/_all.ts b/lib/asm-docs/_all.ts
index 7ba601de40c..c7402cef5cd 100644
--- a/lib/asm-docs/_all.ts
+++ b/lib/asm-docs/_all.ts
@@ -29,8 +29,8 @@ export {EvmDocumentationProvider} from './evm.js';
export {JavaDocumentationProvider} from './java.js';
export {LLVMDocumentationProvider} from './llvm.js';
export {Mos6502DocumentationProvider} from './mos6502.js';
-export {PTXDocumentationProvider} from './ptx.js';
export {PowerDocumentationProvider} from './power.js';
+export {PTXDocumentationProvider} from './ptx.js';
export {PythonDocumentationProvider} from './python.js';
export {Riscv64DocumentationProvider} from './riscv64.js';
export {SASSDocumentationProvider} from './sass.js';
diff --git a/lib/asm-docs/generated/asm-docs-amd64.ts b/lib/asm-docs/generated/asm-docs-amd64.ts
index 45912d9785e..0cf00d0c665 100644
--- a/lib/asm-docs/generated/asm-docs-amd64.ts
+++ b/lib/asm-docs/generated/asm-docs-amd64.ts
@@ -55,48 +55,48 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "ADDPD":
case "VADDPD":
return {
- "html": "
Adds two, four or eight packed double-precision floating-point values from the first source operand to the second source operand, and stores the packed double-precision floating-point result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the first source operand is a XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Adds two, four or eight packed double-precision floating-point values from the first source operand to the second source operand, and stores the packed double-precision floating-point result in the destination operand.",
+ "html": "
Adds two, four or eight packed double precision floating-point values from the first source operand to the second source operand, and stores the packed double precision floating-point result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the first source operand is a XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Adds two, four or eight packed double precision floating-point values from the first source operand to the second source operand, and stores the packed double precision floating-point result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ADDPD.html"
};
case "ADDPS":
case "VADDPS":
return {
- "html": "
Adds four, eight or sixteen packed single-precision floating-point values from the first source operand with the second source operand, and stores the packed single-precision floating-point result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the first source operand is a XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Adds four, eight or sixteen packed single-precision floating-point values from the first source operand with the second source operand, and stores the packed single-precision floating-point result in the destination operand.",
+ "html": "
Adds four, eight or sixteen packed single precision floating-point values from the first source operand with the second source operand, and stores the packed single precision floating-point result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the first source operand is a XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Adds four, eight or sixteen packed single precision floating-point values from the first source operand with the second source operand, and stores the packed single precision floating-point result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ADDPS.html"
};
case "ADDSD":
case "VADDSD":
return {
- "html": "
Adds the low double-precision floating-point values from the second source operand and the first source operand and stores the double-precision floating-point result in the destination operand.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The first source and destination operands are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
EVEX and VEX.128 encoded version: The first source operand is encoded by EVEX.vvvv/VEX.vvvv. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low quadword element of the destination is updated according to the writemask.
",
- "tooltip": "Adds the low double-precision floating-point values from the second source operand and the first source operand and stores the double-precision floating-point result in the destination operand.",
+ "html": "
Adds the low double precision floating-point values from the second source operand and the first source operand and stores the double precision floating-point result in the destination operand.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The first source and destination operands are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
EVEX and VEX.128 encoded version: The first source operand is encoded by EVEX.vvvv/VEX.vvvv. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low quadword element of the destination is updated according to the writemask.
",
+ "tooltip": "Adds the low double precision floating-point values from the second source operand and the first source operand and stores the double precision floating-point result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ADDSD.html"
};
case "ADDSS":
case "VADDSS":
return {
- "html": "
Adds the low single-precision floating-point values from the second source operand and the first source operand, and stores the single-precision floating-point result in the destination operand.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The first source and destination operands are the same. Bits (MAXVL-1:32) of the corresponding the destination register remain unchanged.
EVEX and VEX.128 encoded version: The first source operand is encoded by EVEX.vvvv/VEX.vvvv. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low doubleword element of the destination is updated according to the writemask.
",
- "tooltip": "Adds the low single-precision floating-point values from the second source operand and the first source operand, and stores the single-precision floating-point result in the destination operand.",
+ "html": "
Adds the low single precision floating-point values from the second source operand and the first source operand, and stores the double precision floating-point result in the destination operand.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The first source and destination operands are the same. Bits (MAXVL-1:32) of the corresponding the destination register remain unchanged.
EVEX and VEX.128 encoded version: The first source operand is encoded by EVEX.vvvv/VEX.vvvv. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low doubleword element of the destination is updated according to the writemask.
",
+ "tooltip": "Adds the low single precision floating-point values from the second source operand and the first source operand, and stores the double precision floating-point result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ADDSS.html"
};
case "ADDSUBPD":
case "VADDSUBPD":
return {
- "html": "
Adds odd-numbered double-precision floating-point values of the first source operand (second operand) with the corresponding double-precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered double-precision floating-point values from the second source operand from the corresponding double-precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified. See Figure 3-3.
VEX.128 encoded version: the first source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
- "tooltip": "Adds odd-numbered double-precision floating-point values of the first source operand (second operand) with the corresponding double-precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered double-precision floating-point values from the second source operand from the corresponding double-precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.",
+ "html": "
Adds odd-numbered double precision floating-point values of the first source operand (second operand) with the corresponding double precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered double precision floating-point values from the second source operand from the corresponding double precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified. See Figure 3-3.
VEX.128 encoded version: the first source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
+ "tooltip": "Adds odd-numbered double precision floating-point values of the first source operand (second operand) with the corresponding double precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered double precision floating-point values from the second source operand from the corresponding double precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.",
"url": "https://www.felixcloutier.com/x86/ADDSUBPD.html"
};
case "ADDSUBPS":
case "VADDSUBPS":
return {
- "html": "
Adds odd-numbered single-precision floating-point values of the first source operand (second operand) with the corresponding single-precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered single-precision floating-point values from the second source operand from the corresponding single-precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified. See Figure 3-4.
VEX.128 encoded version: the first source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
- "tooltip": "Adds odd-numbered single-precision floating-point values of the first source operand (second operand) with the corresponding single-precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered single-precision floating-point values from the second source operand from the corresponding single-precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.",
+ "html": "
Adds odd-numbered single precision floating-point values of the first source operand (second operand) with the corresponding single precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered single precision floating-point values from the second source operand from the corresponding single precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified. See Figure 3-4.
VEX.128 encoded version: the first source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
+ "tooltip": "Adds odd-numbered single precision floating-point values of the first source operand (second operand) with the corresponding single precision floating-point values from the second source operand (third operand); stores the result in the odd-numbered values of the destination operand (first operand). Subtracts the even-numbered single precision floating-point values from the second source operand from the corresponding single precision floating values in the first source operand; stores the result into the even-numbered values of the destination operand.",
"url": "https://www.felixcloutier.com/x86/ADDSUBPS.html"
};
@@ -172,38 +172,38 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "ANDNPD":
case "VANDNPD":
return {
- "html": "
Performs a bitwise logical AND NOT of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Performs a bitwise logical AND NOT of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
+ "html": "
Performs a bitwise logical AND NOT of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Performs a bitwise logical AND NOT of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ANDNPD.html"
};
case "ANDNPS":
case "VANDNPS":
return {
- "html": "
Performs a bitwise logical AND NOT of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Performs a bitwise logical AND NOT of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
+ "html": "
Performs a bitwise logical AND NOT of the four, eight or sixteen packed single precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Performs a bitwise logical AND NOT of the four, eight or sixteen packed single precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ANDNPS.html"
};
case "ANDPD":
case "VANDPD":
return {
- "html": "
Performs a bitwise logical AND of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Performs a bitwise logical AND of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
+ "html": "
Performs a bitwise logical AND of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Performs a bitwise logical AND of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ANDPD.html"
};
case "ANDPS":
case "VANDPS":
return {
- "html": "
Performs a bitwise logical AND of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Performs a bitwise logical AND of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
+ "html": "
Performs a bitwise logical AND of the four, eight or sixteen packed single precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Performs a bitwise logical AND of the four, eight or sixteen packed single precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ANDPS.html"
};
case "ARPL":
return {
- "html": "
Compares the RPL fields of two segment selectors. The first operand (the destination operand) contains one segment selector and the second operand (source operand) contains the other. (The RPL field is located in bits 0 and 1 of each operand.) If the RPL field of the destination operand is less than the RPL field of the source operand, the ZF flag is set and the RPL field of the destination operand is increased to match that of the source operand. Otherwise, the ZF flag is cleared and no change is made to the destination operand. (The destination operand can be a word register or a memory location; the source operand must be a word register.)
The ARPL instruction is provided for use by operating-system procedures (however, it can also be used by applications). It is generally used to adjust the RPL of a segment selector that has been passed to the operating system by an application program to match the privilege level of the application program. Here the segment selector passed to the operating system is placed in the destination operand and segment selector for the application program\u2019s code segment is placed in the source operand. (The RPL field in the source operand represents the privilege level of the application program.) Execution of the ARPL instruction then ensures that the RPL of the segment selector received by the operating system is no lower (does not have a higher privilege) than the privilege level of the application program (the segment selector for the application program\u2019s code segment can be read from the stack following a procedure call).
This instruction executes as described in compatibility mode and legacy mode. It is not encodable in 64-bit mode.
See \u201cChecking Caller Access Privileges\u201d in Chapter 3, \u201cProtected-Mode Memory Management,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for more information about the use of this instruction.
",
+ "html": "
Compares the RPL fields of two segment selectors. The first operand (the destination operand) contains one segment selector and the second operand (source operand) contains the other. (The RPL field is located in bits 0 and 1 of each operand.) If the RPL field of the destination operand is less than the RPL field of the source operand, the ZF flag is set and the RPL field of the destination operand is increased to match that of the source operand. Otherwise, the ZF flag is cleared and no change is made to the destination operand. (The destination operand can be a word register or a memory location; the source operand must be a word register.)
The ARPL instruction is provided for use by operating-system procedures (however, it can also be used by applications). It is generally used to adjust the RPL of a segment selector that has been passed to the operating system by an application program to match the privilege level of the application program. Here the segment selector passed to the operating system is placed in the destination operand and segment selector for the application program\u2019s code segment is placed in the source operand. (The RPL field in the source operand represents the privilege level of the application program.) Execution of the ARPL instruction then ensures that the RPL of the segment selector received by the operating system is no lower (does not have a higher privilege) than the privilege level of the application program (the segment selector for the application program\u2019s code segment can be read from the stack following a procedure call).
This instruction executes as described in compatibility mode and legacy mode. It is not encodable in 64-bit mode.
See \u201cChecking Caller Access Privileges\u201d in Chapter 3, \u201cProtected-Mode Memory Management,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for more information about the use of this instruction.
",
"tooltip": "Compares the RPL fields of two segment selectors. The first operand (the destination operand) contains one segment selector and the second operand (source operand) contains the other. (The RPL field is located in bits 0 and 1 of each operand.) If the RPL field of the destination operand is less than the RPL field of the source operand, the ZF flag is set and the RPL field of the destination operand is increased to match that of the source operand. Otherwise, the ZF flag is cleared and no change is made to the destination operand. (The destination operand can be a word register or a memory location; the source operand must be a word register.)",
"url": "https://www.felixcloutier.com/x86/ARPL.html"
};
@@ -218,32 +218,32 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "BLENDPD":
case "VBLENDPD":
return {
- "html": "
Double-precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [3:0] determine whether the corresponding double-precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201d1\u201d, then the double-precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: the first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
- "tooltip": "Double-precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [3:0] determine whether the corresponding double-precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201d1\u201d, then the double-precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.",
+ "html": "
Double-precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [3:0] determine whether the corresponding double precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201d1\u201d, then the double precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: the first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
+ "tooltip": "Double-precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [3:0] determine whether the corresponding double precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201d1\u201d, then the double precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.",
"url": "https://www.felixcloutier.com/x86/BLENDPD.html"
};
case "BLENDPS":
case "VBLENDPS":
return {
- "html": "
Packed single-precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [7:0] determine whether the corresponding single precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201c1\u201d, then the single-precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: The first source operand an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
- "tooltip": "Packed single-precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [7:0] determine whether the corresponding single precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201c1\u201d, then the single-precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.",
+ "html": "
Packed single precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [7:0] determine whether the corresponding single precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201c1\u201d, then the single precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: The first source operand an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
+ "tooltip": "Packed single precision floating-point values from the second source operand (third operand) are conditionally merged with values from the first source operand (second operand) and written to the destination operand (first operand). The immediate bits [7:0] determine whether the corresponding single precision floating-point value in the destination is copied from the second source or first source. If a bit in the mask, corresponding to a word, is \u201c1\u201d, then the single precision floating-point value in the second source operand is copied, else the value in the first source operand is copied.",
"url": "https://www.felixcloutier.com/x86/BLENDPS.html"
};
case "BLENDVPD":
case "VBLENDVPD":
return {
- "html": "
Conditionally copy each quadword data element of double-precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each quadword element of the mask register.
Each quadword element of the destination operand is copied from:
The register assignment of the implicit mask operand for BLENDVPD is defined to be the architectural register XMM0.
128-bit Legacy SSE version: The first source operand and the destination operand is the same. Bits (MAXVL-1:128) of the corresponding YMM destination register remain unchanged. The mask register operand is implicitly defined to be the architectural register XMM0. An attempt to execute BLENDVPD with a VEX prefix will cause #UD.
VEX.128 encoded version: The first source operand and the destination operand are XMM registers. The second source operand is an XMM register or 128-bit memory location. The mask operand is the third source register, and encoded in bits[7:4] of the immediate byte(imm8). The bits[3:0] of imm8 are ignored. In 32-bit mode, imm8[7] is ignored. The upper bits (MAXVL-1:128) of the corresponding YMM register (destination register) are zeroed. VEX.W must be 0, otherwise, the instruction will #UD.
",
- "tooltip": "Conditionally copy each quadword data element of double-precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each quadword element of the mask register.",
+ "html": "
Conditionally copy each quadword data element of double precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each quadword element of the mask register.
Each quadword element of the destination operand is copied from:
The register assignment of the implicit mask operand for BLENDVPD is defined to be the architectural register XMM0.
128-bit Legacy SSE version: The first source operand and the destination operand is the same. Bits (MAXVL-1:128) of the corresponding YMM destination register remain unchanged. The mask register operand is implicitly defined to be the architectural register XMM0. An attempt to execute BLENDVPD with a VEX prefix will cause #UD.
VEX.128 encoded version: The first source operand and the destination operand are XMM registers. The second source operand is an XMM register or 128-bit memory location. The mask operand is the third source register, and encoded in bits[7:4] of the immediate byte(imm8). The bits[3:0] of imm8 are ignored. In 32-bit mode, imm8[7] is ignored. The upper bits (MAXVL-1:128) of the corresponding YMM register (destination register) are zeroed. VEX.W must be 0, otherwise, the instruction will #UD.
",
+ "tooltip": "Conditionally copy each quadword data element of double precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each quadword element of the mask register.",
"url": "https://www.felixcloutier.com/x86/BLENDVPD.html"
};
case "BLENDVPS":
case "VBLENDVPS":
return {
- "html": "
Conditionally copy each dword data element of single-precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each dword element of the mask register.
Each quadword element of the destination operand is copied from:
The register assignment of the implicit mask operand for BLENDVPS is defined to be the architectural register XMM0.
128-bit Legacy SSE version: The first source operand and the destination operand is the same. Bits (MAXVL-1:128) of the corresponding YMM destination register remain unchanged. The mask register operand is implicitly defined to be the architectural register XMM0. An attempt to execute BLENDVPS with a VEX prefix will cause #UD.
VEX.128 encoded version: The first source operand and the destination operand are XMM registers. The second source operand is an XMM register or 128-bit memory location. The mask operand is the third source register, and encoded in bits[7:4] of the immediate byte(imm8). The bits[3:0] of imm8 are ignored. In 32-bit mode, imm8[7] is ignored. The upper bits (MAXVL-1:128) of the corresponding YMM register (destination register) are zeroed. VEX.W must be 0, otherwise, the instruction will #UD.
",
- "tooltip": "Conditionally copy each dword data element of single-precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each dword element of the mask register.",
+ "html": "
Conditionally copy each dword data element of single precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each dword element of the mask register.
Each quadword element of the destination operand is copied from:
The register assignment of the implicit mask operand for BLENDVPS is defined to be the architectural register XMM0.
128-bit Legacy SSE version: The first source operand and the destination operand is the same. Bits (MAXVL-1:128) of the corresponding YMM destination register remain unchanged. The mask register operand is implicitly defined to be the architectural register XMM0. An attempt to execute BLENDVPS with a VEX prefix will cause #UD.
VEX.128 encoded version: The first source operand and the destination operand are XMM registers. The second source operand is an XMM register or 128-bit memory location. The mask operand is the third source register, and encoded in bits[7:4] of the immediate byte(imm8). The bits[3:0] of imm8 are ignored. In 32-bit mode, imm8[7] is ignored. The upper bits (MAXVL-1:128) of the corresponding YMM register (destination register) are zeroed. VEX.W must be 0, otherwise, the instruction will #UD.
",
+ "tooltip": "Conditionally copy each dword data element of single precision floating-point value from the second source operand and the first source operand depending on mask bits defined in the mask register operand. The mask bits are the most significant bit in each dword element of the mask register.",
"url": "https://www.felixcloutier.com/x86/BLENDVPS.html"
};
@@ -320,7 +320,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "BSF":
return {
- "html": "
Searches the source operand (second operand) for the least significant set bit (1 bit). If a least significant 1 bit is found, its bit index is stored in the destination operand (first operand). The source operand can be a register or a memory location; the destination operand is a register. The bit index is an unsigned offset from bit 0 of the source operand. If the content of the source operand is 0, the content of the destination operand is undefined.
In 64-bit mode, the instruction\u2019s default operation size access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "html": "
Searches the source operand (second operand) for the least significant set bit (1 bit). If a least significant 1 bit is found, its bit index is stored in the destination operand (first operand). The source operand can be a register or a memory location; the destination operand is a register. The bit index is an unsigned offset from bit 0 of the source operand. If the content of the source operand is 0, the content of the destination operand is undefined.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Using a REX prefix in the form of REX.R permits access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
"tooltip": "Searches the source operand (second operand) for the least significant set bit (1 bit). If a least significant 1 bit is found, its bit index is stored in the destination operand (first operand). The source operand can be a register or a memory location; the destination operand is a register. The bit index is an unsigned offset from bit 0 of the source operand. If the content of the source operand is 0, the content of the destination operand is undefined.",
"url": "https://www.felixcloutier.com/x86/BSF.html"
};
@@ -376,7 +376,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CALL":
return {
- "html": "
Saves procedure linking information on the stack and branches to the called procedure specified using the target operand. The target operand specifies the address of the first instruction in the called procedure. The operand can be an immediate value, a general-purpose register, or a memory location.
This instruction can be used to execute four types of calls:
The latter two call types (inter-privilege-level call and task switch) can only be executed in protected mode. See \u201cCalling Procedures Using Call and RET\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for additional information on near, far, and inter-privilege-level calls. See Chapter 7, \u201cTask Management,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for information on performing task switches with the CALL instruction.
Near Call. When executing a near call, the processor pushes the value of the EIP register (which contains the offset of the instruction following the CALL instruction) on the stack (for use later as a return-instruction pointer). The processor then branches to the address in the current code segment specified by the target operand. The target operand specifies either an absolute offset in the code segment (an offset from the base of the code segment) or a relative offset (a signed displacement relative to the current value of the instruction pointer in the EIP register; this value points to the instruction following the CALL instruction). The CS register is not changed on near calls.
For a near call absolute, an absolute offset is specified indirectly in a general-purpose register or a memory location (r/m16, r/m32, or r/m64). The operand-size attribute determines the size of the target operand (16, 32 or 64 bits). When in 64-bit mode, the operand size for near call (and all near branches) is forced to 64-bits. Absolute offsets are loaded directly into the EIP(RIP) register. If the operand size attribute is 16, the upper two bytes of the EIP register are cleared, resulting in a maximum instruction pointer size of 16 bits. When accessing an absolute offset indirectly using the stack pointer [ESP] as the base register, the base value used is the value of the ESP before the instruction executes.
",
+ "html": "
Saves procedure linking information on the stack and branches to the called procedure specified using the target operand. The target operand specifies the address of the first instruction in the called procedure. The operand can be an immediate value, a general-purpose register, or a memory location.
This instruction can be used to execute four types of calls:
The latter two call types (inter-privilege-level call and task switch) can only be executed in protected mode. See \u201cCalling Procedures Using Call and RET\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for additional information on near, far, and inter-privilege-level calls. See Chapter 8, \u201cTask Management,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for information on performing task switches with the CALL instruction.
Near Call. When executing a near call, the processor pushes the value of the EIP register (which contains the offset of the instruction following the CALL instruction) on the stack (for use later as a return-instruction pointer). The processor then branches to the address in the current code segment specified by the target operand. The target operand specifies either an absolute offset in the code segment (an offset from the base of the code segment) or a relative offset (a signed displacement relative to the current value of the instruction pointer in the EIP register; this value points to the instruction following the CALL instruction). The CS register is not changed on near calls.
For a near call absolute, an absolute offset is specified indirectly in a general-purpose register or a memory location (r/m16, r/m32, or r/m64). The operand-size attribute determines the size of the target operand (16, 32 or 64 bits). When in 64-bit mode, the operand size for near call (and all near branches) is forced to 64-bits. Absolute offsets are loaded directly into the EIP(RIP) register. If the operand size attribute is 16, the upper two bytes of the EIP register are cleared, resulting in a maximum instruction pointer size of 16 bits. When accessing an absolute offset indirectly using the stack pointer [ESP] as the base register, the base value used is the value of the ESP before the instruction executes.
",
"tooltip": "Saves procedure linking information on the stack and branches to the called procedure specified using the target operand. The target operand specifies the address of the first instruction in the called procedure. The operand can be an immediate value, a general-purpose register, or a memory location.",
"url": "https://www.felixcloutier.com/x86/CALL.html"
};
@@ -392,8 +392,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CLAC":
return {
- "html": "
Clears the AC flag bit in EFLAGS register. This disables any alignment checking of user-mode data accesses. If the SMAP bit is set in the CR4 register, this disallows explicit supervisor-mode data accesses to user-mode pages.
This instruction's operation is the same in non-64-bit modes and 64-bit mode. Attempts to execute CLAC when CPL > 0 cause #UD.
",
- "tooltip": "Clears the AC flag bit in EFLAGS register. This disables any alignment checking of user-mode data accesses. If the SMAP bit is set in the CR4 register, this disallows explicit supervisor-mode data accesses to user-mode pages.",
+ "html": "
Clears the AC flag bit in EFLAGS register. This disables any alignment checking of user-mode data accesses. Ifthe SMAP bit is set in the CR4 register, this disallows explicit supervisor-mode data accesses to user-mode pages.
This instruction's operation is the same in non-64-bit modes and 64-bit mode. Attempts to execute CLAC when CPL > 0 cause #UD.
",
+ "tooltip": "Clears the AC flag bit in EFLAGS register. This disables any alignment checking of user-mode data accesses. Ifthe SMAP bit is set in the CR4 register, this disallows explicit supervisor-mode data accesses to user-mode pages.",
"url": "https://www.felixcloutier.com/x86/CLAC.html"
};
@@ -441,11 +441,18 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CLTS":
return {
- "html": "
Clears the task-switched (TS) flag in the CR0 register. This instruction is intended for use in operating-system procedures. It is a privileged instruction that can only be executed at a CPL of 0. It is allowed to be executed in real-address mode to allow initialization for protected mode.
The processor sets the TS flag every time a task switch occurs. The flag is used to synchronize the saving of FPU context in multitasking applications. See the description of the TS flag in the section titled \u201cControl Registers\u201d in Chapter 2 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for more information about this flag.
CLTS operation is the same in non-64-bit modes and 64-bit mode.
See Chapter 25, \u201cVMX Non-Root Operation,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about the behavior of this instruction in VMX non-root operation.
",
+ "html": "
Clears the task-switched (TS) flag in the CR0 register. This instruction is intended for use in operating-system procedures. It is a privileged instruction that can only be executed at a CPL of 0. It is allowed to be executed in real-address mode to allow initialization for protected mode.
The processor sets the TS flag every time a task switch occurs. The flag is used to synchronize the saving of FPU context in multitasking applications. See the description of the TS flag in the section titled \u201cControl Registers\u201d in Chapter 2 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for more information about this flag.
CLTS operation is the same in non-64-bit modes and 64-bit mode.
See Chapter 26, \u201cVMX Non-Root Operation,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about the behavior of this instruction in VMX non-root operation.
",
"tooltip": "Clears the task-switched (TS) flag in the CR0 register. This instruction is intended for use in operating-system procedures. It is a privileged instruction that can only be executed at a CPL of 0. It is allowed to be executed in real-address mode to allow initialization for protected mode.",
"url": "https://www.felixcloutier.com/x86/CLTS.html"
};
+ case "CLUI":
+ return {
+ "html": "
CLUI clears the user interrupt flag (UIF). Its effect takes place immediately: a user interrupt cannot be delivered on the instruction boundary following CLUI.
An execution of CLUI inside a transactional region causes a transactional abort; the abort loads EAX as it would have had it been caused due to an execution of CLI.
",
+ "tooltip": "CLUI clears the user interrupt flag (UIF). Its effect takes place immediately: a user interrupt cannot be delivered on the instruction boundary following CLUI.",
+ "url": "https://www.felixcloutier.com/x86/CLUI.html"
+ };
+
case "CLWB":
return {
"html": "
Writes back to memory the cache line (if modified) that contains the linear address specified with the memory operand from any level of the cache hierarchy in the cache coherence domain. The line may be retained in the cache hierarchy in non-modified state. Retaining the line in the cache hierarchy is a performance optimization (treated as a hint by hardware) to reduce the possibility of cache miss on a subsequent access. Hardware may choose to retain the line at any of the levels in the cache hierarchy, and in some cases, may invalidate the line from the cache hierarchy. The source operand is a byte memory location.
The availability of CLWB instruction is indicated by the presence of the CPUID feature flag CLWB (bit 24 of the EBX register, see \u201cCPUID \u2014 CPU Identification\u201d in this chapter). The aligned cache line size affected is also indicated with the CPUID instruction (bits 8 through 15 of the EBX register when the initial value in the EAX register is 1).
The memory attribute of the page containing the affected line has no effect on the behavior of this instruction. It should be noted that processors are free to speculatively fetch and cache data from system memory regions that are assigned a memory-type allowing for speculative reads (such as, the WB, WC, and WT memory types). PREFETCHh instructions can be used to provide the processor with hints for this speculative behavior. Because this speculative fetching can occur at any time and is not tied to instruction execution, the CLWB instruction is not ordered with respect to PREFETCHh instructions or any of the speculative fetching mechanisms (that is, data can be speculatively loaded into a cache line just before, during, or after the execution of a CLWB instruction that references the cache line).
Executions of the CLWB instruction are ordered with respect to fence instructions and to locked read-modify-write instructions; they are also ordered with respect to older writes to the cache line being written back. They are not ordered with respect to other executions of CLWB, to executions of CLFLUSH and CLFLUSHOPT, or to younger writes to the cache line being written back. Software can use the SFENCE instruction to order an execution of CLWB relative to one of those operations.
For usages that require only writing back modified data from cache lines to memory (do not require the line to be invalidated), and expect to subsequently access the data, software is recommended to use CLWB (with appropriate fencing) instead of CLFLUSH or CLFLUSHOPT for improved performance.
",
@@ -498,7 +505,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CMP":
return {
- "html": "
Compares the first source operand with the second source operand and sets the status flags in the EFLAGS register according to the results. The comparison is performed by subtracting the second operand from the first operand and then setting the status flags in the same manner as the SUB instruction. When an immediate value is used as an operand, it is sign-extended to the length of the first operand.
The condition codes used by the Jcc, CMOVcc, and SETcc instructions are based on the results of a CMP instruction. Appendix B, \u201cEFLAGS Condition Codes,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, shows the relationship of the status flags and the condition codes.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "html": "
Compares the first source operand with the second source operand and sets the status flags in the EFLAGS register according to the results. The comparison is performed by subtracting the second operand from the first operand and then setting the status flags in the same manner as the SUB instruction. When an immediate value is used as an operand, it is sign-extended to the length of the first operand.
The condition codes used by the Jcc, CMOVcc, and SETcc instructions are based on the results of a CMP instruction. Appendix B, \u201cEFLAGS Condition Codes,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, shows the relationship of the status flags and the condition codes.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
"tooltip": "Compares the first source operand with the second source operand and sets the status flags in the EFLAGS register according to the results. The comparison is performed by subtracting the second operand from the first operand and then setting the status flags in the same manner as the SUB instruction. When an immediate value is used as an operand, it is sign-extended to the length of the first operand.",
"url": "https://www.felixcloutier.com/x86/CMP.html"
};
@@ -506,16 +513,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CMPPD":
case "VCMPPD":
return {
- "html": "
Performs a SIMD compare of the packed double-precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands.
EVEX encoded versions: The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand (first operand) is an opmask register. Comparison results are written to the destination operand under the writemask k2. Each comparison result is a single mask bit of 1 (comparison true) or 0 (comparison false).
VEX.256 encoded version: The first source operand (second operand) is a YMM register. The second source operand (third operand) can be a YMM register or a 256-bit memory location. The destination operand (first operand) is a YMM register. Four comparisons are performed with results written to the destination operand. The result of each comparison is a quadword mask of all 1s (comparison true) or all 0s (comparison false).
128-bit Legacy SSE version: The first source and destination operand (first operand) is an XMM register. The second source operand (second operand) can be an XMM register or 128-bit memory location. Bits (MAXVL-1:128) of the corresponding ZMM destination register remain unchanged. Two comparisons are performed with results written to bits 127:0 of the destination operand. The result of each comparison is a quadword mask of all 1s (comparison true) or all 0s (comparison false).
VEX.128 encoded version: The first source operand (second operand) is an XMM register. The second source operand (third operand) can be an XMM register or a 128-bit memory location. Bits (MAXVL-1:128) of the destination ZMM register are zeroed. Two comparisons are performed with results written to bits 127:0 of the destination operand.
",
- "tooltip": "Performs a SIMD compare of the packed double-precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands.",
+ "html": "
Performs a SIMD compare of the packed double precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands.
EVEX encoded versions: The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand (first operand) is an opmask register. Comparison results are written to the destination operand under the writemask k2. Each comparison result is a single mask bit of 1 (comparison true) or 0 (comparison false).
VEX.256 encoded version: The first source operand (second operand) is a YMM register. The second source operand (third operand) can be a YMM register or a 256-bit memory location. The destination operand (first operand) is a YMM register. Four comparisons are performed with results written to the destination operand. The result of each comparison is a quadword mask of all 1s (comparison true) or all 0s (comparison false).
128-bit Legacy SSE version: The first source and destination operand (first operand) is an XMM register. The second source operand (second operand) can be an XMM register or 128-bit memory location. Bits (MAXVL-1:128) of the corresponding ZMM destination register remain unchanged. Two comparisons are performed with results written to bits 127:0 of the destination operand. The result of each comparison is a quadword mask of all 1s (comparison true) or all 0s (comparison false).
VEX.128 encoded version: The first source operand (second operand) is an XMM register. The second source operand (third operand) can be an XMM register or a 128-bit memory location. Bits (MAXVL-1:128) of the destination ZMM register are zeroed. Two comparisons are performed with results written to bits 127:0 of the destination operand.
",
+ "tooltip": "Performs a SIMD compare of the packed double precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands.",
"url": "https://www.felixcloutier.com/x86/CMPPD.html"
};
case "CMPPS":
case "VCMPPS":
return {
- "html": "
Performs a SIMD compare of the packed single-precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each of the pairs of packed values.
EVEX encoded versions: The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand (first operand) is an opmask register. Comparison results are written to the destination operand under the writemask k2. Each comparison result is a single mask bit of 1 (comparison true) or 0 (comparison false).
VEX.256 encoded version: The first source operand (second operand) is a YMM register. The second source operand (third operand) can be a YMM register or a 256-bit memory location. The destination operand (first operand) is a YMM register. Eight comparisons are performed with results written to the destination operand. The result of each comparison is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
128-bit Legacy SSE version: The first source and destination operand (first operand) is an XMM register. The second source operand (second operand) can be an XMM register or 128-bit memory location. Bits (MAXVL-1:128) of the corresponding ZMM destination register remain unchanged. Four comparisons are performed with results written to bits 127:0 of the destination operand. The result of each comparison is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
VEX.128 encoded version: The first source operand (second operand) is an XMM register. The second source operand (third operand) can be an XMM register or a 128-bit memory location. Bits (MAXVL-1:128) of the destina-
",
- "tooltip": "Performs a SIMD compare of the packed single-precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each of the pairs of packed values.",
+ "html": "
Performs a SIMD compare of the packed single precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each of the pairs of packed values.
EVEX encoded versions: The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand (first operand) is an opmask register. Comparison results are written to the destination operand under the writemask k2. Each comparison result is a single mask bit of 1 (comparison true) or 0 (comparison false).
VEX.256 encoded version: The first source operand (second operand) is a YMM register. The second source operand (third operand) can be a YMM register or a 256-bit memory location. The destination operand (first operand) is a YMM register. Eight comparisons are performed with results written to the destination operand. The result of each comparison is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
128-bit Legacy SSE version: The first source and destination operand (first operand) is an XMM register. The second source operand (second operand) can be an XMM register or 128-bit memory location. Bits (MAXVL-1:128) of the corresponding ZMM destination register remain unchanged. Four comparisons are performed with results written to bits 127:0 of the destination operand. The result of each comparison is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
VEX.128 encoded version: The first source operand (second operand) is an XMM register. The second source operand (third operand) can be an XMM register or a 128-bit memory location. Bits (MAXVL-1:128) of the destination ZMM register are zeroed. Four comparisons are performed with results written to bits 127:0 of the destination operand.
",
+ "tooltip": "Performs a SIMD compare of the packed single precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each of the pairs of packed values.",
"url": "https://www.felixcloutier.com/x86/CMPPS.html"
};
@@ -533,8 +540,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CMPSS":
case "VCMPSS":
return {
- "html": "
Compares the low single-precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate operand) specifies the type of comparison performed.
128-bit Legacy SSE version: The first source and destination operand (first operand) is an XMM register. The second source operand (second operand) can be an XMM register or 32-bit memory location. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged. The comparison result is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
VEX.128 encoded version: The first source operand (second operand) is an XMM register. The second source operand (third operand) can be an XMM register or a 32-bit memory location. The result is stored in the low 32 bits of the destination operand; bits 127:32 of the destination operand are copied from the first source operand. Bits (MAXVL-1:128) of the destination ZMM register are zeroed. The comparison result is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
EVEX encoded version: The first source operand (second operand) is an XMM register. The second source operand can be a XMM register or a 32-bit memory location. The destination operand (first operand) is an opmask register. The comparison result is a single mask bit of 1 (comparison true) or 0 (comparison false), written to the destination starting from the LSB according to the writemask k2. Bits (MAX_KL-1:128) of the destination register are cleared.
The comparison predicate operand is an 8-bit immediate:
",
- "tooltip": "Compares the low single-precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate operand) specifies the type of comparison performed.",
+ "html": "
Compares the low single precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate operand) specifies the type of comparison performed.
128-bit Legacy SSE version: The first source and destination operand (first operand) is an XMM register. The second source operand (second operand) can be an XMM register or 32-bit memory location. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged. The comparison result is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
VEX.128 encoded version: The first source operand (second operand) is an XMM register. The second source operand (third operand) can be an XMM register or a 32-bit memory location. The result is stored in the low 32 bits of the destination operand; bits 127:32 of the destination operand are copied from the first source operand. Bits (MAXVL-1:128) of the destination ZMM register are zeroed. The comparison result is a doubleword mask of all 1s (comparison true) or all 0s (comparison false).
EVEX encoded version: The first source operand (second operand) is an XMM register. The second source operand can be a XMM register or a 32-bit memory location. The destination operand (first operand) is an opmask register. The comparison result is a single mask bit of 1 (comparison true) or 0 (comparison false), written to the destination starting from the LSB according to the writemask k2. Bits (MAX_KL-1:128) of the destination register are cleared.
The comparison predicate operand is an 8-bit immediate:
",
+ "tooltip": "Compares the low single precision floating-point values in the second source operand and the first source operand and returns the result of the comparison to the destination operand. The comparison predicate operand (immediate operand) specifies the type of comparison performed.",
"url": "https://www.felixcloutier.com/x86/CMPSS.html"
};
@@ -547,7 +554,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CMPXCHG8B":
return {
- "html": "
Compares the 64-bit value in EDX:EAX (or 128-bit value in RDX:RAX if operand size is 128 bits) with the operand (destination operand). If the values are equal, the 64-bit value in ECX:EBX (or 128-bit value in RCX:RBX) is stored in the destination operand. Otherwise, the value in the destination operand is loaded into EDX:EAX (or RDX:RAX). The destination operand is an 8-byte memory location (or 16-byte memory location if operand size is 128 bits). For the EDX:EAX and ECX:EBX register pairs, EDX and ECX contain the high-order 32 bits and EAX and EBX contain the low-order 32 bits of a 64-bit value. For the RDX:RAX and RCX:RBX register pairs, RDX and RCX contain the high-order 64 bits and RAX and RBX contain the low-order 64bits of a 128-bit value.
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically. To simplify the interface to the processor\u2019s bus, the destination operand receives a write cycle without regard to the result of the comparison. The destination operand is written back if the comparison fails; otherwise, the source operand is written into the destination. (The processor never produces a locked read without also producing a locked write.)
In 64-bit mode, default operation size is 64 bits. Use of the REX.W prefix promotes operation to 128 bits. Note that CMPXCHG16B requires that the destination (memory) operand be 16-byte aligned. See the summary chart at the beginning of this section for encoding data and limits. For information on the CPUID flag that indicates CMPXCHG16B, see page 3-237.
This instruction encoding is not supported on Intel processors earlier than the Pentium processors.
",
+ "html": "
Compares the 64-bit value in EDX:EAX (or 128-bit value in RDX:RAX if operand size is 128 bits) with the operand (destination operand). If the values are equal, the 64-bit value in ECX:EBX (or 128-bit value in RCX:RBX) is stored in the destination operand. Otherwise, the value in the destination operand is loaded into EDX:EAX (or RDX:RAX). The destination operand is an 8-byte memory location (or 16-byte memory location if operand size is 128 bits). For the EDX:EAX and ECX:EBX register pairs, EDX and ECX contain the high-order 32 bits and EAX and EBX contain the low-order 32 bits of a 64-bit value. For the RDX:RAX and RCX:RBX register pairs, RDX and RCX contain the high-order 64 bits and RAX and RBX contain the low-order 64bits of a 128-bit value.
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically. To simplify the interface to the processor\u2019s bus, the destination operand receives a write cycle without regard to the result of the comparison. The destination operand is written back if the comparison fails; otherwise, the source operand is written into the destination. (The processor never produces a locked read without also producing a locked write.)
In 64-bit mode, default operation size is 64 bits. Use of the REX.W prefix promotes operation to 128 bits. Note that CMPXCHG16B requires that the destination (memory) operand be 16-byte aligned. See the summary chart at the beginning of this section for encoding data and limits. For information on the CPUID flag that indicates CMPX-CHG16B, see page 3-243.
This instruction encoding is not supported on Intel processors earlier than the Pentium processors.
",
"tooltip": "Compares the 64-bit value in EDX:EAX (or 128-bit value in RDX:RAX if operand size is 128 bits) with the operand (destination operand). If the values are equal, the 64-bit value in ECX:EBX (or 128-bit value in RCX:RBX) is stored in the destination operand. Otherwise, the value in the destination operand is loaded into EDX:EAX (or RDX:RAX). The destination operand is an 8-byte memory location (or 16-byte memory location if operand size is 128 bits). For the EDX:EAX and ECX:EBX register pairs, EDX and ECX contain the high-order 32 bits and EAX and EBX contain the low-order 32 bits of a 64-bit value. For the RDX:RAX and RCX:RBX register pairs, RDX and RCX contain the high-order 64 bits and RAX and RBX contain the low-order 64bits of a 128-bit value.",
"url": "https://www.felixcloutier.com/x86/CMPXCHG8B%3ACMPXCHG16B.html"
};
@@ -555,16 +562,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "COMISD":
case "VCOMISD":
return {
- "html": "
Compares the double-precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 64 bit memory location. The COMISD instruction differs from the UCOMISD instruction in that it signals a SIMD floating-point invalid operation exception (#I) when a source operand is either a QNaN or SNaN. The UCOMISD instruction signals an invalid operation exception only if a source operand is an SNaN.
The EFLAGS register is not updated if an unmasked SIMD floating-point exception is generated.
VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
Software should ensure VCOMISD is encoded with VEX.L=0. Encoding VCOMISD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
- "tooltip": "Compares the double-precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
+ "html": "
Compares the double precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 64 bit memory location. The COMISD instruction differs from the UCOMISD instruction in that it signals a SIMD floating-point invalid operation exception (#I) when a source operand is either a QNaN or SNaN. The UCOMISD instruction signals an invalid operation exception only if a source operand is an SNaN.
The EFLAGS register is not updated if an unmasked SIMD floating-point exception is generated.
VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
Software should ensure VCOMISD is encoded with VEX.L=0. Encoding VCOMISD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
+ "tooltip": "Compares the double precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
"url": "https://www.felixcloutier.com/x86/COMISD.html"
};
case "COMISS":
case "VCOMISS":
return {
- "html": "
Compares the single-precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 32 bit memory location.
The COMISS instruction differs from the UCOMISS instruction in that it signals a SIMD floating-point invalid operation exception (#I) when a source operand is either a QNaN or SNaN. The UCOMISS instruction signals an invalid operation exception only if a source operand is an SNaN.
The EFLAGS register is not updated if an unmasked SIMD floating-point exception is generated.
VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Compares the single-precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
+ "html": "
Compares the single precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 32 bit memory location.
The COMISS instruction differs from the UCOMISS instruction in that it signals a SIMD floating-point invalid operation exception (#I) when a source operand is either a QNaN or SNaN. The UCOMISS instruction signals an invalid operation exception only if a source operand is an SNaN.
The EFLAGS register is not updated if an unmasked SIMD floating-point exception is generated.
VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Compares the single precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
"url": "https://www.felixcloutier.com/x86/COMISS.html"
};
@@ -585,170 +592,170 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CVTDQ2PD":
case "VCVTDQ2PD":
return {
- "html": "
Converts two, four or eight packed signed doubleword integers in the source operand (the second operand) to two, four or eight packed double-precision floating-point values in the destination operand (the first operand).
EVEX encoded versions: The source operand can be a YMM/XMM/XMM (low 64 bits) register, a 256/128/64-bit memory location or a 256/128/64-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1. Attempt to encode this instruction with EVEX embedded rounding is ignored.
VEX.256 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a YMM register.
VEX.128 encoded version: The source operand is an XMM register or 64- bit memory location. The destination operand is a XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The source operand is an XMM register or 64- bit memory location. The destination operand is an XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Converts two, four or eight packed signed doubleword integers in the source operand (the second operand) to two, four or eight packed double-precision floating-point values in the destination operand (the first operand).",
+ "html": "
Converts two, four or eight packed signed doubleword integers in the source operand (the second operand) to two, four or eight packed double precision floating-point values in the destination operand (the first operand).
EVEX encoded versions: The source operand can be a YMM/XMM/XMM (low 64 bits) register, a 256/128/64-bit memory location or a 256/128/64-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1. Attempt to encode this instruction with EVEX embedded rounding is ignored.
VEX.256 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a YMM register.
VEX.128 encoded version: The source operand is an XMM register or 64- bit memory location. The destination operand is a XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The source operand is an XMM register or 64- bit memory location. The destination operand is an XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Converts two, four or eight packed signed doubleword integers in the source operand (the second operand) to two, four or eight packed double precision floating-point values in the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/CVTDQ2PD.html"
};
case "CVTDQ2PS":
case "VCVTDQ2PS":
return {
- "html": "
Converts four, eight or sixteen packed signed doubleword integers in the source operand to four, eight or sixteen packed single-precision floating-point values in the destination operand.
EVEX encoded versions: The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding register destination are zeroed.
128-bit Legacy SSE version: The source operand is an XMM register or 128- bit memory location. The destination operand is an XMM register. The upper Bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Converts four, eight or sixteen packed signed doubleword integers in the source operand to four, eight or sixteen packed single-precision floating-point values in the destination operand.",
+ "html": "
Converts four, eight or sixteen packed signed doubleword integers in the source operand to four, eight or sixteen packed single precision floating-point values in the destination operand.
EVEX encoded versions: The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding register destination are zeroed.
128-bit Legacy SSE version: The source operand is an XMM register or 128- bit memory location. The destination operand is an XMM register. The upper Bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Converts four, eight or sixteen packed signed doubleword integers in the source operand to four, eight or sixteen packed single precision floating-point values in the destination operand.",
"url": "https://www.felixcloutier.com/x86/CVTDQ2PS.html"
};
case "CVTPD2DQ":
case "VCVTPD2DQ":
return {
- "html": "
Converts packed double-precision floating-point values in the source operand (second operand) to packed signed doubleword integers in the destination operand (first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1. The upper bits (MAXVL-1:256/128/64) of the corresponding destination are zeroed.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:64) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Converts packed double-precision floating-point values in the source operand (second operand) to packed signed doubleword integers in the destination operand (first operand).",
+ "html": "
Converts packed double precision floating-point values in the source operand (second operand) to packed signed doubleword integers in the destination operand (first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1. The upper bits (MAXVL-1:256/128/64) of the corresponding destination are zeroed.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:64) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Converts packed double precision floating-point values in the source operand (second operand) to packed signed doubleword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTPD2DQ.html"
};
case "CVTPD2PI":
return {
- "html": "
Converts two packed double-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).
The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTPD2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Converts two packed double-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).",
+ "html": "
Converts two packed double precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).
The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTPD2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Converts two packed double precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTPD2PI.html"
};
case "CVTPD2PS":
case "VCVTPD2PS":
return {
- "html": "
Converts two, four or eight packed double-precision floating-point values in the source operand (second operand) to two, four or eight packed single-precision floating-point values in the destination operand (first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM/XMM/XMM (low 64-bits) register conditionally updated with writemask k1. The upper bits (MAXVL-1:256/128/64) of the corresponding destination are zeroed.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:64) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Converts two, four or eight packed double-precision floating-point values in the source operand (second operand) to two, four or eight packed single-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts two, four or eight packed double precision floating-point values in the source operand (second operand) to two, four or eight packed single precision floating-point values in the destination operand (first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM/XMM/XMM (low 64-bits) register conditionally updated with writemask k1. The upper bits (MAXVL-1:256/128/64) of the corresponding destination are zeroed.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:64) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Converts two, four or eight packed double precision floating-point values in the source operand (second operand) to two, four or eight packed single precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTPD2PS.html"
};
case "CVTPI2PD":
return {
- "html": "
Converts two packed signed doubleword integers in the source operand (second operand) to two packed double-precision floating-point values in the destination operand (first operand).
The source operand can be an MMX technology register or a 64-bit memory location. The destination operand is an XMM register. In addition, depending on the operand configuration:
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Converts two packed signed doubleword integers in the source operand (second operand) to two packed double-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts two packed signed doubleword integers in the source operand (second operand) to two packed double precision floating-point values in the destination operand (first operand).
The source operand can be an MMX technology register or a 64-bit memory location. The destination operand is an XMM register. In addition, depending on the operand configuration:
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Converts two packed signed doubleword integers in the source operand (second operand) to two packed double precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTPI2PD.html"
};
case "CVTPI2PS":
return {
- "html": "
Converts two packed signed doubleword integers in the source operand (second operand) to two packed single-precision floating-point values in the destination operand (first operand).
The source operand can be an MMX technology register or a 64-bit memory location. The destination operand is an XMM register. The results are stored in the low quadword of the destination operand, and the high quadword remains unchanged. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTPI2PS instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Converts two packed signed doubleword integers in the source operand (second operand) to two packed single-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts two packed signed doubleword integers in the source operand (second operand) to two packed single precision floating-point values in the destination operand (first operand).
The source operand can be an MMX technology register or a 64-bit memory location. The destination operand is an XMM register. The results are stored in the low quadword of the destination operand, and the high quadword remains unchanged. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTPI2PS instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Converts two packed signed doubleword integers in the source operand (second operand) to two packed single precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTPI2PS.html"
};
case "CVTPS2DQ":
case "VCVTPS2DQ":
return {
- "html": "
Converts four, eight or sixteen packed single-precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX encoded versions: The source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Converts four, eight or sixteen packed single-precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.",
+ "html": "
Converts four, eight or sixteen packed single precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX encoded versions: The source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Converts four, eight or sixteen packed single precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/CVTPS2DQ.html"
};
case "CVTPS2PD":
case "VCVTPS2PD":
return {
- "html": "
Converts two, four or eight packed single-precision floating-point values in the source operand (second operand) to two, four or eight packed double-precision floating-point values in the destination operand (first operand).
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64-bits) register, a 256/128/64-bit memory location or a 256/128/64-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination ZMM register are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 64- bit memory location. The destination operand is a XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The source operand is an XMM register or 64- bit memory location. The destination operand is an XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Converts two, four or eight packed single-precision floating-point values in the source operand (second operand) to two, four or eight packed double-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts two, four or eight packed single precision floating-point values in the source operand (second operand) to two, four or eight packed double precision floating-point values in the destination operand (first operand).
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64-bits) register, a 256/128/64-bit memory location or a 256/128/64-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination ZMM register are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 64- bit memory location. The destination operand is a XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The source operand is an XMM register or 64- bit memory location. The destination operand is an XMM register. The upper Bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Converts two, four or eight packed single precision floating-point values in the source operand (second operand) to two, four or eight packed double precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTPS2PD.html"
};
case "CVTPS2PI":
return {
- "html": "
Converts two packed single-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).
The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register. When the source operand is an XMM register, the two single-precision floating-point values are contained in the low quadword of the register. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
CVTPS2PI causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTPS2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Converts two packed single-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).",
+ "html": "
Converts two packed single precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).
The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register. When the source operand is an XMM register, the two single precision floating-point values are contained in the low quadword of the register. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
CVTPS2PI causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTPS2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Converts two packed single precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTPS2PI.html"
};
case "CVTSD2SI":
case "VCVTSD2SI":
return {
- "html": "
Converts a double-precision floating-point value in the source operand (the second operand) to a signed double-word integer in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
If a converted result exceeds the range limits of signed doubleword integer (in non-64-bit modes or 64-bit mode with REX.W/VEX.W/EVEX.W=0), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
If a converted result exceeds the range limits of signed quadword integer (in 64-bit mode and REX.W/VEX.W/EVEX.W = 1), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000_00000000H) is returned.
Legacy SSE instruction: Use of the REX.W prefix promotes the instruction to produce 64-bit data in 64-bit mode. See the summary chart at the beginning of this section for encoding data and limits.
",
- "tooltip": "Converts a double-precision floating-point value in the source operand (the second operand) to a signed double-word integer in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.",
+ "html": "
Converts a double precision floating-point value in the source operand (the second operand) to a signed double-word integer in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
If a converted result exceeds the range limits of signed doubleword integer (in non-64-bit modes or 64-bit mode with REX.W/VEX.W/EVEX.W=0), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
If a converted result exceeds the range limits of signed quadword integer (in 64-bit mode and REX.W/VEX.W/EVEX.W = 1), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000_00000000H) is returned.
Legacy SSE instruction: Use of the REX.W prefix promotes the instruction to produce 64-bit data in 64-bit mode. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "tooltip": "Converts a double precision floating-point value in the source operand (the second operand) to a signed double-word integer in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.",
"url": "https://www.felixcloutier.com/x86/CVTSD2SI.html"
};
case "CVTSD2SS":
case "VCVTSD2SS":
return {
- "html": "
Converts a double-precision floating-point value in the \u201cconvert-from\u201d source operand (the second operand in SSE2 version, otherwise the third operand) to a single-precision floating-point value in the destination operand.
When the \u201cconvert-from\u201d operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register. The result is stored in the low doubleword of the destination operand. When the conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
128-bit Legacy SSE version: The \u201cconvert-from\u201d source operand (the second operand) is an XMM register or memory location. Bits (MAXVL-1:32) of the corresponding destination register remain unchanged. The destination operand is an XMM register.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers. Bits (127:32) of the XMM register destination are copied from the corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: the converted result in written to the low doubleword element of the destination under the writemask.
",
- "tooltip": "Converts a double-precision floating-point value in the \u201cconvert-from\u201d source operand (the second operand in SSE2 version, otherwise the third operand) to a single-precision floating-point value in the destination operand.",
+ "html": "
Converts a double precision floating-point value in the \u201cconvert-from\u201d source operand (the second operand in SSE2 version, otherwise the third operand) to a single precision floating-point value in the destination operand.
When the \u201cconvert-from\u201d operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register. The result is stored in the low doubleword of the destination operand. When the conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
128-bit Legacy SSE version: The \u201cconvert-from\u201d source operand (the second operand) is an XMM register or memory location. Bits (MAXVL-1:32) of the corresponding destination register remain unchanged. The destination operand is an XMM register.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers. Bits (127:32) of the XMM register destination are copied from the corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: the converted result in written to the low doubleword element of the destination under the writemask.
",
+ "tooltip": "Converts a double precision floating-point value in the \u201cconvert-from\u201d source operand (the second operand in SSE2 version, otherwise the third operand) to a single precision floating-point value in the destination operand.",
"url": "https://www.felixcloutier.com/x86/CVTSD2SS.html"
};
case "CVTSI2SD":
case "VCVTSI2SD":
return {
- "html": "
Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a double-precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand, and the high quadword left unchanged. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
The second source operand can be a general-purpose register or a 32/64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: Use of the REX.W prefix promotes the instruction to 64-bit operands. The \u201cconvert-from\u201d source operand (the second operand) is a general-purpose register or memory location. The destination is an XMM register Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be a general-purpose register or a memory location. The first source and destination operands are XMM registers. Bits (127:64) of the XMM register destination are copied from the corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.W0 version: attempt to encode this instruction with EVEX embedded rounding is ignored.
",
- "tooltip": "Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a double-precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand, and the high quadword left unchanged. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.",
+ "html": "
Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a double precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand, and the high quadword left unchanged. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
The second source operand can be a general-purpose register or a 32/64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: Use of the REX.W prefix promotes the instruction to 64-bit operands. The \u201cconvert-from\u201d source operand (the second operand) is a general-purpose register or memory location. The destination is an XMM register Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be a general-purpose register or a memory location. The first source and destination operands are XMM registers. Bits (127:64) of the XMM register destination are copied from the corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.W0 version: attempt to encode this instruction with EVEX embedded rounding is ignored.
",
+ "tooltip": "Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a double precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand, and the high quadword left unchanged. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.",
"url": "https://www.felixcloutier.com/x86/CVTSI2SD.html"
};
case "CVTSI2SS":
case "VCVTSI2SS":
return {
- "html": "
Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a single-precision floating-point value in the destination operand (first operand). The \u201cconvert-from\u201d source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand, and the upper three doublewords are left unchanged. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.
128-bit Legacy SSE version: In 64-bit mode, Use of the REX.W prefix promotes the instruction to use 64-bit input value. The \u201cconvert-from\u201d source operand (the second operand) is a general-purpose register or memory location. Bits (MAXVL-1:32) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be a general-purpose register or a memory location. The first source and destination operands are XMM registers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: the converted result in written to the low doubleword element of the destination under the writemask.
Software should ensure VCVTSI2SS is encoded with VEX.L=0. Encoding VCVTSI2SS with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
- "tooltip": "Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a single-precision floating-point value in the destination operand (first operand). The \u201cconvert-from\u201d source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand, and the upper three doublewords are left unchanged. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.",
+ "html": "
Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a single precision floating-point value in the destination operand (first operand). The \u201cconvert-from\u201d source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand, and the upper three doublewords are left unchanged. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.
128-bit Legacy SSE version: In 64-bit mode, Use of the REX.W prefix promotes the instruction to use 64-bit input value. The \u201cconvert-from\u201d source operand (the second operand) is a general-purpose register or memory location. Bits (MAXVL-1:32) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be a general-purpose register or a memory location. The first source and destination operands are XMM registers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: the converted result in written to the low doubleword element of the destination under the writemask.
Software should ensure VCVTSI2SS is encoded with VEX.L=0. Encoding VCVTSI2SS with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
+ "tooltip": "Converts a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the \u201cconvert-from\u201d source operand to a single precision floating-point value in the destination operand (first operand). The \u201cconvert-from\u201d source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand, and the upper three doublewords are left unchanged. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.",
"url": "https://www.felixcloutier.com/x86/CVTSI2SS.html"
};
case "CVTSS2SD":
case "VCVTSS2SD":
return {
- "html": "
Converts a single-precision floating-point value in the \u201cconvert-from\u201d source operand to a double-precision floating-point value in the destination operand. When the \u201cconvert-from\u201d source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register. The result is stored in the low quadword of the destination operand.
128-bit Legacy SSE version: The \u201cconvert-from\u201d source operand (the second operand) is an XMM register or memory location. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged. The destination operand is an XMM register.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers. Bits (127:64) of the XMM register destination are copied from the corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
Software should ensure VCVTSS2SD is encoded with VEX.L=0. Encoding VCVTSS2SD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
- "tooltip": "Converts a single-precision floating-point value in the \u201cconvert-from\u201d source operand to a double-precision floating-point value in the destination operand. When the \u201cconvert-from\u201d source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register. The result is stored in the low quadword of the destination operand.",
+ "html": "
Converts a single precision floating-point value in the \u201cconvert-from\u201d source operand to a double precision floating-point value in the destination operand. When the \u201cconvert-from\u201d source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register. The result is stored in the low quadword of the destination operand.
128-bit Legacy SSE version: The \u201cconvert-from\u201d source operand (the second operand) is an XMM register or memory location. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged. The destination operand is an XMM register.
VEX.128 and EVEX encoded versions: The \u201cconvert-from\u201d source operand (the third operand) can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers. Bits (127:64) of the XMM register destination are copied from the corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
Software should ensure VCVTSS2SD is encoded with VEX.L=0. Encoding VCVTSS2SD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
+ "tooltip": "Converts a single precision floating-point value in the \u201cconvert-from\u201d source operand to a double precision floating-point value in the destination operand. When the \u201cconvert-from\u201d source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register. The result is stored in the low quadword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/CVTSS2SD.html"
};
case "CVTSS2SI":
case "VCVTSS2SI":
return {
- "html": "
Converts a single-precision floating-point value in the source operand (the second operand) to a signed double-word integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
Legacy SSE instructions: In 64-bit mode, Use of the REX.W prefix promotes the instruction to produce 64-bit data. See the summary chart at the beginning of this section for encoding data and limits.
VEX.W1 and EVEX.W1 versions: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts a single-precision floating-point value in the source operand (the second operand) to a signed double-word integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.",
+ "html": "
Converts a single precision floating-point value in the source operand (the second operand) to a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
Legacy SSE instructions: In 64-bit mode, Use of the REX.W prefix promotes the instruction to produce 64-bit data. See the summary chart at the beginning of this section for encoding data and limits.
VEX.W1 and EVEX.W1 versions: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts a single precision floating-point value in the source operand (the second operand) to a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.",
"url": "https://www.felixcloutier.com/x86/CVTSS2SI.html"
};
case "CVTTPD2DQ":
case "VCVTTPD2DQ":
return {
- "html": "
Converts two, four or eight packed double-precision floating-point values in the source operand (second operand) to two, four or eight packed signed doubleword integers in the destination operand (first operand).
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM/XMM/XMM (low 64 bits) register conditionally updated with writemask k1. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:64) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Converts two, four or eight packed double-precision floating-point values in the source operand (second operand) to two, four or eight packed signed doubleword integers in the destination operand (first operand).",
+ "html": "
Converts two, four or eight packed double precision floating-point values in the source operand (second operand) to two, four or eight packed signed doubleword integers in the destination operand (first operand).
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM/XMM/XMM (low 64 bits) register conditionally updated with writemask k1. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:64) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Converts two, four or eight packed double precision floating-point values in the source operand (second operand) to two, four or eight packed signed doubleword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/CVTTPD2DQ.html"
};
case "CVTTPD2PI":
return {
- "html": "
Converts two packed double-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register.
When a conversion is inexact, a truncated (round toward zero) result is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTTPD2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Converts two packed double-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register.",
+ "html": "
Converts two packed double precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register.
When a conversion is inexact, a truncated (round toward zero) result is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTTPD2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Converts two packed double precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 128-bit memory location. The destination operand is an MMX technology register.",
"url": "https://www.felixcloutier.com/x86/CVTTPD2PI.html"
};
case "CVTTPS2DQ":
case "VCVTTPS2DQ":
return {
- "html": "
Converts four, eight or sixteen packed single-precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Converts four, eight or sixteen packed single-precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.",
+ "html": "
Converts four, eight or sixteen packed single precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The source operand is a YMM register or 256- bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The source operand is an XMM register or 128- bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Converts four, eight or sixteen packed single precision floating-point values in the source operand to four, eight or sixteen signed doubleword integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/CVTTPS2DQ.html"
};
case "CVTTPS2PI":
return {
- "html": "
Converts two packed single-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is an MMX technology register. When the source operand is an XMM register, the two single-precision floating-point values are contained in the low quadword of the register.
When a conversion is inexact, a truncated (round toward zero) result is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTTPS2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Converts two packed single-precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is an MMX technology register. When the source operand is an XMM register, the two single-precision floating-point values are contained in the low quadword of the register.",
+ "html": "
Converts two packed single precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is an MMX technology register. When the source operand is an XMM register, the two single precision floating-point values are contained in the low quadword of the register.
When a conversion is inexact, a truncated (round toward zero) result is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
This instruction causes a transition from x87 FPU to MMX technology operation (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]). If this instruction is executed while an x87 FPU floating-point exception is pending, the exception is handled before the CVTTPS2PI instruction is executed.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Converts two packed single precision floating-point values in the source operand (second operand) to two packed signed doubleword integers in the destination operand (first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is an MMX technology register. When the source operand is an XMM register, the two single precision floating-point values are contained in the low quadword of the register.",
"url": "https://www.felixcloutier.com/x86/CVTTPS2PI.html"
};
case "CVTTSD2SI":
case "VCVTTSD2SI":
return {
- "html": "
Converts a double-precision floating-point value in the source operand (the second operand) to a signed double-word integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
If a converted result exceeds the range limits of signed doubleword integer (in non-64-bit modes or 64-bit mode with REX.W/VEX.W/EVEX.W=0), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
If a converted result exceeds the range limits of signed quadword integer (in 64-bit mode and REX.W/VEX.W/EVEX.W = 1), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000_00000000H) is returned.
Legacy SSE instructions: In 64-bit mode, Use of the REX.W prefix promotes the instruction to 64-bit operation. See the summary chart at the beginning of this section for encoding data and limits.
",
- "tooltip": "Converts a double-precision floating-point value in the source operand (the second operand) to a signed double-word integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.",
+ "html": "
Converts a double precision floating-point value in the source operand (the second operand) to a signed double-word integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
If a converted result exceeds the range limits of signed doubleword integer (in non-64-bit modes or 64-bit mode with REX.W/VEX.W/EVEX.W=0), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned.
If a converted result exceeds the range limits of signed quadword integer (in 64-bit mode and REX.W/VEX.W/EVEX.W = 1), the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000_00000000H) is returned.
Legacy SSE instructions: In 64-bit mode, Use of the REX.W prefix promotes the instruction to 64-bit operation. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "tooltip": "Converts a double precision floating-point value in the source operand (the second operand) to a signed double-word integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.",
"url": "https://www.felixcloutier.com/x86/CVTTSD2SI.html"
};
case "CVTTSS2SI":
case "VCVTTSS2SI":
return {
- "html": "
Converts a single-precision floating-point value in the source operand (the second operand) to a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 32-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, a truncated (round toward zero) result is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised. If this exception is masked, the indefinite integer value (80000000H or 80000000_00000000H if operand size is 64 bits) is returned.
Legacy SSE instructions: In 64-bit mode, Use of the REX.W prefix promotes the instruction to 64-bit operation. See the summary chart at the beginning of this section for encoding data and limits.
VEX.W1 and EVEX.W1 versions: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts a single-precision floating-point value in the source operand (the second operand) to a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 32-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.",
+ "html": "
Converts a single precision floating-point value in the source operand (the second operand) to a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 32-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, a truncated (round toward zero) result is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised. If this exception is masked, the indefinite integer value (80000000H or 80000000_00000000H if operand size is 64 bits) is returned.
Legacy SSE instructions: In 64-bit mode, Use of the REX.W prefix promotes the instruction to 64-bit operation. See the summary chart at the beginning of this section for encoding data and limits.
VEX.W1 and EVEX.W1 versions: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts a single precision floating-point value in the source operand (the second operand) to a signed doubleword integer (or signed quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 32-bit memory location. The destination operand is a general purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.",
"url": "https://www.felixcloutier.com/x86/CVTTSS2SI.html"
};
@@ -792,61 +799,61 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "DIVPD":
case "VDIVPD":
return {
- "html": "
Performs a SIMD divide of the double-precision floating-point values in the first source operand by the floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand (the second operand) is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
VEX.128 encoded version: The first source operand (the second operand) is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding destination are zeroed.
128-bit Legacy SSE version: The second source operand (the second operand) can be an XMM register or an 128-bit memory location. The destination is the same as the first source operand. The upper bits (MAXVL-1:128) of the corresponding destination are unmodified.
",
- "tooltip": "Performs a SIMD divide of the double-precision floating-point values in the first source operand by the floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).",
+ "html": "
Performs a SIMD divide of the double precision floating-point values in the first source operand by the floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand (the second operand) is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
VEX.128 encoded version: The first source operand (the second operand) is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding destination are zeroed.
128-bit Legacy SSE version: The second source operand (the second operand) can be an XMM register or an 128-bit memory location. The destination is the same as the first source operand. The upper bits (MAXVL-1:128) of the corresponding destination are unmodified.
",
+ "tooltip": "Performs a SIMD divide of the double precision floating-point values in the first source operand by the floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/DIVPD.html"
};
case "DIVPS":
case "VDIVPS":
return {
- "html": "
Performs a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Performs a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).",
+ "html": "
Performs a SIMD divide of the four, eight or sixteen packed single precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single precision floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Performs a SIMD divide of the four, eight or sixteen packed single precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single precision floating-point values in the second source operand (the third operand). Results are written to the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/DIVPS.html"
};
case "DIVSD":
case "VDIVSD":
return {
- "html": "
Divides the low double-precision floating-point value in the first source operand by the low double-precision floating-point value in the second source operand, and stores the double-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:64) of the corresponding ZMM destination register remain unchanged.
VEX.128 encoded version: The first source operand is an xmm register encoded by VEX.vvvv. The quadword at bits 127:64 of the destination operand is copied from the corresponding quadword of the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.128 encoded version: The first source operand is an xmm register encoded by EVEX.vvvv. The quadword element of the destination operand at bits 127:64 are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low quadword element of the destination is updated according to the writemask.
",
- "tooltip": "Divides the low double-precision floating-point value in the first source operand by the low double-precision floating-point value in the second source operand, and stores the double-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination are XMM registers.",
+ "html": "
Divides the low double precision floating-point value in the first source operand by the low double precision floating-point value in the second source operand, and stores the double precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:64) of the corresponding ZMM destination register remain unchanged.
VEX.128 encoded version: The first source operand is an xmm register encoded by VEX.vvvv. The quadword at bits 127:64 of the destination operand is copied from the corresponding quadword of the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.128 encoded version: The first source operand is an xmm register encoded by EVEX.vvvv. The quadword element of the destination operand at bits 127:64 are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low quadword element of the destination is updated according to the writemask.
",
+ "tooltip": "Divides the low double precision floating-point value in the first source operand by the low double precision floating-point value in the second source operand, and stores the double precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination are XMM registers.",
"url": "https://www.felixcloutier.com/x86/DIVSD.html"
};
case "DIVSS":
case "VDIVSS":
return {
- "html": "
Divides the low single-precision floating-point value in the first source operand by the low single-precision floating-point value in the second source operand, and stores the single-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 encoded version: The first source operand is an xmm register encoded by VEX.vvvv. The three high-order doublewords of the destination operand are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.128 encoded version: The first source operand is an xmm register encoded by EVEX.vvvv. The doubleword elements of the destination operand at bits 127:32 are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low doubleword element of the destination is updated according to the writemask.
",
- "tooltip": "Divides the low single-precision floating-point value in the first source operand by the low single-precision floating-point value in the second source operand, and stores the single-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location.",
+ "html": "
Divides the low single precision floating-point value in the first source operand by the low single precision floating-point value in the second source operand, and stores the single precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 encoded version: The first source operand is an xmm register encoded by VEX.vvvv. The three high-order doublewords of the destination operand are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.128 encoded version: The first source operand is an xmm register encoded by EVEX.vvvv. The doubleword elements of the destination operand at bits 127:32 are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX version: The low doubleword element of the destination is updated according to the writemask.
",
+ "tooltip": "Divides the low single precision floating-point value in the first source operand by the low single precision floating-point value in the second source operand, and stores the single precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location.",
"url": "https://www.felixcloutier.com/x86/DIVSS.html"
};
case "DPPD":
case "VDPPD":
return {
- "html": "
Conditionally multiplies the packed double-precision floating-point values in the destination operand (first operand) with the packed double-precision floating-point values in the source (second operand) depending on a mask extracted from bits [5:4] of the immediate operand (third operand). If a condition mask bit is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
The two resulting double-precision values are summed into an intermediate result. The intermediate result is conditionally broadcasted to the destination using a broadcast mask specified by bits [1:0] of the immediate byte.
If a broadcast mask bit is \u201c1\u201d, the intermediate result is copied to the corresponding qword element in the destination operand. If a broadcast mask bit is zero, the corresponding element in the destination is set to zero.
DPPD follows the NaN forwarding rules stated in the Software Developer\u2019s Manual, vol. 1, table 4-7. These rules do not cover horizontal prioritization of NaNs. Horizontal propagation of NaNs to the destination and the positioning of those NaNs in the destination is implementation dependent. NaNs on the input sources or computationally generated NaNs will have at least one NaN propagated to the destination.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
",
- "tooltip": "Conditionally multiplies the packed double-precision floating-point values in the destination operand (first operand) with the packed double-precision floating-point values in the source (second operand) depending on a mask extracted from bits [5:4] of the immediate operand (third operand). If a condition mask bit is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.",
+ "html": "
Conditionally multiplies the packed double precision floating-point values in the destination operand (first operand) with the packed double precision floating-point values in the source (second operand) depending on a mask extracted from bits [5:4] of the immediate operand (third operand). If a condition mask bit is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
The two resulting double precision values are summed into an intermediate result. The intermediate result is conditionally broadcasted to the destination using a broadcast mask specified by bits [1:0] of the immediate byte.
If a broadcast mask bit is \u201c1\u201d, the intermediate result is copied to the corresponding qword element in the destination operand. If a broadcast mask bit is zero, the corresponding element in the destination is set to zero.
DPPD follows the NaN forwarding rules stated in the Software Developer\u2019s Manual, vol. 1, table 4-7. These rules do not cover horizontal prioritization of NaNs. Horizontal propagation of NaNs to the destination and the positioning of those NaNs in the destination is implementation dependent. NaNs on the input sources or computationally generated NaNs will have at least one NaN propagated to the destination.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
",
+ "tooltip": "Conditionally multiplies the packed double precision floating-point values in the destination operand (first operand) with the packed double precision floating-point values in the source (second operand) depending on a mask extracted from bits [5:4] of the immediate operand (third operand). If a condition mask bit is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.",
"url": "https://www.felixcloutier.com/x86/DPPD.html"
};
case "DPPS":
case "VDPPS":
return {
- "html": "
Conditionally multiplies the packed single precision floating-point values in the destination operand (first operand) with the packed single-precision floats in the source (second operand) depending on a mask extracted from the high 4 bits of the immediate byte (third operand). If a condition mask bit in Imm8[7:4] is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
The four resulting single-precision values are summed into an intermediate result. The intermediate result is conditionally broadcasted to the destination using a broadcast mask specified by bits [3:0] of the immediate byte.
If a broadcast mask bit is \u201c1\u201d, the intermediate result is copied to the corresponding dword element in the destination operand. If a broadcast mask bit is zero, the corresponding element in the destination is set to zero.
DPPS follows the NaN forwarding rules stated in the Software Developer\u2019s Manual, vol. 1, table 4-7. These rules do not cover horizontal prioritization of NaNs. Horizontal propagation of NaNs to the destination and the positioning of those NaNs in the destination is implementation dependent. NaNs on the input sources or computationally generated NaNs will have at least one NaN propagated to the destination.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
",
- "tooltip": "Conditionally multiplies the packed single precision floating-point values in the destination operand (first operand) with the packed single-precision floats in the source (second operand) depending on a mask extracted from the high 4 bits of the immediate byte (third operand). If a condition mask bit in Imm8[7:4] is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.",
+ "html": "
Conditionally multiplies the packed single precision floating-point values in the destination operand (first operand) with the packed single precision floats in the source (second operand) depending on a mask extracted from the high 4 bits of the immediate byte (third operand). If a condition mask bit in imm8[7:4] is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
The four resulting single precision values are summed into an intermediate result. The intermediate result is conditionally broadcasted to the destination using a broadcast mask specified by bits [3:0] of the immediate byte.
If a broadcast mask bit is \u201c1\u201d, the intermediate result is copied to the corresponding dword element in the destination operand. If a broadcast mask bit is zero, the corresponding element in the destination is set to zero.
DPPS follows the NaN forwarding rules stated in the Software Developer\u2019s Manual, vol. 1, table 4-7. These rules do not cover horizontal prioritization of NaNs. Horizontal propagation of NaNs to the destination and the positioning of those NaNs in the destination is implementation dependent. NaNs on the input sources or computationally generated NaNs will have at least one NaN propagated to the destination.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
",
+ "tooltip": "Conditionally multiplies the packed single precision floating-point values in the destination operand (first operand) with the packed single precision floats in the source (second operand) depending on a mask extracted from the high 4 bits of the immediate byte (third operand). If a condition mask bit in imm8[7:4] is zero, the corresponding multiplication is replaced by a value of 0.0 in the manner described by Section 12.8.4 of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.",
"url": "https://www.felixcloutier.com/x86/DPPS.html"
};
case "EAX":
return {
- "html": "
This leaf function copies a page from regular main memory to the EPC. As part of the copying process, the page is cryptographically authenticated and decrypted. This instruction can only be executed when current privilege level is 0.
The ELDB leaf function sets the BLOCK bit in the EPCM entry for the destination page in the EPC after copying. The ELDU leaf function clears the BLOCK bit in the EPCM entry for the destination page in the EPC after copying.
RBX contains the effective address of a PAGEINFO structure; RCX contains the effective address of the destination EPC page; RDX holds the effective address of the version array slot that holds the version of the page.
The ELDBC/ELDUC leafs are very similar to ELDB and ELDU. They provide an error code on the concurrency conflict for any of the pages which need to acquire a lock. These include the destination, SECS, and VA slot.
The table below provides additional information on the memory parameter of ELDB/ELDU leaf functions.
",
- "tooltip": "This leaf function copies a page from regular main memory to the EPC. As part of the copying process, the page is cryptographically authenticated and decrypted. This instruction can only be executed when current privilege level is 0.",
- "url": "https://www.felixcloutier.com/x86/ELDB%3AELDU%3AELDBC%3AELDUC.html"
+ "html": "
This leaf function changes the current SSA frame by decrementing TCS.CSSA for the current enclave thread. If the enclave has enabled CET shadow stacks or indirect branch tracking, then EDECCSSA also changes the current CET state save frame. This instruction leaf can only be executed inside an enclave.
The instruction faults if any of the following:
",
+ "tooltip": "This leaf function changes the current SSA frame by decrementing TCS.CSSA for the current enclave thread. If the enclave has enabled CET shadow stacks or indirect branch tracking, then EDECCSSA also changes the current CET state save frame. This instruction leaf can only be executed inside an enclave.",
+ "url": "https://www.felixcloutier.com/x86/EDECCSSA.html"
};
case "EMMS":
return {
- "html": "
Sets the values of all the tags in the x87 FPU tag word to empty (all 1s). This operation marks the x87 FPU data registers (which are aliased to the MMX technology registers) as available for use by x87 FPU floating-point instructions. (See Figure 8-7 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for the format of the x87 FPU tag word.) All other MMX instructions (other than the EMMS instruction) set all the tags in x87 FPU tag word to valid (all 0s).
The EMMS instruction must be used to clear the MMX technology state at the end of all MMX technology procedures or subroutines and before calling other procedures or subroutines that may execute x87 floating-point instructions. If a floating-point instruction loads one of the registers in the x87 FPU data register stack before the x87 FPU tag word has been reset by the EMMS instruction, an x87 floating-point register stack overflow can occur that will result in an x87 floating-point exception or incorrect result.
EMMS operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Sets the values of all the tags in the x87 FPU tag word to empty (all 1s). This operation marks the x87 FPU data registers (which are aliased to the MMX technology registers) as available for use by x87 FPU floating-point instructions. (See Figure 8-7 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for the format of the x87 FPU tag word.) All other MMX instructions (other than the EMMS instruction) set all the tags in x87 FPU tag word to valid (all 0s).
The EMMS instruction must be used to clear the MMX technology state at the end of all MMX technology procedures or subroutines and before calling other procedures or subroutines that may execute x87 floating-point instructions. If a floating-point instruction loads one of the registers in the x87 FPU data register stack before the x87 FPU tag word has been reset by the EMMS instruction, an x87 floating-point register stack overflow can occur that will result in an x87 floating-point exception or incorrect result.
EMMS operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Sets the values of all the tags in the x87 FPU tag word to empty (all 1s). This operation marks the x87 FPU data registers (which are aliased to the MMX technology registers) as available for use by x87 FPU floating-point instructions. (See Figure 8-7 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for the format of the x87 FPU tag word.) All other MMX instructions (other than the EMMS instruction) set all the tags in x87 FPU tag word to valid (all 0s).",
"url": "https://www.felixcloutier.com/x86/EMMS.html"
};
@@ -874,7 +881,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "ENTER":
return {
- "html": "
Creates a stack frame (comprising of space for dynamic storage and 1-32 frame pointer storage) for a procedure. The first operand (imm16) specifies the size of the dynamic storage in the stack frame (that is, the number of bytes of dynamically allocated on the stack for the procedure). The second operand (imm8) gives the lexical nesting level (0 to 31) of the procedure. The nesting level (imm8 mod 32) and the OperandSize attribute determine the size in bytes of the storage space for frame pointers.
The nesting level determines the number of frame pointers that are copied into the \u201cdisplay area\u201d of the new stack frame from the preceding frame. The default size of the frame pointer is the StackAddrSize attribute, but can be overridden using the 66H prefix. Thus, the OperandSize attribute determines the size of each frame pointer that will be copied into the stack frame and the data being transferred from SP/ESP/RSP register into the BP/EBP/RBP register.
The ENTER and companion LEAVE instructions are provided to support block structured languages. The ENTER instruction (when used) is typically the first instruction in a procedure and is used to set up a new stack frame for a procedure. The LEAVE instruction is then used at the end of the procedure (just before the RET instruction) to release the stack frame.
If the nesting level is 0, the processor pushes the frame pointer from the BP/EBP/RBP register onto the stack, copies the current stack pointer from the SP/ESP/RSP register into the BP/EBP/RBP register, and loads the SP/ESP/RSP register with the current stack-pointer value minus the value in the size operand. For nesting levels of 1 or greater, the processor pushes additional frame pointers on the stack before adjusting the stack pointer. These additional frame pointers provide the called procedure with access points to other nested frames on the stack. See \u201cProcedure Calls for Block-Structured Languages\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information about the actions of the ENTER instruction.
The ENTER instruction causes a page fault whenever a write using the final value of the stack pointer (within the current stack segment) would do so.
",
+ "html": "
Creates a stack frame (comprising of space for dynamic storage and 1-32 frame pointer storage) for a procedure. The first operand (imm16) specifies the size of the dynamic storage in the stack frame (that is, the number of bytes of dynamically allocated on the stack for the procedure). The second operand (imm8) gives the lexical nesting level (0 to 31) of the procedure. The nesting level (imm8 mod 32) and the OperandSize attribute determine the size in bytes of the storage space for frame pointers.
The nesting level determines the number of frame pointers that are copied into the \u201cdisplay area\u201d of the new stack frame from the preceding frame. The default size of the frame pointer is the StackAddrSize attribute, but can be overridden using the 66H prefix. Thus, the OperandSize attribute determines the size of each frame pointer that will be copied into the stack frame and the data being transferred from SP/ESP/RSP register into the BP/EBP/RBP register.
The ENTER and companion LEAVE instructions are provided to support block structured languages. The ENTER instruction (when used) is typically the first instruction in a procedure and is used to set up a new stack frame for a procedure. The LEAVE instruction is then used at the end of the procedure (just before the RET instruction) to release the stack frame.
If the nesting level is 0, the processor pushes the frame pointer from the BP/EBP/RBP register onto the stack, copies the current stack pointer from the SP/ESP/RSP register into the BP/EBP/RBP register, and loads the SP/ESP/RSP register with the current stack-pointer value minus the value in the size operand. For nesting levels of 1 or greater, the processor pushes additional frame pointers on the stack before adjusting the stack pointer. These additional frame pointers provide the called procedure with access points to other nested frames on the stack. See \u201cProcedure Calls for Block-Structured Languages\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information about the actions of the ENTER instruction.
The ENTER instruction causes a page fault whenever a write using the final value of the stack pointer (within the current stack segment) would do so.
",
"tooltip": "Creates a stack frame (comprising of space for dynamic storage and 1-32 frame pointer storage) for a procedure. The first operand (imm16) specifies the size of the dynamic storage in the stack frame (that is, the number of bytes of dynamically allocated on the stack for the procedure). The second operand (imm8) gives the lexical nesting level (0 to 31) of the procedure. The nesting level (imm8 mod 32) and the OperandSize attribute determine the size in bytes of the storage space for frame pointers.",
"url": "https://www.felixcloutier.com/x86/ENTER.html"
};
@@ -882,8 +889,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "EXTRACTPS":
case "VEXTRACTPS":
return {
- "html": "
Extracts a single-precision floating-point value from the source operand (second operand) at the 32-bit offset specified from imm8. Immediate bits higher than the most significant offset for the vector length are ignored.
The extracted single-precision floating-point value is stored in the low 32-bits of the destination operand
In 64-bit mode, destination register operand has default operand size of 64 bits. The upper 32-bits of the register are filled with zero. REX.W is ignored.
VEX.128 and EVEX encoded version: When VEX.W1 or EVEX.W1 form is used in 64-bit mode with a general purpose register (GPR) as a destination operand, the packed single quantity is zero extended to 64 bits.
VEX.vvvv/EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Extracts a single-precision floating-point value from the source operand (second operand) at the 32-bit offset specified from imm8. Immediate bits higher than the most significant offset for the vector length are ignored.",
+ "html": "
Extracts a single precision floating-point value from the source operand (second operand) at the 32-bit offset specified from imm8. Immediate bits higher than the most significant offset for the vector length are ignored.
The extracted single precision floating-point value is stored in the low 32-bits of the destination operand
In 64-bit mode, destination register operand has default operand size of 64 bits. The upper 32-bits of the register are filled with zero. REX.W is ignored.
VEX.128 and EVEX encoded version: When VEX.W1 or EVEX.W1 form is used in 64-bit mode with a general purpose register (GPR) as a destination operand, the packed single quantity is zero extended to 64 bits.
VEX.vvvv/EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Extracts a single precision floating-point value from the source operand (second operand) at the 32-bit offset specified from imm8. Immediate bits higher than the most significant offset for the vector length are ignored.",
"url": "https://www.felixcloutier.com/x86/EXTRACTPS.html"
};
@@ -891,8 +898,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FADDP":
case "FIADD":
return {
- "html": "
Adds the destination and source operands and stores the sum in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.
The no-operand version of the instruction adds the contents of the ST(0) register to the ST(1) register. The one-operand version adds the contents of a memory location (either a floating-point or an integer value) to the contents of the ST(0) register. The two-operand version, adds the contents of the ST(0) register to the ST(i) register or vice versa. The value in ST(0) can be doubled by coding:
",
- "tooltip": "Adds the destination and source operands and stores the sum in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.",
+ "html": "
Adds the destination and source operands and stores the sum in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.
The no-operand version of the instruction adds the contents of the ST(0) register to the ST(1) register. The one-operand version adds the contents of a memory location (either a floating-point or an integer value) to the contents of the ST(0) register. The two-operand version, adds the contents of the ST(0) register to the ST(i) register or vice versa. The value in ST(0) can be doubled by coding:
",
+ "tooltip": "Adds the destination and source operands and stores the sum in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.",
"url": "https://www.felixcloutier.com/x86/FADD%3AFADDP%3AFIADD.html"
};
@@ -904,9 +911,9 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
};
case "FCLEX":
- case "FNCLEX":
+ case "FNCLEX1":
return {
- "html": "
Clears the floating-point exception flags (PE, UE, OE, ZE, DE, and IE), the exception summary status flag (ES), the stack fault flag (SF), and the busy flag (B) in the FPU status word. The FCLEX instruction checks for and handles any pending unmasked floating-point exceptions before clearing the exception flags; the FNCLEX instruction does not.
The assembler issues two instructions for the FCLEX instruction (an FWAIT instruction followed by an FNCLEX instruction), and the processor executes each of these instructions separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
When operating a Pentium or Intel486 processor in MS-DOS* compatibility mode, it is possible (under unusual circumstances) for an FNCLEX instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNCLEX instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
This instruction affects only the x87 FPU floating-point exception flags. It does not affect the SIMD floating-point exception flags in the MXCSR register.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Clears the floating-point exception flags (PE, UE, OE, ZE, DE, and IE), the exception summary status flag (ES), the stack fault flag (SF), and the busy flag (B) in the FPU status word. The FCLEX instruction checks for and handles any pending unmasked floating-point exceptions before clearing the exception flags; the FNCLEX instruction does not.
The assembler issues two instructions for the FCLEX instruction (an FWAIT instruction followed by an FNCLEX instruction), and the processor executes each of these instructions separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
When operating a Pentium or Intel486 processor in MS-DOS* compatibility mode, it is possible (under unusual circumstances) for an FNCLEX instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNCLEX instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
This instruction affects only the x87 FPU floating-point exception flags. It does not affect the SIMD floating-point exception flags in the MXCSR register.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Clears the floating-point exception flags (PE, UE, OE, ZE, DE, and IE), the exception summary status flag (ES), the stack fault flag (SF), and the busy flag (B) in the FPU status word. The FCLEX instruction checks for and handles any pending unmasked floating-point exceptions before clearing the exception flags; the FNCLEX instruction does not.",
"url": "https://www.felixcloutier.com/x86/FCLEX%3AFNCLEX.html"
};
@@ -920,7 +927,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FCMOVNU":
case "FCMOVU":
return {
- "html": "
Tests the status flags in the EFLAGS register and moves the source operand (second operand) to the destination operand (first operand) if the given test condition is true. The condition for each mnemonic os given in the Description column above and in Chapter 8 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. The source operand is always in the ST(i) register and the destination operand is always ST(0).
The FCMOVcc instructions are useful for optimizing small IF constructions. They also help eliminate branching overhead for IF operations and the possibility of branch mispredictions by the processor.
A processor may not support the FCMOVcc instructions. Software can check if the FCMOVcc instructions are supported by checking the processor\u2019s feature information with the CPUID instruction (see \u201cCOMISS\u2014Compare Scalar Ordered Single-Precision Floating-Point Values and Set EFLAGS\u201d in this chapter). If both the CMOV and FPU feature bits are set, the FCMOVcc instructions are supported.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
The FCMOVcc instructions were introduced to the IA-32 Architecture in the P6 family processors and are not available in earlier IA-32 processors.
",
+ "html": "
Tests the status flags in the EFLAGS register and moves the source operand (second operand) to the destination operand (first operand) if the given test condition is true. The condition for each mnemonic os given in the Description column above and in Chapter 8 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. The source operand is always in the ST(i) register and the destination operand is always ST(0).
The FCMOVcc instructions are useful for optimizing small IF constructions. They also help eliminate branching overhead for IF operations and the possibility of branch mispredictions by the processor.
A processor may not support the FCMOVcc instructions. Software can check if the FCMOVcc instructions are supported by checking the processor\u2019s feature information with the CPUID instruction (see \u201cCOMISS\u2014Compare Scalar Ordered Single Precision Floating-Point Values and Set EFLAGS\u201d in this chapter). If both the CMOV and FPU feature bits are set, the FCMOVcc instructions are supported.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
The FCMOVcc instructions were introduced to the IA-32 Architecture in the P6 family processors and are not available in earlier IA-32 processors.
",
"tooltip": "Tests the status flags in the EFLAGS register and moves the source operand (second operand) to the destination operand (first operand) if the given test condition is true. The condition for each mnemonic os given in the Description column above and in Chapter 8 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. The source operand is always in the ST(i) register and the destination operand is always ST(0).",
"url": "https://www.felixcloutier.com/x86/FCMOVcc.html"
};
@@ -939,7 +946,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FUCOMI":
case "FUCOMIP":
return {
- "html": "
Performs an unordered comparison of the contents of registers ST(0) and ST(i) and sets the status flags ZF, PF, and CF in the EFLAGS register according to the results (see the table below). The sign of zero is ignored for comparisons, so that \u20130.0 is equal to +0.0.
An unordered comparison checks the class of the numbers being compared (see \u201cFXAM\u2014Examine Floating-Point\u201d in this chapter). The FUCOMI/FUCOMIP instructions perform the same operations as the FCOMI/FCOMIP instructions. The only difference is that the FUCOMI/FUCOMIP instructions raise the invalid-arithmetic-operand exception (#IA) only when either or both operands are an SNaN or are in an unsupported format; QNaNs cause the condition code flags to be set to unordered, but do not cause an exception to be generated. The FCOMI/FCOMIP instructions raise an invalid-operation exception when either or both of the operands are a NaN value of any kind or are in an unsupported format.
If the operation results in an invalid-arithmetic-operand exception being raised, the status flags in the EFLAGS register are set only if the exception is masked.
The FCOMI/FCOMIP and FUCOMI/FUCOMIP instructions set the OF, SF and AF flags to zero in the EFLAGS register (regardless of whether an invalid-operation exception is detected).
The FCOMIP and FUCOMIP instructions also pop the register stack following the comparison operation. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1.
",
+ "html": "
Performs an unordered comparison of the contents of registers ST(0) and ST(i) and sets the status flags ZF, PF, and CF in the EFLAGS register according to the results (see the table below). The sign of zero is ignored for comparisons, so that \u20130.0 is equal to +0.0.
An unordered comparison checks the class of the numbers being compared (see \u201cFXAM\u2014Examine Floating-Point\u201d in this chapter). The FUCOMI/FUCOMIP instructions perform the same operations as the FCOMI/FCOMIP instructions. The only difference is that the FUCOMI/FUCOMIP instructions raise the invalid-arithmetic-operand exception (#IA) only when either or both operands are an SNaN or are in an unsupported format; QNaNs cause the condition code flags to be set to unordered, but do not cause an exception to be generated. The FCOMI/FCOMIP instructions raise an invalid-operation exception when either or both of the operands are a NaN value of any kind or are in an unsupported format.
If the operation results in an invalid-arithmetic-operand exception being raised, the status flags in the EFLAGS register are set only if the exception is masked.
The FCOMI/FCOMIP and FUCOMI/FUCOMIP instructions set the OF, SF, and AF flags to zero in the EFLAGS register (regardless of whether an invalid-operation exception is detected).
The FCOMIP and FUCOMIP instructions also pop the register stack following the comparison operation. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1.
",
"tooltip": "Performs an unordered comparison of the contents of registers ST(0) and ST(i) and sets the status flags ZF, PF, and CF in the EFLAGS register according to the results (see the table below). The sign of zero is ignored for comparisons, so that \u20130.0 is equal to +0.0.",
"url": "https://www.felixcloutier.com/x86/FCOMI%3AFCOMIP%3AFUCOMI%3AFUCOMIP.html"
};
@@ -948,8 +955,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FDIVP":
case "FIDIV":
return {
- "html": "
Divides the destination operand by the source operand and stores the result in the destination location. The destination operand (dividend) is always in an FPU register; the source operand (divisor) can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format, word or doubleword integer format.
The no-operand version of the instruction divides the contents of the ST(1) register by the contents of the ST(0) register. The one-operand version divides the contents of the ST(0) register by the contents of a memory location (either a floating-point or an integer value). The two-operand version, divides the contents of the ST(0) register by the contents of the ST(i) register or vice versa.
The FDIVP instructions perform the additional operation of popping the FPU register stack after storing the result. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point divide instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FDIV rather than FDIVP.
The FIDIV instructions convert an integer source operand to double extended-precision floating-point format before performing the division. When the source operand is an integer 0, it is treated as a +0.
If an unmasked divide-by-zero exception (#Z) is generated, no result is stored; if the exception is masked, an \u221e of the appropriate sign is stored in the destination operand.
",
- "tooltip": "Divides the destination operand by the source operand and stores the result in the destination location. The destination operand (dividend) is always in an FPU register; the source operand (divisor) can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format, word or doubleword integer format.",
+ "html": "
Divides the destination operand by the source operand and stores the result in the destination location. The destination operand (dividend) is always in an FPU register; the source operand (divisor) can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format, word or doubleword integer format.
The no-operand version of the instruction divides the contents of the ST(1) register by the contents of the ST(0) register. The one-operand version divides the contents of the ST(0) register by the contents of a memory location (either a floating-point or an integer value). The two-operand version, divides the contents of the ST(0) register by the contents of the ST(i) register or vice versa.
The FDIVP instructions perform the additional operation of popping the FPU register stack after storing the result. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point divide instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FDIV rather than FDIVP.
The FIDIV instructions convert an integer source operand to double extended-precision floating-point format before performing the division. When the source operand is an integer 0, it is treated as a +0.
If an unmasked divide-by-zero exception (#Z) is generated, no result is stored; if the exception is masked, an \u221e of the appropriate sign is stored in the destination operand.
",
+ "tooltip": "Divides the destination operand by the source operand and stores the result in the destination location. The destination operand (dividend) is always in an FPU register; the source operand (divisor) can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format, word or doubleword integer format.",
"url": "https://www.felixcloutier.com/x86/FDIV%3AFDIVP%3AFIDIV.html"
};
@@ -957,8 +964,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FDIVRP":
case "FIDIVR":
return {
- "html": "
Divides the source operand by the destination operand and stores the result in the destination location. The destination operand (divisor) is always in an FPU register; the source operand (dividend) can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format, word or doubleword integer format.
These instructions perform the reverse operations of the FDIV, FDIVP, and FIDIV instructions. They are provided to support more efficient coding.
The no-operand version of the instruction divides the contents of the ST(0) register by the contents of the ST(1) register. The one-operand version divides the contents of a memory location (either a floating-point or an integer value) by the contents of the ST(0) register. The two-operand version, divides the contents of the ST(i) register by the contents of the ST(0) register or vice versa.
The FDIVRP instructions perform the additional operation of popping the FPU register stack after storing the result. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point divide instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FDIVR rather than FDIVRP.
The FIDIVR instructions convert an integer source operand to double extended-precision floating-point format before performing the division.
",
- "tooltip": "Divides the source operand by the destination operand and stores the result in the destination location. The destination operand (divisor) is always in an FPU register; the source operand (dividend) can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format, word or doubleword integer format.",
+ "html": "
Divides the source operand by the destination operand and stores the result in the destination location. The destination operand (divisor) is always in an FPU register; the source operand (dividend) can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format, word or doubleword integer format.
These instructions perform the reverse operations of the FDIV, FDIVP, and FIDIV instructions. They are provided to support more efficient coding.
The no-operand version of the instruction divides the contents of the ST(0) register by the contents of the ST(1) register. The one-operand version divides the contents of a memory location (either a floating-point or an integer value) by the contents of the ST(0) register. The two-operand version, divides the contents of the ST(i) register by the contents of the ST(0) register or vice versa.
The FDIVRP instructions perform the additional operation of popping the FPU register stack after storing the result. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point divide instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FDIVR rather than FDIVRP.
The FIDIVR instructions convert an integer source operand to double extended-precision floating-point format before performing the division.
",
+ "tooltip": "Divides the source operand by the destination operand and stores the result in the destination location. The destination operand (divisor) is always in an FPU register; the source operand (dividend) can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format, word or doubleword integer format.",
"url": "https://www.felixcloutier.com/x86/FDIVR%3AFDIVRP%3AFIDIVR.html"
};
@@ -978,9 +985,9 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
};
case "FINIT":
- case "FNINIT":
+ case "FNINIT1":
return {
- "html": "
Sets the FPU control, status, tag, instruction pointer, and data pointer registers to their default states. The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). The status word is cleared (no exception flags set, TOP is set to 0). The data registers in the register stack are left unchanged, but they are all tagged as empty (11B). Both the instruction and data pointers are cleared.
The FINIT instruction checks for and handles any pending unmasked floating-point exceptions before performing the initialization; the FNINIT instruction does not.
The assembler issues two instructions for the FINIT instruction (an FWAIT instruction followed by an FNINIT instruction), and the processor executes each of these instructions in separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When operating a Pentium or Intel486 processor in MS-DOS compatibility mode, it is possible (under unusual circumstances) for an FNINIT instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNINIT instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
",
+ "html": "
Sets the FPU control, status, tag, instruction pointer, and data pointer registers to their default states. The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). The status word is cleared (no exception flags set, TOP is set to 0). The data registers in the register stack are left unchanged, but they are all tagged as empty (11B). Both the instruction and data pointers are cleared.
The FINIT instruction checks for and handles any pending unmasked floating-point exceptions before performing the initialization; the FNINIT instruction does not.
The assembler issues two instructions for the FINIT instruction (an FWAIT instruction followed by an FNINIT instruction), and the processor executes each of these instructions in separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When operating a Pentium or Intel486 processor in MS-DOS compatibility mode, it is possible (under unusual circumstances) for an FNINIT instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNINIT instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
",
"tooltip": "Sets the FPU control, status, tag, instruction pointer, and data pointer registers to their default states. The FPU control word is set to 037FH (round to nearest, all exceptions masked, 64-bit precision). The status word is cleared (no exception flags set, TOP is set to 0). The data registers in the register stack are left unchanged, but they are all tagged as empty (11B). Both the instruction and data pointers are cleared.",
"url": "https://www.felixcloutier.com/x86/FINIT%3AFNINIT.html"
};
@@ -1002,8 +1009,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FLD":
return {
- "html": "
Pushes the source operand onto the FPU register stack. The source operand can be in single-precision, double-precision, or double extended-precision floating-point format. If the source operand is in single-precision or double-precision floating-point format, it is automatically converted to the double extended-precision floating-point format before being pushed on the stack.
The FLD instruction can also push the value in a selected FPU register [ST(i)] onto the stack. Here, pushing register ST(0) duplicates the stack top.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
- "tooltip": "Pushes the source operand onto the FPU register stack. The source operand can be in single-precision, double-precision, or double extended-precision floating-point format. If the source operand is in single-precision or double-precision floating-point format, it is automatically converted to the double extended-precision floating-point format before being pushed on the stack.",
+ "html": "
Pushes the source operand onto the FPU register stack. The source operand can be in single precision, double precision, or double extended-precision floating-point format. If the source operand is in single precision or double precision floating-point format, it is automatically converted to the double extended-precision floating-point format before being pushed on the stack.
The FLD instruction can also push the value in a selected FPU register [ST(i)] onto the stack. Here, pushing register ST(0) duplicates the stack top.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "tooltip": "Pushes the source operand onto the FPU register stack. The source operand can be in single precision, double precision, or double extended-precision floating-point format. If the source operand is in single precision or double precision floating-point format, it is automatically converted to the double extended-precision floating-point format before being pushed on the stack.",
"url": "https://www.felixcloutier.com/x86/FLD.html"
};
@@ -1015,7 +1022,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FLDPI":
case "FLDZ":
return {
- "html": "
Push one of seven commonly used constants (in double extended-precision floating-point format) onto the FPU register stack. The constants that can be loaded with these instructions include +1.0, +0.0, log210, log2e, \u03c0, log102, and loge2. For each constant, an internal 66-bit constant is rounded (as specified by the RC field in the FPU control word) to double extended-precision floating-point format. The inexact-result exception (#P) is not generated as a result of the rounding, nor is the C1 flag set in the x87 FPU status word if the value is rounded up.
See the section titled \u201cApproximation of Pi\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of the \u03c0 constant.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When the RC field is set to round-to-nearest, the FPU produces the same constants that is produced by the Intel 8087 and Intel 287 math coprocessors.
",
+ "html": "
Push one of seven commonly used constants (in double extended-precision floating-point format) onto the FPU register stack. The constants that can be loaded with these instructions include +1.0, +0.0, log210, log2e, \u03c0, log102, and loge2. For each constant, an internal 66-bit constant is rounded (as specified by the RC field in the FPU control word) to double extended-precision floating-point format. The inexact-result exception (#P) is not generated as a result of the rounding, nor is the C1 flag set in the x87 FPU status word if the value is rounded up.
See the section titled \u201cApproximation of Pi\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of the \u03c0 constant.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When the RC field is set to round-to-nearest, the FPU produces the same constants that is produced by the Intel 8087 and Intel 287 math coprocessors.
",
"tooltip": "Push one of seven commonly used constants (in double extended-precision floating-point format) onto the FPU register stack. The constants that can be loaded with these instructions include +1.0, +0.0, log210, log2e, \u03c0, log102, and loge2. For each constant, an internal 66-bit constant is rounded (as specified by the RC field in the FPU control word) to double extended-precision floating-point format. The inexact-result exception (#P) is not generated as a result of the rounding, nor is the C1 flag set in the x87 FPU status word if the value is rounded up.",
"url": "https://www.felixcloutier.com/x86/FLD1%3AFLDL2T%3AFLDL2E%3AFLDPI%3AFLDLG2%3AFLDLN2%3AFLDZ.html"
};
@@ -1024,8 +1031,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FMUL":
case "FMULP":
return {
- "html": "
Multiplies the destination and source operands and stores the product in the destination location. The destination operand is always an FPU data register; the source operand can be an FPU data register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.
The no-operand version of the instruction multiplies the contents of the ST(1) register by the contents of the ST(0) register and stores the product in the ST(1) register. The one-operand version multiplies the contents of the ST(0) register by the contents of a memory location (either a floating point or an integer value) and stores the product in the ST(0) register. The two-operand version, multiplies the contents of the ST(0) register by the contents of the ST(i) register, or vice versa, with the result being stored in the register specified with the first operand (the destination operand).
The FMULP instructions perform the additional operation of popping the FPU register stack after storing the product. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point multiply instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FMUL rather than FMULP.
The FIMUL instructions convert an integer source operand to double extended-precision floating-point format before performing the multiplication.
The sign of the result is always the exclusive-OR of the source signs, even if one or more of the values being multiplied is 0 or \u221e. When the source operand is an integer 0, it is treated as a +0.
",
- "tooltip": "Multiplies the destination and source operands and stores the product in the destination location. The destination operand is always an FPU data register; the source operand can be an FPU data register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.",
+ "html": "
Multiplies the destination and source operands and stores the product in the destination location. The destination operand is always an FPU data register; the source operand can be an FPU data register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.
The no-operand version of the instruction multiplies the contents of the ST(1) register by the contents of the ST(0) register and stores the product in the ST(1) register. The one-operand version multiplies the contents of the ST(0) register by the contents of a memory location (either a floating-point or an integer value) and stores the product in the ST(0) register. The two-operand version, multiplies the contents of the ST(0) register by the contents of the ST(i) register, or vice versa, with the result being stored in the register specified with the first operand (the destination operand).
The FMULP instructions perform the additional operation of popping the FPU register stack after storing the product. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point multiply instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FMUL rather than FMULP.
The FIMUL instructions convert an integer source operand to double extended-precision floating-point format before performing the multiplication.
The sign of the result is always the exclusive-OR of the source signs, even if one or more of the values being multiplied is 0 or \u221e. When the source operand is an integer 0, it is treated as a +0.
",
+ "tooltip": "Multiplies the destination and source operands and stores the product in the destination location. The destination operand is always an FPU data register; the source operand can be an FPU data register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.",
"url": "https://www.felixcloutier.com/x86/FMUL%3AFMULP%3AFIMUL.html"
};
@@ -1045,22 +1052,22 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FPTAN":
return {
- "html": "
Computes the approximate tangent of the source operand in register ST(0), stores the result in ST(0), and pushes a 1.0 onto the FPU register stack. The source operand must be given in radians and must be less than \u00b1263. The following table shows the unmasked results obtained when computing the partial tangent of various classes of numbers, assuming that underflow does not occur.
If the source operand is outside the acceptable range, the C2 flag in the FPU status word is set, and the value in register ST(0) remains unchanged. The instruction does not raise an exception when the source operand is out of range. It is up to the program to check the C2 flag for out-of-range conditions. Source values outside the range \u2212 263 to +263 can be reduced to the range of the instruction by subtracting an appropriate integer multiple of 2\u03c0. However, even within the range -263 to +263, inaccurate results can occur because the finite approximation of \u03c0 used internally for argument reduction is not sufficient in all cases. Therefore, for accurate results it is safe to apply FPTAN only to arguments reduced accurately in software, to a value smaller in absolute value than 3\u03c0/8. See the sections titled \u201cApproximation of Pi\u201d and \u201cTranscendental Instruction Accuracy\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a discussion of the proper value to use for \u03c0 in performing such reductions.
The value 1.0 is pushed onto the register stack after the tangent has been computed to maintain compatibility with the Intel 8087 and Intel287 math coprocessors. This operation also simplifies the calculation of other trigonometric functions. For instance, the cotangent (which is the reciprocal of the tangent) can be computed by executing a FDIVR instruction after the FPTAN instruction.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Computes the approximate tangent of the source operand in register ST(0), stores the result in ST(0), and pushes a 1.0 onto the FPU register stack. The source operand must be given in radians and must be less than \u00b1263. The following table shows the unmasked results obtained when computing the partial tangent of various classes of numbers, assuming that underflow does not occur.
If the source operand is outside the acceptable range, the C2 flag in the FPU status word is set, and the value in register ST(0) remains unchanged. The instruction does not raise an exception when the source operand is out of range. It is up to the program to check the C2 flag for out-of-range conditions. Source values outside the range \u2212 263 to +263 can be reduced to the range of the instruction by subtracting an appropriate integer multiple of 2\u03c0. However, even within the range -263 to +263, inaccurate results can occur because the finite approximation of \u03c0 used internally for argument reduction is not sufficient in all cases. Therefore, for accurate results it is safe to apply FPTAN only to arguments reduced accurately in software, to a value smaller in absolute value than 3\u03c0/8. See the sections titled \u201cApproximation of Pi\u201d and \u201cTranscendental Instruction Accuracy\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a discussion of the proper value to use for \u03c0 in performing such reductions.
The value 1.0 is pushed onto the register stack after the tangent has been computed to maintain compatibility with the Intel 8087 and Intel287 math coprocessors. This operation also simplifies the calculation of other trigonometric functions. For instance, the cotangent (which is the reciprocal of the tangent) can be computed by executing a FDIVR instruction after the FPTAN instruction.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Computes the approximate tangent of the source operand in register ST(0), stores the result in ST(0), and pushes a 1.0 onto the FPU register stack. The source operand must be given in radians and must be less than \u00b1263. The following table shows the unmasked results obtained when computing the partial tangent of various classes of numbers, assuming that underflow does not occur.",
"url": "https://www.felixcloutier.com/x86/FPTAN.html"
};
- case "FNSAVE":
+ case "FNSAVE1":
case "FSAVE":
return {
- "html": "
Stores the current FPU state (operating environment and register stack) at the specified destination in memory, and then re-initializes the FPU. The FSAVE instruction checks for and handles pending unmasked floating-point exceptions before storing the FPU state; the FNSAVE instruction does not.
The FPU operating environment consists of the FPU control word, status word, tag word, instruction pointer, data pointer, and last opcode. Figures 8-9 through 8-12 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, show the layout in memory of the stored environment, depending on the operating mode of the processor (protected or real) and the current operand-size attribute (16-bit or 32-bit). In virtual-8086 mode, the real mode layouts are used. The contents of the FPU register stack are stored in the 80 bytes immediately follow the operating environment image.
The saved image reflects the state of the FPU after all floating-point instructions preceding the FSAVE/FNSAVE instruction in the instruction stream have been executed.
After the FPU state has been saved, the FPU is reset to the same default values it is set to with the FINIT/FNINIT instructions (see \u201cFINIT/FNINIT\u2014Initialize Floating-Point Unit\u201d in this chapter).
The FSAVE/FNSAVE instructions are typically used when the operating system needs to perform a context switch, an exception handler needs to use the FPU, or an application program needs to pass a \u201cclean\u201d FPU to a procedure.
",
+ "html": "
Stores the current FPU state (operating environment and register stack) at the specified destination in memory, and then re-initializes the FPU. The FSAVE instruction checks for and handles pending unmasked floating-point exceptions before storing the FPU state; the FNSAVE instruction does not.
The FPU operating environment consists of the FPU control word, status word, tag word, instruction pointer, data pointer, and last opcode. Figures 8-9 through 8-12 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, show the layout in memory of the stored environment, depending on the operating mode of the processor (protected or real) and the current operand-size attribute (16-bit or 32-bit). In virtual-8086 mode, the real mode layouts are used. The contents of the FPU register stack are stored in the 80 bytes immediately follow the operating environment image.
The saved image reflects the state of the FPU after all floating-point instructions preceding the FSAVE/FNSAVE instruction in the instruction stream have been executed.
After the FPU state has been saved, the FPU is reset to the same default values it is set to with the FINIT/FNINIT instructions (see \u201cFINIT/FNINIT\u2014Initialize Floating-Point Unit\u201d in this chapter).
The FSAVE/FNSAVE instructions are typically used when the operating system needs to perform a context switch, an exception handler needs to use the FPU, or an application program needs to pass a \u201cclean\u201d FPU to a procedure.
",
"tooltip": "Stores the current FPU state (operating environment and register stack) at the specified destination in memory, and then re-initializes the FPU. The FSAVE instruction checks for and handles pending unmasked floating-point exceptions before storing the FPU state; the FNSAVE instruction does not.",
"url": "https://www.felixcloutier.com/x86/FSAVE%3AFNSAVE.html"
};
case "FSINCOS":
return {
- "html": "
Computes both the approximate sine and the cosine of the source operand in register ST(0), stores the sine in ST(0), and pushes the cosine onto the top of the FPU register stack. (This instruction is faster than executing the FSIN and FCOS instructions in succession.)
The source operand must be given in radians and must be within the range \u2212263 to +263. The following table shows the results obtained when taking the sine and cosine of various classes of numbers, assuming that underflow does not occur.
If the source operand is outside the acceptable range, the C2 flag in the FPU status word is set, and the value in register ST(0) remains unchanged. The instruction does not raise an exception when the source operand is out of range. It is up to the program to check the C2 flag for out-of-range conditions. Source values outside the range \u2212 263 to +263 can be reduced to the range of the instruction by subtracting an appropriate integer multiple of 2\u03c0. However, even within the range -263 to +263, inaccurate results can occur because the finite approximation of \u03c0 used internally for argument reduction is not sufficient in all cases. Therefore, for accurate results it is safe to apply FSINCOS only to arguments reduced accurately in software, to a value smaller in absolute value than 3\u03c0/8. See the sections titled \u201cApproximation of Pi\u201d and \u201cTranscendental Instruction Accuracy\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a discussion of the proper value to use for \u03c0 in performing such reductions.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Computes both the approximate sine and the cosine of the source operand in register ST(0), stores the sine in ST(0), and pushes the cosine onto the top of the FPU register stack. (This instruction is faster than executing the FSIN and FCOS instructions in succession.)
The source operand must be given in radians and must be within the range \u2212263 to +263. The following table shows the results obtained when taking the sine and cosine of various classes of numbers, assuming that underflow does not occur.
If the source operand is outside the acceptable range, the C2 flag in the FPU status word is set, and the value in register ST(0) remains unchanged. The instruction does not raise an exception when the source operand is out of range. It is up to the program to check the C2 flag for out-of-range conditions. Source values outside the range \u2212 263 to +263 can be reduced to the range of the instruction by subtracting an appropriate integer multiple of 2\u03c0. However, even within the range -263 to +263, inaccurate results can occur because the finite approximation of \u03c0 used internally for argument reduction is not sufficient in all cases. Therefore, for accurate results it is safe to apply FSINCOS only to arguments reduced accurately in software, to a value smaller in absolute value than 3\u03c0/8. See the sections titled \u201cApproximation of Pi\u201d and \u201cTranscendental Instruction Accuracy\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a discussion of the proper value to use for \u03c0 in performing such reductions.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Computes both the approximate sine and the cosine of the source operand in register ST(0), stores the sine in ST(0), and pushes the cosine onto the top of the FPU register stack. (This instruction is faster than executing the FSIN and FCOS instructions in succession.)",
"url": "https://www.felixcloutier.com/x86/FSINCOS.html"
};
@@ -1068,31 +1075,31 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FST":
case "FSTP":
return {
- "html": "
The FST instruction copies the value in the ST(0) register to the destination operand, which can be a memory location or another register in the FPU register stack. When storing the value in memory, the value is converted to single-precision or double-precision floating-point format.
The FSTP instruction performs the same operation as the FST instruction and then pops the register stack. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The FSTP instruction can also store values in memory in double extended-precision floating-point format.
If the destination operand is a memory location, the operand specifies the address where the first byte of the destination value is to be stored. If the destination operand is a register, the operand specifies a register in the register stack relative to the top of the stack.
If the destination size is single-precision or double-precision, the significand of the value being stored is rounded to the width of the destination (according to the rounding mode specified by the RC field of the FPU control word), and the exponent is converted to the width and bias of the destination format. If the value being stored is too large for the destination format, a numeric overflow exception (#O) is generated and, if the exception is unmasked, no value is stored in the destination operand. If the value being stored is a denormal value, the denormal exception (#D) is not generated. This condition is simply signaled as a numeric underflow exception (#U) condition.
If the value being stored is \u00b10, \u00b1\u221e, or a NaN, the least-significant bits of the significand and the exponent are truncated to fit the destination format. This operation preserves the value\u2019s identity as a 0, \u221e, or NaN.
",
- "tooltip": "The FST instruction copies the value in the ST(0) register to the destination operand, which can be a memory location or another register in the FPU register stack. When storing the value in memory, the value is converted to single-precision or double-precision floating-point format.",
+ "html": "
The FST instruction copies the value in the ST(0) register to the destination operand, which can be a memory location or another register in the FPU register stack. When storing the value in memory, the value is converted to single precision or double precision floating-point format.
The FSTP instruction performs the same operation as the FST instruction and then pops the register stack. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The FSTP instruction can also store values in memory in double extended-precision floating-point format.
If the destination operand is a memory location, the operand specifies the address where the first byte of the destination value is to be stored. If the destination operand is a register, the operand specifies a register in the register stack relative to the top of the stack.
If the destination size is single precision or double precision, the significand of the value being stored is rounded to the width of the destination (according to the rounding mode specified by the RC field of the FPU control word), and the exponent is converted to the width and bias of the destination format. If the value being stored is too large for the destination format, a numeric overflow exception (#O) is generated and, if the exception is unmasked, no value is stored in the destination operand. If the value being stored is a denormal value, the denormal exception (#D) is not generated. This condition is simply signaled as a numeric underflow exception (#U) condition.
If the value being stored is \u00b10, \u00b1\u221e, or a NaN, the least-significant bits of the significand and the exponent are truncated to fit the destination format. This operation preserves the value\u2019s identity as a 0, \u221e, or NaN.
",
+ "tooltip": "The FST instruction copies the value in the ST(0) register to the destination operand, which can be a memory location or another register in the FPU register stack. When storing the value in memory, the value is converted to single precision or double precision floating-point format.",
"url": "https://www.felixcloutier.com/x86/FST%3AFSTP.html"
};
- case "FNSTCW":
+ case "FNSTCW1":
case "FSTCW":
return {
- "html": "
Stores the current value of the FPU control word at the specified destination in memory. The FSTCW instruction checks for and handles pending unmasked floating-point exceptions before storing the control word; the FNSTCW instruction does not.
The assembler issues two instructions for the FSTCW instruction (an FWAIT instruction followed by an FNSTCW instruction), and the processor executes each of these instructions in separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When operating a Pentium or Intel486 processor in MS-DOS compatibility mode, it is possible (under unusual circumstances) for an FNSTCW instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNSTCW instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
",
+ "html": "
Stores the current value of the FPU control word at the specified destination in memory. The FSTCW instruction checks for and handles pending unmasked floating-point exceptions before storing the control word; the FNSTCW instruction does not.
The assembler issues two instructions for the FSTCW instruction (an FWAIT instruction followed by an FNSTCW instruction), and the processor executes each of these instructions in separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When operating a Pentium or Intel486 processor in MS-DOS compatibility mode, it is possible (under unusual circumstances) for an FNSTCW instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNSTCW instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
",
"tooltip": "Stores the current value of the FPU control word at the specified destination in memory. The FSTCW instruction checks for and handles pending unmasked floating-point exceptions before storing the control word; the FNSTCW instruction does not.",
"url": "https://www.felixcloutier.com/x86/FSTCW%3AFNSTCW.html"
};
- case "FNSTENV":
+ case "FNSTENV1":
case "FSTENV":
return {
- "html": "
Saves the current FPU operating environment at the memory location specified with the destination operand, and then masks all floating-point exceptions. The FPU operating environment consists of the FPU control word, status word, tag word, instruction pointer, data pointer, and last opcode. Figures 8-9 through 8-12 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, show the layout in memory of the stored environment, depending on the operating mode of the processor (protected or real) and the current operand-size attribute (16-bit or 32-bit). In virtual-8086 mode, the real mode layouts are used.
The FSTENV instruction checks for and handles any pending unmasked floating-point exceptions before storing the FPU environment; the FNSTENV instruction does not. The saved image reflects the state of the FPU after all floating-point instructions preceding the FSTENV/FNSTENV instruction in the instruction stream have been executed.
These instructions are often used by exception handlers because they provide access to the FPU instruction and data pointers. The environment is typically saved in the stack. Masking all exceptions after saving the environment prevents floating-point exceptions from interrupting the exception handler.
The assembler issues two instructions for the FSTENV instruction (an FWAIT instruction followed by an FNSTENV instruction), and the processor executes each of these instructions separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Saves the current FPU operating environment at the memory location specified with the destination operand, and then masks all floating-point exceptions. The FPU operating environment consists of the FPU control word, status word, tag word, instruction pointer, data pointer, and last opcode. Figures 8-9 through 8-12 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, show the layout in memory of the stored environment, depending on the operating mode of the processor (protected or real) and the current operand-size attribute (16-bit or 32-bit). In virtual-8086 mode, the real mode layouts are used.
The FSTENV instruction checks for and handles any pending unmasked floating-point exceptions before storing the FPU environment; the FNSTENV instruction does not. The saved image reflects the state of the FPU after all floating-point instructions preceding the FSTENV/FNSTENV instruction in the instruction stream have been executed.
These instructions are often used by exception handlers because they provide access to the FPU instruction and data pointers. The environment is typically saved in the stack. Masking all exceptions after saving the environment prevents floating-point exceptions from interrupting the exception handler.
The assembler issues two instructions for the FSTENV instruction (an FWAIT instruction followed by an FNSTENV instruction), and the processor executes each of these instructions separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Saves the current FPU operating environment at the memory location specified with the destination operand, and then masks all floating-point exceptions. The FPU operating environment consists of the FPU control word, status word, tag word, instruction pointer, data pointer, and last opcode. Figures 8-9 through 8-12 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, show the layout in memory of the stored environment, depending on the operating mode of the processor (protected or real) and the current operand-size attribute (16-bit or 32-bit). In virtual-8086 mode, the real mode layouts are used.",
"url": "https://www.felixcloutier.com/x86/FSTENV%3AFNSTENV.html"
};
- case "FNSTSW":
+ case "FNSTSW1":
case "FSTSW":
return {
- "html": "
Stores the current value of the x87 FPU status word in the destination location. The destination operand can be either a two-byte memory location or the AX register. The FSTSW instruction checks for and handles pending unmasked floating-point exceptions before storing the status word; the FNSTSW instruction does not.
The FNSTSW AX form of the instruction is used primarily in conditional branching (for instance, after an FPU comparison instruction or an FPREM, FPREM1, or FXAM instruction), where the direction of the branch depends on the state of the FPU condition code flags. (See the section titled \u201cBranching and Conditional Moves on FPU Condition Codes\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.) This instruction can also be used to invoke exception handlers (by examining the exception flags) in environments that do not use interrupts. When the FNSTSW AX instruction is executed, the AX register is updated before the processor executes any further instructions. The status stored in the AX register is thus guaranteed to be from the completion of the prior FPU instruction.
The assembler issues two instructions for the FSTSW instruction (an FWAIT instruction followed by an FNSTSW instruction), and the processor executes each of these instructions separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When operating a Pentium or Intel486 processor in MS-DOS compatibility mode, it is possible (under unusual circumstances) for an FNSTSW instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNSTSW instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
",
+ "html": "
Stores the current value of the x87 FPU status word in the destination location. The destination operand can be either a two-byte memory location or the AX register. The FSTSW instruction checks for and handles pending unmasked floating-point exceptions before storing the status word; the FNSTSW instruction does not.
The FNSTSW AX form of the instruction is used primarily in conditional branching (for instance, after an FPU comparison instruction or an FPREM, FPREM1, or FXAM instruction), where the direction of the branch depends on the state of the FPU condition code flags. (See the section titled \u201cBranching and Conditional Moves on FPU Condition Codes\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.) This instruction can also be used to invoke exception handlers (by examining the exception flags) in environments that do not use interrupts. When the FNSTSW AX instruction is executed, the AX register is updated before the processor executes any further instructions. The status stored in the AX register is thus guaranteed to be from the completion of the prior FPU instruction.
The assembler issues two instructions for the FSTSW instruction (an FWAIT instruction followed by an FNSTSW instruction), and the processor executes each of these instructions separately. If an exception is generated for either of these instructions, the save EIP points to the instruction that caused the exception.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
When operating a Pentium or Intel486 processor in MS-DOS compatibility mode, it is possible (under unusual circumstances) for an FNSTSW instruction to be interrupted prior to being executed to handle a pending FPU exception. See the section titled \u201cNo-Wait FPU Instructions Can Get FPU Interrupt in Window\u201d in Appendix D of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of these circumstances. An FNSTSW instruction cannot be interrupted in this way on later Intel processors, except for the Intel QuarkTM X1000 processor.
",
"tooltip": "Stores the current value of the x87 FPU status word in the destination location. The destination operand can be either a two-byte memory location or the AX register. The FSTSW instruction checks for and handles pending unmasked floating-point exceptions before storing the status word; the FNSTSW instruction does not.",
"url": "https://www.felixcloutier.com/x86/FSTSW%3AFNSTSW.html"
};
@@ -1101,8 +1108,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FSUB":
case "FSUBP":
return {
- "html": "
Subtracts the source operand from the destination operand and stores the difference in the destination location. The destination operand is always an FPU data register; the source operand can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.
The no-operand version of the instruction subtracts the contents of the ST(0) register from the ST(1) register and stores the result in ST(1). The one-operand version subtracts the contents of a memory location (either a floating-point or an integer value) from the contents of the ST(0) register and stores the result in ST(0). The two-operand version, subtracts the contents of the ST(0) register from the ST(i) register or vice versa.
The FSUBP instructions perform the additional operation of popping the FPU register stack following the subtraction. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point subtract instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FSUB rather than FSUBP.
The FISUB instructions convert an integer source operand to double extended-precision floating-point format before performing the subtraction.
Table 3-38 shows the results obtained when subtracting various classes of numbers from one another, assuming that neither overflow nor underflow occurs. Here, the SRC value is subtracted from the DEST value (DEST \u2212 SRC = result).
",
- "tooltip": "Subtracts the source operand from the destination operand and stores the difference in the destination location. The destination operand is always an FPU data register; the source operand can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.",
+ "html": "
Subtracts the source operand from the destination operand and stores the difference in the destination location. The destination operand is always an FPU data register; the source operand can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.
The no-operand version of the instruction subtracts the contents of the ST(0) register from the ST(1) register and stores the result in ST(1). The one-operand version subtracts the contents of a memory location (either a floating-point or an integer value) from the contents of the ST(0) register and stores the result in ST(0). The two-operand version, subtracts the contents of the ST(0) register from the ST(i) register or vice versa.
The FSUBP instructions perform the additional operation of popping the FPU register stack following the subtraction. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point subtract instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FSUB rather than FSUBP.
The FISUB instructions convert an integer source operand to double extended-precision floating-point format before performing the subtraction.
Table 3-38 shows the results obtained when subtracting various classes of numbers from one another, assuming that neither overflow nor underflow occurs. Here, the SRC value is subtracted from the DEST value (DEST \u2212 SRC = result).
",
+ "tooltip": "Subtracts the source operand from the destination operand and stores the difference in the destination location. The destination operand is always an FPU data register; the source operand can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.",
"url": "https://www.felixcloutier.com/x86/FSUB%3AFSUBP%3AFISUB.html"
};
@@ -1110,8 +1117,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FSUBR":
case "FSUBRP":
return {
- "html": "
Subtracts the destination operand from the source operand and stores the difference in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.
These instructions perform the reverse operations of the FSUB, FSUBP, and FISUB instructions. They are provided to support more efficient coding.
The no-operand version of the instruction subtracts the contents of the ST(1) register from the ST(0) register and stores the result in ST(1). The one-operand version subtracts the contents of the ST(0) register from the contents of a memory location (either a floating-point or an integer value) and stores the result in ST(0). The two-operand version, subtracts the contents of the ST(i) register from the ST(0) register or vice versa.
The FSUBRP instructions perform the additional operation of popping the FPU register stack following the subtraction. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point reverse subtract instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FSUBR rather than FSUBRP.
The FISUBR instructions convert an integer source operand to double extended-precision floating-point format before performing the subtraction.
",
- "tooltip": "Subtracts the destination operand from the source operand and stores the difference in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single-precision or double-precision floating-point format or in word or doubleword integer format.",
+ "html": "
Subtracts the destination operand from the source operand and stores the difference in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.
These instructions perform the reverse operations of the FSUB, FSUBP, and FISUB instructions. They are provided to support more efficient coding.
The no-operand version of the instruction subtracts the contents of the ST(1) register from the ST(0) register and stores the result in ST(1). The one-operand version subtracts the contents of the ST(0) register from the contents of a memory location (either a floating-point or an integer value) and stores the result in ST(0). The two-operand version, subtracts the contents of the ST(i) register from the ST(0) register or vice versa.
The FSUBRP instructions perform the additional operation of popping the FPU register stack following the subtraction. To pop the register stack, the processor marks the ST(0) register as empty and increments the stack pointer (TOP) by 1. The no-operand version of the floating-point reverse subtract instructions always results in the register stack being popped. In some assemblers, the mnemonic for this instruction is FSUBR rather than FSUBRP.
The FISUBR instructions convert an integer source operand to double extended-precision floating-point format before performing the subtraction.
",
+ "tooltip": "Subtracts the destination operand from the source operand and stores the difference in the destination location. The destination operand is always an FPU register; the source operand can be a register or a memory location. Source operands in memory can be in single precision or double precision floating-point format or in word or doubleword integer format.",
"url": "https://www.felixcloutier.com/x86/FSUBR%3AFSUBRP%3AFISUBR.html"
};
@@ -1147,7 +1154,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FXTRACT":
return {
- "html": "
Separates the source value in the ST(0) register into its exponent and significand, stores the exponent in ST(0), and pushes the significand onto the register stack. Following this operation, the new top-of-stack register ST(0) contains the value of the original significand expressed as a floating-point value. The sign and significand of this value are the same as those found in the source operand, and the exponent is 3FFFH (biased value for a true exponent of zero). The ST(1) register contains the value of the original operand\u2019s true (unbiased) exponent expressed as a floating-point value. (The operation performed by this instruction is a superset of the IEEE-recommended logb(x) function.)
This instruction and the F2XM1 instruction are useful for performing power and range scaling operations. The FXTRACT instruction is also useful for converting numbers in double extended-precision floating-point format to decimal representations (e.g., for printing or displaying).
If the floating-point zero-divide exception (#Z) is masked and the source operand is zero, an exponent value of \u2013 \u221e is stored in register ST(1) and 0 with the sign of the source operand is stored in register ST(0).
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Separates the source value in the ST(0) register into its exponent and significand, stores the exponent in ST(0), and pushes the significand onto the register stack. Following this operation, the new top-of-stack register ST(0) contains the value of the original significand expressed as a floating-point value. The sign and significand of this value are the same as those found in the source operand, and the exponent is 3FFFH (biased value for a true exponent of zero). The ST(1) register contains the value of the original operand\u2019s true (unbiased) exponent expressed as a floating-point value. (The operation performed by this instruction is a superset of the IEEE-recommended logb(x) function.)
This instruction and the F2XM1 instruction are useful for performing power and range scaling operations. The FXTRACT instruction is also useful for converting numbers in double extended-precision floating-point format to decimal representations (e.g., for printing or displaying).
If the floating-point zero-divide exception (#Z) is masked and the source operand is zero, an exponent value of \u2013\u221e is stored in register ST(1) and 0 with the sign of the source operand is stored in register ST(0).
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Separates the source value in the ST(0) register into its exponent and significand, stores the exponent in ST(0), and pushes the significand onto the register stack. Following this operation, the new top-of-stack register ST(0) contains the value of the original significand expressed as a floating-point value. The sign and significand of this value are the same as those found in the source operand, and the exponent is 3FFFH (biased value for a true exponent of zero). The ST(1) register contains the value of the original operand\u2019s true (unbiased) exponent expressed as a floating-point value. (The operation performed by this instruction is a superset of the IEEE-recommended logb(x) function.)",
"url": "https://www.felixcloutier.com/x86/FXTRACT.html"
};
@@ -1190,16 +1197,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "HADDPD":
case "VHADDPD":
return {
- "html": "
Adds the double-precision floating-point values in the high and low quadwords of the destination operand and stores the result in the low quadword of the destination operand.
Adds the double-precision floating-point values in the high and low quadwords of the source operand and stores the result in the high quadword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
",
- "tooltip": "Adds the double-precision floating-point values in the high and low quadwords of the destination operand and stores the result in the low quadword of the destination operand.",
+ "html": "
Adds the double precision floating-point values in the high and low quadwords of the destination operand and stores the result in the low quadword of the destination operand.
Adds the double precision floating-point values in the high and low quadwords of the source operand and stores the result in the high quadword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
",
+ "tooltip": "Adds the double precision floating-point values in the high and low quadwords of the destination operand and stores the result in the low quadword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/HADDPD.html"
};
case "HADDPS":
case "VHADDPS":
return {
- "html": "
Adds the single-precision floating-point values in the first and second dwords of the destination operand and stores the result in the first dword of the destination operand.
Adds single-precision floating-point values in the third and fourth dword of the destination operand and stores the result in the second dword of the destination operand.
Adds single-precision floating-point values in the first and second dword of the source operand and stores the result in the third dword of the destination operand.
Adds single-precision floating-point values in the third and fourth dword of the source operand and stores the result in the fourth dword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Adds the single-precision floating-point values in the first and second dwords of the destination operand and stores the result in the first dword of the destination operand.",
+ "html": "
Adds the single precision floating-point values in the first and second dwords of the destination operand and stores the result in the first dword of the destination operand.
Adds single precision floating-point values in the third and fourth dword of the destination operand and stores the result in the second dword of the destination operand.
Adds single precision floating-point values in the first and second dword of the source operand and stores the result in the third dword of the destination operand.
Adds single precision floating-point values in the third and fourth dword of the source operand and stores the result in the fourth dword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Adds the single precision floating-point values in the first and second dwords of the destination operand and stores the result in the first dword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/HADDPS.html"
};
@@ -1212,7 +1219,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "HRESET":
return {
- "html": "
Requests the processor to selectively reset selected components of hardware history maintained by the current logical processor. HRESET operation is controlled by the implicit EAX operand. The value of the explicit imm8 operand is ignored. This instruction can only be executed at privilege level 0.
The HRESET instruction can be used to request reset of multiple components of hardware history. Prior to the execution of HRESET, the system software must take the following steps:
1. Enumerate the HRESET capabilities via CPUID.20H.0H:EBX, which indicates what components of hardware history can be reset.
2. Only the bits enumerated by CPUID.20H.0H:EBX can be set in the IA32_HRESET_ENABLE MSR.
HRESET causes a general-protection exception (#GP) if EAX sets any bits that are not set in the IA32_HRESET_ENABLE MSR.
",
+ "html": "
Requests the processor to selectively reset selected components of hardware history maintained by the current logical processor. HRESET operation is controlled by the implicit EAX operand. The value of the explicit imm8 operand is ignored. This instruction can only be executed at privilege level 0.
The HRESET instruction can be used to request reset of multiple components of hardware history. Prior to the execution of HRESET, the system software must take the following steps:
1. Enumerate the HRESET capabilities via CPUID.20H.0H:EBX, which indicates what components of hardware history can be reset.
2. Only the bits enumerated by CPUID.20H.0H:EBX can be set in the IA32_HRESET_ENABLE MSR.
HRESET causes a general-protection exception (#GP) if EAX sets any bits that are not set in the IA32_HRESET_EN-ABLE MSR.
",
"tooltip": "Requests the processor to selectively reset selected components of hardware history maintained by the current logical processor. HRESET operation is controlled by the implicit EAX operand. The value of the explicit imm8 operand is ignored. This instruction can only be executed at privilege level 0.",
"url": "https://www.felixcloutier.com/x86/HRESET.html"
};
@@ -1220,16 +1227,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "HSUBPD":
case "VHSUBPD":
return {
- "html": "
The HSUBPD instruction subtracts horizontally the packed DP FP numbers of both operands.
Subtracts the double-precision floating-point value in the high quadword of the destination operand from the low quadword of the destination operand and stores the result in the low quadword of the destination operand.
Subtracts the double-precision floating-point value in the high quadword of the source operand from the low quadword of the source operand and stores the result in the high quadword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "The HSUBPD instruction subtracts horizontally the packed DP FP numbers of both operands.",
+ "html": "
The HSUBPD instruction subtracts horizontally the packed double precision floating-point numbers of both operands.
Subtracts the double precision floating-point value in the high quadword of the destination operand from the low quadword of the destination operand and stores the result in the low quadword of the destination operand.
Subtracts the double precision floating-point value in the high quadword of the source operand from the low quadword of the source operand and stores the result in the high quadword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "The HSUBPD instruction subtracts horizontally the packed double precision floating-point numbers of both operands.",
"url": "https://www.felixcloutier.com/x86/HSUBPD.html"
};
case "HSUBPS":
case "VHSUBPS":
return {
- "html": "
Subtracts the single-precision floating-point value in the second dword of the destination operand from the first dword of the destination operand and stores the result in the first dword of the destination operand.
Subtracts the single-precision floating-point value in the fourth dword of the destination operand from the third dword of the destination operand and stores the result in the second dword of the destination operand.
Subtracts the single-precision floating-point value in the second dword of the source operand from the first dword of the source operand and stores the result in the third dword of the destination operand.
Subtracts the single-precision floating-point value in the fourth dword of the source operand from the third dword of the source operand and stores the result in the fourth dword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Subtracts the single-precision floating-point value in the second dword of the destination operand from the first dword of the destination operand and stores the result in the first dword of the destination operand.",
+ "html": "
Subtracts the single precision floating-point value in the second dword of the destination operand from the first dword of the destination operand and stores the result in the first dword of the destination operand.
Subtracts the single precision floating-point value in the fourth dword of the destination operand from the third dword of the destination operand and stores the result in the second dword of the destination operand.
Subtracts the single precision floating-point value in the second dword of the source operand from the first dword of the source operand and stores the result in the third dword of the destination operand.
Subtracts the single precision floating-point value in the fourth dword of the source operand from the third dword of the source operand and stores the result in the fourth dword of the destination operand.
In 64-bit mode, use of the REX.R prefix permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Subtracts the single precision floating-point value in the second dword of the destination operand from the first dword of the destination operand and stores the result in the first dword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/HSUBPS.html"
};
@@ -1249,7 +1256,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "IN":
return {
- "html": "
Copies the value from the I/O port specified with the second operand (source operand) to the destination operand (first operand). The source operand can be a byte-immediate or the DX register; the destination operand can be register AL, AX, or EAX, depending on the size of the port being accessed (8, 16, or 32 bits, respectively). Using the DX register as a source operand allows I/O port addresses from 0 to 65,535 to be accessed; using a byte immediate allows I/O port addresses 0 to 255 to be accessed.
When accessing an 8-bit I/O port, the opcode determines the port size; when accessing a 16- and 32-bit I/O port, the operand-size attribute determines the port size. At the machine code level, I/O instructions are shorter when accessing 8-bit I/O ports. Here, the upper eight bits of the port address will be 0.
This instruction is only useful for accessing I/O ports located in the processor\u2019s I/O address space. See Chapter 19, \u201cInput/Output,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information on accessing I/O ports in the I/O address space.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Copies the value from the I/O port specified with the second operand (source operand) to the destination operand (first operand). The source operand can be a byte-immediate or the DX register; the destination operand can be register AL, AX, or EAX, depending on the size of the port being accessed (8, 16, or 32 bits, respectively). Using the DX register as a source operand allows I/O port addresses from 0 to 65,535 to be accessed; using a byte immediate allows I/O port addresses 0 to 255 to be accessed.
When accessing an 8-bit I/O port, the opcode determines the port size; when accessing a 16- and 32-bit I/O port, the operand-size attribute determines the port size. At the machine code level, I/O instructions are shorter when accessing 8-bit I/O ports. Here, the upper eight bits of the port address will be 0.
This instruction is only useful for accessing I/O ports located in the processor\u2019s I/O address space. See Chapter 19, \u201cInput/Output,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information on accessing I/O ports in the I/O address space.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Copies the value from the I/O port specified with the second operand (source operand) to the destination operand (first operand). The source operand can be a byte-immediate or the DX register; the destination operand can be register AL, AX, or EAX, depending on the size of the port being accessed (8, 16, or 32 bits, respectively). Using the DX register as a source operand allows I/O port addresses from 0 to 65,535 to be accessed; using a byte immediate allows I/O port addresses 0 to 255 to be accessed.",
"url": "https://www.felixcloutier.com/x86/IN.html"
};
@@ -1274,7 +1281,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "INSD":
case "INSW":
return {
- "html": "
Copies the data from the I/O port specified with the source operand (second operand) to the destination operand (first operand). The source operand is an I/O port address (from 0 to 65,535) that is read from the DX register. The destination operand is a memory location, the address of which is read from either the ES:DI, ES:EDI or the RDI registers (depending on the address-size attribute of the instruction, 16, 32 or 64, respectively). (The ES segment cannot be overridden with a segment override prefix.) The size of the I/O port being accessed (that is, the size of the source and destination operands) is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.
At the assembly-code level, two forms of this instruction are allowed: the \u201cexplicit-operands\u201d form and the \u201cno-operands\u201d form. The explicit-operands form (specified with the INS mnemonic) allows the source and destination operands to be specified explicitly. Here, the source operand must be \u201cDX,\u201d and the destination operand should be a symbol that indicates the size of the I/O port and the destination address. This explicit-operands form is provided to allow documentation; however, note that the documentation provided by this form can be misleading. That is, the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location. The location is always specified by the ES:(E)DI registers, which must be loaded correctly before the INS instruction is executed.
The no-operands form provides \u201cshort forms\u201d of the byte, word, and doubleword versions of the INS instructions. Here also DX is assumed by the processor to be the source operand and ES:(E)DI is assumed to be the destination operand. The size of the I/O port is specified with the choice of mnemonic: INSB (byte), INSW (word), or INSD (doubleword).
After the byte, word, or doubleword is transfer from the I/O port to the memory location, the DI/EDI/RDI register is incremented or decremented automatically according to the setting of the DF flag in the EFLAGS register. (If the DF flag is 0, the (E)DI register is incremented; if the DF flag is 1, the (E)DI register is decremented.) The (E)DI register is incremented or decremented by 1 for byte operations, by 2 for word operations, or by 4 for doubleword operations.
The INS, INSB, INSW, and INSD instructions can be preceded by the REP prefix for block input of ECX bytes, words, or doublewords. See \u201cREP/REPE/REPZ /REPNE/REPNZ\u2014Repeat String Operation Prefix\u201d in Chapter 4 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B, for a description of the REP prefix.
",
+ "html": "
Copies the data from the I/O port specified with the source operand (second operand) to the destination operand (first operand). The source operand is an I/O port address (from 0 to 65,535) that is read from the DX register. The destination operand is a memory location, the address of which is read from either the ES:DI, ES:EDI or the RDI registers (depending on the address-size attribute of the instruction, 16, 32 or 64, respectively). (The ES segment cannot be overridden with a segment override prefix.) The size of the I/O port being accessed (that is, the size of the source and destination operands) is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.
At the assembly-code level, two forms of this instruction are allowed: the \u201cexplicit-operands\u201d form and the \u201cno-operands\u201d form. The explicit-operands form (specified with the INS mnemonic) allows the source and destination operands to be specified explicitly. Here, the source operand must be \u201cDX,\u201d and the destination operand should be a symbol that indicates the size of the I/O port and the destination address. This explicit-operands form is provided to allow documentation; however, note that the documentation provided by this form can be misleading. That is, the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location. The location is always specified by the ES:(E)DI registers, which must be loaded correctly before the INS instruction is executed.
The no-operands form provides \u201cshort forms\u201d of the byte, word, and doubleword versions of the INS instructions. Here also DX is assumed by the processor to be the source operand and ES:(E)DI is assumed to be the destination operand. The size of the I/O port is specified with the choice of mnemonic: INSB (byte), INSW (word), or INSD (doubleword).
After the byte, word, or doubleword is transfer from the I/O port to the memory location, the DI/EDI/RDI register is incremented or decremented automatically according to the setting of the DF flag in the EFLAGS register. (If the DF flag is 0, the (E)DI register is incremented; if the DF flag is 1, the (E)DI register is decremented.) The (E)DI register is incremented or decremented by 1 for byte operations, by 2 for word operations, or by 4 for doubleword operations.
The INS, INSB, INSW, and INSD instructions can be preceded by the REP prefix for block input of ECX bytes, words, or doublewords. See \u201cREP/REPE/REPZ /REPNE/REPNZ\u2014Repeat String Operation Prefix\u201d in Chapter 4 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B, for a description of the REP prefix.
",
"tooltip": "Copies the data from the I/O port specified with the source operand (second operand) to the destination operand (first operand). The source operand is an I/O port address (from 0 to 65,535) that is read from the DX register. The destination operand is a memory location, the address of which is read from either the ES:DI, ES:EDI or the RDI registers (depending on the address-size attribute of the instruction, 16, 32 or 64, respectively). (The ES segment cannot be overridden with a segment override prefix.) The size of the I/O port being accessed (that is, the size of the source and destination operands) is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.",
"url": "https://www.felixcloutier.com/x86/INS%3AINSB%3AINSW%3AINSD.html"
};
@@ -1282,7 +1289,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "INSERTPS":
case "VINSERTPS":
return {
- "html": "
(register source form)
Copy a single-precision scalar floating-point element into a 128-bit vector register. The immediate operand has three fields, where the ZMask bits specify which elements of the destination will be set to zero, the Count_D bits specify which element of the destination will be overwritten with the scalar value, and for vector register sources the Count_S bits specify which element of the source will be copied. When the scalar source is a memory operand the Count_S bits are ignored.
",
+ "html": "
(register source form)
Copy a single precision scalar floating-point element into a 128-bit vector register. The immediate operand has three fields, where the ZMask bits specify which elements of the destination will be set to zero, the Count_D bits specify which element of the destination will be overwritten with the scalar value, and for vector register sources the Count_S bits specify which element of the source will be copied. When the scalar source is a memory operand the Count_S bits are ignored.
",
"tooltip": "(register source form)",
"url": "https://www.felixcloutier.com/x86/INSERTPS.html"
};
@@ -1292,7 +1299,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "INT3":
case "INTO":
return {
- "html": "
The INT n instruction generates a call to the interrupt or exception handler specified with the destination operand (see the section titled \u201cInterrupts and Exceptions\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). The destination operand specifies a vector from 0 to 255, encoded as an 8-bit unsigned intermediate value. Each vector provides an index to a gate descriptor in the IDT. The first 32 vectors are reserved by Intel for system use. Some of these vectors are used for internally generated exceptions.
The INT n instruction is the general mnemonic for executing a software-generated call to an interrupt handler. The INTO instruction is a special mnemonic for calling overflow exception (#OF), exception 4. The overflow interrupt checks the OF flag in the EFLAGS register and calls the overflow interrupt handler if the OF flag is set to 1. (The INTO instruction cannot be used in 64-bit mode.)
The INT3 instruction uses a one-byte opcode (CC) and is intended for calling the debug exception handler with a breakpoint exception (#BP). (This one-byte form is useful because it can replace the first byte of any instruction at which a breakpoint is desired, including other one-byte instructions, without overwriting other instructions.)
The INT1 instruction also uses a one-byte opcode (F1) and generates a debug exception (#DB) without setting any bits in DR6.1 Hardware vendors may use the INT1 instruction for hardware debug. For that reason, Intel recommends software vendors instead use the INT3 instruction for software breakpoints.
An interrupt generated by the INTO, INT3, or INT1 instruction differs from one generated by INT n in the following ways:
",
+ "html": "
The INT n instruction generates a call to the interrupt or exception handler specified with the destination operand (see the section titled \u201cInterrupts and Exceptions\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). The destination operand specifies a vector from 0 to 255, encoded as an 8-bit unsigned intermediate value. Each vector provides an index to a gate descriptor in the IDT. The first 32 vectors are reserved by Intel for system use. Some of these vectors are used for internally generated exceptions.
The INT n instruction is the general mnemonic for executing a software-generated call to an interrupt handler. The INTO instruction is a special mnemonic for calling overflow exception (#OF), exception 4. The overflow interrupt checks the OF flag in the EFLAGS register and calls the overflow interrupt handler if the OF flag is set to 1. (The INTO instruction cannot be used in 64-bit mode.)
The INT3 instruction uses a one-byte opcode (CC) and is intended for calling the debug exception handler with a breakpoint exception (#BP). (This one-byte form is useful because it can replace the first byte of any instruction at which a breakpoint is desired, including other one-byte instructions, without overwriting other instructions.)
The INT1 instruction also uses a one-byte opcode (F1) and generates a debug exception (#DB) without setting any bits in DR6.1 Hardware vendors may use the INT1 instruction for hardware debug. For that reason, Intel recommends software vendors instead use the INT3 instruction for software breakpoints.
An interrupt generated by the INTO, INT3, or INT1 instruction differs from one generated by INT n in the following ways:
",
"tooltip": "The INT n instruction generates a call to the interrupt or exception handler specified with the destination operand (see the section titled \u201cInterrupts and Exceptions\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). The destination operand specifies a vector from 0 to 255, encoded as an 8-bit unsigned intermediate value. Each vector provides an index to a gate descriptor in the IDT. The first 32 vectors are reserved by Intel for system use. Some of these vectors are used for internally generated exceptions.",
"url": "https://www.felixcloutier.com/x86/INTn%3AINTO%3AINT3%3AINT1.html"
};
@@ -1306,8 +1313,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "INVPCID":
return {
- "html": "
Invalidates mappings in the translation lookaside buffers (TLBs) and paging-structure caches based on process-context identifier (PCID). (See Section 4.10, \u201cCaching Translation Information,\u201d in Intel 64 and IA-32 Architecture Software Developer\u2019s Manual, Volume 3A.) Invalidation is based on the INVPCID type specified in the register operand and the INVPCID descriptor specified in the memory operand.
Outside 64-bit mode, the register operand is always 32 bits, regardless of the value of CS.D. In 64-bit mode the register operand has 64 bits.
There are four INVPCID types currently defined:
The INVPCID descriptor comprises 128 bits and consists of a PCID and a linear address as shown in Figure 3-24. For INVPCID type 0, the processor uses the full 64 bits of the linear address even outside 64-bit mode; the linear address is not used for other INVPCID types.
If CR4.PCIDE = 0, a logical processor does not cache information for any PCID other than 000H. In this case, executions with INVPCID types 0 and 1 are allowed only if the PCID specified in the INVPCID descriptor is 000H; executions with INVPCID types 2 and 3 invalidate mappings only for PCID 000H. Note that CR4.PCIDE must be 0 outside IA-32e mode (see Chapter 4.10.1, \u201cProcess-Context Identifiers (PCIDs)\u201a\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
",
- "tooltip": "Invalidates mappings in the translation lookaside buffers (TLBs) and paging-structure caches based on process-context identifier (PCID). (See Section 4.10, \u201cCaching Translation Information,\u201d in Intel 64 and IA-32 Architecture Software Developer\u2019s Manual, Volume 3A.) Invalidation is based on the INVPCID type specified in the register operand and the INVPCID descriptor specified in the memory operand.",
+ "html": "
Invalidates mappings in the translation lookaside buffers (TLBs) and paging-structure caches based on process-context identifier (PCID). (See Section 4.10, \u201cCaching Translation Information,\u201d in the Intel 64 and IA-32 Architecture Software Developer\u2019s Manual, Volume 3A.) Invalidation is based on the INVPCID type specified in the register operand and the INVPCID descriptor specified in the memory operand.
Outside 64-bit mode, the register operand is always 32 bits, regardless of the value of CS.D. In 64-bit mode the register operand has 64 bits.
There are four INVPCID types currently defined:
The INVPCID descriptor comprises 128 bits and consists of a PCID and a linear address as shown in Figure 3-25. For INVPCID type 0, the processor uses the full 64 bits of the linear address even outside 64-bit mode; the linear address is not used for other INVPCID types.
If CR4.PCIDE = 0, a logical processor does not cache information for any PCID other than 000H. In this case, executions with INVPCID types 0 and 1 are allowed only if the PCID specified in the INVPCID descriptor is 000H; executions with INVPCID types 2 and 3 invalidate mappings only for PCID 000H. Note that CR4.PCIDE must be 0 outside IA-32e mode (see Section 4.10.1, \u201cProcess-Context Identifiers (PCIDs),\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
",
+ "tooltip": "Invalidates mappings in the translation lookaside buffers (TLBs) and paging-structure caches based on process-context identifier (PCID). (See Section 4.10, \u201cCaching Translation Information,\u201d in the Intel 64 and IA-32 Architecture Software Developer\u2019s Manual, Volume 3A.) Invalidation is based on the INVPCID type specified in the register operand and the INVPCID descriptor specified in the memory operand.",
"url": "https://www.felixcloutier.com/x86/INVPCID.html"
};
@@ -1315,14 +1322,14 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "IRETD":
case "IRETQ":
return {
- "html": "
Returns program control from an exception or interrupt handler to a program or procedure that was interrupted by an exception, an external interrupt, or a software-generated interrupt. These instructions are also used to perform a return from a nested task. (A nested task is created when a CALL instruction is used to initiate a task switch or when an interrupt or exception causes a task switch to an interrupt or exception handler.) See the section titled \u201cTask Linking\u201d in Chapter 7 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
IRET and IRETD are mnemonics for the same opcode. The IRETD mnemonic (interrupt return double) is intended for use when returning from an interrupt when using the 32-bit operand size; however, most assemblers use the IRET mnemonic interchangeably for both operand sizes.
In Real-Address Mode, the IRET instruction performs a far return to the interrupted program or procedure. During this operation, the processor pops the return instruction pointer, return code segment selector, and EFLAGS image from the stack to the EIP, CS, and EFLAGS registers, respectively, and then resumes execution of the interrupted program or procedure.
In Protected Mode, the action of the IRET instruction depends on the settings of the NT (nested task) and VM flags in the EFLAGS register and the VM flag in the EFLAGS image stored on the current stack. Depending on the setting of these flags, the processor performs the following types of interrupt returns:
If the NT flag (EFLAGS register) is cleared, the IRET instruction performs a far return from the interrupt procedure, without a task switch. The code segment being returned to must be equally or less privileged than the interrupt handler routine (as indicated by the RPL field of the code segment selector popped from the stack).
",
- "tooltip": "Returns program control from an exception or interrupt handler to a program or procedure that was interrupted by an exception, an external interrupt, or a software-generated interrupt. These instructions are also used to perform a return from a nested task. (A nested task is created when a CALL instruction is used to initiate a task switch or when an interrupt or exception causes a task switch to an interrupt or exception handler.) See the section titled \u201cTask Linking\u201d in Chapter 7 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.",
+ "html": "
Returns program control from an exception or interrupt handler to a program or procedure that was interrupted by an exception, an external interrupt, or a software-generated interrupt. These instructions are also used to perform a return from a nested task. (A nested task is created when a CALL instruction is used to initiate a task switch or when an interrupt or exception causes a task switch to an interrupt or exception handler.) See the section titled \u201cTask Linking\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
IRET and IRETD are mnemonics for the same opcode. The IRETD mnemonic (interrupt return double) is intended for use when returning from an interrupt when using the 32-bit operand size; however, most assemblers use the IRET mnemonic interchangeably for both operand sizes.
In Real-Address Mode, the IRET instruction performs a far return to the interrupted program or procedure. During this operation, the processor pops the return instruction pointer, return code segment selector, and EFLAGS image from the stack to the EIP, CS, and EFLAGS registers, respectively, and then resumes execution of the interrupted program or procedure.
In Protected Mode, the action of the IRET instruction depends on the settings of the NT (nested task) and VM flags in the EFLAGS register and the VM flag in the EFLAGS image stored on the current stack. Depending on the setting of these flags, the processor performs the following types of interrupt returns:
If the NT flag (EFLAGS register) is cleared, the IRET instruction performs a far return from the interrupt procedure, without a task switch. The code segment being returned to must be equally or less privileged than the interrupt handler routine (as indicated by the RPL field of the code segment selector popped from the stack).
",
+ "tooltip": "Returns program control from an exception or interrupt handler to a program or procedure that was interrupted by an exception, an external interrupt, or a software-generated interrupt. These instructions are also used to perform a return from a nested task. (A nested task is created when a CALL instruction is used to initiate a task switch or when an interrupt or exception causes a task switch to an interrupt or exception handler.) See the section titled \u201cTask Linking\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.",
"url": "https://www.felixcloutier.com/x86/IRET%3AIRETD%3AIRETQ.html"
};
case "JMP":
return {
- "html": "
Transfers program control to a different point in the instruction stream without recording return information. The destination (target) operand specifies the address of the instruction being jumped to. This operand can be an immediate value, a general-purpose register, or a memory location.
This instruction can be used to execute four different types of jumps:
A task switch can only be executed in protected mode (see Chapter 7, in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for information on performing task switches with the JMP instruction).
Near and Short Jumps. When executing a near jump, the processor jumps to the address (within the current code segment) that is specified with the target operand. The target operand specifies either an absolute offset (that is an offset from the base of the code segment) or a relative offset (a signed displacement relative to the current
value of the instruction pointer in the EIP register). A near jump to a relative offset of 8-bits (rel8) is referred to as a short jump. The CS register is not changed on near and short jumps.
",
+ "html": "
Transfers program control to a different point in the instruction stream without recording return information. The destination (target) operand specifies the address of the instruction being jumped to. This operand can be an immediate value, a general-purpose register, or a memory location.
This instruction can be used to execute four different types of jumps:
A task switch can only be executed in protected mode (see Chapter 8, in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for information on performing task switches with the JMP instruction).
Near and Short Jumps. When executing a near jump, the processor jumps to the address (within the current code segment) that is specified with the target operand. The target operand specifies either an absolute offset (that is an offset from the base of the code segment) or a relative offset (a signed displacement relative to the current
value of the instruction pointer in the EIP register). A near jump to a relative offset of 8-bits (rel8) is referred to as a short jump. The CS register is not changed on near and short jumps.
",
"tooltip": "Transfers program control to a different point in the instruction stream without recording return information. The destination (target) operand specifies the address of the instruction being jumped to. This operand can be an immediate value, a general-purpose register, or a memory location.",
"url": "https://www.felixcloutier.com/x86/JMP.html"
};
@@ -1513,7 +1520,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "LDMXCSR":
case "VLDMXCSR":
return {
- "html": "
Loads the source operand into the MXCSR control/status register. The source operand is a 32-bit memory location. See \u201cMXCSR Control and Status Register\u201d in Chapter 10, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of the MXCSR register and its contents.
The LDMXCSR instruction is typically used in conjunction with the (V)STMXCSR instruction, which stores the contents of the MXCSR register in memory.
The default MXCSR value at reset is 1F80H.
If a (V)LDMXCSR instruction clears a SIMD floating-point exception mask bit and sets the corresponding exception flag bit, a SIMD floating-point exception will not be immediately generated. The exception will be generated only upon the execution of the next instruction that meets both conditions below:
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Loads the source operand into the MXCSR control/status register. The source operand is a 32-bit memory location. See \u201cMXCSR Control and Status Register\u201d in Chapter 10, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of the MXCSR register and its contents.
The LDMXCSR instruction is typically used in conjunction with the (V)STMXCSR instruction, which stores the contents of the MXCSR register in memory.
The default MXCSR value at reset is 1F80H.
If a (V)LDMXCSR instruction clears a SIMD floating-point exception mask bit and sets the corresponding exception flag bit, a SIMD floating-point exception will not be immediately generated. The exception will be generated only upon the execution of the next instruction that meets both conditions below:
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Loads the source operand into the MXCSR control/status register. The source operand is a 32-bit memory location. See \u201cMXCSR Control and Status Register\u201d in Chapter 10, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for a description of the MXCSR register and its contents.",
"url": "https://www.felixcloutier.com/x86/LDMXCSR.html"
};
@@ -1538,7 +1545,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "LEAVE":
return {
- "html": "
Releases the stack frame set up by an earlier ENTER instruction. The LEAVE instruction copies the frame pointer (in the EBP register) into the stack pointer register (ESP), which releases the stack space allocated to the stack frame. The old frame pointer (the frame pointer for the calling procedure that was saved by the ENTER instruction) is then popped from the stack into the EBP register, restoring the calling procedure\u2019s stack frame.
A RET instruction is commonly executed following a LEAVE instruction to return program control to the calling procedure.
See \u201cProcedure Calls for Block-Structured Languages\u201d in Chapter 7 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for detailed information on the use of the ENTER and LEAVE instructions.
In 64-bit mode, the instruction\u2019s default operation size is 64 bits; 32-bit operation cannot be encoded. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "html": "
Releases the stack frame set up by an earlier ENTER instruction. The LEAVE instruction copies the frame pointer (in the EBP register) into the stack pointer register (ESP), which releases the stack space allocated to the stack frame. The old frame pointer (the frame pointer for the calling procedure that was saved by the ENTER instruction) is then popped from the stack into the EBP register, restoring the calling procedure\u2019s stack frame.
A RET instruction is commonly executed following a LEAVE instruction to return program control to the calling procedure.
See \u201cProcedure Calls for Block-Structured Languages\u201d in Chapter 7 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for detailed information on the use of the ENTER and LEAVE instructions.
In 64-bit mode, the instruction\u2019s default operation size is 64 bits; 32-bit operation cannot be encoded. See the summary chart at the beginning of this section for encoding data and limits.
",
"tooltip": "Releases the stack frame set up by an earlier ENTER instruction. The LEAVE instruction copies the frame pointer (in the EBP register) into the stack pointer register (ESP), which releases the stack space allocated to the stack frame. The old frame pointer (the frame pointer for the calling procedure that was saved by the ENTER instruction) is then popped from the stack into the EBP register, restoring the calling procedure\u2019s stack frame.",
"url": "https://www.felixcloutier.com/x86/LEAVE.html"
};
@@ -1553,7 +1560,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "LGDT":
case "LIDT":
return {
- "html": "
Loads the values in the source operand into the global descriptor table register (GDTR) or the interrupt descriptor table register (IDTR). The source operand specifies a 6-byte memory location that contains the base address (a linear address) and the limit (size of table in bytes) of the global descriptor table (GDT) or the interrupt descriptor table (IDT). If operand-size attribute is 32 bits, a 16-bit limit (lower 2 bytes of the 6-byte data operand) and a 32-bit base address (upper 4 bytes of the data operand) are loaded into the register. If the operand-size attribute is 16 bits, a 16-bit limit (lower 2 bytes) and a 24-bit base address (third, fourth, and fifth byte) are loaded. Here, the high-order byte of the operand is not used and the high-order byte of the base address in the GDTR or IDTR is filled with zeros.
The LGDT and LIDT instructions are used only in operating-system software; they are not used in application programs. They are the only instructions that directly load a linear address (that is, not a segment-relative address) and a limit in protected mode. They are commonly executed in real-address mode to allow processor initialization prior to switching to protected mode.
In 64-bit mode, the instruction\u2019s operand size is fixed at 8+2 bytes (an 8-byte base and a 2-byte limit). See the summary chart at the beginning of this section for encoding data and limits.
See \u201cSGDT\u2014Store Global Descriptor Table Register\u201d in Chapter 4, Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B, for information on storing the contents of the GDTR and IDTR.
",
+ "html": "
Loads the values in the source operand into the global descriptor table register (GDTR) or the interrupt descriptor table register (IDTR). The source operand specifies a 6-byte memory location that contains the base address (a linear address) and the limit (size of table in bytes) of the global descriptor table (GDT) or the interrupt descriptor table (IDT). If operand-size attribute is 32 bits, a 16-bit limit (lower 2 bytes of the 6-byte data operand) and a 32-bit base address (upper 4 bytes of the data operand) are loaded into the register. If the operand-size attribute is 16 bits, a 16-bit limit (lower 2 bytes) and a 24-bit base address (third, fourth, and fifth byte) are loaded. Here, the high-order byte of the operand is not used and the high-order byte of the base address in the GDTR or IDTR is filled with zeros.
The LGDT and LIDT instructions are used only in operating-system software; they are not used in application programs. They are the only instructions that directly load a linear address (that is, not a segment-relative address) and a limit in protected mode. They are commonly executed in real-address mode to allow processor initialization prior to switching to protected mode.
In 64-bit mode, the instruction\u2019s operand size is fixed at 8+2 bytes (an 8-byte base and a 2-byte limit). See the summary chart at the beginning of this section for encoding data and limits.
See \u201cSGDT\u2014Store Global Descriptor Table Register\u201d in Chapter 4, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B, for information on storing the contents of the GDTR and IDTR.
",
"tooltip": "Loads the values in the source operand into the global descriptor table register (GDTR) or the interrupt descriptor table register (IDTR). The source operand specifies a 6-byte memory location that contains the base address (a linear address) and the limit (size of table in bytes) of the global descriptor table (GDT) or the interrupt descriptor table (IDT). If operand-size attribute is 32 bits, a 16-bit limit (lower 2 bytes of the 6-byte data operand) and a 32-bit base address (upper 4 bytes of the data operand) are loaded into the register. If the operand-size attribute is 16 bits, a 16-bit limit (lower 2 bytes) and a 24-bit base address (third, fourth, and fifth byte) are loaded. Here, the high-order byte of the operand is not used and the high-order byte of the base address in the GDTR or IDTR is filled with zeros.",
"url": "https://www.felixcloutier.com/x86/LGDT%3ALIDT.html"
};
@@ -1623,14 +1630,14 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MASKMOVDQU":
case "VMASKMOVDQU":
return {
- "html": "
Stores selected bytes from the source operand (first operand) into an 128-bit memory location. The mask operand (second operand) selects which bytes from the source operand are written to memory. The source and mask operands are XMM registers. The memory location specified by the effective address in the DI/EDI/RDI register (the default segment register is DS, but this may be overridden with a segment-override prefix). The memory location does not need to be aligned on a natural boundary. (The size of the store address depends on the address-size attribute.)
The most significant bit in each byte of the mask operand determines whether the corresponding byte in the source operand is written to the corresponding byte location in memory: 0 indicates no write and 1 indicates write.
The MASKMOVDQU instruction generates a non-temporal hint to the processor to minimize cache pollution. The non-temporal hint is implemented by using a write combining (WC) memory type protocol (see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MASKMOVDQU instructions if multiple processors might use different memory types to read/write the destination memory locations.
Behavior with a mask of all 0s is as follows:
The MASKMOVDQU instruction can be used to improve performance of algorithms that need to merge data on a byte-by-byte basis. MASKMOVDQU should not cause a read for ownership; doing so generates unnecessary bandwidth since data is to be written directly using the byte-mask without allocating old data prior to the store.
",
+ "html": "
Stores selected bytes from the source operand (first operand) into an 128-bit memory location. The mask operand (second operand) selects which bytes from the source operand are written to memory. The source and mask operands are XMM registers. The memory location specified by the effective address in the DI/EDI/RDI register (the default segment register is DS, but this may be overridden with a segment-override prefix). The memory location does not need to be aligned on a natural boundary. (The size of the store address depends on the address-size attribute.)
The most significant bit in each byte of the mask operand determines whether the corresponding byte in the source operand is written to the corresponding byte location in memory: 0 indicates no write and 1 indicates write.
The MASKMOVDQU instruction generates a non-temporal hint to the processor to minimize cache pollution. The non-temporal hint is implemented by using a write combining (WC) memory type protocol (see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MASKMOVDQU instructions if multiple processors might use different memory types to read/write the destination memory locations.
Behavior with a mask of all 0s is as follows:
The MASKMOVDQU instruction can be used to improve performance of algorithms that need to merge data on a byte-by-byte basis. MASKMOVDQU should not cause a read for ownership; doing so generates unnecessary bandwidth since data is to be written directly using the byte-mask without allocating old data prior to the store.
",
"tooltip": "Stores selected bytes from the source operand (first operand) into an 128-bit memory location. The mask operand (second operand) selects which bytes from the source operand are written to memory. The source and mask operands are XMM registers. The memory location specified by the effective address in the DI/EDI/RDI register (the default segment register is DS, but this may be overridden with a segment-override prefix). The memory location does not need to be aligned on a natural boundary. (The size of the store address depends on the address-size attribute.)",
"url": "https://www.felixcloutier.com/x86/MASKMOVDQU.html"
};
case "MASKMOVQ":
return {
- "html": "
Stores selected bytes from the source operand (first operand) into a 64-bit memory location. The mask operand (second operand) selects which bytes from the source operand are written to memory. The source and mask operands are MMX technology registers. The memory location specified by the effective address in the DI/EDI/RDI register (the default segment register is DS, but this may be overridden with a segment-override prefix). The memory location does not need to be aligned on a natural boundary. (The size of the store address depends on the address-size attribute.)
The most significant bit in each byte of the mask operand determines whether the corresponding byte in the source operand is written to the corresponding byte location in memory: 0 indicates no write and 1 indicates write.
The MASKMOVQ instruction generates a non-temporal hint to the processor to minimize cache pollution. The non-temporal hint is implemented by using a write combining (WC) memory type protocol (see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MASKMOVQ instructions if multiple processors might use different memory types to read/write the destination memory locations.
This instruction causes a transition from x87 FPU to MMX technology state (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]).
The behavior of the MASKMOVQ instruction with a mask of all 0s is as follows:
",
+ "html": "
Stores selected bytes from the source operand (first operand) into a 64-bit memory location. The mask operand (second operand) selects which bytes from the source operand are written to memory. The source and mask operands are MMX technology registers. The memory location specified by the effective address in the DI/EDI/RDI register (the default segment register is DS, but this may be overridden with a segment-override prefix). The memory location does not need to be aligned on a natural boundary. (The size of the store address depends on the address-size attribute.)
The most significant bit in each byte of the mask operand determines whether the corresponding byte in the source operand is written to the corresponding byte location in memory: 0 indicates no write and 1 indicates write.
The MASKMOVQ instruction generates a non-temporal hint to the processor to minimize cache pollution. The non-temporal hint is implemented by using a write combining (WC) memory type protocol (see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10, of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MASKMOVQ instructions if multiple processors might use different memory types to read/write the destination memory locations.
This instruction causes a transition from x87 FPU to MMX technology state (that is, the x87 FPU top-of-stack pointer is set to 0 and the x87 FPU tag word is set to all 0s [valid]).
The behavior of the MASKMOVQ instruction with a mask of all 0s is as follows:
",
"tooltip": "Stores selected bytes from the source operand (first operand) into a 64-bit memory location. The mask operand (second operand) selects which bytes from the source operand are written to memory. The source and mask operands are MMX technology registers. The memory location specified by the effective address in the DI/EDI/RDI register (the default segment register is DS, but this may be overridden with a segment-override prefix). The memory location does not need to be aligned on a natural boundary. (The size of the store address depends on the address-size attribute.)",
"url": "https://www.felixcloutier.com/x86/MASKMOVQ.html"
};
@@ -1638,70 +1645,70 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MAXPD":
case "VMAXPD":
return {
- "html": "
Performs a SIMD compare of the packed double-precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MAXPD can be emulated using a sequence of instructions, such as a comparison followed by AND, ANDN and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Performs a SIMD compare of the packed double-precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.",
+ "html": "
Performs a SIMD compare of the packed double precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MAXPD can be emulated using a sequence of instructions, such as a comparison followed by AND, ANDN, and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Performs a SIMD compare of the packed double precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.",
"url": "https://www.felixcloutier.com/x86/MAXPD.html"
};
case "MAXPS":
case "VMAXPS":
return {
- "html": "
Performs a SIMD compare of the packed single-precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MAXPS can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Performs a SIMD compare of the packed single-precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.",
+ "html": "
Performs a SIMD compare of the packed single precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MAXPS can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN, and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Performs a SIMD compare of the packed single precision floating-point values in the first source operand and the second source operand and returns the maximum value for each pair of values to the destination operand.",
"url": "https://www.felixcloutier.com/x86/MAXPS.html"
};
case "MAXSD":
case "VMAXSD":
return {
- "html": "
Compares the low double-precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low quadword of the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers. When the second source operand is a memory operand, only 64 bits are accessed.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second source operand is an SNaN, that SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN of either source operand be returned, the action of MAXSD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded version: Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
",
- "tooltip": "Compares the low double-precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low quadword of the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers. When the second source operand is a memory operand, only 64 bits are accessed.",
+ "html": "
Compares the low double precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low quadword of the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers. When the second source operand is a memory operand, only 64 bits are accessed.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second source operand is an SNaN, that SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN of either source operand be returned, the action of MAXSD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN, and OR.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded version: Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
",
+ "tooltip": "Compares the low double precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low quadword of the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers. When the second source operand is a memory operand, only 64 bits are accessed.",
"url": "https://www.felixcloutier.com/x86/MAXSD.html"
};
case "MAXSS":
case "VMAXSS":
return {
- "html": "
Compares the low single-precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low doubleword of the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second source operand is an SNaN, that SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN from either source operand be returned, the action of MAXSS can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR.
The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL:32) of the corresponding destination register remain unchanged.
",
- "tooltip": "Compares the low single-precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low doubleword of the destination operand.",
+ "html": "
Compares the low single precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low doubleword of the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second source operand is an SNaN, that SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN from either source operand be returned, the action of MAXSS can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN, and OR.
The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL:32) of the corresponding destination register remain unchanged.
",
+ "tooltip": "Compares the low single precision floating-point values in the first source operand and the second source operand, and returns the maximum value to the low doubleword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/MAXSS.html"
};
case "MINPD":
case "VMINPD":
return {
- "html": "
Performs a SIMD compare of the packed double-precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MINPD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Performs a SIMD compare of the packed double-precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.",
+ "html": "
Performs a SIMD compare of the packed double precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MINPD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN, and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Performs a SIMD compare of the packed double precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.",
"url": "https://www.felixcloutier.com/x86/MINPD.html"
};
case "MINPS":
case "VMINPS":
return {
- "html": "
Performs a SIMD compare of the packed single-precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MINPS can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
- "tooltip": "Performs a SIMD compare of the packed single-precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.",
+ "html": "
Performs a SIMD compare of the packed single precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second operand (source operand) is returned. If a value in the second operand is an SNaN, then SNaN is forwarded unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second operand) be returned, the action of MINPS can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN, and OR.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
+ "tooltip": "Performs a SIMD compare of the packed single precision floating-point values in the first source operand and the second source operand and returns the minimum value for each pair of values to the destination operand.",
"url": "https://www.felixcloutier.com/x86/MINPS.html"
};
case "MINSD":
case "VMINSD":
return {
- "html": "
Compares the low double-precision floating-point values in the first source operand and the second source operand, and returns the minimum value to the low quadword of the destination operand. When the source operand is a memory operand, only the 64 bits are accessed.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second source operand is an SNaN, then SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second source) be returned, the action of MINSD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
",
- "tooltip": "Compares the low double-precision floating-point values in the first source operand and the second source operand, and returns the minimum value to the low quadword of the destination operand. When the source operand is a memory operand, only the 64 bits are accessed.",
+ "html": "
Compares the low double precision floating-point values in the first source operand and the second source operand, and returns the minimum value to the low quadword of the destination operand. When the source operand is a memory operand, only the 64 bits are accessed.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second source operand is an SNaN, then SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN source operand (from either the first or second source) be returned, the action of MINSD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN, and OR.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
",
+ "tooltip": "Compares the low double precision floating-point values in the first source operand and the second source operand, and returns the minimum value to the low quadword of the destination operand. When the source operand is a memory operand, only the 64 bits are accessed.",
"url": "https://www.felixcloutier.com/x86/MINSD.html"
};
case "MINSS":
case "VMINSS":
return {
- "html": "
Compares the low single-precision floating-point values in the first source operand and the second source operand and returns the minimum value to the low doubleword of the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second operand is an SNaN, that SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN in either source operand be returned, the action of MINSD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN and OR.
The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL:32) of the corresponding destination register remain unchanged.
",
- "tooltip": "Compares the low single-precision floating-point values in the first source operand and the second source operand and returns the minimum value to the low doubleword of the destination operand.",
+ "html": "
Compares the low single precision floating-point values in the first source operand and the second source operand and returns the minimum value to the low doubleword of the destination operand.
If the values being compared are both 0.0s (of either sign), the value in the second source operand is returned. If a value in the second operand is an SNaN, that SNaN is returned unchanged to the destination (that is, a QNaN version of the SNaN is not returned).
If only one value is a NaN (SNaN or QNaN) for this instruction, the second source operand, either a NaN or a valid floating-point value, is written to the result. If instead of this behavior, it is required that the NaN in either source operand be returned, the action of MINSD can be emulated using a sequence of instructions, such as, a comparison followed by AND, ANDN, and OR.
The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL:32) of the corresponding destination register remain unchanged.
",
+ "tooltip": "Compares the low single precision floating-point values in the first source operand and the second source operand and returns the minimum value to the low doubleword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/MINSS.html"
};
case "MOV":
return {
- "html": "
Copies the second operand (source operand) to the first operand (destination operand). The source operand can be an immediate value, general-purpose register, segment register, or memory location; the destination register can be a general-purpose register, segment register, or memory location. Both operands must be the same size, which can be a byte, a word, a doubleword, or a quadword.
The MOV instruction cannot be used to load the CS register. Attempting to do so results in an invalid opcode exception (#UD). To load the CS register, use the far JMP, CALL, or RET instruction.
If the destination operand is a segment register (DS, ES, FS, GS, or SS), the source operand must be a valid segment selector. In protected mode, moving a segment selector into a segment register automatically causes the segment descriptor information associated with that segment selector to be loaded into the hidden (shadow) part of the segment register. While loading this information, the segment selector and segment descriptor information is validated (see the \u201cOperation\u201d algorithm below). The segment descriptor data is obtained from the GDT or LDT entry for the specified segment selector.
A NULL segment selector (values 0000-0003) can be loaded into the DS, ES, FS, and GS registers without causing a protection exception. However, any subsequent attempt to reference a segment whose corresponding segment register is loaded with a NULL value causes a general protection exception (#GP) and no memory reference occurs.
Loading the SS register with a MOV instruction suppresses or inhibits some debug exceptions and inhibits interrupts on the following instruction boundary. (The inhibition ends after delivery of an exception or the execution of the next instruction.) This behavior allows a stack pointer to be loaded into the ESP register with the next instruction (MOV ESP, stack-pointer value) before an event can be delivered. See Section 6.8.3, \u201cMasking Exceptions and Interrupts When Switching Stacks,\u201d in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A. Intel recommends that software use the LSS instruction to load the SS register and ESP together.
",
+ "html": "
Copies the second operand (source operand) to the first operand (destination operand). The source operand can be an immediate value, general-purpose register, segment register, or memory location; the destination register can be a general-purpose register, segment register, or memory location. Both operands must be the same size, which can be a byte, a word, a doubleword, or a quadword.
The MOV instruction cannot be used to load the CS register. Attempting to do so results in an invalid opcode exception (#UD). To load the CS register, use the far JMP, CALL, or RET instruction.
If the destination operand is a segment register (DS, ES, FS, GS, or SS), the source operand must be a valid segment selector. In protected mode, moving a segment selector into a segment register automatically causes the segment descriptor information associated with that segment selector to be loaded into the hidden (shadow) part of the segment register. While loading this information, the segment selector and segment descriptor information is validated (see the \u201cOperation\u201d algorithm below). The segment descriptor data is obtained from the GDT or LDT entry for the specified segment selector.
A NULL segment selector (values 0000-0003) can be loaded into the DS, ES, FS, and GS registers without causing a protection exception. However, any subsequent attempt to reference a segment whose corresponding segment register is loaded with a NULL value causes a general protection exception (#GP) and no memory reference occurs.
Loading the SS register with a MOV instruction suppresses or inhibits some debug exceptions and inhibits interrupts on the following instruction boundary. (The inhibition ends after delivery of an exception or the execution of the next instruction.) This behavior allows a stack pointer to be loaded into the ESP register with the next instruction (MOV ESP, stack-pointer value) before an event can be delivered. See Section 6.8.3, \u201cMasking Exceptions and Interrupts When Switching Stacks,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A. Intel recommends that software use the LSS instruction to load the SS register and ESP together.
",
"tooltip": "Copies the second operand (source operand) to the first operand (destination operand). The source operand can be an immediate value, general-purpose register, segment register, or memory location; the destination register can be a general-purpose register, segment register, or memory location. Both operands must be the same size, which can be a byte, a word, a doubleword, or a quadword.",
"url": "https://www.felixcloutier.com/x86/MOV.html"
};
@@ -1709,16 +1716,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVAPD":
case "VMOVAPD":
return {
- "html": "
Moves 2, 4 or 8 double-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.
When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte (128-bit versions), 32-byte (256-bit version) or 64-byte (EVEX.512 encoded version) boundary or a general-protection exception (#GP) will be generated. For EVEX encoded versions, the operand must be aligned to the size of the memory operand. To move double-precision floating-point values to and from unaligned memory locations, use the VMOVUPD instruction.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
Moves 512 bits of packed double-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a ZMM register from a 512-bit float64 memory location, to store the contents of a ZMM register into a 512-bit float64 memory location, or to move data between two ZMM registers. When the source or destination operand is a memory operand, the operand must be aligned on a 64-byte boundary or a general-protection exception (#GP) will be generated. To move single-precision floating-point values to and from unaligned memory locations, use the VMOVUPD instruction.
",
- "tooltip": "Moves 2, 4 or 8 double-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.",
+ "html": "
Moves 2, 4 or 8 double precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.
When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte (128-bit versions), 32-byte (256-bit version) or 64-byte (EVEX.512 encoded version) boundary or a general-protection
exception (#GP) will be generated. For EVEX encoded versions, the operand must be aligned to the size of the memory operand. To move double precision floating-point values to and from unaligned memory locations, use the VMOVUPD instruction.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
",
+ "tooltip": "Moves 2, 4 or 8 double precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.",
"url": "https://www.felixcloutier.com/x86/MOVAPD.html"
};
case "MOVAPS":
case "VMOVAPS":
return {
- "html": "
Moves 4, 8 or 16 single-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.
When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary or a general-protection exception (#GP) will be generated. For EVEX.512 encoded versions, the operand must be aligned to the size of the memory operand. To move single-precision floating-point values to and from unaligned memory locations, use the VMOVUPS instruction.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
Moves 512 bits of packed single-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a ZMM register from a 512-bit float32 memory location, to store the contents of a ZMM register into a float32 memory location, or to move data between two ZMM registers. When the source or destination operand is a memory operand, the operand must be aligned on a 64-byte boundary or a general-protection exception (#GP) will be generated. To move single-precision floating-point values to and from unaligned memory locations, use the VMOVUPS instruction.
",
- "tooltip": "Moves 4, 8 or 16 single-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.",
+ "html": "
Moves 4, 8 or 16 single precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.
When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary or a general-protection exception (#GP) will be generated. For EVEX.512 encoded versions, the operand must be aligned to the size of the memory operand. To move single precision floating-point values to and from unaligned memory locations, use the VMOVUPS instruction.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
Moves 512 bits of packed single precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a ZMM register from a 512-bit float32 memory location, to store the contents of a ZMM register into a float32 memory location, or to move data between two ZMM registers. When the source or destination operand is a memory operand, the operand must be aligned on a 64-byte boundary or a general-protection exception (#GP) will be generated. To move single precision floating-point values to and from unaligned memory locations, use the VMOVUPS instruction.
",
+ "tooltip": "Moves 4, 8 or 16 single precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load an XMM, YMM or ZMM register from an 128-bit, 256-bit or 512-bit memory location, to store the contents of an XMM, YMM or ZMM register into a 128-bit, 256-bit or 512-bit memory location, or to move data between two XMM, two YMM or two ZMM registers.",
"url": "https://www.felixcloutier.com/x86/MOVAPS.html"
};
@@ -1734,7 +1741,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VMOVD":
case "VMOVQ":
return {
- "html": "
Copies a doubleword from the source operand (second operand) to the destination operand (first operand). The source and destination operands can be general-purpose registers, MMX technology registers, XMM registers, or 32-bit memory locations. This instruction can be used to move a doubleword to and from the low doubleword of an MMX technology register and a general-purpose register or a 32-bit memory location, or to and from the low doubleword of an XMM register and a general-purpose register or a 32-bit memory location. The instruction cannot be used to transfer data between MMX technology registers, between XMM registers, between general-purpose registers, or between memory locations.
When the destination operand is an MMX technology register, the source operand is written to the low doubleword of the register, and the register is zero-extended to 64 bits. When the destination operand is an XMM register, the source operand is written to the low doubleword of the register, and the register is zero-extended to 128 bits.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
Moves a dword/qword integer from the source operand and stores it in the low 32/64-bits of the destination XMM register. The upper bits of the destination are zeroed. The source operand can be a 32/64-bit register or 32/64-bit memory location.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding YMM destination register remain unchanged. Qword operation requires the use of REX.W=1.
",
+ "html": "
Copies a doubleword from the source operand (second operand) to the destination operand (first operand). The source and destination operands can be general-purpose registers, MMX technology registers, XMM registers, or 32-bit memory locations. This instruction can be used to move a doubleword to and from the low doubleword of an MMX technology register and a general-purpose register or a 32-bit memory location, or to and from the low doubleword of an XMM register and a general-purpose register or a 32-bit memory location. The instruction cannot be used to transfer data between MMX technology registers, between XMM registers, between general-purpose registers, or between memory locations.
When the destination operand is an MMX technology register, the source operand is written to the low doubleword of the register, and the register is zero-extended to 64 bits. When the destination operand is an XMM register, the source operand is written to the low doubleword of the register, and the register is zero-extended to 128 bits.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
MOVD/Q with XMM destination:
Moves a dword/qword integer from the source operand and stores it in the low 32/64-bits of the destination XMM register. The upper bits of the destination are zeroed. The source operand can be a 32/64-bit register or 32/64-bit memory location.
",
"tooltip": "Copies a doubleword from the source operand (second operand) to the destination operand (first operand). The source and destination operands can be general-purpose registers, MMX technology registers, XMM registers, or 32-bit memory locations. This instruction can be used to move a doubleword to and from the low doubleword of an MMX technology register and a general-purpose register or a 32-bit memory location, or to and from the low doubleword of an XMM register and a general-purpose register or a 32-bit memory location. The instruction cannot be used to transfer data between MMX technology registers, between XMM registers, between general-purpose registers, or between memory locations.",
"url": "https://www.felixcloutier.com/x86/MOVD%3AMOVQ.html"
};
@@ -1742,21 +1749,21 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVDDUP":
case "VMOVDDUP":
return {
- "html": "
For 256-bit or higher versions: Duplicates even-indexed double-precision floating-point values from the source operand (the second operand) and into adjacent pair and store to the destination operand (the first operand).
For 128-bit versions: Duplicates the low double-precision floating-point value from the source operand (the second operand) and store to the destination operand (the first operand).
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register are unchanged. The source operand is XMM register or a 64-bit memory location.
VEX.128 and EVEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are zeroed. The source operand is XMM register or a 64-bit memory location. The destination is updated conditionally under the writemask for EVEX version.
VEX.256 and EVEX.256 encoded version: Bits (MAXVL-1:256) of the destination register are zeroed. The source operand is YMM register or a 256-bit memory location. The destination is updated conditionally under the writemask for EVEX version.
",
- "tooltip": "For 256-bit or higher versions: Duplicates even-indexed double-precision floating-point values from the source operand (the second operand) and into adjacent pair and store to the destination operand (the first operand).",
+ "html": "
For 256-bit or higher versions: Duplicates even-indexed double precision floating-point values from the source operand (the second operand) and into adjacent pair and store to the destination operand (the first operand).
For 128-bit versions: Duplicates the low double precision floating-point value from the source operand (the second operand) and store to the destination operand (the first operand).
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register are unchanged. The source operand is XMM register or a 64-bit memory location.
VEX.128 and EVEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are zeroed. The source operand is XMM register or a 64-bit memory location. The destination is updated conditionally under the writemask for EVEX version.
VEX.256 and EVEX.256 encoded version: Bits (MAXVL-1:256) of the destination register are zeroed. The source operand is YMM register or a 256-bit memory location. The destination is updated conditionally under the write-mask for EVEX version.
",
+ "tooltip": "For 256-bit or higher versions: Duplicates even-indexed double precision floating-point values from the source operand (the second operand) and into adjacent pair and store to the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/MOVDDUP.html"
};
case "MOVDIR64B":
return {
- "html": "
Moves 64-bytes as direct-store with 64-byte write atomicity from source memory address to destination memory address. The source operand is a normal memory operand. The destination operand is a memory location specified in a general-purpose register. The register content is interpreted as an offset into ES segment without any segment override. In 64-bit mode, the register operand width is 64-bits (32-bits with 67H prefix). Outside of 64-bit mode, the register width is 32-bits when CS.D=1 (16-bits with 67H prefix), and 16-bits when CS.D=0 (32-bits with 67H prefix). MOVDIR64B requires the destination address to be 64-byte aligned. No alignment restriction is enforced for source operand.
MOVDIR64B first reads 64-bytes from the source memory address. It then performs a 64-byte direct-store operation to the destination address. The load operation follows normal read ordering based on source address memory-type. The direct-store is implemented by using the write combining (WC) memory type protocol for writing data. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. If the destination address is cached, the line is written-back (if modified) and invalidated from the cache, before the direct-store.
Unlike stores with non-temporal hint which allow UC/WP memory-type for destination to override the non-temporal hint, direct-stores always follow WC memory type protocol irrespective of destination address memory type (including UC/WP types). Unlike WC stores and stores with non-temporal hint, direct-stores are eligible for immediate eviction from the write-combining buffer, and thus not combined with younger stores (including direct-stores) to the same address. Older WC and non-temporal stores held in the write-combing buffer may be combined with younger direct stores to the same address. Direct stores are weakly ordered relative to other stores. Software that desires stronger ordering should use a fencing instruction (MFENCE or SFENCE) before or after a direct store to enforce the ordering desired.
There is no atomicity guarantee provided for the 64-byte load operation from source address, and processor implementations may use multiple load operations to read the 64-bytes. The 64-byte direct-store issued by MOVDIR64B guarantees 64-byte write-completion atomicity. This means that the data arrives at the destination in a single undivided 64-byte write transaction.
Availability of the MOVDIR64B instruction is indicated by the presence of the CPUID feature flag MOVDIR64B (bit 28 of the ECX register in leaf 07H, see \u201cCPUID\u2014CPU Identification\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2A).
",
+ "html": "
Moves 64-bytes as direct-store with 64-byte write atomicity from source memory address to destination memory address. The source operand is a normal memory operand. The destination operand is a memory location specified in a general-purpose register. The register content is interpreted as an offset into ES segment without any segment override. In 64-bit mode, the register operand width is 64-bits (32-bits with 67H prefix). Outside of 64-bit mode, the register width is 32-bits when CS.D=1 (16-bits with 67H prefix), and 16-bits when CS.D=0 (32-bits with 67H prefix). MOVDIR64B requires the destination address to be 64-byte aligned. No alignment restriction is enforced for source operand.
MOVDIR64B first reads 64-bytes from the source memory address. It then performs a 64-byte direct-store operation to the destination address. The load operation follows normal read ordering based on source address memory-type. The direct-store is implemented by using the write combining (WC) memory type protocol for writing data. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. If the destination address is cached, the line is written-back (if modified) and invalidated from the cache, before the direct-store.
Unlike stores with non-temporal hint which allow UC/WP memory-type for destination to override the non-temporal hint, direct-stores always follow WC memory type protocol irrespective of destination address memory type (including UC/WP types). Unlike WC stores and stores with non-temporal hint, direct-stores are eligible for immediate eviction from the write-combining buffer, and thus not combined with younger stores (including direct-stores) to the same address. Older WC and non-temporal stores held in the write-combing buffer may be combined with younger direct stores to the same address. Direct stores are weakly ordered relative to other stores. Software that desires stronger ordering should use a fencing instruction (MFENCE or SFENCE) before or after a direct store to enforce the ordering desired.
There is no atomicity guarantee provided for the 64-byte load operation from source address, and processor implementations may use multiple load operations to read the 64-bytes. The 64-byte direct-store issued by MOVDIR64B guarantees 64-byte write-completion atomicity. This means that the data arrives at the destination in a single undivided 64-byte write transaction.
Availability of the MOVDIR64B instruction is indicated by the presence of the CPUID feature flag MOVDIR64B (bit 28 of the ECX register in leaf 07H, see \u201cCPUID\u2014CPU Identification\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2A).
",
"tooltip": "Moves 64-bytes as direct-store with 64-byte write atomicity from source memory address to destination memory address. The source operand is a normal memory operand. The destination operand is a memory location specified in a general-purpose register. The register content is interpreted as an offset into ES segment without any segment override. In 64-bit mode, the register operand width is 64-bits (32-bits with 67H prefix). Outside of 64-bit mode, the register width is 32-bits when CS.D=1 (16-bits with 67H prefix), and 16-bits when CS.D=0 (32-bits with 67H prefix). MOVDIR64B requires the destination address to be 64-byte aligned. No alignment restriction is enforced for source operand.",
"url": "https://www.felixcloutier.com/x86/MOVDIR64B.html"
};
case "MOVDIRI":
return {
- "html": "
Moves the doubleword integer in the source operand (second operand) to the destination operand (first operand) using a direct-store operation. The source operand is a general purpose register. The destination operand is a 32-bit memory location. In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See summary chart at the beginning of this section for encoding data and limits.
The direct-store is implemented by using write combining (WC) memory type protocol for writing data. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. If the destination address is cached, the line is written-back (if modified) and invalidated from the cache, before the direct-store. Unlike stores with non-temporal hint that allow uncached (UC) and write-protected (WP) memory-type for the destination to override the non-temporal hint, direct-stores always follow WC memory type protocol irrespective of the destination address memory type (including UC and WP types).
Unlike WC stores and stores with non-temporal hint, direct-stores are eligible for immediate eviction from the write-combining buffer, and thus not combined with younger stores (including direct-stores) to the same address. Older WC and non-temporal stores held in the write-combing buffer may be combined with younger direct stores to the same address. Direct stores are weakly ordered relative to other stores. Software that desires stronger ordering should use a fencing instruction (MFENCE or SFENCE) before or after a direct store to enforce the ordering desired.
Direct-stores issued by MOVDIRI to a destination aligned to a 4-byte boundary (8-byte boundary if used with REX.W prefix) guarantee 4-byte (8-byte with REX.W prefix) write-completion atomicity. This means that the data arrives at the destination in a single undivided 4-byte (or 8-byte) write transaction. If the destination is not aligned for the write size, the direct-stores issued by MOVDIRI are split and arrive at the destination in two parts. Each part of such split direct-store will not merge with younger stores but can arrive at the destination in either order. Availability of the MOVDIRI instruction is indicated by the presence of the CPUID feature flag MOVDIRI (bit 27 of the ECX register in leaf 07H, see \u201cCPUID\u2014CPU Identification\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2A).
",
+ "html": "
Moves the doubleword integer in the source operand (second operand) to the destination operand (first operand) using a direct-store operation. The source operand is a general purpose register. The destination operand is a 32-bit memory location. In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See summary chart at the beginning of this section for encoding data and limits.
The direct-store is implemented by using write combining (WC) memory type protocol for writing data. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. If the destination address is cached, the line is written-back (if modified) and invalidated from the cache, before the direct-store. Unlike stores with non-temporal hint that allow uncached (UC) and write-protected (WP) memory-type for the destination to override the non-temporal hint, direct-stores always follow WC memory type protocol irrespective of the destination address memory type (including UC and WP types).
Unlike WC stores and stores with non-temporal hint, direct-stores are eligible for immediate eviction from the write-combining buffer, and thus not combined with younger stores (including direct-stores) to the same address. Older WC and non-temporal stores held in the write-combing buffer may be combined with younger direct stores to the same address. Direct stores are weakly ordered relative to other stores. Software that desires stronger ordering should use a fencing instruction (MFENCE or SFENCE) before or after a direct store to enforce the ordering desired.
Direct-stores issued by MOVDIRI to a destination aligned to a 4-byte boundary (8-byte boundary if used with REX.W prefix) guarantee 4-byte (8-byte with REX.W prefix) write-completion atomicity. This means that the data arrives at the destination in a single undivided 4-byte (or 8-byte) write transaction. If the destination is not aligned for the write size, the direct-stores issued by MOVDIRI are split and arrive at the destination in two parts. Each part of such split direct-store will not merge with younger stores but can arrive at the destination in either order. Availability of the MOVDIRI instruction is indicated by the presence of the CPUID feature flag MOVDIRI (bit 27 of the ECX register in leaf 07H, see \u201cCPUID\u2014CPU Identification\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2A).
",
"tooltip": "Moves the doubleword integer in the source operand (second operand) to the destination operand (first operand) using a direct-store operation. The source operand is a general purpose register. The destination operand is a 32-bit memory location. In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See summary chart at the beginning of this section for encoding data and limits.",
"url": "https://www.felixcloutier.com/x86/MOVDIRI.html"
};
@@ -1778,7 +1785,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VMOVDQU64":
case "VMOVDQU8":
return {
- "html": "
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
EVEX encoded versions:
Moves 128, 256 or 512 bits of packed byte/word/doubleword/quadword integer values from the source operand (the second operand) to the destination operand (first operand). This instruction can be used to load a vector register from a memory location, to store the contents of a vector register into a memory location, or to move data between two vector registers.
The destination operand is updated at 8-bit (VMOVDQU8), 16-bit (VMOVDQU16), 32-bit (VMOVDQU32), or 64-bit (VMOVDQU64) granularity according to the writemask.
VEX.256 encoded version:
",
+ "html": "
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
EVEX encoded versions:
Moves 128, 256 or 512 bits of packed byte/word/doubleword/quadword integer values from the source operand (the second operand) to the destination operand (first operand). This instruction can be used to load a vector register from a memory location, to store the contents of a vector register into a memory location, or to move data between two vector registers.
The destination operand is updated at 8-bit (VMOVDQU8), 16-bit (VMOVDQU16), 32-bit (VMOVDQU32), or 64-bit (VMOVDQU64) granularity according to the writemask.
VEX.256 encoded version:
",
"tooltip": "Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.",
"url": "https://www.felixcloutier.com/x86/MOVDQU%3AVMOVDQU8%3AVMOVDQU16%3AVMOVDQU32%3AVMOVDQU64.html"
};
@@ -1786,7 +1793,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVHLPS":
case "VMOVHLPS":
return {
- "html": "
This instruction cannot be used for memory to register moves.
128-bit two-argument form:
Moves two packed single-precision floating-point values from the high quadword of the second XMM argument (second operand) to the low quadword of the first XMM register (first argument). The quadword at bits 127:64 of the destination operand is left unchanged. Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
128-bit and EVEX three-argument form
Moves two packed single-precision floating-point values from the high quadword of the third XMM argument (third operand) to the low quadword of the destination (first operand). Copies the high quadword from the second XMM argument (second operand) to the high quadword of the destination (first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
+ "html": "
This instruction cannot be used for memory to register moves.
128-bit two-argument form:
Moves two packed single precision floating-point values from the high quadword of the second XMM argument (second operand) to the low quadword of the first XMM register (first argument). The quadword at bits 127:64 of the destination operand is left unchanged. Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
128-bit and EVEX three-argument form:
Moves two packed single precision floating-point values from the high quadword of the third XMM argument (third operand) to the low quadword of the destination (first operand). Copies the high quadword from the second XMM argument (second operand) to the high quadword of the destination (first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
"tooltip": "This instruction cannot be used for memory to register moves.",
"url": "https://www.felixcloutier.com/x86/MOVHLPS.html"
};
@@ -1794,7 +1801,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVHPD":
case "VMOVHPD":
return {
- "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves a double-precision floating-point value from the source 64-bit memory operand and stores it in the high 64-bits of the destination XMM register. The lower 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads a double-precision floating-point value from the source 64-bit memory operand (the third operand) and stores it in the upper 64-bits of the destination XMM register (first operand). The low 64-bits from the first source operand (second operand) are copied to the low 64-bits of the destination. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
+ "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves a double precision floating-point value from the source 64-bit memory operand and stores it in the high 64-bits of the destination XMM register. The lower 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads a double precision floating-point value from the source 64-bit memory operand (the third operand) and stores it in the upper 64-bits of the destination XMM register (first operand). The low 64-bits from the first source operand (second operand) are copied to the low 64-bits of the destination. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
"tooltip": "This instruction cannot be used for register to register or memory to memory moves.",
"url": "https://www.felixcloutier.com/x86/MOVHPD.html"
};
@@ -1802,7 +1809,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVHPS":
case "VMOVHPS":
return {
- "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves two packed single-precision floating-point values from the source 64-bit memory operand and stores them in the high 64-bits of the destination XMM register. The lower 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads two single-precision floating-point values from the source 64-bit memory operand (the third operand) and stores it in the upper 64-bits of the destination XMM register (first operand). The low 64-bits from the first source operand (the second operand) are copied to the lower 64-bits of the destination. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
+ "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves two packed single precision floating-point values from the source 64-bit memory operand and stores them in the high 64-bits of the destination XMM register. The lower 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads two single precision floating-point values from the source 64-bit memory operand (the third operand) and stores it in the upper 64-bits of the destination XMM register (first operand). The low 64-bits from the first source operand (the second operand) are copied to the lower 64-bits of the destination. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
"tooltip": "This instruction cannot be used for register to register or memory to memory moves.",
"url": "https://www.felixcloutier.com/x86/MOVHPS.html"
};
@@ -1810,7 +1817,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVLHPS":
case "VMOVLHPS":
return {
- "html": "
This instruction cannot be used for memory to register moves.
128-bit two-argument form:
Moves two packed single-precision floating-point values from the low quadword of the second XMM argument (second operand) to the high quadword of the first XMM register (first argument). The low quadword of the destination operand is left unchanged. Bits (MAXVL-1:128) of the corresponding destination register are unmodified.
128-bit three-argument forms:
Moves two packed single-precision floating-point values from the low quadword of the third XMM argument (third operand) to the high quadword of the destination (first operand). Copies the low quadword from the second XMM argument (second operand) to the low quadword of the destination (first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
+ "html": "
This instruction cannot be used for memory to register moves.
128-bit two-argument form:
Moves two packed single precision floating-point values from the low quadword of the second XMM argument (second operand) to the high quadword of the first XMM register (first argument). The low quadword of the destination operand is left unchanged. Bits (MAXVL-1:128) of the corresponding destination register are unmodified.
128-bit three-argument forms:
Moves two packed single precision floating-point values from the low quadword of the third XMM argument (third operand) to the high quadword of the destination (first operand). Copies the low quadword from the second XMM argument (second operand) to the low quadword of the destination (first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
"tooltip": "This instruction cannot be used for memory to register moves.",
"url": "https://www.felixcloutier.com/x86/MOVLHPS.html"
};
@@ -1818,7 +1825,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVLPD":
case "VMOVLPD":
return {
- "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves a double-precision floating-point value from the source 64-bit memory operand and stores it in the low 64-bits of the destination XMM register. The upper 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads a double-precision floating-point value from the source 64-bit memory operand (third operand), merges it with the upper 64-bits of the first source XMM register (second operand), and stores it in the low 128-bits of the destination XMM register (first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
+ "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves a double precision floating-point value from the source 64-bit memory operand and stores it in the low 64-bits of the destination XMM register. The upper 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads a double precision floating-point value from the source 64-bit memory operand (third operand), merges it with the upper 64-bits of the first source XMM register (second operand), and stores it in the low 128-bits of the destination XMM register (first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
"tooltip": "This instruction cannot be used for register to register or memory to memory moves.",
"url": "https://www.felixcloutier.com/x86/MOVLPD.html"
};
@@ -1826,7 +1833,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVLPS":
case "VMOVLPS":
return {
- "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves two packed single-precision floating-point values from the source 64-bit memory operand and stores them in the low 64-bits of the destination XMM register. The upper 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads two packed single-precision floating-point values from the source 64-bit memory operand (the third operand), merges them with the upper 64-bits of the first source operand (the second operand), and stores them in the low 128-bits of the destination register (the first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
+ "html": "
This instruction cannot be used for register to register or memory to memory moves.
128-bit Legacy SSE load:
Moves two packed single precision floating-point values from the source 64-bit memory operand and stores them in the low 64-bits of the destination XMM register. The upper 64bits of the XMM register are preserved. Bits (MAXVL-1:128) of the corresponding destination register are preserved.
VEX.128 & EVEX encoded load:
Loads two packed single precision floating-point values from the source 64-bit memory operand (the third operand), merges them with the upper 64-bits of the first source operand (the second operand), and stores them in the low 128-bits of the destination register (the first operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
"tooltip": "This instruction cannot be used for register to register or memory to memory moves.",
"url": "https://www.felixcloutier.com/x86/MOVLPS.html"
};
@@ -1834,16 +1841,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVMSKPD":
case "VMOVMSKPD":
return {
- "html": "
Extracts the sign bits from the packed double-precision floating-point values in the source operand (second operand), formats them into a 2-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM register, and the destination operand is a general-purpose register. The mask is stored in the 2 low-order bits of the destination operand. Zero-extend the upper bits of the destination.
In 64-bit mode, the instruction can access additional registers (XMM8-XMM15, R8-R15) when used with a REX.R prefix. The default operand size is 64-bit in 64-bit mode.
128-bit versions: The source operand is a YMM register. The destination operand is a general purpose register.
VEX.256 encoded version: The source operand is a YMM register. The destination operand is a general purpose register.
Note: In VEX-encoded versions, VEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Extracts the sign bits from the packed double-precision floating-point values in the source operand (second operand), formats them into a 2-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM register, and the destination operand is a general-purpose register. The mask is stored in the 2 low-order bits of the destination operand. Zero-extend the upper bits of the destination.",
+ "html": "
Extracts the sign bits from the packed double precision floating-point values in the source operand (second operand), formats them into a 2-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM register, and the destination operand is a general-purpose register. The mask is stored in the 2 low-order bits of the destination operand. Zero-extend the upper bits of the destination.
In 64-bit mode, the instruction can access additional registers (XMM8-XMM15, R8-R15) when used with a REX.R prefix. The default operand size is 64-bit in 64-bit mode.
128-bit versions: The source operand is a YMM register. The destination operand is a general purpose register.
VEX.256 encoded version: The source operand is a YMM register. The destination operand is a general purpose register.
Note: In VEX-encoded versions, VEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Extracts the sign bits from the packed double precision floating-point values in the source operand (second operand), formats them into a 2-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM register, and the destination operand is a general-purpose register. The mask is stored in the 2 low-order bits of the destination operand. Zero-extend the upper bits of the destination.",
"url": "https://www.felixcloutier.com/x86/MOVMSKPD.html"
};
case "MOVMSKPS":
case "VMOVMSKPS":
return {
- "html": "
Extracts the sign bits from the packed single-precision floating-point values in the source operand (second operand), formats them into a 4- or 8-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM or YMM register, and the destination operand is a general-purpose register. The mask is stored in the 4 or 8 low-order bits of the destination operand. The upper bits of the destination operand beyond the mask are filled with zeros.
In 64-bit mode, the instruction can access additional registers (XMM8-XMM15, R8-R15) when used with a REX.R prefix. The default operand size is 64-bit in 64-bit mode.
128-bit versions: The source operand is a YMM register. The destination operand is a general purpose register.
VEX.256 encoded version: The source operand is a YMM register. The destination operand is a general purpose register.
Note: In VEX-encoded versions, VEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Extracts the sign bits from the packed single-precision floating-point values in the source operand (second operand), formats them into a 4- or 8-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM or YMM register, and the destination operand is a general-purpose register. The mask is stored in the 4 or 8 low-order bits of the destination operand. The upper bits of the destination operand beyond the mask are filled with zeros.",
+ "html": "
Extracts the sign bits from the packed single precision floating-point values in the source operand (second operand), formats them into a 4- or 8-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM or YMM register, and the destination operand is a general-purpose register. The mask is stored in the 4 or 8 low-order bits of the destination operand. The upper bits of the destination operand beyond the mask are filled with zeros.
In 64-bit mode, the instruction can access additional registers (XMM8-XMM15, R8-R15) when used with a REX.R prefix. The default operand size is 64-bit in 64-bit mode.
128-bit versions: The source operand is a YMM register. The destination operand is a general purpose register.
VEX.256 encoded version: The source operand is a YMM register. The destination operand is a general purpose register.
Note: In VEX-encoded versions, VEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Extracts the sign bits from the packed single precision floating-point values in the source operand (second operand), formats them into a 4- or 8-bit mask, and stores the mask in the destination operand (first operand). The source operand is an XMM or YMM register, and the destination operand is a general-purpose register. The mask is stored in the 4 or 8 low-order bits of the destination operand. The upper bits of the destination operand beyond the mask are filled with zeros.",
"url": "https://www.felixcloutier.com/x86/MOVMSKPS.html"
};
@@ -1858,14 +1865,14 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVNTDQA":
case "VMOVNTDQA":
return {
- "html": "
MOVNTDQA loads a double quadword from the source operand (second operand) to the destination operand (first operand) using a non-temporal hint if the memory source is WC (write combining) memory type. For WC memory type, the nontemporal hint may be implemented by loading a temporary internal buffer with the equivalent of an aligned cache line without filling this data to the cache. Any memory-type aliased lines in the cache will be snooped and flushed. Subsequent MOVNTDQA reads to unread portions of the WC cache line will receive data from the temporary internal buffer if data is available. The temporary internal buffer may be flushed by the processor at any time for any reason, for example:
a mis-speculation condition, and various fault conditions
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when reading the data from memory. Using this protocol, the processor does not read the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being read can override the non-temporal hint, if the memory address specified for the non-temporal read is not a WC memory region. Information on non-temporal reads and writes can be found in \u201cCaching of Temporal vs. NonTemporal Data\u201d in Chapter 10 in the Intel\u00ae 64 and IA-32 Architecture Software Developer\u2019s Manual, Volume 3A.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with a MFENCE instruction should be used in conjunction with MOVNTDQA instructions if multiple processors might use different memory types for the referenced memory locations or to synchronize reads of a processor with writes by other agents in the system. A processor\u2019s implementation of the streaming load hint does not override the effective memory type, but the implementation of the hint is processor dependent. For example, a processor implementation may choose to ignore the hint and process the instruction as a normal MOVDQA for any memory type. Alter-
natively, another implementation may optimize cache reads generated by MOVNTDQA on WB memory type to reduce cache evictions.
",
+ "html": "
MOVNTDQA loads a double quadword from the source operand (second operand) to the destination operand (first operand) using a non-temporal hint if the memory source is WC (write combining) memory type. For WC memory type, the nontemporal hint may be implemented by loading a temporary internal buffer with the equivalent of an aligned cache line without filling this data to the cache. Any memory-type aliased lines in the cache will be snooped and flushed. Subsequent MOVNTDQA reads to unread portions of the WC cache line will receive data from the temporary internal buffer if data is available. The temporary internal buffer may be flushed by the processor at any time for any reason, for example:
a mis-speculation condition, and various fault conditions
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when reading the data from memory. Using this protocol, the processor does not read the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being read can override the non-temporal hint, if the memory address specified for the non-temporal read is not a WC memory region. Information on non-temporal reads and writes can be found in \u201cCaching of Temporal vs. NonTemporal Data\u201d in Chapter 10 in the Intel\u00ae 64 and IA-32 Architecture Software Developer\u2019s Manual, Volume 3A.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with a MFENCE instruction should be used in conjunction with MOVNTDQA instructions if multiple processors might use different memory types for the referenced memory locations or to synchronize reads of a processor with writes by other agents in the system. A processor\u2019s implementation of the streaming load hint does not override the effective memory type, but the implementation of the hint is processor dependent. For example, a processor implementa-
tion may choose to ignore the hint and process the instruction as a normal MOVDQA for any memory type. Alternatively, another implementation may optimize cache reads generated by MOVNTDQA on WB memory type to reduce cache evictions.
",
"tooltip": "MOVNTDQA loads a double quadword from the source operand (second operand) to the destination operand (first operand) using a non-temporal hint if the memory source is WC (write combining) memory type. For WC memory type, the nontemporal hint may be implemented by loading a temporary internal buffer with the equivalent of an aligned cache line without filling this data to the cache. Any memory-type aliased lines in the cache will be snooped and flushed. Subsequent MOVNTDQA reads to unread portions of the WC cache line will receive data from the temporary internal buffer if data is available. The temporary internal buffer may be flushed by the processor at any time for any reason, for example",
"url": "https://www.felixcloutier.com/x86/MOVNTDQA.html"
};
case "MOVNTI":
return {
- "html": "
Moves the doubleword integer in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to minimize cache pollution during the write to memory. The source operand is a general-purpose register. The destination operand is a 32-bit memory location.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTI instructions if multiple processors might use different memory types to read/write the destination memory locations.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "html": "
Moves the doubleword integer in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to minimize cache pollution during the write to memory. The source operand is a general-purpose register. The destination operand is a 32-bit memory location.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTI instructions if multiple processors might use different memory types to read/write the destination memory locations.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
"tooltip": "Moves the doubleword integer in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to minimize cache pollution during the write to memory. The source operand is a general-purpose register. The destination operand is a 32-bit memory location.",
"url": "https://www.felixcloutier.com/x86/MOVNTI.html"
};
@@ -1873,22 +1880,22 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVNTPD":
case "VMOVNTPD":
return {
- "html": "
Moves the packed double-precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed double-precision, floating-pointing data. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the IA-32 Intel Architecture Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTPD instructions if multiple processors might use different memory types to read/write the destination memory locations.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, VEX.L must be 0; otherwise instructions will #UD.
",
- "tooltip": "Moves the packed double-precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed double-precision, floating-pointing data. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.",
+ "html": "
Moves the packed double precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed double precision, floating-pointing data. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the IA-32 Intel Architecture Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTPD instructions if multiple processors might use different memory types to read/write the destination memory locations.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, VEX.L must be 0; otherwise instructions will #UD.
",
+ "tooltip": "Moves the packed double precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed double precision, floating-pointing data. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.",
"url": "https://www.felixcloutier.com/x86/MOVNTPD.html"
};
case "MOVNTPS":
case "VMOVNTPS":
return {
- "html": "
Moves the packed single-precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed single-precision, floating-pointing. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the IA-32 Intel Architecture Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTPS instructions if multiple processors might use different memory types to read/write the destination memory locations.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Moves the packed single-precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed single-precision, floating-pointing. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.",
+ "html": "
Moves the packed single precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed single precision, floating-pointing. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the IA-32 Intel Architecture Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTPS instructions if multiple processors might use different memory types to read/write the destination memory locations.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Moves the packed single precision floating-point values in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to prevent caching of the data during the write to memory. The source operand is an XMM register, YMM register or ZMM register, which is assumed to contain packed single precision, floating-pointing. The destination operand is a 128-bit, 256-bit or 512-bit memory location. The memory operand must be aligned on a 16-byte (128-bit version), 32-byte (VEX.256 encoded version) or 64-byte (EVEX.512 encoded version) boundary otherwise a general-protection exception (#GP) will be generated.",
"url": "https://www.felixcloutier.com/x86/MOVNTPS.html"
};
case "MOVNTQ":
return {
- "html": "
Moves the quadword in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to minimize cache pollution during the write to memory. The source operand is an MMX technology register, which is assumed to contain packed integer data (packed bytes, words, or doublewords). The destination operand is a 64-bit memory location.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTQ instructions if multiple processors might use different memory types to read/write the destination memory locations.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Moves the quadword in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to minimize cache pollution during the write to memory. The source operand is an MMX technology register, which is assumed to contain packed integer data (packed bytes, words, or doublewords). The destination operand is a 64-bit memory location.
The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy. The memory type of the region being written to can override the non-temporal hint, if the memory address specified for the non-temporal store is in an uncacheable (UC) or write protected (WP) memory region. For more information on non-temporal stores, see \u201cCaching of Temporal vs. Non-Temporal Data\u201d in Chapter 10 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Because the WC protocol uses a weakly-ordered memory consistency model, a fencing operation implemented with the SFENCE or MFENCE instruction should be used in conjunction with MOVNTQ instructions if multiple processors might use different memory types to read/write the destination memory locations.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Moves the quadword in the source operand (second operand) to the destination operand (first operand) using a non-temporal hint to minimize cache pollution during the write to memory. The source operand is an MMX technology register, which is assumed to contain packed integer data (packed bytes, words, or doublewords). The destination operand is a 64-bit memory location.",
"url": "https://www.felixcloutier.com/x86/MOVNTQ.html"
};
@@ -1914,31 +1921,31 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVSHDUP":
case "VMOVSHDUP":
return {
- "html": "
Duplicates odd-indexed single-precision floating-point values from the source operand (the second operand) to adjacent element pair in the destination operand (the first operand). See Figure 4-3. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are zeroed.
VEX.256 encoded version: Bits (MAXVL-1:256) of the destination register are zeroed.
EVEX encoded version: The destination operand is updated at 32-bit granularity according to the writemask.
",
- "tooltip": "Duplicates odd-indexed single-precision floating-point values from the source operand (the second operand) to adjacent element pair in the destination operand (the first operand). See Figure 4-3. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.",
+ "html": "
Duplicates odd-indexed single precision floating-point values from the source operand (the second operand) to adjacent element pair in the destination operand (the first operand). See Figure 4-3. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are zeroed.
VEX.256 encoded version: Bits (MAXVL-1:256) of the destination register are zeroed.
EVEX encoded version: The destination operand is updated at 32-bit granularity according to the writemask.
",
+ "tooltip": "Duplicates odd-indexed single precision floating-point values from the source operand (the second operand) to adjacent element pair in the destination operand (the first operand). See Figure 4-3. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.",
"url": "https://www.felixcloutier.com/x86/MOVSHDUP.html"
};
case "MOVSLDUP":
case "VMOVSLDUP":
return {
- "html": "
Duplicates even-indexed single-precision floating-point values from the source operand (the second operand). See Figure 4-4. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are zeroed.
VEX.256 encoded version: Bits (MAXVL-1:256) of the destination register are zeroed.
EVEX encoded version: The destination operand is updated at 32-bit granularity according to the writemask.
",
- "tooltip": "Duplicates even-indexed single-precision floating-point values from the source operand (the second operand). See Figure 4-4. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.",
+ "html": "
Duplicates even-indexed single precision floating-point values from the source operand (the second operand). See Figure 4-4. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are zeroed.
VEX.256 encoded version: Bits (MAXVL-1:256) of the destination register are zeroed.
EVEX encoded version: The destination operand is updated at 32-bit granularity according to the writemask.
",
+ "tooltip": "Duplicates even-indexed single precision floating-point values from the source operand (the second operand). See Figure 4-4. The source operand is an XMM, YMM or ZMM register or 128, 256 or 512-bit memory location and the destination operand is an XMM, YMM or ZMM register.",
"url": "https://www.felixcloutier.com/x86/MOVSLDUP.html"
};
case "MOVSS":
case "VMOVSS":
return {
- "html": "
Moves a scalar single-precision floating-point value from the source operand (second operand) to the destination operand (first operand). The source and destination operands can be XMM registers or 32-bit memory locations. This instruction can be used to move a single-precision floating-point value to and from the low doubleword of an XMM register and a 32-bit memory location, or to move a single-precision floating-point value between the low doublewords of two XMM registers. The instruction cannot be used to transfer data between memory locations.
Legacy version: When the source and destination operands are XMM registers, bits (MAXVL-1:32) of the corresponding destination register are unmodified. When the source operand is a memory location and destination operand is an XMM registers, Bits (127:32) of the destination operand is cleared to all 0s, bits MAXVL:128 of the destination operand remains unchanged.
VEX and EVEX encoded register-register syntax: Moves a scalar single-precision floating-point value from the second source operand (the third operand) to the low doubleword element of the destination operand (the first operand). Bits 127:32 of the destination operand are copied from the first source operand (the second operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX and EVEX encoded memory load syntax: When the source operand is a memory location and destination operand is an XMM registers, bits MAXVL:32 of the destination operand is cleared to all 0s.
EVEX encoded versions: The low doubleword of the destination is updated according to the writemask.
",
- "tooltip": "Moves a scalar single-precision floating-point value from the source operand (second operand) to the destination operand (first operand). The source and destination operands can be XMM registers or 32-bit memory locations. This instruction can be used to move a single-precision floating-point value to and from the low doubleword of an XMM register and a 32-bit memory location, or to move a single-precision floating-point value between the low doublewords of two XMM registers. The instruction cannot be used to transfer data between memory locations.",
+ "html": "
Moves a scalar single precision floating-point value from the source operand (second operand) to the destination operand (first operand). The source and destination operands can be XMM registers or 32-bit memory locations. This instruction can be used to move a single precision floating-point value to and from the low doubleword of an XMM register and a 32-bit memory location, or to move a single precision floating-point value between the low doublewords of two XMM registers. The instruction cannot be used to transfer data between memory locations.
Legacy version: When the source and destination operands are XMM registers, bits (MAXVL-1:32) of the corresponding destination register are unmodified. When the source operand is a memory location and destination
operand is an XMM registers, Bits (127:32) of the destination operand is cleared to all 0s, bits MAXVL:128 of the destination operand remains unchanged.
VEX and EVEX encoded register-register syntax: Moves a scalar single precision floating-point value from the second source operand (the third operand) to the low doubleword element of the destination operand (the first operand). Bits 127:32 of the destination operand are copied from the first source operand (the second operand). Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX and EVEX encoded memory load syntax: When the source operand is a memory location and destination operand is an XMM registers, bits MAXVL:32 of the destination operand is cleared to all 0s.
",
+ "tooltip": "Moves a scalar single precision floating-point value from the source operand (second operand) to the destination operand (first operand). The source and destination operands can be XMM registers or 32-bit memory locations. This instruction can be used to move a single precision floating-point value to and from the low doubleword of an XMM register and a 32-bit memory location, or to move a single precision floating-point value between the low doublewords of two XMM registers. The instruction cannot be used to transfer data between memory locations.",
"url": "https://www.felixcloutier.com/x86/MOVSS.html"
};
case "MOVSX":
case "MOVSXD":
return {
- "html": "
Copies the contents of the source operand (register or memory location) to the destination operand (register) and sign extends the value to 16 or 32 bits (see Figure 7-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). The size of the converted value depends on the operand-size attribute.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "html": "
Copies the contents of the source operand (register or memory location) to the destination operand (register) and sign extends the value to 16 or 32 bits (see Figure 7-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). The size of the converted value depends on the operand-size attribute.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Use of the REX.R prefix permits access to additional registers (R8-R15). Use of the REX.W prefix promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
"tooltip": "Copies the contents of the source operand (register or memory location) to the destination operand (register) and sign extends the value to 16 or 32 bits (see Figure 7-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1). The size of the converted value depends on the operand-size attribute.",
"url": "https://www.felixcloutier.com/x86/MOVSX%3AMOVSXD.html"
};
@@ -1946,7 +1953,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVUPD":
case "VMOVUPD":
return {
- "html": "
Note: VEX.vvvv and EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
Moves 512 bits of packed double-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a ZMM register from a float64 memory location, to store the contents of a ZMM register into a memory. The destination operand is updated according to the writemask.
VEX.256 encoded version:
Moves 256 bits of packed double-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a YMM register from a 256-bit memory location, to store the contents of a YMM register into a 256-bit memory location, or to move data between two YMM registers. Bits (MAXVL-1:256) of the destination register are zeroed.
",
+ "html": "
Note: VEX.vvvv and EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
Moves 512 bits of packed double precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a ZMM register from a float64 memory location, to store the contents of a ZMM register into a memory. The destination operand is updated according to the writemask.
VEX.256 encoded version:
Moves 256 bits of packed double precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a YMM register from a 256-bit memory location, to store the contents of a YMM register into a 256-bit memory location, or to move data between two YMM registers. Bits (MAXVL-1:256) of the destination register are zeroed.
",
"tooltip": "Note: VEX.vvvv and EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.",
"url": "https://www.felixcloutier.com/x86/MOVUPD.html"
};
@@ -1954,7 +1961,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MOVUPS":
case "VMOVUPS":
return {
- "html": "
Note: VEX.vvvv and EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
Moves 512 bits of packed single-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a ZMM register from a 512-bit float32 memory location, to store the contents of a ZMM register into memory. The destination operand is updated according to the writemask.
VEX.256 and EVEX.256 encoded versions:
Moves 256 bits of packed single-precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a YMM register from a 256-bit memory location, to store the contents of a YMM register into a 256-bit memory location, or to move data between two YMM registers. Bits (MAXVL-1:256) of the destination register are zeroed.
",
+ "html": "
Note: VEX.vvvv and EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
EVEX.512 encoded version:
Moves 512 bits of packed single precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a ZMM register from a 512-bit float32 memory location, to store the contents of a ZMM register into memory. The destination operand is updated according to the writemask.
VEX.256 and EVEX.256 encoded versions:
Moves 256 bits of packed single precision floating-point values from the source operand (second operand) to the destination operand (first operand). This instruction can be used to load a YMM register from a 256-bit memory location, to store the contents of a YMM register into a 256-bit memory location, or to move data between two YMM registers. Bits (MAXVL-1:256) of the destination register are zeroed.
",
"tooltip": "Note: VEX.vvvv and EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.",
"url": "https://www.felixcloutier.com/x86/MOVUPS.html"
};
@@ -1984,32 +1991,32 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MULPD":
case "VMULPD":
return {
- "html": "
Multiply packed double-precision floating-point values from the first source operand with corresponding values in the second source operand, and stores the packed double-precision floating-point results in the destination operand.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination ZMM register are zeroed.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the destination YMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Multiply packed double-precision floating-point values from the first source operand with corresponding values in the second source operand, and stores the packed double-precision floating-point results in the destination operand.",
+ "html": "
Multiply packed double precision floating-point values from the first source operand with corresponding values in the second source operand, and stores the packed double precision floating-point results in the destination operand.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination ZMM register are zeroed.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the destination YMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Multiply packed double precision floating-point values from the first source operand with corresponding values in the second source operand, and stores the packed double precision floating-point results in the destination operand.",
"url": "https://www.felixcloutier.com/x86/MULPD.html"
};
case "MULPS":
case "VMULPS":
return {
- "html": "
Multiply the packed single-precision floating-point values from the first source operand with the corresponding values in the second source operand, and stores the packed double-precision floating-point results in the destination operand.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination ZMM register are zeroed.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the destination YMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Multiply the packed single-precision floating-point values from the first source operand with the corresponding values in the second source operand, and stores the packed double-precision floating-point results in the destination operand.",
+ "html": "
Multiply the packed single precision floating-point values from the first source operand with the corresponding values in the second source operand, and stores the packed double precision floating-point results in the destination operand.
EVEX encoded versions: The first source operand (the second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination ZMM register are zeroed.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the destination YMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Multiply the packed single precision floating-point values from the first source operand with the corresponding values in the second source operand, and stores the packed double precision floating-point results in the destination operand.",
"url": "https://www.felixcloutier.com/x86/MULPS.html"
};
case "MULSD":
case "VMULSD":
return {
- "html": "
Multiplies the low double-precision floating-point value in the second source operand by the low double-precision floating-point value in the first source operand, and stores the double-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source operand and the destination operands are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded version: The quadword at bits 127:64 of the destination operand is copied from the same bits of the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination operand is updated according to the writemask.
Software should ensure VMULSD is encoded with VEX.L=0. Encoding VMULSD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
- "tooltip": "Multiplies the low double-precision floating-point value in the second source operand by the low double-precision floating-point value in the first source operand, and stores the double-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source operand and the destination operands are XMM registers.",
+ "html": "
Multiplies the low double precision floating-point value in the second source operand by the low double precision floating-point value in the first source operand, and stores the double precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source operand and the destination operands are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded version: The quadword at bits 127:64 of the destination operand is copied from the same bits of the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination operand is updated according to the write-mask.
Software should ensure VMULSD is encoded with VEX.L=0. Encoding VMULSD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
+ "tooltip": "Multiplies the low double precision floating-point value in the second source operand by the low double precision floating-point value in the first source operand, and stores the double precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source operand and the destination operands are XMM registers.",
"url": "https://www.felixcloutier.com/x86/MULSD.html"
};
case "MULSS":
case "VMULSS":
return {
- "html": "
Multiplies the low single-precision floating-point value from the second source operand by the low single-precision floating-point value in the first source operand, and stores the single-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source operand and the destination operands are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 and EVEX encoded version: The first source operand is an xmm register encoded by VEX.vvvv. The three high-order doublewords of the destination operand are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low doubleword element of the destination operand is updated according to the writemask.
Software should ensure VMULSS is encoded with VEX.L=0. Encoding VMULSS with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
- "tooltip": "Multiplies the low single-precision floating-point value from the second source operand by the low single-precision floating-point value in the first source operand, and stores the single-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source operand and the destination operands are XMM registers.",
+ "html": "
Multiplies the low single precision floating-point value from the second source operand by the low single precision floating-point value in the first source operand, and stores the single precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source operand and the destination operands are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 and EVEX encoded version: The first source operand is an xmm register encoded by VEX.vvvv. The three high-order doublewords of the destination operand are copied from the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low doubleword element of the destination operand is updated according to the write-mask.
Software should ensure VMULSS is encoded with VEX.L=0. Encoding VMULSS with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
+ "tooltip": "Multiplies the low single precision floating-point value from the second source operand by the low single precision floating-point value in the first source operand, and stores the single precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source operand and the destination operands are XMM registers.",
"url": "https://www.felixcloutier.com/x86/MULSS.html"
};
@@ -2058,22 +2065,22 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "ORPD":
case "VORPD":
return {
- "html": "
Performs a bitwise logical OR of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Performs a bitwise logical OR of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
+ "html": "
Performs a bitwise logical OR of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with write-mask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Performs a bitwise logical OR of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/ORPD.html"
};
case "ORPS":
case "VORPS":
return {
- "html": "
Performs a bitwise logical OR of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Performs a bitwise logical OR of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand",
+ "html": "
Performs a bitwise logical OR of the four, eight or sixteen packed single precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with write-mask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Performs a bitwise logical OR of the four, eight or sixteen packed single precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand",
"url": "https://www.felixcloutier.com/x86/ORPS.html"
};
case "OUT":
return {
- "html": "
Copies the value from the second operand (source operand) to the I/O port specified with the destination operand (first operand). The source operand can be register AL, AX, or EAX, depending on the size of the port being accessed (8, 16, or 32 bits, respectively); the destination operand can be a byte-immediate or the DX register. Using a byte immediate allows I/O port addresses 0 to 255 to be accessed; using the DX register as a source operand allows I/O ports from 0 to 65,535 to be accessed.
The size of the I/O port being accessed is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.
At the machine code level, I/O instructions are shorter when accessing 8-bit I/O ports. Here, the upper eight bits of the port address will be 0.
This instruction is only useful for accessing I/O ports located in the processor\u2019s I/O address space. See Chapter 19, \u201cInput/Output,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information on accessing I/O ports in the I/O address space.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Copies the value from the second operand (source operand) to the I/O port specified with the destination operand (first operand). The source operand can be register AL, AX, or EAX, depending on the size of the port being accessed (8, 16, or 32 bits, respectively); the destination operand can be a byte-immediate or the DX register. Using a byte immediate allows I/O port addresses 0 to 255 to be accessed; using the DX register as a source operand allows I/O ports from 0 to 65,535 to be accessed.
The size of the I/O port being accessed is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.
At the machine code level, I/O instructions are shorter when accessing 8-bit I/O ports. Here, the upper eight bits of the port address will be 0.
This instruction is only useful for accessing I/O ports located in the processor\u2019s I/O address space. See Chapter 19, \u201cInput/Output,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information on accessing I/O ports in the I/O address space.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Copies the value from the second operand (source operand) to the I/O port specified with the destination operand (first operand). The source operand can be register AL, AX, or EAX, depending on the size of the port being accessed (8, 16, or 32 bits, respectively); the destination operand can be a byte-immediate or the DX register. Using a byte immediate allows I/O port addresses 0 to 255 to be accessed; using the DX register as a source operand allows I/O ports from 0 to 65,535 to be accessed.",
"url": "https://www.felixcloutier.com/x86/OUT.html"
};
@@ -2083,7 +2090,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "OUTSD":
case "OUTSW":
return {
- "html": "
Copies data from the source operand (second operand) to the I/O port specified with the destination operand (first operand). The source operand is a memory location, the address of which is read from either the DS:SI, DS:ESI or the RSI registers (depending on the address-size attribute of the instruction, 16, 32 or 64, respectively). (The DS segment may be overridden with a segment override prefix.) The destination operand is an I/O port address (from 0 to 65,535) that is read from the DX register. The size of the I/O port being accessed (that is, the size of the source and destination operands) is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.
At the assembly-code level, two forms of this instruction are allowed: the \u201cexplicit-operands\u201d form and the \u201cno-operands\u201d form. The explicit-operands form (specified with the OUTS mnemonic) allows the source and destination operands to be specified explicitly. Here, the source operand should be a symbol that indicates the size of the I/O port and the source address, and the destination operand must be DX. This explicit-operands form is provided to allow documentation; however, note that the documentation provided by this form can be misleading. That is, the source operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location. The location is always specified by the DS:(E)SI or RSI registers, which must be loaded correctly before the OUTS instruction is executed.
The no-operands form provides \u201cshort forms\u201d of the byte, word, and doubleword versions of the OUTS instructions. Here also DS:(E)SI is assumed to be the source operand and DX is assumed to be the destination operand. The size of the I/O port is specified with the choice of mnemonic: OUTSB (byte), OUTSW (word), or OUTSD (doubleword).
After the byte, word, or doubleword is transferred from the memory location to the I/O port, the SI/ESI/RSI register is incremented or decremented automatically according to the setting of the DF flag in the EFLAGS register. (If the DF flag is 0, the (E)SI register is incremented; if the DF flag is 1, the SI/ESI/RSI register is decremented.) The SI/ESI/RSI register is incremented or decremented by 1 for byte operations, by 2 for word operations, and by 4 for doubleword operations.
The OUTS, OUTSB, OUTSW, and OUTSD instructions can be preceded by the REP prefix for block input of ECX bytes, words, or doublewords. See \u201cREP/REPE/REPZ /REPNE/REPNZ\u2014Repeat String Operation Prefix\u201d in this chapter for a description of the REP prefix. This instruction is only useful for accessing I/O ports located in the processor\u2019s I/O address space. See Chapter 19, \u201cInput/Output,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information on accessing I/O ports in the I/O address space.
",
+ "html": "
Copies data from the source operand (second operand) to the I/O port specified with the destination operand (first operand). The source operand is a memory location, the address of which is read from either the DS:SI, DS:ESI or the RSI registers (depending on the address-size attribute of the instruction, 16, 32 or 64, respectively). (The DS segment may be overridden with a segment override prefix.) The destination operand is an I/O port address (from 0 to 65,535) that is read from the DX register. The size of the I/O port being accessed (that is, the size of the source and destination operands) is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.
At the assembly-code level, two forms of this instruction are allowed: the \u201cexplicit-operands\u201d form and the \u201cno-operands\u201d form. The explicit-operands form (specified with the OUTS mnemonic) allows the source and destination operands to be specified explicitly. Here, the source operand should be a symbol that indicates the size of the I/O port and the source address, and the destination operand must be DX. This explicit-operands form is provided to allow documentation; however, note that the documentation provided by this form can be misleading. That is, the source operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location. The location is always specified by the DS:(E)SI or RSI registers, which must be loaded correctly before the OUTS instruction is executed.
The no-operands form provides \u201cshort forms\u201d of the byte, word, and doubleword versions of the OUTS instructions. Here also DS:(E)SI is assumed to be the source operand and DX is assumed to be the destination operand. The size of the I/O port is specified with the choice of mnemonic: OUTSB (byte), OUTSW (word), or OUTSD (doubleword).
After the byte, word, or doubleword is transferred from the memory location to the I/O port, the SI/ESI/RSI register is incremented or decremented automatically according to the setting of the DF flag in the EFLAGS register. (If the DF flag is 0, the (E)SI register is incremented; if the DF flag is 1, the SI/ESI/RSI register is decremented.) The SI/ESI/RSI register is incremented or decremented by 1 for byte operations, by 2 for word operations, and by 4 for doubleword operations.
The OUTS, OUTSB, OUTSW, and OUTSD instructions can be preceded by the REP prefix for block input of ECX bytes, words, or doublewords. See \u201cREP/REPE/REPZ /REPNE/REPNZ\u2014Repeat String Operation Prefix\u201d in this chapter for a
",
"tooltip": "Copies data from the source operand (second operand) to the I/O port specified with the destination operand (first operand). The source operand is a memory location, the address of which is read from either the DS:SI, DS:ESI or the RSI registers (depending on the address-size attribute of the instruction, 16, 32 or 64, respectively). (The DS segment may be overridden with a segment override prefix.) The destination operand is an I/O port address (from 0 to 65,535) that is read from the DX register. The size of the I/O port being accessed (that is, the size of the source and destination operands) is determined by the opcode for an 8-bit I/O port or by the operand-size attribute of the instruction for a 16- or 32-bit I/O port.",
"url": "https://www.felixcloutier.com/x86/OUTS%3AOUTSB%3AOUTSW%3AOUTSD.html"
};
@@ -2106,7 +2113,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPACKSSDW":
case "VPACKSSWB":
return {
- "html": "
Converts packed signed word integers into packed signed byte integers (PACKSSWB) or converts packed signed doubleword integers into packed signed word integers (PACKSSDW), using saturation to handle overflow conditions. See Figure 4-6 for an example of the packing operation.
PACKSSWB converts packed signed word integers in the first and second source operands into packed signed byte integers using signed saturation to handle overflow conditions beyond the range of signed byte integers. If the signed word value is beyond the range of a signed byte value (i.e., greater than 7FH or less than 80H), the saturated signed byte integer value of 7FH or 80H, respectively, is stored in the destination. PACKSSDW converts packed signed doubleword integers in the first and second source operands into packed signed word integers using signed saturation to handle overflow conditions beyond 7FFFH and 8000H.
EVEX encoded PACKSSWB: The first source operand is a ZMM/YMM/XMM register. The second source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a ZMM/YMM/XMM register, updated conditional under the writemask k1.
EVEX encoded PACKSSDW: The first source operand is a ZMM/YMM/XMM register. The second source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register, updated conditional under the writemask k1.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
",
+ "html": "
Converts packed signed word integers into packed signed byte integers (PACKSSWB) or converts packed signed doubleword integers into packed signed word integers (PACKSSDW), using saturation to handle overflow conditions. See Figure 4-6 for an example of the packing operation.
PACKSSWB converts packed signed word integers in the first and second source operands into packed signed byte integers using signed saturation to handle overflow conditions beyond the range of signed byte integers. If the signed word value is beyond the range of a signed byte value (i.e., greater than 7FH or less than 80H), the saturated signed byte integer value of 7FH or 80H, respectively, is stored in the destination. PACKSSDW converts packed signed doubleword integers in the first and second source operands into packed signed word integers using signed saturation to handle overflow conditions beyond 7FFFH and 8000H.
EVEX encoded PACKSSWB: The first source operand is a ZMM/YMM/XMM register. The second source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a ZMM/YMM/XMM register, updated conditional under the writemask k1.
EVEX encoded PACKSSDW: The first source operand is a ZMM/YMM/XMM register. The second source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-
bit memory location. The destination operand is a ZMM/YMM/XMM register, updated conditional under the write-mask k1.
",
"tooltip": "Converts packed signed word integers into packed signed byte integers (PACKSSWB) or converts packed signed doubleword integers into packed signed word integers (PACKSSDW), using saturation to handle overflow conditions. See Figure 4-6 for an example of the packing operation.",
"url": "https://www.felixcloutier.com/x86/PACKSSWB%3APACKSSDW.html"
};
@@ -2122,8 +2129,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "PACKUSWB":
case "VPACKUSWB":
return {
- "html": "
Converts 4, 8, 16 or 32 signed word integers from the destination operand (first operand) and 4, 8, 16 or 32 signed word integers from the source operand (second operand) into 8, 16, 32 or 64 unsigned byte integers and stores the result in the destination operand. (See Figure 4-6 for an example of the packing operation.) If a signed word integer value is beyond the range of an unsigned byte integer (that is, greater than FFH or less than 00H), the saturated unsigned byte integer value of FFH or 00H, respectively, is stored in the destination.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register or a 512-bit memory location. The destination operand is a ZMM register.
VEX.256 and EVEX.256 encoded versions: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 and EVEX.128 encoded versions: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding register destination are zeroed.
128-bit Legacy SSE version: The first source operand is an XMM register. The second operand can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Converts 4, 8, 16 or 32 signed word integers from the destination operand (first operand) and 4, 8, 16 or 32 signed word integers from the source operand (second operand) into 8, 16, 32 or 64 unsigned byte integers and stores the result in the destination operand. (See Figure 4-6 for an example of the packing operation.) If a signed word integer value is beyond the range of an unsigned byte integer (that is, greater than FFH or less than 00H), the saturated unsigned byte integer value of FFH or 00H, respectively, is stored in the destination.",
+ "html": "
Converts 4, 8, 16, or 32 signed word integers from the destination operand (first operand) and 4, 8, 16, or 32 signed word integers from the source operand (second operand) into 8, 16, 32 or 64 unsigned byte integers and stores the result in the destination operand. (See Figure 4-6 for an example of the packing operation.) If a signed word integer value is beyond the range of an unsigned byte integer (that is, greater than FFH or less than 00H), the saturated unsigned byte integer value of FFH or 00H, respectively, is stored in the destination.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register or a 512-bit memory location. The destination operand is a ZMM register.
VEX.256 and EVEX.256 encoded versions: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 and EVEX.128 encoded versions: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding register destination are zeroed.
128-bit Legacy SSE version: The first source operand is an XMM register. The second operand can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Converts 4, 8, 16, or 32 signed word integers from the destination operand (first operand) and 4, 8, 16, or 32 signed word integers from the source operand (second operand) into 8, 16, 32 or 64 unsigned byte integers and stores the result in the destination operand. (See Figure 4-6 for an example of the packing operation.) If a signed word integer value is beyond the range of an unsigned byte integer (that is, greater than FFH or less than 00H), the saturated unsigned byte integer value of FFH or 00H, respectively, is stored in the destination.",
"url": "https://www.felixcloutier.com/x86/PACKUSWB.html"
};
@@ -2136,7 +2143,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPADDQ":
case "VPADDW":
return {
- "html": "
Performs a SIMD add of the packed integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with wraparound, as described in the following paragraphs.
The PADDB and VPADDB instructions add packed byte integers from the first source operand and second source operand and store the packed integer results in the destination operand. When an individual result is too large to be represented in 8 bits (overflow), the result is wrapped around and the low 8 bits are written to the destination operand (that is, the carry is ignored).
The PADDW and VPADDW instructions add packed word integers from the first source operand and second source operand and store the packed integer results in the destination operand. When an individual result is too large to be represented in 16 bits (overflow), the result is wrapped around and the low 16 bits are written to the destination operand (that is, the carry is ignored).
The PADDD and VPADDD instructions add packed doubleword integers from the first source operand and second source operand and store the packed integer results in the destination operand. When an individual result is too large to be represented in 32 bits (overflow), the result is wrapped around and the low 32 bits are written to the destination operand (that is, the carry is ignored).
The PADDQ and VPADDQ instructions add packed quadword integers from the first source operand and second source operand and store the packed integer results in the destination operand. When a quadword result is too
",
+ "html": "
Performs a SIMD add of the packed integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with wraparound, as described in the following paragraphs.
The PADDB and VPADDB instructions add packed byte integers from the first source operand and second source operand and store the packed integer results in the destination operand. When an individual result is too large to be represented in 8 bits (overflow), the result is wrapped around and the low 8 bits are written to the destination operand (that is, the carry is ignored).
The PADDW and VPADDW instructions add packed word integers from the first source operand and second source operand and store the packed integer results in the destination operand. When an individual result is too large to
be represented in 16 bits (overflow), the result is wrapped around and the low 16 bits are written to the destination operand (that is, the carry is ignored).
The PADDD and VPADDD instructions add packed doubleword integers from the first source operand and second source operand and store the packed integer results in the destination operand. When an individual result is too large to be represented in 32 bits (overflow), the result is wrapped around and the low 32 bits are written to the destination operand (that is, the carry is ignored).
",
"tooltip": "Performs a SIMD add of the packed integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with wraparound, as described in the following paragraphs.",
"url": "https://www.felixcloutier.com/x86/PADDB%3APADDW%3APADDD%3APADDQ.html"
};
@@ -2146,7 +2153,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPADDSB":
case "VPADDSW":
return {
- "html": "
Performs a SIMD add of the packed signed integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with signed saturation, as described in the following paragraphs.
(V)PADDSB performs a SIMD add of the packed signed integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual byte result is beyond the range of a signed byte integer (that is, greater than 7FH or less than 80H), the saturated value of 7FH or 80H, respectively, is written to the destination operand.
(V)PADDSW performs a SIMD add of the packed signed word integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual word result is beyond the range of a signed word integer (that is, greater than 7FFFH or less than 8000H), the saturated value of 7FFFH or 8000H, respectively, is written to the destination operand.
EVEX encoded versions: The first source operand is an ZMM/YMM/XMM register. The second source operand is an ZMM/YMM/XMM register or a memory location. The destination operand is an ZMM/YMM/XMM register.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
+ "html": "
Performs a SIMD add of the packed signed integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with signed saturation, as described in the following paragraphs.
(V)PADDSB performs a SIMD add of the packed signed integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual byte result is beyond the range of a signed byte integer (that is, greater than 7FH or less than 80H), the saturated value of 7FH or 80H, respectively, is written to the destination operand.
(V)PADDSW performs a SIMD add of the packed signed word integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual word result is beyond the range of a signed word integer (that is, greater than 7FFFH or less than 8000H), the saturated value of 7FFFH or 8000H, respectively, is written to the destination operand.
EVEX encoded versions: The first source operand is an ZMM/YMM/XMM register. The second source operand is an ZMM/YMM/XMM register or a memory location. The destination operand is an ZMM/YMM/XMM register.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
"tooltip": "Performs a SIMD add of the packed signed integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with signed saturation, as described in the following paragraphs.",
"url": "https://www.felixcloutier.com/x86/PADDSB%3APADDSW.html"
};
@@ -2156,7 +2163,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPADDUSB":
case "VPADDUSW":
return {
- "html": "
Performs a SIMD add of the packed unsigned integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with unsigned saturation, as described in the following paragraphs.
(V)PADDUSB performs a SIMD add of the packed unsigned integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual byte result is beyond the range of an unsigned byte integer (that is, greater than FFH), the saturated value of FFH is written to the destination operand.
(V)PADDUSW performs a SIMD add of the packed unsigned word integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual word result is beyond the range of an unsigned word integer (that is, greater than FFFFH), the saturated value of FFFFH is written to the destination operand.
EVEX encoded versions: The first source operand is an ZMM/YMM/XMM register. The second source operand is an ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination is an ZMM/YMM/XMM register.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
+ "html": "
Performs a SIMD add of the packed unsigned integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with unsigned saturation, as described in the following paragraphs.
(V)PADDUSB performs a SIMD add of the packed unsigned integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual byte result is beyond the range of an unsigned byte integer (that is, greater than FFH), the saturated value of FFH is written to the destination operand.
(V)PADDUSW performs a SIMD add of the packed unsigned word integers with saturation from the first source operand and second source operand and stores the packed integer results in the destination operand. When an individual word result is beyond the range of an unsigned word integer (that is, greater than FFFFH), the saturated value of FFFFH is written to the destination operand.
EVEX encoded versions: The first source operand is an ZMM/YMM/XMM register. The second source operand is an ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination is an ZMM/YMM/XMM register.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
"tooltip": "Performs a SIMD add of the packed unsigned integers from the source operand (second operand) and the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with unsigned saturation, as described in the following paragraphs.",
"url": "https://www.felixcloutier.com/x86/PADDUSB%3APADDUSW.html"
};
@@ -2164,8 +2171,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "PALIGNR":
case "VPALIGNR":
return {
- "html": "
(V)PALIGNR concatenates the destination operand (the first operand) and the source operand (the second operand) into an intermediate composite, shifts the composite at byte granularity to the right by a constant immediate, and extracts the right-aligned result into the destination. The first and the second operands can be an MMX,
XMM or a YMM register. The immediate value is considered unsigned. Immediate shift counts larger than the 2L (i.e., 32 for 128-bit operands, or 16 for 64-bit operands) produce a zero result. Both operands can be MMX registers, XMM registers or YMM registers. When the source operand is a 128-bit memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) will be generated.
In 64-bit mode and not encoded by VEX/EVEX prefix, use the REX prefix to access additional registers.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding YMM destination register remain unchanged.
EVEX.512 encoded version: The first source operand is a ZMM register and contains four 16-byte blocks. The second source operand is a ZMM register or a 512-bit memory location containing four 16-byte block. The destination operand is a ZMM register and contain four 16-byte results. The imm8[7:0] is the common shift count
",
- "tooltip": "(V)PALIGNR concatenates the destination operand (the first operand) and the source operand (the second operand) into an intermediate composite, shifts the composite at byte granularity to the right by a constant immediate, and extracts the right-aligned result into the destination. The first and the second operands can be an MMX",
+ "html": "
(V)PALIGNR concatenates the destination operand (the first operand) and the source operand (the second operand) into an intermediate composite, shifts the composite at byte granularity to the right by a constant immediate, and extracts the right-aligned result into the destination. The first and the second operands can be an MMX, XMM or a YMM register. The immediate value is considered unsigned. Immediate shift counts larger than the 2L (i.e., 32 for 128-bit operands, or 16 for 64-bit operands) produce a zero result. Both operands can be MMX registers, XMM registers or YMM registers. When the source operand is a 128-bit memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) will be generated.
In 64-bit mode and not encoded by VEX/EVEX prefix, use the REX prefix to access additional registers.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding YMM destination register remain unchanged.
EVEX.512 encoded version: The first source operand is a ZMM register and contains four 16-byte blocks. The second source operand is a ZMM register or a 512-bit memory location containing four 16-byte block. The destination operand is a ZMM register and contain four 16-byte results. The imm8[7:0] is the common shift count
used for each of the four successive 16-byte block sources. The low 16-byte block of the two source operands produce the low 16-byte result of the destination operand, the high 16-byte block of the two source operands produce the high 16-byte result of the destination operand and so on for the blocks in the middle.
",
+ "tooltip": "(V)PALIGNR concatenates the destination operand (the first operand) and the source operand (the second operand) into an intermediate composite, shifts the composite at byte granularity to the right by a constant immediate, and extracts the right-aligned result into the destination. The first and the second operands can be an MMX, XMM or a YMM register. The immediate value is considered unsigned. Immediate shift counts larger than the 2L (i.e., 32 for 128-bit operands, or 16 for 64-bit operands) produce a zero result. Both operands can be MMX registers, XMM registers or YMM registers. When the source operand is a 128-bit memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) will be generated.",
"url": "https://www.felixcloutier.com/x86/PALIGNR.html"
};
@@ -2174,7 +2181,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPANDD":
case "VPANDQ":
return {
- "html": "
Performs a bitwise logical AND operation on the first source operand and second source operand and stores the result in the destination operand. Each bit of the result is set to 1 if the corresponding bits of the first and second operands are 1, otherwise it is set to 0.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
Legacy SSE instructions: The source operand can be an MMX technology register or a 64-bit memory location. The destination operand can be an MMX technology register.
128-bit Legacy SSE version: The first source operand is an XMM register. The second operand can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1 at 32/64-bit granularity.
",
+ "html": "
Performs a bitwise logical AND operation on the first source operand and second source operand and stores the result in the destination operand. Each bit of the result is set to 1 if the corresponding bits of the first and second operands are 1, otherwise it is set to 0.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
Legacy SSE instructions: The source operand can be an MMX technology register or a 64-bit memory location. The destination operand can be an MMX technology register.
128-bit Legacy SSE version: The first source operand is an XMM register. The second operand can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with write-mask k1 at 32/64-bit granularity.
",
"tooltip": "Performs a bitwise logical AND operation on the first source operand and second source operand and stores the result in the destination operand. Each bit of the result is set to 1 if the corresponding bits of the first and second operands are 1, otherwise it is set to 0.",
"url": "https://www.felixcloutier.com/x86/PAND.html"
};
@@ -2184,7 +2191,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPANDND":
case "VPANDNQ":
return {
- "html": "
Performs a bitwise logical NOT operation on the first source operand, then performs bitwise AND with second source operand and stores the result in the destination operand. Each bit of the result is set to 1 if the corresponding bit in the first operand is 0 and the corresponding bit in the second operand is 1, otherwise it is set to 0.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
Legacy SSE instructions: The source operand can be an MMX technology register or a 64-bit memory location. The destination operand can be an MMX technology register.
128-bit Legacy SSE version: The first source operand is an XMM register. The second operand can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1 at 32/64-bit granularity.
",
+ "html": "
Performs a bitwise logical NOT operation on the first source operand, then performs bitwise AND with second source operand and stores the result in the destination operand. Each bit of the result is set to 1 if the corresponding bit in the first operand is 0 and the corresponding bit in the second operand is 1, otherwise it is set to 0.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
Legacy SSE instructions: The source operand can be an MMX technology register or a 64-bit memory location. The destination operand can be an MMX technology register.
128-bit Legacy SSE version: The first source operand is an XMM register. The second operand can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with write-mask k1 at 32/64-bit granularity.
",
"tooltip": "Performs a bitwise logical NOT operation on the first source operand, then performs bitwise AND with second source operand and stores the result in the destination operand. Each bit of the result is set to 1 if the corresponding bit in the first operand is 0 and the corresponding bit in the second operand is 1, otherwise it is set to 0.",
"url": "https://www.felixcloutier.com/x86/PANDN.html"
};
@@ -2252,14 +2259,14 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPCMPESTRI":
return {
- "html": "
The instruction compares and processes data from two string fragments based on the encoded value in the Imm8 Control Byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to the count register (ECX).
Each string fragment is represented by two values. The first value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). The second value is stored in an input length register. The input length register is EAX/RAX (for xmm1) or EDX/RDX (for xmm2/m128). The length represents the number of bytes/words which are valid for the respective xmm/m128 data.
The length of each input is interpreted as being the absolute-value of the value in the length register. The absolute-value computation saturates to 16 (for bytes) and 8 (for words), based on the value of imm8[bit3] when the value in the length register is greater than 16 (8) or less than -16 (-8).
The comparison and aggregation operations are performed according to the encoded value of Imm8 bit fields (see Section 4.1). The index of the first (or last, according to imm8[6]) set bit of IntRes2 (see Section 4.1.4) is returned in ECX. If no bits are set in IntRes2, ECX is set to 16 (8).
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
",
- "tooltip": "The instruction compares and processes data from two string fragments based on the encoded value in the Imm8 Control Byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to the count register (ECX).",
+ "html": "
The instruction compares and processes data from two string fragments based on the encoded value in the imm8 control byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to the count register (ECX).
Each string fragment is represented by two values. The first value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). The second value is stored in an input length register. The input length register is EAX/RAX (for xmm1) or EDX/RDX (for xmm2/m128). The length represents the number of bytes/words which are valid for the respective xmm/m128 data.
The length of each input is interpreted as being the absolute-value of the value in the length register. The absolute-value computation saturates to 16 (for bytes) and 8 (for words), based on the value of imm8[bit3] when the value in the length register is greater than 16 (8) or less than -16 (-8).
The comparison and aggregation operations are performed according to the encoded value of imm8 bit fields (see Section 4.1). The index of the first (or last, according to imm8[6]) set bit of IntRes2 (see Section 4.1.4) is returned in ECX. If no bits are set in IntRes2, ECX is set to 16 (8).
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
",
+ "tooltip": "The instruction compares and processes data from two string fragments based on the encoded value in the imm8 control byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to the count register (ECX).",
"url": "https://www.felixcloutier.com/x86/PCMPESTRI.html"
};
case "VPCMPESTRM":
return {
- "html": "
The instruction compares data from two string fragments based on the encoded value in the imm8 contol byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates a mask stored to XMM0.
Each string fragment is represented by two values. The first value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). The second value is stored in an input length register. The input length register is EAX/RAX (for xmm1) or EDX/RDX (for xmm2/m128). The length represents the number of bytes/words which are valid for the respective xmm/m128 data.
The length of each input is interpreted as being the absolute-value of the value in the length register. The absolute-value computation saturates to 16 (for bytes) and 8 (for words), based on the value of imm8[bit3] when the value in the length register is greater than 16 (8) or less than -16 (-8).
The comparison and aggregation operations are performed according to the encoded value of Imm8 bit fields (see Section 4.1). As defined by imm8[6], IntRes2 is then either stored to the least significant bits of XMM0 (zero extended to 128 bits) or expanded into a byte/word-mask and then stored to XMM0.
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
",
+ "html": "
The instruction compares data from two string fragments based on the encoded value in the imm8 contol byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates a mask stored to XMM0.
Each string fragment is represented by two values. The first value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). The second value is stored in an input length register. The input length register is EAX/RAX (for xmm1) or EDX/RDX (for xmm2/m128). The length represents the number of bytes/words which are valid for the respective xmm/m128 data.
The length of each input is interpreted as being the absolute-value of the value in the length register. The absolute-value computation saturates to 16 (for bytes) and 8 (for words), based on the value of imm8[bit3] when the value in the length register is greater than 16 (8) or less than -16 (-8).
The comparison and aggregation operations are performed according to the encoded value of imm8 bit fields (see Section 4.1). As defined by imm8[6], IntRes2 is then either stored to the least significant bits of XMM0 (zero extended to 128 bits) or expanded into a byte/word-mask and then stored to XMM0.
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
",
"tooltip": "The instruction compares data from two string fragments based on the encoded value in the imm8 contol byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates a mask stored to XMM0.",
"url": "https://www.felixcloutier.com/x86/PCMPESTRM.html"
};
@@ -2286,22 +2293,22 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPCMPISTRI":
return {
- "html": "
The instruction compares data from two strings based on the encoded value in the Imm8 Control Byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to ECX.
Each string is represented by a single value. The value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). Each input byte/word is augmented with a valid/invalid tag. A byte/word is considered valid only if it has a lower index than the least significant null byte/word. (The least significant null byte/word is also considered invalid.)
The comparison and aggregation operations are performed according to the encoded value of Imm8 bit fields (see Section 4.1). The index of the first (or last, according to imm8[6]) set bit of IntRes2 is returned in ECX. If no bits are set in IntRes2, ECX is set to 16 (8).
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
CFlag \u2013 Reset if IntRes2 is equal to zero, set otherwise
",
- "tooltip": "The instruction compares data from two strings based on the encoded value in the Imm8 Control Byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to ECX.",
+ "html": "
The instruction compares data from two strings based on the encoded value in the imm8 control byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to ECX.
Each string is represented by a single value. The value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). Each input byte/word is augmented with a valid/invalid tag. A byte/word is considered valid only if it has a lower index than the least significant null byte/word. (The least significant null byte/word is also considered invalid.)
The comparison and aggregation operations are performed according to the encoded value of imm8 bit fields (see Section 4.1). The index of the first (or last, according to imm8[6]) set bit of IntRes2 is returned in ECX. If no bits are set in IntRes2, ECX is set to 16 (8).
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
CFlag \u2013 Reset if IntRes2 is equal to zero, set otherwise
",
+ "tooltip": "The instruction compares data from two strings based on the encoded value in the imm8 control byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d), and generates an index stored to ECX.",
"url": "https://www.felixcloutier.com/x86/PCMPISTRI.html"
};
case "VPCMPISTRM":
return {
- "html": "
The instruction compares data from two strings based on the encoded value in the imm8 byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d) generating a mask stored to XMM0.
Each string is represented by a single value. The value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). Each input byte/word is augmented with a valid/invalid tag. A byte/word is considered valid only if it has a lower index than the least significant null byte/word. (The least significant null byte/word is also considered invalid.)
The comparison and aggregation operation are performed according to the encoded value of Imm8 bit fields (see Section 4.1). As defined by imm8[6], IntRes2 is then either stored to the least significant bits of XMM0 (zero extended to 128 bits) or expanded into a byte/word-mask and then stored to XMM0.
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
CFlag \u2013 Reset if IntRes2 is equal to zero, set otherwise
",
+ "html": "
The instruction compares data from two strings based on the encoded value in the imm8 byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d) generating a mask stored to XMM0.
Each string is represented by a single value. The value is an xmm (or possibly m128 for the second operand) which contains the data elements of the string (byte or word data). Each input byte/word is augmented with a valid/invalid tag. A byte/word is considered valid only if it has a lower index than the least significant null byte/word. (The least significant null byte/word is also considered invalid.)
The comparison and aggregation operation are performed according to the encoded value of imm8 bit fields (see Section 4.1). As defined by imm8[6], IntRes2 is then either stored to the least significant bits of XMM0 (zero extended to 128 bits) or expanded into a byte/word-mask and then stored to XMM0.
Note that the Arithmetic Flags are written in a non-standard manner in order to supply the most relevant information:
CFlag \u2013 Reset if IntRes2 is equal to zero, set otherwise
",
"tooltip": "The instruction compares data from two strings based on the encoded value in the imm8 byte (see Section 4.1, \u201cImm8 Control Byte Operation for PCMPESTRI / PCMPESTRM / PCMPISTRI / PCMPISTRM\u201d) generating a mask stored to XMM0.",
"url": "https://www.felixcloutier.com/x86/PCMPISTRM.html"
};
case "PCONFIG":
return {
- "html": "
PCONFIG allows software to configure certain platform features. PCONFIG supports multiple leaf functions, with a leaf function identified by the value in EAX. The registers RBX, RCX, and RDX may provide input or output information for certain leaves. All leaves write status information to EAX but do not modify RBX, RCX, or RDX unless they are being used as leaf-specific output.
Each PCONFIG leaf function applies to a specific hardware block called a PCONFIG target, and each PCONFIG target is associated with a numerical target identifier. Supported target identifiers are enumerated, along with other PCONFIG capabilities, in the sub-leaves of the PCONFIG-information leaf of CPUID (EAX = 1BH). An attempt to execute an undefined leaf function, or a leaf function that applies to an unsupported target identifier, results in a general-protection exception (#GP). (In the future, the PCONFIG-information leaf of CPUID may enumerate PCONFIG capabilities in addition to the supported target identifiers.)
Addresses and operands are 32 bits outside 64-bit mode and are 64 bits in 64-bit mode. The value of CS.D does not affect operand size or address size.
Table 4-15 shows the leaf encodings for PCONFIG, and Table 4-16 shows the leaf register usage for PCONFIG.
The MKTME_KEY_PROGRAM leaf of PCONFIG pertains to the MKTME1 target, which has target identifier 1. It is used by software to manage the key associated with a KeyID. The leaf function is invoked by setting the leaf value of 0 in EAX and the address of MKTME_KEY_PROGRAM_STRUCT in RBX. Successful execution of the leaf clears RAX (set to zero) and ZF, CF, PF, AF, OF, and SF are cleared. In case of failure, the failure reason is indicated in RAX with ZF set to 1 and CF, PF, AF, OF, and SF are cleared. The MKTME_KEY_PROGRAM leaf uses the MKTME_KEY_PROGRAM_STRUCT in memory shown in Table 4-17.
",
- "tooltip": "PCONFIG allows software to configure certain platform features. PCONFIG supports multiple leaf functions, with a leaf function identified by the value in EAX. The registers RBX, RCX, and RDX may provide input or output information for certain leaves. All leaves write status information to EAX but do not modify RBX, RCX, or RDX unless they are being used as leaf-specific output.",
+ "html": "
The PCONFIG instruction allows software to configure certain platform features. It supports these features with multiple leaf functions, selecting a leaf function using the value in EAX.
Depending on the leaf function, the registers RBX, RCX, and RDX may be used to provide input information or for the instruction to report output information. Addresses and operands are 32 bits outside 64-bit mode and are 64 bits in 64-bit mode. The value of CS.D does not affect operand size or address size.
Executions of PCONFIG may fail for platform-specific reasons. An execution reports failure by setting the ZF flag and loading EAX with a non-zero failure reason; a successful execution clears ZF and EAX.
Each PCONFIG leaf function applies to a specific hardware block called a PCONFIG target. The leaf function is supported only if the processor supports that target. Each target is associated with a numerical target identifier, and CPUID leaf 1BH (PCONFIG information) enumerates the identifiers of the supported targets. An attempt to execute an undefined leaf function, or a leaf function that applies to an unsupported target identifier, results in a general-protection exception (#GP).
As of this writing, the only defined PCONFIG leaf function is used for key programming for total memory encryption-multi-key (TME-MK).1 This leaf function is called MKTME_KEY_PROGRAM and it pertains to the TME-MK target, which has target identifier 1. The leaf function is selected by loading EAX with value 0. The MKTME_KEY_PROGRAM leaf function uses the EBX (or RBX) register for additional input information.
",
+ "tooltip": "The PCONFIG instruction allows software to configure certain platform features. It supports these features with multiple leaf functions, selecting a leaf function using the value in EAX.",
"url": "https://www.felixcloutier.com/x86/PCONFIG.html"
};
@@ -2326,7 +2333,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPEXTRD":
case "VPEXTRQ":
return {
- "html": "
Extract a byte/dword/qword integer value from the source XMM register at a byte/dword/qword offset determined from imm8[3:0]. The destination can be a register or byte/dword/qword memory location. If the destination is a register, the upper bits of the register are zero extended.
In legacy non-VEX encoded version and if the destination operand is a register, the default operand size in 64-bit mode for PEXTRB/PEXTRD is 64 bits, the bits above the least significant byte/dword data are filled with zeros. PEXTRQ is not encodable in non-64-bit modes and requires REX.W in 64-bit mode.
Note: In VEX.128 encoded versions, VEX.vvvv is reserved and must be 1111b, VEX.L must be 0, otherwise the instruction will #UD. In EVEX.128 encoded versions, EVEX.vvvv is reserved and must be 1111b, EVEX.L\u201dL must be
0, otherwise the instruction will #UD. If the destination operand is a register, the default operand size in 64-bit mode for VPEXTRB/VPEXTRD is 64 bits, the bits above the least significant byte/word/dword data are filled with zeros.
",
+ "html": "
Extract a byte/dword/qword integer value from the source XMM register at a byte/dword/qword offset determined from imm8[3:0]. The destination can be a register or byte/dword/qword memory location. If the destination is a register, the upper bits of the register are zero extended.
In legacy non-VEX encoded version and if the destination operand is a register, the default operand size in 64-bit mode for PEXTRB/PEXTRD is 64 bits, the bits above the least significant byte/dword data are filled with zeros. PEXTRQ is not encodable in non-64-bit modes and requires REX.W in 64-bit mode.
Note: In VEX.128 encoded versions, VEX.vvvv is reserved and must be 1111b, VEX.L must be 0, otherwise the instruction will #UD. In EVEX.128 encoded versions, EVEX.vvvv is reserved and must be 1111b, EVEX.L\u201dL must be 0, otherwise the instruction will #UD. If the destination operand is a register, the default operand size in 64-bit mode for VPEXTRB/VPEXTRD is 64 bits, the bits above the least significant byte/word/dword data are filled with zeros.
",
"tooltip": "Extract a byte/dword/qword integer value from the source XMM register at a byte/dword/qword offset determined from imm8[3:0]. The destination can be a register or byte/dword/qword memory location. If the destination is a register, the upper bits of the register are zero extended.",
"url": "https://www.felixcloutier.com/x86/PEXTRB%3APEXTRD%3APEXTRQ.html"
};
@@ -2528,8 +2535,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPMOVZXWD":
case "VPMOVZXWQ":
return {
- "html": "
Legacy, VEX and EVEX encoded versions: Packed byte, word, or dword integers starting from the low bytes of the source operand (second operand) are zero extended to word, dword, or quadword integers and stored in packed signed bytes the destination operand.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 encoded version: Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX encoded versions: Packed dword integers starting from the low bytes of the source operand (second operand) are zero extended to quadword integers and stored to the destination operand under the writemask.The destination register is XMM, YMM or ZMM Register.
",
- "tooltip": "Legacy, VEX and EVEX encoded versions: Packed byte, word, or dword integers starting from the low bytes of the source operand (second operand) are zero extended to word, dword, or quadword integers and stored in packed signed bytes the destination operand.",
+ "html": "
Legacy, VEX, and EVEX encoded versions: Packed byte, word, or dword integers starting from the low bytes of the source operand (second operand) are zero extended to word, dword, or quadword integers and stored in packed signed bytes the destination operand.
128-bit Legacy SSE version: Bits (MAXVL-1:128) of the corresponding destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 encoded version: Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX encoded versions: Packed dword integers starting from the low bytes of the source operand (second operand) are zero extended to quadword integers and stored to the destination operand under the writemask.The destination register is XMM, YMM or ZMM Register.
",
+ "tooltip": "Legacy, VEX, and EVEX encoded versions: Packed byte, word, or dword integers starting from the low bytes of the source operand (second operand) are zero extended to word, dword, or quadword integers and stored in packed signed bytes the destination operand.",
"url": "https://www.felixcloutier.com/x86/PMOVZX.html"
};
@@ -2592,7 +2599,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "POP":
return {
- "html": "
Loads the value from the top of the stack to the location specified with the destination operand (or explicit opcode) and then increments the stack pointer. The destination operand can be a general-purpose register, memory location, or segment register.
Address and operand sizes are determined and used as follows:
The operand size (16, 32, or 64 bits) determines the amount by which the stack pointer is incremented (2, 4 or 8).
The stack-address size determines the width of the stack pointer when reading from the stack in memory and when incrementing the stack pointer. (As stated above, the amount by which the stack pointer is incremented is determined by the operand size.)
If the destination operand is one of the segment registers DS, ES, FS, GS, or SS, the value loaded into the register must be a valid segment selector. In protected mode, popping a segment selector into a segment register automatically causes the descriptor information associated with that segment selector to be loaded into the hidden (shadow) part of the segment register and causes the selector and the descriptor information to be validated (see the \u201cOperation\u201d section below).
",
+ "html": "
Loads the value from the top of the stack to the location specified with the destination operand (or explicit opcode) and then increments the stack pointer. The destination operand can be a general-purpose register, memory location, or segment register.
Address and operand sizes are determined and used as follows:
The address size is used only when writing to a destination operand in memory.
The operand size (16, 32, or 64 bits) determines the amount by which the stack pointer is incremented (2, 4 or 8).
The stack-address size determines the width of the stack pointer when reading from the stack in memory and when incrementing the stack pointer. (As stated above, the amount by which the stack pointer is incremented is determined by the operand size.)
",
"tooltip": "Loads the value from the top of the stack to the location specified with the destination operand (or explicit opcode) and then increments the stack pointer. The destination operand can be a general-purpose register, memory location, or segment register.",
"url": "https://www.felixcloutier.com/x86/POP.html"
};
@@ -2616,7 +2623,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "POPFD":
case "POPFQ":
return {
- "html": "
Pops a doubleword (POPFD) from the top of the stack (if the current operand-size attribute is 32) and stores the value in the EFLAGS register, or pops a word from the top of the stack (if the operand-size attribute is 16) and stores it in the lower 16 bits of the EFLAGS register (that is, the FLAGS register). These instructions reverse the operation of the PUSHF/PUSHFD/PUSHFQ instructions.
The POPF (pop flags) and POPFD (pop flags double) mnemonics reference the same opcode. The POPF instruction is intended for use when the operand-size attribute is 16; the POPFD instruction is intended for use when the operand-size attribute is 32. Some assemblers may force the operand size to 16 for POPF and to 32 for POPFD. Others may treat the mnemonics as synonyms (POPF/POPFD) and use the setting of the operand-size attribute to determine the size of values to pop from the stack.
The effect of POPF/POPFD on the EFLAGS register changes, depending on the mode of operation. See Table 4-21 and the key below for details.
When operating in protected, compatibility, or 64-bit mode at privilege level 0 (or in real-address mode, the equivalent to privilege level 0), all non-reserved flags in the EFLAGS register except RF1, VIP, VIF, and VM may be modified. VIP, VIF and VM remain unaffected.
When operating in protected, compatibility, or 64-bit mode with a privilege level greater than 0, but less than or equal to IOPL, all flags can be modified except the IOPL field and RF, IF, VIP, VIF, and VM; these remain unaffected. The AC and ID flags can only be modified if the operand-size attribute is 32. The interrupt flag (IF) is altered only when executing at a level at least as privileged as the IOPL. If a POPF/POPFD instruction is executed with insufficient privilege, an exception does not occur but privileged bits do not change.
",
+ "html": "
Pops a doubleword (POPFD) from the top of the stack (if the current operand-size attribute is 32) and stores the value in the EFLAGS register, or pops a word from the top of the stack (if the operand-size attribute is 16) and stores it in the lower 16 bits of the EFLAGS register (that is, the FLAGS register). These instructions reverse the operation of the PUSHF/PUSHFD/PUSHFQ instructions.
The POPF (pop flags) and POPFD (pop flags double) mnemonics reference the same opcode. The POPF instruction is intended for use when the operand-size attribute is 16; the POPFD instruction is intended for use when the operand-size attribute is 32. Some assemblers may force the operand size to 16 for POPF and to 32 for POPFD. Others may treat the mnemonics as synonyms (POPF/POPFD) and use the setting of the operand-size attribute to determine the size of values to pop from the stack.
The effect of POPF/POPFD on the EFLAGS register changes, depending on the mode of operation. See Table 4-16 and the key below for details.
When operating in protected, compatibility, or 64-bit mode at privilege level 0 (or in real-address mode, the equivalent to privilege level 0), all non-reserved flags in the EFLAGS register except RF1, VIP, VIF, and VM may be modified. VIP, VIF, and VM remain unaffected.
When operating in protected, compatibility, or 64-bit mode with a privilege level greater than 0, but less than or equal to IOPL, all flags can be modified except the IOPL field and RF, IF, VIP, VIF, and VM; these remain unaffected. The AC and ID flags can only be modified if the operand-size attribute is 32. The interrupt flag (IF) is altered only when executing at a level at least as privileged as the IOPL. If a POPF/POPFD instruction is executed with insufficient privilege, an exception does not occur but privileged bits do not change.
",
"tooltip": "Pops a doubleword (POPFD) from the top of the stack (if the current operand-size attribute is 32) and stores the value in the EFLAGS register, or pops a word from the top of the stack (if the operand-size attribute is 16) and stores it in the lower 16 bits of the EFLAGS register (that is, the FLAGS register). These instructions reverse the operation of the PUSHF/PUSHFD/PUSHFQ instructions.",
"url": "https://www.felixcloutier.com/x86/POPF%3APOPFD%3APOPFQ.html"
};
@@ -2633,7 +2640,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "PREFETCHW":
return {
- "html": "
Fetches the cache line of data from memory that contains the byte specified with the source operand to a location in the 1st or 2nd level cache and invalidates other cached instances of the line.
The source operand is a byte memory location. If the line selected is already present in the lowest level cache and is already in an exclusively owned state, no data movement occurs. Prefetches from non-writeback memory are ignored.
The PREFETCHW instruction is merely a hint and does not affect program behavior. If executed, this instruction moves data closer to the processor and invalidates other cached copies in anticipation of the line being written to in the future.
The characteristic of prefetch locality hints is implementation-dependent, and can be overloaded or ignored by a processor implementation. The amount of data prefetched is also processor implementation-dependent. It will, however, be a minimum of 32 bytes. Additional details of the implementation-dependent locality hints are described in Section 7.4 of Intel\u00ae 64 and IA-32 Architectures Optimization Reference Manual.
It should be noted that processors are free to speculatively fetch and cache data with exclusive ownership from system memory regions that permit such accesses (that is, the WB memory type). A PREFETCHW instruction is considered a hint to this speculative behavior. Because this speculative fetching can occur at any time and is not tied to instruction execution, a PREFETCHW instruction is not ordered with respect to the fence instructions (MFENCE, SFENCE, and LFENCE) or locked memory references. A PREFETCHW instruction is also unordered with respect to CLFLUSH and CLFLUSHOPT instructions, other PREFETCHW instructions, or any other general instruction
",
+ "html": "
Fetches the cache line of data from memory that contains the byte specified with the source operand to a location in the 1st or 2nd level cache and invalidates other cached instances of the line.
The source operand is a byte memory location. If the line selected is already present in the lowest level cache and is already in an exclusively owned state, no data movement occurs. Prefetches from non-writeback memory are ignored.
The PREFETCHW instruction is merely a hint and does not affect program behavior. If executed, this instruction moves data closer to the processor and invalidates other cached copies in anticipation of the line being written to in the future.
The characteristic of prefetch locality hints is implementation-dependent, and can be overloaded or ignored by a processor implementation. The amount of data prefetched is also processor implementation-dependent. It will, however, be a minimum of 32 bytes. Additional details of the implementation-dependent locality hints are described in Section 7.4 of Intel\u00ae 64 and IA-32 Architectures Optimization Reference Manual.
It should be noted that processors are free to speculatively fetch and cache data with exclusive ownership from system memory regions that permit such accesses (that is, the WB memory type). A PREFETCHW instruction is considered a hint to this speculative behavior. Because this speculative fetching can occur at any time and is not tied to instruction execution, a PREFETCHW instruction is not ordered with respect to the fence instructions (MFENCE, SFENCE, and LFENCE) or locked memory references. A PREFETCHW instruction is also unordered with respect to CLFLUSH and CLFLUSHOPT instructions, other PREFETCHW instructions, or any other general instruction
",
"tooltip": "Fetches the cache line of data from memory that contains the byte specified with the source operand to a location in the 1st or 2nd level cache and invalidates other cached instances of the line.",
"url": "https://www.felixcloutier.com/x86/PREFETCHW.html"
};
@@ -2650,7 +2657,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "PREFETCHT1":
case "PREFETCHT2":
return {
- "html": "
Fetches the line of data from memory that contains the byte specified with the source operand to a location in the cache hierarchy specified by a locality hint:
The source operand is a byte memory location. (The locality hints are encoded into the machine level instruction using bits 3 through 5 of the ModR/M byte.)
If the line selected is already present in the cache hierarchy at a level closer to the processor, no data movement occurs. Prefetches from uncacheable or WC memory are ignored.
The PREFETCHh instruction is merely a hint and does not affect program behavior. If executed, this instruction moves data closer to the processor in anticipation of future use.
The implementation of prefetch locality hints is implementation-dependent, and can be overloaded or ignored by a processor implementation. The amount of data prefetched is also processor implementation-dependent. It will, however, be a minimum of 32 bytes. Additional details of the implementation-dependent locality hints are described in Section 7.4 of Intel\u00ae 64 and IA-32 Architectures Optimization Reference Manual.
",
+ "html": "
Fetches the line of data from memory that contains the byte specified with the source operand to a location in the cache hierarchy specified by a locality hint:
The source operand is a byte memory location. (The locality hints are encoded into the machine level instruction using bits 3 through 5 of the ModR/M byte.)
If the line selected is already present in the cache hierarchy at a level closer to the processor, no data movement occurs. Prefetches from uncacheable or WC memory are ignored.
The PREFETCHh instruction is merely a hint and does not affect program behavior. If executed, this instruction moves data closer to the processor in anticipation of future use.
The implementation of prefetch locality hints is implementation-dependent, and can be overloaded or ignored by a processor implementation. The amount of data prefetched is also processor implementation-dependent. It will, however, be a minimum of 32 bytes. Additional details of the implementation-dependent locality hints are described in Section 7.4 of Intel\u00ae 64 and IA-32 Architectures Optimization Reference Manual.
",
"tooltip": "Fetches the line of data from memory that contains the byte specified with the source operand to a location in the cache hierarchy specified by a locality hint",
"url": "https://www.felixcloutier.com/x86/PREFETCHh.html"
};
@@ -2772,7 +2779,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPSUBD":
case "VPSUBW":
return {
- "html": "
Performs a SIMD subtract of the packed integers of the source operand (second operand) from the packed integers of the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with wraparound, as described in the following paragraphs.
The (V)PSUBB instruction subtracts packed byte integers. When an individual result is too large or too small to be represented in a byte, the result is wrapped around and the low 8 bits are written to the destination element.
The (V)PSUBW instruction subtracts packed word integers. When an individual result is too large or too small to be represented in a word, the result is wrapped around and the low 16 bits are written to the destination element.
The (V)PSUBD instruction subtracts packed doubleword integers. When an individual result is too large or too small to be represented in a doubleword, the result is wrapped around and the low 32 bits are written to the destination element.
Note that the (V)PSUBB, (V)PSUBW, and (V)PSUBD instructions can operate on either unsigned or signed (two's complement notation) packed integers; however, it does not set bits in the EFLAGS register to indicate overflow and/or a carry. To prevent undetected overflow conditions, software must control the ranges of values upon which it operates.
",
+ "html": "
Performs a SIMD subtract of the packed integers of the source operand (second operand) from the packed integers of the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with wraparound, as described in the following paragraphs.
The (V)PSUBB instruction subtracts packed byte integers. When an individual result is too large or too small to be represented in a byte, the result is wrapped around and the low 8 bits are written to the destination element.
The (V)PSUBW instruction subtracts packed word integers. When an individual result is too large or too small to be represented in a word, the result is wrapped around and the low 16 bits are written to the destination element.
The (V)PSUBD instruction subtracts packed doubleword integers. When an individual result is too large or too small to be represented in a doubleword, the result is wrapped around and the low 32 bits are written to the destination element.
Note that the (V)PSUBB, (V)PSUBW, and (V)PSUBD instructions can operate on either unsigned or signed (two's complement notation) packed integers; however, it does not set bits in the EFLAGS register to indicate overflow and/or a carry. To prevent undetected overflow conditions, software must control the ranges of values upon which it operates.
",
"tooltip": "Performs a SIMD subtract of the packed integers of the source operand (second operand) from the packed integers of the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with wraparound, as described in the following paragraphs.",
"url": "https://www.felixcloutier.com/x86/PSUBB%3APSUBW%3APSUBD.html"
};
@@ -2790,7 +2797,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPSUBSB":
case "VPSUBSW":
return {
- "html": "
Performs a SIMD subtract of the packed signed integers of the source operand (second operand) from the packed signed integers of the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with signed saturation, as described in the following paragraphs.
The (V)PSUBSB instruction subtracts packed signed byte integers. When an individual byte result is beyond the range of a signed byte integer (that is, greater than 7FH or less than 80H), the saturated value of 7FH or 80H, respectively, is written to the destination operand.
The (V)PSUBSW instruction subtracts packed signed word integers. When an individual word result is beyond the range of a signed word integer (that is, greater than 7FFFH or less than 8000H), the saturated value of 7FFFH or 8000H, respectively, is written to the destination operand.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
Legacy SSE version 64-bit operand: The destination operand must be an MMX technology register and the source operand can be either an MMX technology register or a 64-bit memory location.
",
+ "html": "
Performs a SIMD subtract of the packed signed integers of the source operand (second operand) from the packed signed integers of the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with signed saturation, as described in the following paragraphs.
The (V)PSUBSB instruction subtracts packed signed byte integers. When an individual byte result is beyond the range of a signed byte integer (that is, greater than 7FH or less than 80H), the saturated value of 7FH or 80H, respectively, is written to the destination operand.
The (V)PSUBSW instruction subtracts packed signed word integers. When an individual word result is beyond the range of a signed word integer (that is, greater than 7FFFH or less than 8000H), the saturated value of 7FFFH or 8000H, respectively, is written to the destination operand.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
Legacy SSE version 64-bit operand: The destination operand must be an MMX technology register and the source operand can be either an MMX technology register or a 64-bit memory location.
",
"tooltip": "Performs a SIMD subtract of the packed signed integers of the source operand (second operand) from the packed signed integers of the destination operand (first operand), and stores the packed integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with signed saturation, as described in the following paragraphs.",
"url": "https://www.felixcloutier.com/x86/PSUBSB%3APSUBSW.html"
};
@@ -2800,7 +2807,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPSUBUSB":
case "VPSUBUSW":
return {
- "html": "
Performs a SIMD subtract of the packed unsigned integers of the source operand (second operand) from the packed unsigned integers of the destination operand (first operand), and stores the packed unsigned integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with unsigned saturation, as described in the following paragraphs.
These instructions can operate on either 64-bit or 128-bit operands.
The (V)PSUBUSB instruction subtracts packed unsigned byte integers. When an individual byte result is less than zero, the saturated value of 00H is written to the destination operand.
The (V)PSUBUSW instruction subtracts packed unsigned word integers. When an individual word result is less than zero, the saturated value of 0000H is written to the destination operand.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
+ "html": "
Performs a SIMD subtract of the packed unsigned integers of the source operand (second operand) from the packed unsigned integers of the destination operand (first operand), and stores the packed unsigned integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with unsigned saturation, as described in the following paragraphs.
These instructions can operate on either 64-bit or 128-bit operands.
The (V)PSUBUSB instruction subtracts packed unsigned byte integers. When an individual byte result is less than zero, the saturated value of 00H is written to the destination operand.
The (V)PSUBUSW instruction subtracts packed unsigned word integers. When an individual word result is less than zero, the saturated value of 0000H is written to the destination operand.
In 64-bit mode and not encoded with VEX/EVEX, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
"tooltip": "Performs a SIMD subtract of the packed unsigned integers of the source operand (second operand) from the packed unsigned integers of the destination operand (first operand), and stores the packed unsigned integer results in the destination operand. See Figure 9-4 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD operation. Overflow is handled with unsigned saturation, as described in the following paragraphs.",
"url": "https://www.felixcloutier.com/x86/PSUBUSB%3APSUBUSW.html"
};
@@ -2815,8 +2822,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "PTWRITE":
return {
- "html": "
This instruction reads data in the source operand and sends it to the Intel Processor Trace hardware to be encoded in a PTW packet if TriggerEn, ContextEn, FilterEn, and PTWEn are all set to 1. For more details on these values, see Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, Section 32.2.2, \u201cSoftware Trace Instrumentation with PTWRITE\u201d. The size of data is 64-bit if using REX.W in 64-bit mode, otherwise 32-bits of data are copied from the source operand.
Note: The instruction will #UD if prefix 66H is used.
",
- "tooltip": "This instruction reads data in the source operand and sends it to the Intel Processor Trace hardware to be encoded in a PTW packet if TriggerEn, ContextEn, FilterEn, and PTWEn are all set to 1. For more details on these values, see Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, Section 32.2.2, \u201cSoftware Trace Instrumentation with PTWRITE\u201d. The size of data is 64-bit if using REX.W in 64-bit mode, otherwise 32-bits of data are copied from the source operand.",
+ "html": "
This instruction reads data in the source operand and sends it to the Intel Processor Trace hardware to be encoded in a PTW packet if TriggerEn, ContextEn, FilterEn, and PTWEn are all set to 1. For more details on these values, see Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, Section 33.2.2, \u201cSoftware Trace Instrumentation with PTWRITE.\u201d The size of data is 64-bit if using REX.W in 64-bit mode, otherwise 32-bits of data are copied from the source operand.
Note: The instruction will #UD if prefix 66H is used.
",
+ "tooltip": "This instruction reads data in the source operand and sends it to the Intel Processor Trace hardware to be encoded in a PTW packet if TriggerEn, ContextEn, FilterEn, and PTWEn are all set to 1. For more details on these values, see Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, Section 33.2.2, \u201cSoftware Trace Instrumentation with PTWRITE.\u201d The size of data is 64-bit if using REX.W in 64-bit mode, otherwise 32-bits of data are copied from the source operand.",
"url": "https://www.felixcloutier.com/x86/PTWRITE.html"
};
@@ -2858,7 +2865,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "PUSHA":
case "PUSHAD":
return {
- "html": "
Pushes the contents of the general-purpose registers onto the stack. The registers are stored on the stack in the following order: EAX, ECX, EDX, EBX, ESP (original value), EBP, ESI, and EDI (if the current operand-size attribute is 32) and AX, CX, DX, BX, SP (original value), BP, SI, and DI (if the operand-size attribute is 16). These instructions perform the reverse operation of the POPA/POPAD instructions. The value pushed for the ESP or SP register is its value before prior to pushing the first register (see the \u201cOperation\u201d section below).
The PUSHA (push all) and PUSHAD (push all double) mnemonics reference the same opcode. The PUSHA instruction is intended for use when the operand-size attribute is 16 and the PUSHAD instruction for when the operand-size attribute is 32. Some assemblers may force the operand size to 16 when PUSHA is used and to 32 when PUSHAD is used. Others may treat these mnemonics as synonyms (PUSHA/PUSHAD) and use the current setting of the operand-size attribute to determine the size of values to be pushed from the stack, regardless of the mnemonic used.
In the real-address mode, if the ESP or SP register is 1, 3, or 5 when PUSHA/PUSHAD executes: an #SS exception is generated but not delivered (the stack error reported prevents #SS delivery). Next, the processor generates a #DF exception and enters a shutdown state as described in the #DF discussion in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
This instruction executes as described in compatibility mode and legacy mode. It is not valid in 64-bit mode.
",
+ "html": "
Pushes the contents of the general-purpose registers onto the stack. The registers are stored on the stack in the following order: EAX, ECX, EDX, EBX, ESP (original value), EBP, ESI, and EDI (if the current operand-size attribute is 32) and AX, CX, DX, BX, SP (original value), BP, SI, and DI (if the operand-size attribute is 16). These instructions perform the reverse operation of the POPA/POPAD instructions. The value pushed for the ESP or SP register is its value before prior to pushing the first register (see the \u201cOperation\u201d section below).
The PUSHA (push all) and PUSHAD (push all double) mnemonics reference the same opcode. The PUSHA instruction is intended for use when the operand-size attribute is 16 and the PUSHAD instruction for when the operand-size attribute is 32. Some assemblers may force the operand size to 16 when PUSHA is used and to 32 when PUSHAD is used. Others may treat these mnemonics as synonyms (PUSHA/PUSHAD) and use the current setting of the operand-size attribute to determine the size of values to be pushed from the stack, regardless of the mnemonic used.
In the real-address mode, if the ESP or SP register is 1, 3, or 5 when PUSHA/PUSHAD executes: an #SS exception is generated but not delivered (the stack error reported prevents #SS delivery). Next, the processor generates a #DF exception and enters a shutdown state as described in the #DF discussion in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
This instruction executes as described in compatibility mode and legacy mode. It is not valid in 64-bit mode.
",
"tooltip": "Pushes the contents of the general-purpose registers onto the stack. The registers are stored on the stack in the following order: EAX, ECX, EDX, EBX, ESP (original value), EBP, ESI, and EDI (if the current operand-size attribute is 32) and AX, CX, DX, BX, SP (original value), BP, SI, and DI (if the operand-size attribute is 16). These instructions perform the reverse operation of the POPA/POPAD instructions. The value pushed for the ESP or SP register is its value before prior to pushing the first register (see the \u201cOperation\u201d section below).",
"url": "https://www.felixcloutier.com/x86/PUSHA%3APUSHAD.html"
};
@@ -2867,7 +2874,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "PUSHFD":
case "PUSHFQ":
return {
- "html": "
Decrements the stack pointer by 4 (if the current operand-size attribute is 32) and pushes the entire contents of the EFLAGS register onto the stack, or decrements the stack pointer by 2 (if the operand-size attribute is 16) and pushes the lower 16 bits of the EFLAGS register (that is, the FLAGS register) onto the stack. These instructions reverse the operation of the POPF/POPFD instructions.
When copying the entire EFLAGS register to the stack, the VM and RF flags (bits 16 and 17) are not copied; instead, the values for these flags are cleared in the EFLAGS image stored on the stack. See Chapter 3 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information about the EFLAGS register.
The PUSHF (push flags) and PUSHFD (push flags double) mnemonics reference the same opcode. The PUSHF instruction is intended for use when the operand-size attribute is 16 and the PUSHFD instruction for when the operand-size attribute is 32. Some assemblers may force the operand size to 16 when PUSHF is used and to 32 when PUSHFD is used. Others may treat these mnemonics as synonyms (PUSHF/PUSHFD) and use the current setting of the operand-size attribute to determine the size of values to be pushed from the stack, regardless of the mnemonic used.
In 64-bit mode, the instruction\u2019s default operation is to decrement the stack pointer (RSP) by 8 and pushes RFLAGS on the stack. 16-bit operation is supported using the operand size override prefix 66H. 32-bit operand size cannot be encoded in this mode. When copying RFLAGS to the stack, the VM and RF flags (bits 16 and 17) are not copied; instead, values for these flags are cleared in the RFLAGS image stored on the stack.
When operating in virtual-8086 mode (EFLAGS.VM = 1) without the virtual-8086 mode extensions (CR4.VME = 0), the PUSHF/PUSHFD instructions can be used only if IOPL = 3; otherwise, a general-protection exception (#GP) occurs. If the virtual-8086 mode extensions are enabled (CR4.VME = 1), PUSHF (but not PUSHFD) can be executed in virtual-8086 mode with IOPL < 3.
",
+ "html": "
Decrements the stack pointer by 4 (if the current operand-size attribute is 32) and pushes the entire contents of the EFLAGS register onto the stack, or decrements the stack pointer by 2 (if the operand-size attribute is 16) and pushes the lower 16 bits of the EFLAGS register (that is, the FLAGS register) onto the stack. These instructions reverse the operation of the POPF/POPFD instructions.
When copying the entire EFLAGS register to the stack, the VM and RF flags (bits 16 and 17) are not copied; instead, the values for these flags are cleared in the EFLAGS image stored on the stack. See Chapter 3 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information about the EFLAGS register.
The PUSHF (push flags) and PUSHFD (push flags double) mnemonics reference the same opcode. The PUSHF instruction is intended for use when the operand-size attribute is 16 and the PUSHFD instruction for when the operand-size attribute is 32. Some assemblers may force the operand size to 16 when PUSHF is used and to 32 when PUSHFD is used. Others may treat these mnemonics as synonyms (PUSHF/PUSHFD) and use the current setting of the operand-size attribute to determine the size of values to be pushed from the stack, regardless of the mnemonic used.
In 64-bit mode, the instruction\u2019s default operation is to decrement the stack pointer (RSP) by 8 and pushes RFLAGS on the stack. 16-bit operation is supported using the operand size override prefix 66H. 32-bit operand size cannot be encoded in this mode. When copying RFLAGS to the stack, the VM and RF flags (bits 16 and 17) are not copied; instead, values for these flags are cleared in the RFLAGS image stored on the stack.
When operating in virtual-8086 mode (EFLAGS.VM = 1) without the virtual-8086 mode extensions (CR4.VME = 0), the PUSHF/PUSHFD instructions can be used only if IOPL = 3; otherwise, a general-protection exception (#GP) occurs. If the virtual-8086 mode extensions are enabled (CR4.VME = 1), PUSHF (but not PUSHFD) can be executed in virtual-8086 mode with IOPL < 3.
",
"tooltip": "Decrements the stack pointer by 4 (if the current operand-size attribute is 32) and pushes the entire contents of the EFLAGS register onto the stack, or decrements the stack pointer by 2 (if the operand-size attribute is 16) and pushes the lower 16 bits of the EFLAGS register (that is, the FLAGS register) onto the stack. These instructions reverse the operation of the POPF/POPFD instructions.",
"url": "https://www.felixcloutier.com/x86/PUSHF%3APUSHFD%3APUSHFQ.html"
};
@@ -2895,24 +2902,24 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "RCPPS":
case "VRCPPS":
return {
- "html": "
Performs a SIMD computation of the approximate reciprocals of the four packed single-precision floating-point values in the source operand (second operand) stores the packed single-precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single-precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RCPPS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). Tiny results (see Section 4.9.1.5, \u201cNumeric Underflow Exception (#U)\u201d in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1) are always flushed to 0.0, with the sign of the operand. (Input values greater than or equal to |1.11111111110100000000000B\u22172125| are guaranteed to not produce tiny results; input values less than or equal to |1.00000000000110000000001B*2126| are guaranteed to produce tiny results, which are in turn flushed to 0.0; and input values in between this range may or may not produce tiny results, depending on the implementation.) When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Performs a SIMD computation of the approximate reciprocals of the four packed single-precision floating-point values in the source operand (second operand) stores the packed single-precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single-precision floating-point operation.",
+ "html": "
Performs a SIMD computation of the approximate reciprocals of the four packed single precision floating-point values in the source operand (second operand) stores the packed single precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RCPPS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). Tiny results (see Section 4.9.1.5, \u201cNumeric Underflow Exception (#U)\u201d in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1) are always flushed to 0.0, with the sign of the operand. (Input values greater than or equal to |1.11111111110100000000000B\u22172125| are guaranteed to not produce tiny results; input values less than or equal to |1.00000000000110000000001B*2126| are guaranteed to produce tiny results, which are in turn flushed to 0.0; and input values in between this range may or may not produce tiny results, depending on the implementation.) When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Performs a SIMD computation of the approximate reciprocals of the four packed single precision floating-point values in the source operand (second operand) stores the packed single precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single precision floating-point operation.",
"url": "https://www.felixcloutier.com/x86/RCPPS.html"
};
case "RCPSS":
case "VRCPSS":
return {
- "html": "
Computes of an approximate reciprocal of the low single-precision floating-point value in the source operand (second operand) and stores the single-precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single-precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RCPSS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). Tiny results (see Section 4.9.1.5, \u201cNumeric Underflow Exception (#U)\u201d in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1) are always flushed to 0.0, with the sign of the operand. (Input values greater than or equal to |1.11111111110100000000000B\u22172125| are guaranteed to not produce tiny results; input values less than or equal to |1.00000000000110000000001B*2126| are guaranteed to produce tiny results, which are in turn flushed to 0.0; and input values in between this range may or may not produce tiny results, depending on the implementation.) When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Computes of an approximate reciprocal of the low single-precision floating-point value in the source operand (second operand) and stores the single-precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single-precision floating-point operation.",
+ "html": "
Computes of an approximate reciprocal of the low single precision floating-point value in the source operand (second operand) and stores the single precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RCPSS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). Tiny results (see Section 4.9.1.5, \u201cNumeric Underflow Exception (#U)\u201d in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1) are always flushed to 0.0, with the sign of the operand. (Input values greater than or equal to |1.11111111110100000000000B\u22172125| are guaranteed to not produce tiny results; input values less than or equal to |1.00000000000110000000001B*2126| are guaranteed to produce tiny results, which are in turn flushed to 0.0; and input values in between this range may or may not produce tiny results, depending on the implementation.) When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Computes of an approximate reciprocal of the low single precision floating-point value in the source operand (second operand) and stores the single precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single precision floating-point operation.",
"url": "https://www.felixcloutier.com/x86/RCPSS.html"
};
case "RDFSBASE":
case "RDGSBASE":
return {
- "html": "
Loads the general-purpose register indicated by the modR/M:r/m field with the FS or GS segment base address.
The destination operand may be either a 32-bit or a 64-bit general-purpose register. The REX.W prefix indicates the operand size is 64 bits. If no REX.W prefix is used, the operand size is 32 bits; the upper 32 bits of the source base address (for FS or GS) are ignored and upper 32 bits of the destination register are cleared.
This instruction is supported only in 64-bit mode.
",
- "tooltip": "Loads the general-purpose register indicated by the modR/M:r/m field with the FS or GS segment base address.",
+ "html": "
Loads the general-purpose register indicated by the ModR/M:r/m field with the FS or GS segment base address.
The destination operand may be either a 32-bit or a 64-bit general-purpose register. The REX.W prefix indicates the operand size is 64 bits. If no REX.W prefix is used, the operand size is 32 bits; the upper 32 bits of the source base address (for FS or GS) are ignored and upper 32 bits of the destination register are cleared.
This instruction is supported only in 64-bit mode.
",
+ "tooltip": "Loads the general-purpose register indicated by the ModR/M:r/m field with the FS or GS segment base address.",
"url": "https://www.felixcloutier.com/x86/RDFSBASE%3ARDGSBASE.html"
};
@@ -2932,21 +2939,21 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "RDPMC":
return {
- "html": "
Reads the contents of the performance monitoring counter (PMC) specified in ECX register into registers EDX:EAX. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The EDX register is loaded with the high-order 32 bits of the PMC and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.) If fewer than 64 bits are implemented in the PMC being read, unimplemented bits returned to EDX:EAX will have value zero.
The width of PMCs on processors supporting architectural performance monitoring (CPUID.0AH:EAX[7:0] =\u0338 0) are reported by CPUID.0AH:EAX[23:16]. On processors that do not support architectural performance monitoring (CPUID.0AH:EAX[7:0]=0), the width of general-purpose performance PMCs is 40 bits, while the widths of special-purpose PMCs are implementation specific.
Use of ECX to specify a PMC depends on whether the processor supports architectural performance monitoring:
Specifying an unsupported PMC encoding will cause a general protection exception #GP(0). For PMC details see Chapter 19, \u201cPerformance Monitoring\u201d, in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3B.
When in protected or virtual 8086 mode, the Performance-monitoring Counters Enabled (PCE) flag in register CR4 restricts the use of the RDPMC instruction. When the PCE flag is set, the RDPMC instruction can be executed at any privilege level; when the flag is clear, the instruction can only be executed at privilege level 0. (When in real-address mode, the RDPMC instruction is always enabled.) The PMCs can also be read with the RDMSR instruction, when executing at privilege level 0.
",
+ "html": "
Reads the contents of the performance monitoring counter (PMC) specified in ECX register into registers EDX:EAX. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The EDX register is loaded with the high-order 32 bits of the PMC and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.) If fewer than 64 bits are implemented in the PMC being read, unimplemented bits returned to EDX:EAX will have value zero.
The width of PMCs on processors supporting architectural performance monitoring (CPUID.0AH:EAX[7:0] =\u0338 0) are reported by CPUID.0AH:EAX[23:16]. On processors that do not support architectural performance monitoring (CPUID.0AH:EAX[7:0]=0), the width of general-purpose performance PMCs is 40 bits, while the widths of special-purpose PMCs are implementation specific.
Use of ECX to specify a PMC depends on whether the processor supports architectural performance monitoring:
Specifying an unsupported PMC encoding will cause a general protection exception #GP(0). For PMC details see Chapter 20, \u201cPerformance Monitoring,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3B.
When in protected or virtual 8086 mode, the Performance-monitoring Counters Enabled (PCE) flag in register CR4 restricts the use of the RDPMC instruction. When the PCE flag is set, the RDPMC instruction can be executed at any privilege level; when the flag is clear, the instruction can only be executed at privilege level 0. (When in real-address mode, the RDPMC instruction is always enabled.) The PMCs can also be read with the RDMSR instruction, when executing at privilege level 0.
",
"tooltip": "Reads the contents of the performance monitoring counter (PMC) specified in ECX register into registers EDX:EAX. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The EDX register is loaded with the high-order 32 bits of the PMC and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.) If fewer than 64 bits are implemented in the PMC being read, unimplemented bits returned to EDX:EAX will have value zero.",
"url": "https://www.felixcloutier.com/x86/RDPMC.html"
};
case "RDTSC":
return {
- "html": "
Reads the current value of the processor\u2019s time-stamp counter (a 64-bit MSR) into the EDX:EAX registers. The EDX register is loaded with the high-order 32 bits of the MSR and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.)
The processor monotonically increments the time-stamp counter MSR every clock cycle and resets it to 0 whenever the processor is reset. See \u201cTime Stamp Counter\u201d in Chapter 17 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3B, for specific details of the time stamp counter behavior.
The time stamp disable (TSD) flag in register CR4 restricts the use of the RDTSC instruction as follows. When the flag is clear, the RDTSC instruction can be executed at any privilege level; when the flag is set, the instruction can only be executed at privilege level 0.
The time-stamp counter can also be read with the RDMSR instruction, when executing at privilege level 0.
The RDTSC instruction is not a serializing instruction. It does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed. The following items may guide software seeking to order executions of RDTSC:
",
+ "html": "
Reads the current value of the processor\u2019s time-stamp counter (a 64-bit MSR) into the EDX:EAX registers. The EDX register is loaded with the high-order 32 bits of the MSR and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.)
The processor monotonically increments the time-stamp counter MSR every clock cycle and resets it to 0 whenever the processor is reset. See \u201cTime Stamp Counter\u201d in Chapter 18 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3B, for specific details of the time stamp counter behavior.
The time stamp disable (TSD) flag in register CR4 restricts the use of the RDTSC instruction as follows. When the flag is clear, the RDTSC instruction can be executed at any privilege level; when the flag is set, the instruction can only be executed at privilege level 0.
The time-stamp counter can also be read with the RDMSR instruction, when executing at privilege level 0.
The RDTSC instruction is not a serializing instruction. It does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed. The following items may guide software seeking to order executions of RDTSC:
",
"tooltip": "Reads the current value of the processor\u2019s time-stamp counter (a 64-bit MSR) into the EDX:EAX registers. The EDX register is loaded with the high-order 32 bits of the MSR and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.)",
"url": "https://www.felixcloutier.com/x86/RDTSC.html"
};
case "RDTSCP":
return {
- "html": "
Reads the current value of the processor\u2019s time-stamp counter (a 64-bit MSR) into the EDX:EAX registers and also reads the value of the IA32_TSC_AUX MSR (address C0000103H) into the ECX register. The EDX register is loaded with the high-order 32 bits of the IA32_TSC MSR; the EAX register is loaded with the low-order 32 bits of the IA32_TSC MSR; and the ECX register is loaded with the low-order 32-bits of IA32_TSC_AUX MSR. On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX, RDX, and RCX are cleared.
The processor monotonically increments the time-stamp counter MSR every clock cycle and resets it to 0 whenever the processor is reset. See \u201cTime Stamp Counter\u201d in Chapter 17 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3B, for specific details of the time stamp counter behavior.
The time stamp disable (TSD) flag in register CR4 restricts the use of the RDTSCP instruction as follows. When the flag is clear, the RDTSCP instruction can be executed at any privilege level; when the flag is set, the instruction can only be executed at privilege level 0.
The RDTSCP instruction is not a serializing instruction, but it does wait until all previous instructions have executed and all previous loads are globally visible.1 But it does not wait for previous stores to be globally visible, and subsequent instructions may begin execution before the read operation is performed. The following items may guide software seeking to order executions of RDTSCP:
See \u201cChanges to Instruction Behavior in VMX Non-Root Operation\u201d in Chapter 25 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about the behavior of this instruction in VMX non-root operation.
",
+ "html": "
Reads the current value of the processor\u2019s time-stamp counter (a 64-bit MSR) into the EDX:EAX registers and also reads the value of the IA32_TSC_AUX MSR (address C0000103H) into the ECX register. The EDX register is loaded with the high-order 32 bits of the IA32_TSC MSR; the EAX register is loaded with the low-order 32 bits of the IA32_TSC MSR; and the ECX register is loaded with the low-order 32-bits of IA32_TSC_AUX MSR. On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX, RDX, and RCX are cleared.
The processor monotonically increments the time-stamp counter MSR every clock cycle and resets it to 0 whenever the processor is reset. See \u201cTime Stamp Counter\u201d in Chapter 18 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3B, for specific details of the time stamp counter behavior.
The time stamp disable (TSD) flag in register CR4 restricts the use of the RDTSCP instruction as follows. When the flag is clear, the RDTSCP instruction can be executed at any privilege level; when the flag is set, the instruction can only be executed at privilege level 0.
The RDTSCP instruction is not a serializing instruction, but it does wait until all previous instructions have executed and all previous loads are globally visible.1 But it does not wait for previous stores to be globally visible, and subsequent instructions may begin execution before the read operation is performed. The following items may guide software seeking to order executions of RDTSCP:
See \u201cChanges to Instruction Behavior in VMX Non-Root Operation\u201d in Chapter 26 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about the behavior of this instruction in VMX non-root operation.
",
"tooltip": "Reads the current value of the processor\u2019s time-stamp counter (a 64-bit MSR) into the EDX:EAX registers and also reads the value of the IA32_TSC_AUX MSR (address C0000103H) into the ECX register. The EDX register is loaded with the high-order 32 bits of the IA32_TSC MSR; the EAX register is loaded with the low-order 32 bits of the IA32_TSC MSR; and the ECX register is loaded with the low-order 32-bits of IA32_TSC_AUX MSR. On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX, RDX, and RCX are cleared.",
"url": "https://www.felixcloutier.com/x86/RDTSCP.html"
};
@@ -2955,14 +2962,14 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "REPE":
case "REPNE":
return {
- "html": "
Repeats a string instruction the number of times specified in the count register or until the indicated condition of the ZF flag is no longer met. The REP (repeat), REPE (repeat while equal), REPNE (repeat while not equal), REPZ (repeat while zero), and REPNZ (repeat while not zero) mnemonics are prefixes that can be added to one of the string instructions. The REP prefix can be added to the INS, OUTS, MOVS, LODS, and STOS instructions, and the REPE, REPNE, REPZ, and REPNZ prefixes can be added to the CMPS and SCAS instructions. (The REPZ and REPNZ prefixes are synonymous forms of the REPE and REPNE prefixes, respectively.) The F3H prefix is defined for the following instructions and undefined for the rest:
The REP prefixes apply only to one string instruction at a time. To repeat a block of instructions, use the LOOP instruction or another looping construct. All of these repeat prefixes cause the associated instruction to be repeated until the count in register is decremented to 0. See Table 4-22.
The REPE, REPNE, REPZ, and REPNZ prefixes also check the state of the ZF flag after each iteration and terminate the repeat loop if the ZF flag is not in the specified state. When both termination conditions are tested, the cause of a repeat termination can be determined either by testing the count register with a JECXZ instruction or by testing the ZF flag (with a JZ, JNZ, or JNE instruction).
When the REPE/REPZ and REPNE/REPNZ prefixes are used, the ZF flag does not require initialization because both the CMPS and SCAS instructions affect the ZF flag according to the results of the comparisons they make.
A repeating string operation can be suspended by an exception or interrupt. When this happens, the state of the registers is preserved to allow the string operation to be resumed upon a return from the exception or interrupt handler. The source and destination registers point to the next string elements to be operated on, the EIP register points to the string instruction, and the ECX register has the value it held following the last successful iteration of the instruction. This mechanism allows long string operations to proceed without affecting the interrupt response time of the system.
",
+ "html": "
Repeats a string instruction the number of times specified in the count register or until the indicated condition of the ZF flag is no longer met. The REP (repeat), REPE (repeat while equal), REPNE (repeat while not equal), REPZ (repeat while zero), and REPNZ (repeat while not zero) mnemonics are prefixes that can be added to one of the string instructions. The REP prefix can be added to the INS, OUTS, MOVS, LODS, and STOS instructions, and the REPE, REPNE, REPZ, and REPNZ prefixes can be added to the CMPS and SCAS instructions. (The REPZ and REPNZ prefixes are synonymous forms of the REPE and REPNE prefixes, respectively.) The F3H prefix is defined for the following instructions and undefined for the rest:
The REP prefixes apply only to one string instruction at a time. To repeat a block of instructions, use the LOOP instruction or another looping construct. All of these repeat prefixes cause the associated instruction to be repeated until the count in register is decremented to 0. See Table 4-17.
The REPE, REPNE, REPZ, and REPNZ prefixes also check the state of the ZF flag after each iteration and terminate the repeat loop if the ZF flag is not in the specified state. When both termination conditions are tested, the cause of a repeat termination can be determined either by testing the count register with a JECXZ instruction or by testing the ZF flag (with a JZ, JNZ, or JNE instruction).
When the REPE/REPZ and REPNE/REPNZ prefixes are used, the ZF flag does not require initialization because both the CMPS and SCAS instructions affect the ZF flag according to the results of the comparisons they make.
A repeating string operation can be suspended by an exception or interrupt. When this happens, the state of the registers is preserved to allow the string operation to be resumed upon a return from the exception or interrupt handler. The source and destination registers point to the next string elements to be operated on, the EIP register points to the string instruction, and the ECX register has the value it held following the last successful iteration of the instruction. This mechanism allows long string operations to proceed without affecting the interrupt response time of the system.
",
"tooltip": "Repeats a string instruction the number of times specified in the count register or until the indicated condition of the ZF flag is no longer met. The REP (repeat), REPE (repeat while equal), REPNE (repeat while not equal), REPZ (repeat while zero), and REPNZ (repeat while not zero) mnemonics are prefixes that can be added to one of the string instructions. The REP prefix can be added to the INS, OUTS, MOVS, LODS, and STOS instructions, and the REPE, REPNE, REPZ, and REPNZ prefixes can be added to the CMPS and SCAS instructions. (The REPZ and REPNZ prefixes are synonymous forms of the REPE and REPNE prefixes, respectively.) The F3H prefix is defined for the following instructions and undefined for the rest",
"url": "https://www.felixcloutier.com/x86/REP%3AREPE%3AREPZ%3AREPNE%3AREPNZ.html"
};
case "RET":
return {
- "html": "
Transfers program control to a return address located on the top of the stack. The address is usually placed on the stack by a CALL instruction, and the return is made to the instruction that follows the CALL instruction.
The optional source operand specifies the number of stack bytes to be released after the return address is popped; the default is none. This operand can be used to release parameters from the stack that were passed to the called procedure and are no longer needed. It must be used when the CALL instruction used to switch to a new procedure uses a call gate with a non-zero word count to access the new procedure. Here, the source operand for the RET instruction must specify the same number of bytes as is specified in the word count field of the call gate.
The RET instruction can be used to execute three different types of returns:
The inter-privilege-level return type can only be executed in protected mode. See the section titled \u201cCalling Procedures Using Call and RET\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for detailed information on near, far, and inter-privilege-level returns.
When executing a near return, the processor pops the return instruction pointer (offset) from the top of the stack into the EIP register and begins program execution at the new instruction pointer. The CS register is unchanged.
",
+ "html": "
Transfers program control to a return address located on the top of the stack. The address is usually placed on the stack by a CALL instruction, and the return is made to the instruction that follows the CALL instruction.
The optional source operand specifies the number of stack bytes to be released after the return address is popped; the default is none. This operand can be used to release parameters from the stack that were passed to the called procedure and are no longer needed. It must be used when the CALL instruction used to switch to a new procedure uses a call gate with a non-zero word count to access the new procedure. Here, the source operand for the RET instruction must specify the same number of bytes as is specified in the word count field of the call gate.
The RET instruction can be used to execute three different types of returns:
The inter-privilege-level return type can only be executed in protected mode. See the section titled \u201cCalling Procedures Using Call and RET\u201d in Chapter 6 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for detailed information on near, far, and inter-privilege-level returns.
When executing a near return, the processor pops the return instruction pointer (offset) from the top of the stack into the EIP register and begins program execution at the new instruction pointer. The CS register is unchanged.
",
"tooltip": "Transfers program control to a return address located on the top of the stack. The address is usually placed on the stack by a CALL instruction, and the return is made to the instruction that follows the CALL instruction.",
"url": "https://www.felixcloutier.com/x86/RET.html"
};
@@ -2977,38 +2984,38 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "ROUNDPD":
case "VROUNDPD":
return {
- "html": "
Round the 2 double-precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a double-precision floating-point value.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-23 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
",
- "tooltip": "Round the 2 double-precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a double-precision floating-point value.",
+ "html": "
Round the 2 double precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a double precision floating-point value.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-18 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
",
+ "tooltip": "Round the 2 double precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a double precision floating-point value.",
"url": "https://www.felixcloutier.com/x86/ROUNDPD.html"
};
case "ROUNDPS":
case "VROUNDPS":
return {
- "html": "
Round the 4 single-precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a single-precision floating-point value.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-23 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
",
- "tooltip": "Round the 4 single-precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a single-precision floating-point value.",
+ "html": "
Round the 4 single precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a single precision floating-point value.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-18 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding YMM register destination are unmodified.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding YMM register destination are zeroed.
",
+ "tooltip": "Round the 4 single precision floating-point values in the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the results in the destination operand (first operand). The rounding process rounds each input floating-point value to an integer value and returns the integer result as a single precision floating-point value.",
"url": "https://www.felixcloutier.com/x86/ROUNDPS.html"
};
case "ROUNDSD":
case "VROUNDSD":
return {
- "html": "
Round the DP FP value in the lower qword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a double-precision floating-point input to an integer value and returns the integer result as a double precision floating-point value in the lowest position. The upper double precision floating-point value in the destination is retained.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-23 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:64) of the corresponding YMM destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination YMM register are zeroed.
",
- "tooltip": "Round the DP FP value in the lower qword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a double-precision floating-point input to an integer value and returns the integer result as a double precision floating-point value in the lowest position. The upper double precision floating-point value in the destination is retained.",
+ "html": "
Round the double precision floating-point value in the lower qword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a double precision floating-point input to an integer value and returns the integer result as a double precision floating-point value in the lowest position. The upper double precision floating-point value in the destination is retained.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-18 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:64) of the corresponding YMM destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination YMM register are zeroed.
",
+ "tooltip": "Round the double precision floating-point value in the lower qword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a double precision floating-point input to an integer value and returns the integer result as a double precision floating-point value in the lowest position. The upper double precision floating-point value in the destination is retained.",
"url": "https://www.felixcloutier.com/x86/ROUNDSD.html"
};
case "ROUNDSS":
case "VROUNDSS":
return {
- "html": "
Round the single-precision floating-point value in the lowest dword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a single-precision floating-point input to an integer value and returns the result as a single-precision floating-point value in the lowest position. The upper three single-precision floating-point values in the destination are retained.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-23 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination YMM register are zeroed.
",
- "tooltip": "Round the single-precision floating-point value in the lowest dword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a single-precision floating-point input to an integer value and returns the result as a single-precision floating-point value in the lowest position. The upper three single-precision floating-point values in the destination are retained.",
+ "html": "
Round the single precision floating-point value in the lowest dword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a single precision floating-point input to an integer value and returns the result as a single precision floating-point value in the lowest position. The upper three single precision floating-point values in the destination are retained.
The immediate operand specifies control fields for the rounding operation, three bit fields are defined and shown in Figure 4-24. Bit 3 of the immediate byte controls processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Table 4-18 lists the encoded values for rounding-mode field).
The Precision Floating-Point Exception is signaled according to the immediate operand. If any source operand is an SNaN then it will be converted to a QNaN. If DAZ is set to \u20181 then denormals will be converted to zero before rounding.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination YMM register are zeroed.
",
+ "tooltip": "Round the single precision floating-point value in the lowest dword of the source operand (second operand) using the rounding mode specified in the immediate operand (third operand) and place the result in the destination operand (first operand). The rounding process rounds a single precision floating-point input to an integer value and returns the result as a single precision floating-point value in the lowest position. The upper three single precision floating-point values in the destination are retained.",
"url": "https://www.felixcloutier.com/x86/ROUNDSS.html"
};
case "RSM":
return {
- "html": "
Returns program control from system management mode (SMM) to the application program or operating-system procedure that was interrupted when the processor received an SMM interrupt. The processor\u2019s state is restored from the dump created upon entering SMM. If the processor detects invalid state information during state restoration, it enters the shutdown state. The following invalid information can cause a shutdown:
The contents of the model-specific registers are not affected by a return from SMM.
The SMM state map used by RSM supports resuming processor context for non-64-bit modes and 64-bit mode.
See Chapter 31, \u201cSystem Management Mode,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about SMM and the behavior of the RSM instruction.
",
+ "html": "
Returns program control from system management mode (SMM) to the application program or operating-system procedure that was interrupted when the processor received an SMM interrupt. The processor\u2019s state is restored from the dump created upon entering SMM. If the processor detects invalid state information during state restoration, it enters the shutdown state. The following invalid information can cause a shutdown:
The contents of the model-specific registers are not affected by a return from SMM.
The SMM state map used by RSM supports resuming processor context for non-64-bit modes and 64-bit mode.
See Chapter 32, \u201cSystem Management Mode,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about SMM and the behavior of the RSM instruction.
",
"tooltip": "Returns program control from system management mode (SMM) to the application program or operating-system procedure that was interrupted when the processor received an SMM interrupt. The processor\u2019s state is restored from the dump created upon entering SMM. If the processor detects invalid state information during state restoration, it enters the shutdown state. The following invalid information can cause a shutdown",
"url": "https://www.felixcloutier.com/x86/RSM.html"
};
@@ -3016,16 +3023,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "RSQRTPS":
case "VRSQRTPS":
return {
- "html": "
Performs a SIMD computation of the approximate reciprocals of the square roots of the four packed single-precision floating-point values in the source operand (second operand) and stores the packed single-precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single-precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RSQRTPS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). When a source value is a negative value (other than \u22120.0), a floating-point indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Performs a SIMD computation of the approximate reciprocals of the square roots of the four packed single-precision floating-point values in the source operand (second operand) and stores the packed single-precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single-precision floating-point operation.",
+ "html": "
Performs a SIMD computation of the approximate reciprocals of the square roots of the four packed single precision floating-point values in the source operand (second operand) and stores the packed single precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RSQRTPS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). When a source value is a negative value (other than \u22120.0), a floating-point indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Performs a SIMD computation of the approximate reciprocals of the square roots of the four packed single precision floating-point values in the source operand (second operand) and stores the packed single precision floating-point results in the destination operand. The source operand can be an XMM register or a 128-bit memory location. The destination operand is an XMM register. See Figure 10-5 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a SIMD single precision floating-point operation.",
"url": "https://www.felixcloutier.com/x86/RSQRTPS.html"
};
case "RSQRTSS":
case "VRSQRTSS":
return {
- "html": "
Computes an approximate reciprocal of the square root of the low single-precision floating-point value in the source operand (second operand) stores the single-precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single-precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RSQRTSS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). When a source value is a negative value (other than \u22120.0), a floating-point indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
- "tooltip": "Computes an approximate reciprocal of the square root of the low single-precision floating-point value in the source operand (second operand) stores the single-precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single-precision floating-point operation.",
+ "html": "
Computes an approximate reciprocal of the square root of the low single precision floating-point value in the source operand (second operand) stores the single precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single precision floating-point operation.
The relative error for this approximation is:
|Relative Error| \u2264 1.5 \u2217 2\u221212
The RSQRTSS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e of the sign of the source value is returned. A denormal source value is treated as a 0.0 (of the same sign). When a source value is a negative value (other than \u22120.0), a floating-point indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
In 64-bit mode, using a REX prefix in the form of REX.R permits this instruction to access additional registers (XMM8-XMM15).
",
+ "tooltip": "Computes an approximate reciprocal of the square root of the low single precision floating-point value in the source operand (second operand) stores the single precision floating-point result in the destination operand. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register. The three high-order doublewords of the destination operand remain unchanged. See Figure 10-6 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for an illustration of a scalar single precision floating-point operation.",
"url": "https://www.felixcloutier.com/x86/RSQRTSS.html"
};
@@ -3041,7 +3048,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SHL":
case "SHR":
return {
- "html": "
Shifts the bits in the first operand (destination operand) to the left or right by the number of bits specified in the second operand (count operand). Bits shifted beyond the destination operand boundary are first shifted into the CF flag, then discarded. At the end of the shift operation, the CF flag contains the last bit shifted out of the destination operand.
The destination operand can be a register or a memory location. The count operand can be an immediate value or the CL register. The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used). A special opcode encoding is provided for a count of 1.
The shift arithmetic left (SAL) and shift logical left (SHL) instructions perform the same operation; they shift the bits in the destination operand to the left (toward more significant bit locations). For each shift count, the most significant bit of the destination operand is shifted into the CF flag, and the least significant bit is cleared (see Figure 7-7 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1).
The shift arithmetic right (SAR) and shift logical right (SHR) instructions shift the bits of the destination operand to the right (toward less significant bit locations). For each shift count, the least significant bit of the destination operand is shifted into the CF flag, and the most significant bit is either set or cleared depending on the instruction type. The SHR instruction clears the most significant bit (see Figure 7-8 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1); the SAR instruction sets or clears the most significant bit to correspond to the sign (most significant bit) of the original value in the destination operand. In effect, the SAR instruction fills the empty bit position\u2019s shifted value with the sign of the unshifted value (see Figure 7-9 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1).
The SAR and SHR instructions can be used to perform signed or unsigned division, respectively, of the destination operand by powers of 2. For example, using the SAR instruction to shift a signed integer 1 bit to the right divides the value by 2.
",
+ "html": "
Shifts the bits in the first operand (destination operand) to the left or right by the number of bits specified in the second operand (count operand). Bits shifted beyond the destination operand boundary are first shifted into the CF flag, then discarded. At the end of the shift operation, the CF flag contains the last bit shifted out of the destination operand.
The destination operand can be a register or a memory location. The count operand can be an immediate value or the CL register. The count is masked to 5 bits (or 6 bits with a 64-bit operand). The count range is limited to 0 to 31 (or 63 with a 64-bit operand). A special opcode encoding is provided for a count of 1.
The shift arithmetic left (SAL) and shift logical left (SHL) instructions perform the same operation; they shift the bits in the destination operand to the left (toward more significant bit locations). For each shift count, the most significant bit of the destination operand is shifted into the CF flag, and the least significant bit is cleared (see Figure 7-7 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1).
The shift arithmetic right (SAR) and shift logical right (SHR) instructions shift the bits of the destination operand to the right (toward less significant bit locations). For each shift count, the least significant bit of the destination operand is shifted into the CF flag, and the most significant bit is either set or cleared depending on the instruction type. The SHR instruction clears the most significant bit (see Figure 7-8 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1); the SAR instruction sets or clears the most significant bit to correspond to the sign (most significant bit) of the original value in the destination operand. In effect, the SAR instruction fills the empty bit position\u2019s shifted value with the sign of the unshifted value (see Figure 7-9 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1).
The SAR and SHR instructions can be used to perform signed or unsigned division, respectively, of the destination operand by powers of 2. For example, using the SAR instruction to shift a signed integer 1 bit to the right divides the value by 2.
",
"tooltip": "Shifts the bits in the first operand (destination operand) to the left or right by the number of bits specified in the second operand (count operand). Bits shifted beyond the destination operand boundary are first shifted into the CF flag, then discarded. At the end of the shift operation, the CF flag contains the last bit shifted out of the destination operand.",
"url": "https://www.felixcloutier.com/x86/SAL%3ASAR%3ASHL%3ASHR.html"
};
@@ -3057,8 +3064,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SBB":
return {
- "html": "
Adds the source operand (second operand) and the carry (CF) flag, and subtracts the result from the destination operand (first operand). The result of the subtraction is stored in the destination operand. The destination operand can be a register or a memory location; the source operand can be an immediate, a register, or a memory location. (However, two memory operands cannot be used in one instruction.) The state of the CF flag represents a borrow from a previous subtraction.
When an immediate value is used as an operand, it is sign-extended to the length of the destination operand format.
The SBB instruction does not distinguish between signed or unsigned operands. Instead, the processor evaluates the result for both data types and sets the OF and CF flags to indicate a borrow in the signed or unsigned result, respectively. The SF flag indicates the sign of the signed result.
The SBB instruction is usually executed as part of a multibyte or multiword subtraction in which a SUB instruction is followed by a SBB instruction.
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.
",
- "tooltip": "Adds the source operand (second operand) and the carry (CF) flag, and subtracts the result from the destination operand (first operand). The result of the subtraction is stored in the destination operand. The destination operand can be a register or a memory location; the source operand can be an immediate, a register, or a memory location. (However, two memory operands cannot be used in one instruction.) The state of the CF flag represents a borrow from a previous subtraction.",
+ "html": "
Adds the source operand (second operand) and the carry (CF) flag, and subtracts the result from the destination operand (first operand). The result of the subtraction is stored in the destination operand. The destination operand can be a register or a memory location; the source operand can be an immediate, a register, or a memory location.
(However, two memory operands cannot be used in one instruction.) The state of the CF flag represents a borrow from a previous subtraction.
When an immediate value is used as an operand, it is sign-extended to the length of the destination operand format.
The SBB instruction does not distinguish between signed or unsigned operands. Instead, the processor evaluates the result for both data types and sets the OF and CF flags to indicate a borrow in the signed or unsigned result, respectively. The SF flag indicates the sign of the signed result.
The SBB instruction is usually executed as part of a multibyte or multiword subtraction in which a SUB instruction is followed by a SBB instruction.
",
+ "tooltip": "Adds the source operand (second operand) and the carry (CF) flag, and subtracts the result from the destination operand (first operand). The result of the subtraction is stored in the destination operand. The destination operand can be a register or a memory location; the source operand can be an immediate, a register, or a memory location.",
"url": "https://www.felixcloutier.com/x86/SBB.html"
};
@@ -3068,15 +3075,22 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SCASQ":
case "SCASW":
return {
- "html": "
In non-64-bit modes and in default 64-bit mode: this instruction compares a byte, word, doubleword or quadword specified using a memory operand with the value in AL, AX, or EAX. It then sets status flags in EFLAGS recording the results. The memory operand address is read from ES:(E)DI register (depending on the address-size attribute of the instruction and the current operational mode). Note that ES cannot be overridden with a segment override prefix.
At the assembly-code level, two forms of this instruction are allowed. The explicit-operand form and the no-operands form. The explicit-operand form (specified using the SCAS mnemonic) allows a memory operand to be specified explicitly. The memory operand must be a symbol that indicates the size and location of the operand value. The register operand is then automatically selected to match the size of the memory operand (AL register for byte comparisons, AX for word comparisons, EAX for doubleword comparisons). The explicit-operand form is provided to allow documentation. Note that the documentation provided by this form can be misleading. That is, the memory operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword) but it does not have to specify the correct location. The location is always specified by ES:(E)DI.
The no-operands form of the instruction uses a short form of SCAS. Again, ES:(E)DI is assumed to be the memory operand and AL, AX, or EAX is assumed to be the register operand. The size of operands is selected by the mnemonic: SCASB (byte comparison), SCASW (word comparison), or SCASD (doubleword comparison).
After the comparison, the (E)DI register is incremented or decremented automatically according to the setting of the DF flag in the EFLAGS register. If the DF flag is 0, the (E)DI register is incremented; if the DF flag is 1, the (E)DI register is decremented. The register is incremented or decremented by 1 for byte operations, by 2 for word operations, and by 4 for doubleword operations.
SCAS, SCASB, SCASW, SCASD, and SCASQ can be preceded by the REP prefix for block comparisons of ECX bytes, words, doublewords, or quadwords. Often, however, these instructions will be used in a LOOP construct that takes
",
+ "html": "
In non-64-bit modes and in default 64-bit mode: this instruction compares a byte, word, doubleword or quadword specified using a memory operand with the value in AL, AX, or EAX. It then sets status flags in EFLAGS recording the results. The memory operand address is read from ES:(E)DI register (depending on the address-size attribute of the instruction and the current operational mode). Note that ES cannot be overridden with a segment override prefix.
At the assembly-code level, two forms of this instruction are allowed. The explicit-operand form and the no-operands form. The explicit-operand form (specified using the SCAS mnemonic) allows a memory operand to be specified explicitly. The memory operand must be a symbol that indicates the size and location of the operand value. The register operand is then automatically selected to match the size of the memory operand (AL register for byte comparisons, AX for word comparisons, EAX for doubleword comparisons). The explicit-operand form is provided to allow documentation. Note that the documentation provided by this form can be misleading. That is, the memory operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword) but it does not have to specify the correct location. The location is always specified by ES:(E)DI.
The no-operands form of the instruction uses a short form of SCAS. Again, ES:(E)DI is assumed to be the memory operand and AL, AX, or EAX is assumed to be the register operand. The size of operands is selected by the mnemonic: SCASB (byte comparison), SCASW (word comparison), or SCASD (doubleword comparison).
After the comparison, the (E)DI register is incremented or decremented automatically according to the setting of the DF flag in the EFLAGS register. If the DF flag is 0, the (E)DI register is incremented; if the DF flag is 1, the (E)DI register is decremented. The register is incremented or decremented by 1 for byte operations, by 2 for word operations, and by 4 for doubleword operations.
SCAS, SCASB, SCASW, SCASD, and SCASQ can be preceded by the REP prefix for block comparisons of ECX bytes, words, doublewords, or quadwords. Often, however, these instructions will be used in a LOOP construct that takes some action based on the setting of status flags. See \u201cREP/REPE/REPZ /REPNE/REPNZ\u2014Repeat String Operation Prefix\u201d in this chapter for a description of the REP prefix.
",
"tooltip": "In non-64-bit modes and in default 64-bit mode: this instruction compares a byte, word, doubleword or quadword specified using a memory operand with the value in AL, AX, or EAX. It then sets status flags in EFLAGS recording the results. The memory operand address is read from ES:(E)DI register (depending on the address-size attribute of the instruction and the current operational mode). Note that ES cannot be overridden with a segment override prefix.",
"url": "https://www.felixcloutier.com/x86/SCAS%3ASCASB%3ASCASW%3ASCASD.html"
};
+ case "SENDUIPI":
+ return {
+ "html": "
The SENDUIPI instruction sends the user interprocessor interrupt (IPI) indicated by its register operand. (The operand always has 64 bits; operand-size overrides such as the prefix 66 are ignored.)
SENDUIPI uses a data structure called the user-interrupt target table (UITT). This table is located at the linear address UITTADDR (in the IA32_UINTR_TT MSR); it comprises UITTSZ+1 16-byte entries, where UITTSZ = IA32_UINT_MISC[31:0]. SENDUIPI uses the UITT entry (UITTE) indexed by the instruction's register operand. Each UITTE has the following format:
Each UPID has the following format (fields and bits not referenced are reserved):
Although SENDUIPI may be executed at any privilege level, all of the instruction\u2019s memory accesses (to a UITTE and a UPID) are performed with supervisor privilege.
SENDUIPI sends a user interrupt by posting a user interrupt with vector V in the UPID referenced by UPIDADDR and then sending, as an ordinary IPI, any notification interrupt specified in that UPID.
",
+ "tooltip": "The SENDUIPI instruction sends the user interprocessor interrupt (IPI) indicated by its register operand. (The operand always has 64 bits; operand-size overrides such as the prefix 66 are ignored.)",
+ "url": "https://www.felixcloutier.com/x86/SENDUIPI.html"
+ };
+
case "SERIALIZE":
return {
- "html": "
Serializes instruction execution. Before the next instruction is fetched and executed, the SERIALIZE instruction ensures that all modifications to flags, registers, and memory by previous instructions are completed, draining all buffered writes to memory. This instruction is also a serializing instruction as defined in the section \u201cSerializing Instructions\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
SERIALIZE does not modify registers, arithmetic flags, or memory.
",
- "tooltip": "Serializes instruction execution. Before the next instruction is fetched and executed, the SERIALIZE instruction ensures that all modifications to flags, registers, and memory by previous instructions are completed, draining all buffered writes to memory. This instruction is also a serializing instruction as defined in the section \u201cSerializing Instructions\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.",
+ "html": "
Serializes instruction execution. Before the next instruction is fetched and executed, the SERIALIZE instruction ensures that all modifications to flags, registers, and memory by previous instructions are completed, draining all buffered writes to memory. This instruction is also a serializing instruction as defined in the section \u201cSerializing Instructions\u201d in Chapter 9 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
SERIALIZE does not modify registers, arithmetic flags, or memory.
",
+ "tooltip": "Serializes instruction execution. Before the next instruction is fetched and executed, the SERIALIZE instruction ensures that all modifications to flags, registers, and memory by previous instructions are completed, draining all buffered writes to memory. This instruction is also a serializing instruction as defined in the section \u201cSerializing Instructions\u201d in Chapter 9 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.",
"url": "https://www.felixcloutier.com/x86/SERIALIZE.html"
};
@@ -3118,7 +3132,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SETS":
case "SETZ":
return {
- "html": "
Sets the destination operand to 0 or 1 depending on the settings of the status flags (CF, SF, OF, ZF, and PF) in the EFLAGS register. The destination operand points to a byte register or a byte in memory. The condition code suffix (cc) indicates the condition being tested for.
The terms \u201cabove\u201d and \u201cbelow\u201d are associated with the CF flag and refer to the relationship between two unsigned integer values. The terms \u201cgreater\u201d and \u201cless\u201d are associated with the SF and OF flags and refer to the relationship between two signed integer values.
Many of the SETcc instruction opcodes have alternate mnemonics. For example, SETG (set byte if greater) and SETNLE (set if not less or equal) have the same opcode and test for the same condition: ZF equals 0 and SF equals OF. These alternate mnemonics are provided to make code more intelligible. Appendix B, \u201cEFLAGS Condition Codes,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, shows the alternate mnemonics for various test conditions.
Some languages represent a logical one as an integer with all bits set. This representation can be obtained by choosing the logically opposite condition for the SETcc instruction, then decrementing the result. For example, to test for overflow, use the SETNO instruction, then decrement the result.
The reg field of the ModR/M byte is not used for the SETCC instruction and those opcode bits are ignored by the processor.
",
+ "html": "
Sets the destination operand to 0 or 1 depending on the settings of the status flags (CF, SF, OF, ZF, and PF) in the EFLAGS register. The destination operand points to a byte register or a byte in memory. The condition code suffix (cc) indicates the condition being tested for.
The terms \u201cabove\u201d and \u201cbelow\u201d are associated with the CF flag and refer to the relationship between two unsigned integer values. The terms \u201cgreater\u201d and \u201cless\u201d are associated with the SF and OF flags and refer to the relationship between two signed integer values.
Many of the SETcc instruction opcodes have alternate mnemonics. For example, SETG (set byte if greater) and SETNLE (set if not less or equal) have the same opcode and test for the same condition: ZF equals 0 and SF equals OF. These alternate mnemonics are provided to make code more intelligible. Appendix B, \u201cEFLAGS Condition Codes,\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, shows the alternate mnemonics for various test conditions.
Some languages represent a logical one as an integer with all bits set. This representation can be obtained by choosing the logically opposite condition for the SETcc instruction, then decrementing the result. For example, to test for overflow, use the SETNO instruction, then decrement the result.
The reg field of the ModR/M byte is not used for the SETCC instruction and those opcode bits are ignored by the processor.
",
"tooltip": "Sets the destination operand to 0 or 1 depending on the settings of the status flags (CF, SF, OF, ZF, and PF) in the EFLAGS register. The destination operand points to a byte register or a byte in memory. The condition code suffix (cc) indicates the condition being tested for.",
"url": "https://www.felixcloutier.com/x86/SETcc.html"
};
@@ -3196,26 +3210,19 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SHUFPD":
case "VSHUFPD":
return {
- "html": "
Selects a double-precision floating-point value of an input pair using a bit control and move to a designated element of the destination operand. The low-to-high order of double-precision element of the destination operand is interleaved between the first source operand and the second source operand at the granularity of input pair of 128 bits. Each bit in the imm8 byte, starting from bit 0, is the select control of the corresponding element of the destination to received the shuffled result of an input pair.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location The destination operand is a ZMM/YMM/XMM register updated according to the writemask. The select controls are the lower 8/4/2 bits of the imm8 byte.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The select controls are the bit 3:0 of the imm8 byte, imm8[7:4) are ignored.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed. The select controls are the bit 1:0 of the imm8 byte, imm8[7:2) are ignored.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination operand and the first source operand is the same and is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. The select controls are the bit 1:0 of the imm8 byte, imm8[7:2) are ignored.
",
- "tooltip": "Selects a double-precision floating-point value of an input pair using a bit control and move to a designated element of the destination operand. The low-to-high order of double-precision element of the destination operand is interleaved between the first source operand and the second source operand at the granularity of input pair of 128 bits. Each bit in the imm8 byte, starting from bit 0, is the select control of the corresponding element of the destination to received the shuffled result of an input pair.",
+ "html": "
Selects a double precision floating-point value of an input pair using a bit control and move to a designated element of the destination operand. The low-to-high order of double precision element of the destination operand is interleaved between the first source operand and the second source operand at the granularity of input pair of 128 bits. Each bit in the imm8 byte, starting from bit 0, is the select control of the corresponding element of the destination to received the shuffled result of an input pair.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location The destination operand is a ZMM/YMM/XMM register updated according to the writemask. The select controls are the lower 8/4/2 bits of the imm8 byte.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. The select controls are the bit 3:0 of the imm8 byte, imm8[7:4) are ignored.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of
the corresponding ZMM register destination are zeroed. The select controls are the bit 1:0 of the imm8 byte, imm8[7:2) are ignored.
",
+ "tooltip": "Selects a double precision floating-point value of an input pair using a bit control and move to a designated element of the destination operand. The low-to-high order of double precision element of the destination operand is interleaved between the first source operand and the second source operand at the granularity of input pair of 128 bits. Each bit in the imm8 byte, starting from bit 0, is the select control of the corresponding element of the destination to received the shuffled result of an input pair.",
"url": "https://www.felixcloutier.com/x86/SHUFPD.html"
};
case "SHUFPS":
case "VSHUFPS":
return {
- "html": "
Selects a single-precision floating-point value of an input quadruplet using a two-bit control and move to a designated element of the destination operand. Each 64-bit element-pair of a 128-bit lane of the destination operand is interleaved between the corresponding lane of the first source operand and the second source operand at the granularity 128 bits. Each two bits in the imm8 byte, starting from bit 0, is the select control of the corresponding element of a 128-bit lane of the destination to received the shuffled result of an input quadruplet. The two lower elements of a 128-bit lane in the destination receives shuffle results from the quadruple of the first source operand. The next two elements of the destination receives shuffle results from the quadruple of the second source operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register updated according to the writemask. Imm8[7:0] provides 4 select controls for each applicable 128-bit lane of the destination.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. Imm8[7:0] provides 4 select controls for the high and low 128-bit of the destination.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed. Imm8[7:0] provides 4 select controls for each element of the destination.
128-bit Legacy SSE version: The source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. Imm8[7:0] provides 4 select controls for each element of the destination.
",
- "tooltip": "Selects a single-precision floating-point value of an input quadruplet using a two-bit control and move to a designated element of the destination operand. Each 64-bit element-pair of a 128-bit lane of the destination operand is interleaved between the corresponding lane of the first source operand and the second source operand at the granularity 128 bits. Each two bits in the imm8 byte, starting from bit 0, is the select control of the corresponding element of a 128-bit lane of the destination to received the shuffled result of an input quadruplet. The two lower elements of a 128-bit lane in the destination receives shuffle results from the quadruple of the first source operand. The next two elements of the destination receives shuffle results from the quadruple of the second source operand.",
+ "html": "
Selects a single precision floating-point value of an input quadruplet using a two-bit control and move to a designated element of the destination operand. Each 64-bit element-pair of a 128-bit lane of the destination operand is interleaved between the corresponding lane of the first source operand and the second source operand at the granularity 128 bits. Each two bits in the imm8 byte, starting from bit 0, is the select control of the corresponding element of a 128-bit lane of the destination to received the shuffled result of an input quadruplet. The two lower elements of a 128-bit lane in the destination receives shuffle results from the quadruple of the first source operand. The next two elements of the destination receives shuffle results from the quadruple of the second source operand.
EVEX encoded versions: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register updated according to the writemask. imm8[7:0] provides 4 select controls for each applicable 128-bit lane of the destination.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register. Imm8[7:0] provides 4 select controls for the high and low 128-bit of the destination.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed. Imm8[7:0] provides 4 select controls for each element of the destination.
128-bit Legacy SSE version: The source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. Imm8[7:0] provides 4 select controls for each element of the destination.
",
+ "tooltip": "Selects a single precision floating-point value of an input quadruplet using a two-bit control and move to a designated element of the destination operand. Each 64-bit element-pair of a 128-bit lane of the destination operand is interleaved between the corresponding lane of the first source operand and the second source operand at the granularity 128 bits. Each two bits in the imm8 byte, starting from bit 0, is the select control of the corresponding element of a 128-bit lane of the destination to received the shuffled result of an input quadruplet. The two lower elements of a 128-bit lane in the destination receives shuffle results from the quadruple of the first source operand. The next two elements of the destination receives shuffle results from the quadruple of the second source operand.",
"url": "https://www.felixcloutier.com/x86/SHUFPS.html"
};
- case "SIDT":
- return {
- "html": "
Stores the content the interrupt descriptor table register (IDTR) in the destination operand. The destination operand specifies a 6-byte memory location.
In non-64-bit modes, the 16-bit limit field of the register is stored in the low 2 bytes of the memory location and the 32-bit base address is stored in the high 4 bytes.
In 64-bit mode, the operand size fixed at 8+2 bytes. The instruction stores 8-byte base and 2-byte limit values.
SIDT is only useful in operating-system software; however, it can be used in application programs without causing an exception to be generated if CR4.UMIP = 0. See \u201cLGDT/LIDT\u2014Load Global/Interrupt Descriptor Table Register\u201d in Chapter 3, Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2A, for information on loading the GDTR and IDTR.
The 16-bit form of SIDT is compatible with the Intel 286 processor if the upper 8 bits are not referenced. The Intel 286 processor fills these bits with 1s; processor generations later than the Intel 286 processor fill these bits with 0s.
",
- "tooltip": "Stores the content the interrupt descriptor table register (IDTR) in the destination operand. The destination operand specifies a 6-byte memory location.",
- "url": "https://www.felixcloutier.com/x86/SIDT.html"
- };
-
case "SLDT":
return {
"html": "
Stores the segment selector from the local descriptor table register (LDTR) in the destination operand. The destination operand can be a general-purpose register or a memory location. The segment selector stored with this instruction points to the segment descriptor (located in the GDT) for the current LDT. This instruction can only be executed in protected mode.
Outside IA-32e mode, when the destination operand is a 32-bit register, the 16-bit segment selector is copied into the low-order 16 bits of the register. The high-order 16 bits of the register are cleared for the Pentium 4, Intel Xeon, and P6 family processors. They are undefined for Pentium, Intel486, and Intel386 processors. When the destination operand is a memory location, the segment selector is written to memory as a 16-bit quantity, regardless of the operand size.
In compatibility mode, when the destination operand is a 32-bit register, the 16-bit segment selector is copied into the low-order 16 bits of the register. The high-order 16 bits of the register are cleared. When the destination operand is a memory location, the segment selector is written to memory as a 16-bit quantity, regardless of the operand size.
In 64-bit mode, using a REX prefix in the form of REX.R permits access to additional registers (R8-R15). The behavior of SLDT with a 64-bit register is to zero-extend the 16-bit selector and store it in the register. If the destination is memory and operand size is 64, SLDT will write the 16-bit selector to memory as a 16-bit quantity, regardless of the operand size.
",
@@ -3225,7 +3232,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SMSW":
return {
- "html": "
Stores the machine status word (bits 0 through 15 of control register CR0) into the destination operand. The destination operand can be a general-purpose register or a memory location.
In non-64-bit modes, when the destination operand is a 32-bit register, the low-order 16 bits of register CR0 are copied into the low-order 16 bits of the register and the high-order 16 bits are undefined. When the destination operand is a memory location, the low-order 16 bits of register CR0 are written to memory as a 16-bit quantity, regardless of the operand size.
In 64-bit mode, the behavior of the SMSW instruction is defined by the following examples:
SMSW is only useful in operating-system software. However, it is not a privileged instruction and can be used in application programs if CR4.UMIP = 0. It is provided for compatibility with the Intel 286 processor. Programs and procedures intended to run on IA-32 and Intel 64 processors beginning with the Intel386 processors should use the MOV CR instruction to load the machine status word.
See \u201cChanges to Instruction Behavior in VMX Non-Root Operation\u201d in Chapter 25 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about the behavior of this instruction in VMX non-root operation.
",
+ "html": "
Stores the machine status word (bits 0 through 15 of control register CR0) into the destination operand. The destination operand can be a general-purpose register or a memory location.
In non-64-bit modes, when the destination operand is a 32-bit register, the low-order 16 bits of register CR0 are copied into the low-order 16 bits of the register and the high-order 16 bits are undefined. When the destination operand is a memory location, the low-order 16 bits of register CR0 are written to memory as a 16-bit quantity, regardless of the operand size.
In 64-bit mode, the behavior of the SMSW instruction is defined by the following examples:
SMSW is only useful in operating-system software. However, it is not a privileged instruction and can be used in application programs if CR4.UMIP = 0. It is provided for compatibility with the Intel 286 processor. Programs and procedures intended to run on IA-32 and Intel 64 processors beginning with the Intel386 processors should use the MOV CR instruction to load the machine status word.
See \u201cChanges to Instruction Behavior in VMX Non-Root Operation\u201d in Chapter 26 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3C, for more information about the behavior of this instruction in VMX non-root operation.
",
"tooltip": "Stores the machine status word (bits 0 through 15 of control register CR0) into the destination operand. The destination operand can be a general-purpose register or a memory location.",
"url": "https://www.felixcloutier.com/x86/SMSW.html"
};
@@ -3233,32 +3240,32 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SQRTPD":
case "VSQRTPD":
return {
- "html": "
Performs a SIMD computation of the square roots of the two, four or eight packed double-precision floating-point values in the source operand (the second operand) stores the packed double-precision floating-point results in the destination operand (the first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register updated according to the writemask.
VEX.256 encoded version: The source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Performs a SIMD computation of the square roots of the two, four or eight packed double-precision floating-point values in the source operand (the second operand) stores the packed double-precision floating-point results in the destination operand (the first operand).",
+ "html": "
Performs a SIMD computation of the square roots of the two, four or eight packed double precision floating-point values in the source operand (the second operand) stores the packed double precision floating-point results in the destination operand (the first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register updated according to the writemask.
VEX.256 encoded version: The source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Performs a SIMD computation of the square roots of the two, four or eight packed double precision floating-point values in the source operand (the second operand) stores the packed double precision floating-point results in the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/SQRTPD.html"
};
case "SQRTPS":
case "VSQRTPS":
return {
- "html": "
Performs a SIMD computation of the square roots of the four, eight or sixteen packed single-precision floating-point values in the source operand (second operand) stores the packed single-precision floating-point results in the destination operand.
EVEX.512 encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register updated according to the writemask.
VEX.256 encoded version: The source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
- "tooltip": "Performs a SIMD computation of the square roots of the four, eight or sixteen packed single-precision floating-point values in the source operand (second operand) stores the packed single-precision floating-point results in the destination operand.",
+ "html": "
Performs a SIMD computation of the square roots of the four, eight or sixteen packed single precision floating-point values in the source operand (second operand) stores the packed single precision floating-point results in the destination operand.
EVEX.512 encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register updated according to the writemask.
VEX.256 encoded version: The source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register. The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 encoded version: the source operand second source operand or a 128-bit memory location. The destination operand is an XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified.
",
+ "tooltip": "Performs a SIMD computation of the square roots of the four, eight or sixteen packed single precision floating-point values in the source operand (second operand) stores the packed single precision floating-point results in the destination operand.",
"url": "https://www.felixcloutier.com/x86/SQRTPS.html"
};
case "SQRTSD":
case "VSQRTSD":
return {
- "html": "
Computes the square root of the low double-precision floating-point value in the second source operand and stores the double-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. The quadword at bits 127:64 of the destination operand remains unchanged. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits 127:64 of the destination operand are copied from the corresponding bits of the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination operand is updated according to the writemask.
Software should ensure VSQRTSD is encoded with VEX.L=0. Encoding VSQRTSD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
- "tooltip": "Computes the square root of the low double-precision floating-point value in the second source operand and stores the double-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.",
+ "html": "
Computes the square root of the low double precision floating-point value in the second source operand and stores the double precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. The quadword at bits 127:64 of the destination operand remains unchanged. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits 127:64 of the destination operand are copied from the corresponding bits of the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination operand is updated according to the write-mask.
Software should ensure VSQRTSD is encoded with VEX.L=0. Encoding VSQRTSD with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
+ "tooltip": "Computes the square root of the low double precision floating-point value in the second source operand and stores the double precision floating-point result in the destination operand. The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.",
"url": "https://www.felixcloutier.com/x86/SQRTSD.html"
};
case "SQRTSS":
case "VSQRTSS":
return {
- "html": "
Computes the square root of the low single-precision floating-point value in the second source operand and stores the single-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands is an XMM register.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits 127:32 of the destination operand are copied from the corresponding bits of the first source operand. Bits (MAXVL-1:128) of the destination ZMM register are zeroed.
EVEX encoded version: The low doubleword element of the destination operand is updated according to the writemask.
Software should ensure VSQRTSS is encoded with VEX.L=0. Encoding VSQRTSS with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
- "tooltip": "Computes the square root of the low single-precision floating-point value in the second source operand and stores the single-precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands is an XMM register.",
+ "html": "
Computes the square root of the low single precision floating-point value in the second source operand and stores the single precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands is an XMM register.
128-bit Legacy SSE version: The first source operand and the destination operand are the same. Bits (MAXVL-1:32) of the corresponding YMM destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits 127:32 of the destination operand are copied from the corresponding bits of the first source operand. Bits (MAXVL-1:128) of the destination ZMM register are zeroed.
EVEX encoded version: The low doubleword element of the destination operand is updated according to the write-mask.
Software should ensure VSQRTSS is encoded with VEX.L=0. Encoding VSQRTSS with VEX.L=1 may encounter unpredictable behavior across different processor generations.
",
+ "tooltip": "Computes the square root of the low single precision floating-point value in the second source operand and stores the single precision floating-point result in the destination operand. The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands is an XMM register.",
"url": "https://www.felixcloutier.com/x86/SQRTSS.html"
};
@@ -3304,7 +3311,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "STOSQ":
case "STOSW":
return {
- "html": "
In non-64-bit and default 64-bit mode; stores a byte, word, or doubleword from the AL, AX, or EAX register (respectively) into the destination operand. The destination operand is a memory location, the address of which is read from either the ES:EDI or ES:DI register (depending on the address-size attribute of the instruction and the mode of operation). The ES segment cannot be overridden with a segment override prefix.
At the assembly-code level, two forms of the instruction are allowed: the \u201cexplicit-operands\u201d form and the \u201cno-operands\u201d form. The explicit-operands form (specified with the STOS mnemonic) allows the destination operand to be specified explicitly. Here, the destination operand should be a symbol that indicates the size and location of the destination value. The source operand is then automatically selected to match the size of the destination operand (the AL register for byte operands, AX for word operands, EAX for doubleword operands). The explicit-operands form is provided to allow documentation; however, note that the documentation provided by this form can be misleading. That is, the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location. The location is always specified by the ES:(E)DI register. These must be loaded correctly before the store string instruction is executed.
The no-operands form provides \u201cshort forms\u201d of the byte, word, doubleword, and quadword versions of the STOS instructions. Here also ES:(E)DI is assumed to be the destination operand and AL, AX, or EAX is assumed to be the source operand. The size of the destination and source operands is selected by the mnemonic: STOSB (byte read from register AL), STOSW (word from AX), STOSD (doubleword from EAX).
After the byte, word, or doubleword is transferred from the register to the memory location, the (E)DI register is incremented or decremented according to the setting of the DF flag in the EFLAGS register. If the DF flag is 0, the register is incremented; if the DF flag is 1, the register is decremented (the register is incremented or decremented by 1 for byte operations, by 2 for word operations, by 4 for doubleword operations).
NOTE: To improve performance, more recent processors support modifications to the processor\u2019s operation during the string store operations initiated with STOS and STOSB. See Section 7.3.9.3 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for additional information on fast-string operation.
",
+ "html": "
In non-64-bit and default 64-bit mode; stores a byte, word, or doubleword from the AL, AX, or EAX register (respectively) into the destination operand. The destination operand is a memory location, the address of which is read from either the ES:EDI or ES:DI register (depending on the address-size attribute of the instruction and the mode of operation). The ES segment cannot be overridden with a segment override prefix.
At the assembly-code level, two forms of the instruction are allowed: the \u201cexplicit-operands\u201d form and the \u201cno-operands\u201d form. The explicit-operands form (specified with the STOS mnemonic) allows the destination operand to be specified explicitly. Here, the destination operand should be a symbol that indicates the size and location of the destination value. The source operand is then automatically selected to match the size of the destination operand (the AL register for byte operands, AX for word operands, EAX for doubleword operands). The explicit-operands form is provided to allow documentation; however, note that the documentation provided by this form can be misleading. That is, the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location. The location is always specified by the ES:(E)DI register. These must be loaded correctly before the store string instruction is executed.
The no-operands form provides \u201cshort forms\u201d of the byte, word, doubleword, and quadword versions of the STOS instructions. Here also ES:(E)DI is assumed to be the destination operand and AL, AX, or EAX is assumed to be the source operand. The size of the destination and source operands is selected by the mnemonic: STOSB (byte read from register AL), STOSW (word from AX), STOSD (doubleword from EAX).
After the byte, word, or doubleword is transferred from the register to the memory location, the (E)DI register is incremented or decremented according to the setting of the DF flag in the EFLAGS register. If the DF flag is 0, the register is incremented; if the DF flag is 1, the register is decremented (the register is incremented or decremented by 1 for byte operations, by 2 for word operations, by 4 for doubleword operations).
In 64-bit mode, the default address size is 64 bits, 32-bit address size is supported using the prefix 67H. Using a REX prefix in the form of REX.W promotes operation on doubleword operand to 64 bits. The promoted no-operand mnemonic is STOSQ. STOSQ (and its explicit operands variant) store a quadword from the RAX register into the destination addressed by RDI or EDI. See the summary chart at the beginning of this section for encoding data and limits.
",
"tooltip": "In non-64-bit and default 64-bit mode; stores a byte, word, or doubleword from the AL, AX, or EAX register (respectively) into the destination operand. The destination operand is a memory location, the address of which is read from either the ES:EDI or ES:DI register (depending on the address-size attribute of the instruction and the mode of operation). The ES segment cannot be overridden with a segment override prefix.",
"url": "https://www.felixcloutier.com/x86/STOS%3ASTOSB%3ASTOSW%3ASTOSD%3ASTOSQ.html"
};
@@ -3316,6 +3323,13 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://www.felixcloutier.com/x86/STR.html"
};
+ case "STUI":
+ return {
+ "html": "
STUI sets the user interrupt flag (UIF). Its effect takes place immediately; a user interrupt may be delivered on the instruction boundary following STUI. (This is in contrast with STI, whose effect is delayed by one instruction).
An execution of STUI inside a transactional region causes a transactional abort; the abort loads EAX as it would have had it been due to an execution of STI.
",
+ "tooltip": "STUI sets the user interrupt flag (UIF). Its effect takes place immediately; a user interrupt may be delivered on the instruction boundary following STUI. (This is in contrast with STI, whose effect is delayed by one instruction).",
+ "url": "https://www.felixcloutier.com/x86/STUI.html"
+ };
+
case "SUB":
return {
"html": "
Subtracts the second operand (source operand) from the first operand (destination operand) and stores the result in the destination operand. The destination operand can be a register or a memory location; the source operand can be an immediate, register, or memory location. (However, two memory operands cannot be used in one instruction.) When an immediate value is used as an operand, it is sign-extended to the length of the destination operand format.
The SUB instruction performs integer subtraction. It evaluates the result for both signed and unsigned integer operands and sets the OF and CF flags to indicate an overflow in the signed or unsigned result, respectively. The SF flag indicates the sign of the signed result.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Using a REX prefix in the form of REX.R permits access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.
",
@@ -3326,32 +3340,32 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SUBPD":
case "VSUBPD":
return {
- "html": "
Performs a SIMD subtract of the two, four or eight packed double-precision floating-point values of the second Source operand from the first Source operand, and stores the packed double-precision floating-point results in the destination operand.
VEX.128 and EVEX.128 encoded versions: The second source operand is an XMM register or an 128-bit memory location. The first source operand and destination operands are XMM registers. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 and EVEX.256 encoded versions: The second source operand is an YMM register or an 256-bit memory location. The first source operand and destination operands are YMM registers. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX.512 encoded version: The second source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The first source operand and destination operands are ZMM registers. The destination operand is conditionally updated according to the writemask.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Performs a SIMD subtract of the two, four or eight packed double-precision floating-point values of the second Source operand from the first Source operand, and stores the packed double-precision floating-point results in the destination operand.",
+ "html": "
Performs a SIMD subtract of the two, four or eight packed double precision floating-point values of the second Source operand from the first Source operand, and stores the packed double precision floating-point results in the destination operand.
VEX.128 and EVEX.128 encoded versions: The second source operand is an XMM register or an 128-bit memory location. The first source operand and destination operands are XMM registers. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 and EVEX.256 encoded versions: The second source operand is an YMM register or an 256-bit memory location. The first source operand and destination operands are YMM registers. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX.512 encoded version: The second source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The first source operand and destination operands are ZMM registers. The destination operand is conditionally updated according to the writemask.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Performs a SIMD subtract of the two, four or eight packed double precision floating-point values of the second Source operand from the first Source operand, and stores the packed double precision floating-point results in the destination operand.",
"url": "https://www.felixcloutier.com/x86/SUBPD.html"
};
case "SUBPS":
case "VSUBPS":
return {
- "html": "
Performs a SIMD subtract of the packed single-precision floating-point values in the second Source operand from the First Source operand, and stores the packed single-precision floating-point results in the destination operand.
VEX.128 and EVEX.128 encoded versions: The second source operand is an XMM register or an 128-bit memory location. The first source operand and destination operands are XMM registers. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 and EVEX.256 encoded versions: The second source operand is an YMM register or an 256-bit memory location. The first source operand and destination operands are YMM registers. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX.512 encoded version: The second source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 32-bit memory location. The first source operand and destination operands are ZMM registers. The destination operand is conditionally updated according to the writemask.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Performs a SIMD subtract of the packed single-precision floating-point values in the second Source operand from the First Source operand, and stores the packed single-precision floating-point results in the destination operand.",
+ "html": "
Performs a SIMD subtract of the packed single precision floating-point values in the second Source operand from the First Source operand, and stores the packed single precision floating-point results in the destination operand.
VEX.128 and EVEX.128 encoded versions: The second source operand is an XMM register or an 128-bit memory location. The first source operand and destination operands are XMM registers. Bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 and EVEX.256 encoded versions: The second source operand is an YMM register or an 256-bit memory location. The first source operand and destination operands are YMM registers. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX.512 encoded version: The second source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 32-bit memory location. The first source operand and destination operands are ZMM registers. The destination operand is conditionally updated according to the writemask.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper Bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Performs a SIMD subtract of the packed single precision floating-point values in the second Source operand from the First Source operand, and stores the packed single precision floating-point results in the destination operand.",
"url": "https://www.felixcloutier.com/x86/SUBPS.html"
};
case "SUBSD":
case "VSUBSD":
return {
- "html": "
Subtract the low double-precision floating-point value in the second source operand from the first source operand and stores the double-precision floating-point result in the low quadword of the destination operand.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination operand is updated according to the writemask.
",
- "tooltip": "Subtract the low double-precision floating-point value in the second source operand from the first source operand and stores the double-precision floating-point result in the low quadword of the destination operand.",
+ "html": "
Subtract the low double precision floating-point value in the second source operand from the first source operand and stores the double precision floating-point result in the low quadword of the destination operand.
The second source operand can be an XMM register or a 64-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:64) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination operand is updated according to the write-mask.
",
+ "tooltip": "Subtract the low double precision floating-point value in the second source operand from the first source operand and stores the double precision floating-point result in the low quadword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/SUBSD.html"
};
case "SUBSS":
case "VSUBSS":
return {
- "html": "
Subtract the low single-precision floating-point value from the second source operand and the first source operand and store the double-precision floating-point result in the low doubleword of the destination operand.
The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:32) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low doubleword element of the destination operand is updated according to the writemask.
",
- "tooltip": "Subtract the low single-precision floating-point value from the second source operand and the first source operand and store the double-precision floating-point result in the low doubleword of the destination operand.",
+ "html": "
Subtract the low single precision floating-point value from the second source operand and the first source operand and store the double precision floating-point result in the low doubleword of the destination operand.
The second source operand can be an XMM register or a 32-bit memory location. The first source and destination operands are XMM registers.
128-bit Legacy SSE version: The destination and first source operand are the same. Bits (MAXVL-1:32) of the corresponding destination register remain unchanged.
VEX.128 and EVEX encoded versions: Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX encoded version: The low doubleword element of the destination operand is updated according to the write-mask.
",
+ "tooltip": "Subtract the low single precision floating-point value from the second source operand and the first source operand and store the double precision floating-point result in the low doubleword of the destination operand.",
"url": "https://www.felixcloutier.com/x86/SUBSS.html"
};
@@ -3364,7 +3378,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SYSCALL":
return {
- "html": "
SYSCALL invokes an OS system-call handler at privilege level 0. It does so by loading RIP from the IA32_LSTAR MSR (after saving the address of the instruction following SYSCALL into RCX). (The WRMSR instruction ensures that the IA32_LSTAR MSR always contain a canonical address.)
SYSCALL also saves RFLAGS into R11 and then masks RFLAGS using the IA32_FMASK MSR (MSR address C0000084H); specifically, the processor clears in RFLAGS every bit corresponding to a bit that is set in the IA32_FMASK MSR.
SYSCALL loads the CS and SS selectors with values derived from bits 47:32 of the IA32_STAR MSR. However, the CS and SS descriptor caches are not loaded from the descriptors (in GDT or LDT) referenced by those selectors. Instead, the descriptor caches are loaded with fixed values. See the Operation section for details. It is the responsibility of OS software to ensure that the descriptors (in GDT or LDT) referenced by those selector values correspond to the fixed values loaded into the descriptor caches; the SYSCALL instruction does not ensure this correspondence.
The SYSCALL instruction does not save the stack pointer (RSP). If the OS system-call handler will change the stack pointer, it is the responsibility of software to save the previous value of the stack pointer. This might be done prior to executing SYSCALL, with software restoring the stack pointer with the instruction following SYSCALL (which will be executed after SYSRET). Alternatively, the OS system-call handler may save the stack pointer and restore it before executing SYSRET.
When shadow stacks are enabled at a privilege level where the SYSCALL instruction is invoked, the SSP is saved to the IA32_PL3_SSP MSR. If shadow stacks are enabled at privilege level 0, the SSP is loaded with 0. Refer to Chapter 6, \u201cProcedure Calls, Interrupts, and Exceptions\u201d and Chapter 18, \u201cControl-Flow Enforcement Technology (CET)\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for additional CET details.
",
+ "html": "
SYSCALL invokes an OS system-call handler at privilege level 0. It does so by loading RIP from the IA32_LSTAR MSR (after saving the address of the instruction following SYSCALL into RCX). (The WRMSR instruction ensures that the IA32_LSTAR MSR always contain a canonical address.)
SYSCALL also saves RFLAGS into R11 and then masks RFLAGS using the IA32_FMASK MSR (MSR address C0000084H); specifically, the processor clears in RFLAGS every bit corresponding to a bit that is set in the IA32_FMASK MSR.
SYSCALL loads the CS and SS selectors with values derived from bits 47:32 of the IA32_STAR MSR. However, the CS and SS descriptor caches are not loaded from the descriptors (in GDT or LDT) referenced by those selectors. Instead, the descriptor caches are loaded with fixed values. See the Operation section for details. It is the responsibility of OS software to ensure that the descriptors (in GDT or LDT) referenced by those selector values correspond to the fixed values loaded into the descriptor caches; the SYSCALL instruction does not ensure this correspondence.
The SYSCALL instruction does not save the stack pointer (RSP). If the OS system-call handler will change the stack pointer, it is the responsibility of software to save the previous value of the stack pointer. This might be done prior to executing SYSCALL, with software restoring the stack pointer with the instruction following SYSCALL (which will be executed after SYSRET). Alternatively, the OS system-call handler may save the stack pointer and restore it before executing SYSRET.
When shadow stacks are enabled at a privilege level where the SYSCALL instruction is invoked, the SSP is saved to the IA32_PL3_SSP MSR. If shadow stacks are enabled at privilege level 0, the SSP is loaded with 0. Refer to Chapter 6, \u201cProcedure Calls, Interrupts, and Exceptions\u201a\u201d and Chapter 17, \u201cControl-flow Enforcement Technology (CET)\u201a\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for additional CET details.
",
"tooltip": "SYSCALL invokes an OS system-call handler at privilege level 0. It does so by loading RIP from the IA32_LSTAR MSR (after saving the address of the instruction following SYSCALL into RCX). (The WRMSR instruction ensures that the IA32_LSTAR MSR always contain a canonical address.)",
"url": "https://www.felixcloutier.com/x86/SYSCALL.html"
};
@@ -3385,7 +3399,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SYSRET":
return {
- "html": "
SYSRET is a companion instruction to the SYSCALL instruction. It returns from an OS system-call handler to user code at privilege level 3. It does so by loading RIP from RCX and loading RFLAGS from R11.1 With a 64-bit operand size, SYSRET remains in 64-bit mode; otherwise, it enters compatibility mode and only the low 32 bits of the registers are loaded.
SYSRET loads the CS and SS selectors with values derived from bits 63:48 of the IA32_STAR MSR. However, the CS and SS descriptor caches are not loaded from the descriptors (in GDT or LDT) referenced by those selectors. Instead, the descriptor caches are loaded with fixed values. See the Operation section for details. It is the responsibility of OS software to ensure that the descriptors (in GDT or LDT) referenced by those selector values correspond to the fixed values loaded into the descriptor caches; the SYSRET instruction does not ensure this correspondence.
The SYSRET instruction does not modify the stack pointer (ESP or RSP). For that reason, it is necessary for software to switch to the user stack. The OS may load the user stack pointer (if it was saved after SYSCALL) before executing SYSRET; alternatively, user code may load the stack pointer (if it was saved before SYSCALL) after receiving control from SYSRET.
If the OS loads the stack pointer before executing SYSRET, it must ensure that the handler of any interrupt or exception delivered between restoring the stack pointer and successful execution of SYSRET is not invoked with the user stack. It can do so using approaches such as the following:
When shadow stacks are enabled at privilege level 3 the instruction loads SSP with value from IA32_PL3_SSP MSR. Refer to Chapter 6, \u201cProcedure Calls, Interrupts, and Exceptions\u201d and Chapter 18, \u201cControl-Flow Enforcement Technology (CET)\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for additional CET details.
",
+ "html": "
SYSRET is a companion instruction to the SYSCALL instruction. It returns from an OS system-call handler to user code at privilege level 3. It does so by loading RIP from RCX and loading RFLAGS from R11.1 With a 64-bit operand size, SYSRET remains in 64-bit mode; otherwise, it enters compatibility mode and only the low 32 bits of the registers are loaded.
SYSRET loads the CS and SS selectors with values derived from bits 63:48 of the IA32_STAR MSR. However, the CS and SS descriptor caches are not loaded from the descriptors (in GDT or LDT) referenced by those selectors. Instead, the descriptor caches are loaded with fixed values. See the Operation section for details. It is the responsibility of OS software to ensure that the descriptors (in GDT or LDT) referenced by those selector values correspond to the fixed values loaded into the descriptor caches; the SYSRET instruction does not ensure this correspondence.
The SYSRET instruction does not modify the stack pointer (ESP or RSP). For that reason, it is necessary for software to switch to the user stack. The OS may load the user stack pointer (if it was saved after SYSCALL) before executing SYSRET; alternatively, user code may load the stack pointer (if it was saved before SYSCALL) after receiving control from SYSRET.
If the OS loads the stack pointer before executing SYSRET, it must ensure that the handler of any interrupt or exception delivered between restoring the stack pointer and successful execution of SYSRET is not invoked with the user stack. It can do so using approaches such as the following:
When shadow stacks are enabled at privilege level 3 the instruction loads SSP with value from IA32_PL3_SSP MSR. Refer to Chapter 6, \u201cProcedure Calls, Interrupts, and Exceptions\u201a\u201d and Chapter 17, \u201cControl-flow Enforcement Technology (CET)\u201a\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for additional CET details.
",
"tooltip": "SYSRET is a companion instruction to the SYSCALL instruction. It returns from an OS system-call handler to user code at privilege level 3. It does so by loading RIP from RCX and loading RFLAGS from R11.1 With a 64-bit operand size, SYSRET remains in 64-bit mode; otherwise, it enters compatibility mode and only the low 32 bits of the registers are loaded.",
"url": "https://www.felixcloutier.com/x86/SYSRET.html"
};
@@ -3397,9 +3411,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://www.felixcloutier.com/x86/TEST.html"
};
+ case "TILERELEASE":
+ return {
+ "html": "
This instruction returns TILECFG and TILEDATA to the INIT state.
Any attempt to execute the TILERELEASE instruction inside an Intel TSX transaction will result in a transaction abort.
",
+ "tooltip": "This instruction returns TILECFG and TILEDATA to the INIT state.",
+ "url": "https://www.felixcloutier.com/x86/TILERELEASE.html"
+ };
+
case "TPAUSE":
return {
- "html": "
TPAUSE instructs the processor to enter an implementation-dependent optimized state. There are two such optimized states to choose from: light-weight power/performance optimized state, and improved power/performance optimized state. The selection between the two is governed by the explicit input register bit[0] source operand.
TPAUSE is available when CPUID.7.0:ECX.WAITPKG[bit 5] is enumerated as 1. TPAUSE may be executed at any privilege level. This instruction\u2019s operation is the same in non-64-bit modes and in 64-bit mode.
Unlike PAUSE, the TPAUSE instruction will not cause an abort when used inside a transactional region, described in the chapter Chapter 16, \u201cProgramming with Intel\u00ae Transactional Synchronization Extensions,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
The input register contains information such as the preferred optimized state the processor should enter as described in the following table. Bits other than bit 0 are reserved and will result in #GP if non-zero.
The instruction execution wakes up when the time-stamp counter reaches or exceeds the implicit EDX:EAX 64-bit input value.
",
+ "html": "
TPAUSE instructs the processor to enter an implementation-dependent optimized state. There are two such optimized states to choose from: light-weight power/performance optimized state, and improved power/performance optimized state. The selection between the two is governed by the explicit input register bit[0] source operand.
TPAUSE is available when CPUID.7.0:ECX.WAITPKG[bit 5] is enumerated as 1. TPAUSE may be executed at any privilege level. This instruction\u2019s operation is the same in non-64-bit modes and in 64-bit mode.
Unlike PAUSE, the TPAUSE instruction will not cause an abort when used inside a transactional region, described in the chapter Chapter 16, \u201cProgramming with Intel\u00ae Transactional Synchronization Extensions,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
The input register contains information such as the preferred optimized state the processor should enter as described in the following table. Bits other than bit 0 are reserved and will result in #GP if non-zero.
The instruction execution wakes up when the time-stamp counter reaches or exceeds the implicit EDX:EAX 64-bit input value.
",
"tooltip": "TPAUSE instructs the processor to enter an implementation-dependent optimized state. There are two such optimized states to choose from: light-weight power/performance optimized state, and improved power/performance optimized state. The selection between the two is governed by the explicit input register bit[0] source operand.",
"url": "https://www.felixcloutier.com/x86/TPAUSE.html"
};
@@ -3414,16 +3435,16 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "UCOMISD":
case "VUCOMISD":
return {
- "html": "
Performs an unordered compare of the double-precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 64 bit memory
",
- "tooltip": "Performs an unordered compare of the double-precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
+ "html": "
Performs an unordered compare of the double precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 64 bit memory
",
+ "tooltip": "Performs an unordered compare of the double precision floating-point values in the low quadwords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
"url": "https://www.felixcloutier.com/x86/UCOMISD.html"
};
case "UCOMISS":
case "VUCOMISS":
return {
- "html": "
Compares the single-precision floating-point values in the low doublewords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 32 bit memory location.
The UCOMISS instruction differs from the COMISS instruction in that it signals a SIMD floating-point invalid operation exception (#I) only if a source operand is an SNaN. The COMISS instruction signals an invalid operation exception when a source operand is either a QNaN or SNaN.
The EFLAGS register is not updated if an unmasked SIMD floating-point exception is generated.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Compares the single-precision floating-point values in the low doublewords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
+ "html": "
Compares the single precision floating-point values in the low doublewords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).
Operand 1 is an XMM register; operand 2 can be an XMM register or a 32 bit memory location.
The UCOMISS instruction differs from the COMISS instruction in that it signals a SIMD floating-point invalid operation exception (#I) only if a source operand is an SNaN. The COMISS instruction signals an invalid operation exception when a source operand is either a QNaN or SNaN.
The EFLAGS register is not updated if an unmasked SIMD floating-point exception is generated.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Compares the single precision floating-point values in the low doublewords of operand 1 (first operand) and operand 2 (second operand), and sets the ZF, PF, and CF flags in the EFLAGS register according to the result (unordered, greater than, less than, or equal). The OF, SF, and AF flags in the EFLAGS register are set to 0. The unordered result is returned if either source operand is a NaN (QNaN or SNaN).",
"url": "https://www.felixcloutier.com/x86/UCOMISS.html"
};
@@ -3436,16 +3457,23 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://www.felixcloutier.com/x86/UD.html"
};
+ case "UIRET":
+ return {
+ "html": "
UIRET returns from the handling of a user interrupt. It can be executed regardless of CPL.
Execution of UIRET inside a transactional region causes a transactional abort; the abort loads EAX as it would have had it been due to an execution of IRET.
UIRET can be tracked by Architectural Last Branch Records (LBRs), Intel Processor Trace (Intel PT), and Performance Monitoring. For both Intel PT and LBRs, UIRET is recorded in precisely the same manner as IRET. Hence for LBRs, UIRETs fall into the OTHER_BRANCH category, which implies that IA32_LBR_CTL.OTHER_BRANCH[bit 22] must be set to record user-interrupt delivery, and that the IA32_LBR_x_INFO.BR_TYPE field will indicate OTHER_BRANCH for any recorded user interrupt. For Intel PT, control flow tracing must be enabled by setting IA32_RTIT_CTL.BranchEn[bit 13].
UIRET will also increment performance counters for which counting BR_INST_RETIRED.FAR_BRANCH is enabled.
",
+ "tooltip": "UIRET returns from the handling of a user interrupt. It can be executed regardless of CPL.",
+ "url": "https://www.felixcloutier.com/x86/UIRET.html"
+ };
+
case "UMONITOR":
return {
- "html": "
The UMONITOR instruction arms address monitoring hardware using an address specified in the source register (the address range that the monitoring hardware checks for store operations can be determined by using the CPUID monitor leaf function, EAX=05H). A store to an address within the specified address range triggers the monitoring hardware. The state of monitor hardware is used by UMWAIT.
The content of the source register is an effective address. By default, the DS segment is used to create a linear address that is monitored. Segment overrides can be used. The address range must use memory of the write-back type. Only write-back memory is guaranteed to correctly trigger the monitoring hardware. Additional information on determining what address range to use in order to prevent false wake-ups is described in Chapter 8, \u201cMultipleProcessor Management\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
The UMONITOR instruction is ordered as a load operation with respect to other memory transactions. The instruction is subject to the permission checking and faults associated with a byte load. Like a load, UMONITOR sets the A-bit but not the D-bit in page tables.
UMONITOR and UMWAIT are available when CPUID.7.0:ECX.WAITPKG[bit 5] is enumerated as 1. UMONITOR and UMWAIT may be executed at any privilege level. Except for the width of the source register, the instruction\u2019s operation is the same in non-64-bit modes and in 64-bit mode.
UMONITOR does not interoperate with the legacy MWAIT instruction. If UMONITOR was executed prior to executing MWAIT and following the most recent execution of the legacy MONITOR instruction, MWAIT will not enter an optimized state. Execution will continue to the instruction following MWAIT.
",
+ "html": "
The UMONITOR instruction arms address monitoring hardware using an address specified in the source register (the address range that the monitoring hardware checks for store operations can be determined by using the CPUID monitor leaf function, EAX=05H). A store to an address within the specified address range triggers the monitoring hardware. The state of monitor hardware is used by UMWAIT.
The content of the source register is an effective address. By default, the DS segment is used to create a linear address that is monitored. Segment overrides can be used. The address range must use memory of the write-back type. Only write-back memory is guaranteed to correctly trigger the monitoring hardware. Additional information on determining what address range to use in order to prevent false wake-ups is described in Chapter 9, \u201cMultipleProcessor Management\u201a\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
The UMONITOR instruction is ordered as a load operation with respect to other memory transactions. The instruction is subject to the permission checking and faults associated with a byte load. Like a load, UMONITOR sets the A-bit but not the D-bit in page tables.
UMONITOR and UMWAIT are available when CPUID.7.0:ECX.WAITPKG[bit 5] is enumerated as 1. UMONITOR and UMWAIT may be executed at any privilege level. Except for the width of the source register, the instruction\u2019s operation is the same in non-64-bit modes and in 64-bit mode.
UMONITOR does not interoperate with the legacy MWAIT instruction. If UMONITOR was executed prior to executing MWAIT and following the most recent execution of the legacy MONITOR instruction, MWAIT will not enter an optimized state. Execution will continue to the instruction following MWAIT.
",
"tooltip": "The UMONITOR instruction arms address monitoring hardware using an address specified in the source register (the address range that the monitoring hardware checks for store operations can be determined by using the CPUID monitor leaf function, EAX=05H). A store to an address within the specified address range triggers the monitoring hardware. The state of monitor hardware is used by UMWAIT.",
"url": "https://www.felixcloutier.com/x86/UMONITOR.html"
};
case "UMWAIT":
return {
- "html": "
UMWAIT instructs the processor to enter an implementation-dependent optimized state while monitoring a range of addresses. The optimized state may be either a light-weight power/performance optimized state or an improved power/performance optimized state. The selection between the two states is governed by the explicit input register bit[0] source operand.
UMWAIT is available when CPUID.7.0:ECX.WAITPKG[bit 5] is enumerated as 1. UMWAIT may be executed at any privilege level. This instruction\u2019s operation is the same in non-64-bit modes and in 64-bit mode.
The input register contains information such as the preferred optimized state the processor should enter as described in the following table. Bits other than bit 0 are reserved and will result in #GP if nonzero.
The instruction wakes up when the time-stamp counter reaches or exceeds the implicit EDX:EAX 64-bit input value (if the monitoring hardware did not trigger beforehand).
Prior to executing the UMWAIT instruction, an operating system may specify the maximum delay it allows the processor to suspend its operation. It can do so by writing TSC-quanta value to the following 32bit MSR (IA32_UMWAIT_CONTROL at MSR index E1H):
",
+ "html": "
UMWAIT instructs the processor to enter an implementation-dependent optimized state while monitoring a range of addresses. The optimized state may be either a light-weight power/performance optimized state or an improved power/performance optimized state. The selection between the two states is governed by the explicit input register bit[0] source operand.
UMWAIT is available when CPUID.7.0:ECX.WAITPKG[bit 5] is enumerated as 1. UMWAIT may be executed at any privilege level. This instruction\u2019s operation is the same in non-64-bit modes and in 64-bit mode.
The input register contains information such as the preferred optimized state the processor should enter as described in the following table. Bits other than bit 0 are reserved and will result in #GP if nonzero.
The instruction wakes up when the time-stamp counter reaches or exceeds the implicit EDX:EAX 64-bit input value (if the monitoring hardware did not trigger beforehand).
Prior to executing the UMWAIT instruction, an operating system may specify the maximum delay it allows the processor to suspend its operation. It can do so by writing TSC-quanta value to the following 32bit MSR (IA32_UM-WAIT_CONTROL at MSR index E1H):
",
"tooltip": "UMWAIT instructs the processor to enter an implementation-dependent optimized state while monitoring a range of addresses. The optimized state may be either a light-weight power/performance optimized state or an improved power/performance optimized state. The selection between the two states is governed by the explicit input register bit[0] source operand.",
"url": "https://www.felixcloutier.com/x86/UMWAIT.html"
};
@@ -3453,32 +3481,32 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "UNPCKHPD":
case "VUNPCKHPD":
return {
- "html": "
Performs an interleaved unpack of the high double-precision floating-point values from the first source operand and the second source operand. See Figure 4-15 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
- "tooltip": "Performs an interleaved unpack of the high double-precision floating-point values from the first source operand and the second source operand. See Figure 4-15 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B.",
+ "html": "
Performs an interleaved unpack of the high double precision floating-point values from the first source operand and the second source operand. See Figure 4-15 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
+ "tooltip": "Performs an interleaved unpack of the high double precision floating-point values from the first source operand and the second source operand. See Figure 4-15 in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 2B.",
"url": "https://www.felixcloutier.com/x86/UNPCKHPD.html"
};
case "UNPCKHPS":
case "VUNPCKHPS":
return {
- "html": "
Performs an interleaved unpack of the high single-precision floating-point values from the first source operand and the second source operand.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The second source operand is an YMM register or an 256-bit memory location. The first source operand and destination operands are YMM registers.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
- "tooltip": "Performs an interleaved unpack of the high single-precision floating-point values from the first source operand and the second source operand.",
+ "html": "
Performs an interleaved unpack of the high single precision floating-point values from the first source operand and the second source operand.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The second source operand is an YMM register or an 256-bit memory location. The first source operand and destination operands are YMM registers.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
+ "tooltip": "Performs an interleaved unpack of the high single precision floating-point values from the first source operand and the second source operand.",
"url": "https://www.felixcloutier.com/x86/UNPCKHPS.html"
};
case "UNPCKLPD":
case "VUNPCKLPD":
return {
- "html": "
Performs an interleaved unpack of the low double-precision floating-point values from the first source operand and the second source operand.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
- "tooltip": "Performs an interleaved unpack of the low double-precision floating-point values from the first source operand and the second source operand.",
+ "html": "
Performs an interleaved unpack of the low double precision floating-point values from the first source operand and the second source operand.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
+ "tooltip": "Performs an interleaved unpack of the low double precision floating-point values from the first source operand and the second source operand.",
"url": "https://www.felixcloutier.com/x86/UNPCKLPD.html"
};
case "UNPCKLPS":
case "VUNPCKLPS":
return {
- "html": "
Performs an interleaved unpack of the low single-precision floating-point values from the first source operand and the second source operand.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
- "tooltip": "Performs an interleaved unpack of the low single-precision floating-point values from the first source operand and the second source operand.",
+ "html": "
Performs an interleaved unpack of the low single precision floating-point values from the first source operand and the second source operand.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding ZMM register destination are unmodified. When unpacking from a memory operand, an implementation may fetch only the appropriate 64 bits; however, alignment to 16-byte boundary and normal segment checking will still be enforced.
VEX.128 encoded version: The first source operand is a XMM register. The second source operand can be a XMM register or a 128-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand can be a YMM register or a 256-bit memory location. The destination operand is a YMM register.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
",
+ "tooltip": "Performs an interleaved unpack of the low single precision floating-point values from the first source operand and the second source operand.",
"url": "https://www.felixcloutier.com/x86/UNPCKLPS.html"
};
@@ -3530,15 +3558,15 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VCOMPRESSPD":
return {
- "html": "
Compress (store) up to 8 double-precision floating-point values from the source operand (the second operand) as a contiguous vector to the destination operand (the first operand) The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The opmask register k1 selects the active elements (partial vector or possibly non-contiguous if less than 8 active elements) from the source operand to compress into a contiguous vector. The contiguous vector is written to the destination starting from the low element of the destination operand.
Memory destination version: Only the contiguous vector is written to the destination memory location. EVEX.z must be zero.
Register destination version: If the vector length of the contiguous vector is less than that of the input vector in the source operand, the upper bits of the destination register are unmodified if EVEX.z is not set, otherwise the upper bits are zeroed.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Compress (store) up to 8 double-precision floating-point values from the source operand (the second operand) as a contiguous vector to the destination operand (the first operand) The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.",
+ "html": "
Compress (store) up to 8 double precision floating-point values from the source operand (the second operand) as a contiguous vector to the destination operand (the first operand) The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The opmask register k1 selects the active elements (partial vector or possibly non-contiguous if less than 8 active elements) from the source operand to compress into a contiguous vector. The contiguous vector is written to the destination starting from the low element of the destination operand.
Memory destination version: Only the contiguous vector is written to the destination memory location. EVEX.z must be zero.
Register destination version: If the vector length of the contiguous vector is less than that of the input vector in the source operand, the upper bits of the destination register are unmodified if EVEX.z is not set, otherwise the upper bits are zeroed.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Compress (store) up to 8 double precision floating-point values from the source operand (the second operand) as a contiguous vector to the destination operand (the first operand) The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VCOMPRESSPD.html"
};
case "VCOMPRESSPS":
return {
- "html": "
Compress (stores) up to 16 single-precision floating-point values from the source operand (the second operand) to the destination operand (the first operand). The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The opmask register k1 selects the active elements (a partial vector or possibly non-contiguous if less than 16 active elements) from the source operand to compress into a contiguous vector. The contiguous vector is written to the destination starting from the low element of the destination operand.
Memory destination version: Only the contiguous vector is written to the destination memory location. EVEX.z must be zero.
Register destination version: If the vector length of the contiguous vector is less than that of the input vector in the source operand, the upper bits of the destination register are unmodified if EVEX.z is not set, otherwise the upper bits are zeroed.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Compress (stores) up to 16 single-precision floating-point values from the source operand (the second operand) to the destination operand (the first operand). The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.",
+ "html": "
Compress (stores) up to 16 single precision floating-point values from the source operand (the second operand) to the destination operand (the first operand). The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The opmask register k1 selects the active elements (a partial vector or possibly non-contiguous if less than 16 active elements) from the source operand to compress into a contiguous vector. The contiguous vector is written to the destination starting from the low element of the destination operand.
Memory destination version: Only the contiguous vector is written to the destination memory location. EVEX.z must be zero.
Register destination version: If the vector length of the contiguous vector is less than that of the input vector in the source operand, the upper bits of the destination register are unmodified if EVEX.z is not set, otherwise the upper bits are zeroed.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Compress (stores) up to 16 single precision floating-point values from the source operand (the second operand) to the destination operand (the first operand). The source operand is a ZMM/YMM/XMM register, the destination operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VCOMPRESSPS.html"
};
@@ -3558,183 +3586,191 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VCVTPD2QQ":
return {
- "html": "
Converts packed double-precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts packed double-precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).",
+ "html": "
Converts packed double precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts packed double precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTPD2QQ.html"
};
case "VCVTPD2UDQ":
return {
- "html": "
Converts packed double-precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts packed double-precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).",
+ "html": "
Converts packed double precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts packed double precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTPD2UDQ.html"
};
case "VCVTPD2UQQ":
return {
- "html": "
Converts packed double-precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts packed double-precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).",
+ "html": "
Converts packed double precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts packed double precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTPD2UQQ.html"
};
case "VCVTPH2PS":
+ case "VCVTPH2PSX":
return {
- "html": "
Converts packed half precision (16-bits) floating-point values in the low-order bits of the source operand (the second operand) to packed single-precision floating-point values and writes the converted values into the destination operand (the first operand).
If case of a denormal operand, the correct normal result is returned. MXCSR.DAZ is ignored and is treated as if it 0. No denormal exception is reported on MXCSR.
VEX.128 version: The source operand is a XMM register or 64-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 version: The source operand is a XMM register or 128-bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64-bits) register or a 256/128/64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
",
- "tooltip": "Converts packed half precision (16-bits) floating-point values in the low-order bits of the source operand (the second operand) to packed single-precision floating-point values and writes the converted values into the destination operand (the first operand).",
- "url": "https://www.felixcloutier.com/x86/VCVTPH2PS.html"
+ "html": "
This instruction converts packed half precision (16-bits) floating-point values in the low-order bits of the source operand (the second operand) to packed single precision floating-point values and writes the converted values into the destination operand (the first operand).
If case of a denormal operand, the correct normal result is returned. MXCSR.DAZ is ignored and is treated as if it 0. No denormal exception is reported on MXCSR.
VEX.128 version: The source operand is a XMM register or 64-bit memory location. The destination operand is a XMM register. The upper bits (MAXVL-1:128) of the corresponding destination register are zeroed.
VEX.256 version: The source operand is a XMM register or 128-bit memory location. The destination operand is a YMM register. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64-bits) register or a 256/128/64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
",
+ "tooltip": "This instruction converts packed half precision (16-bits) floating-point values in the low-order bits of the source operand (the second operand) to packed single precision floating-point values and writes the converted values into the destination operand (the first operand).",
+ "url": "https://www.felixcloutier.com/x86/VCVTPH2PS%3AVCVTPH2PSX.html"
};
case "VCVTPS2PH":
return {
- "html": "
Convert packed single-precision floating values in the source operand to half-precision (16-bit) floating-point values and store to the destination operand. The rounding mode is specified using the immediate field (imm8).
Underflow results (i.e., tiny results) are converted to denormals. MXCSR.FTZ is ignored. If a source element is denormal relative to the input format with DM masked and at least one of PM or UM unmasked; a SIMD exception will be raised with DE, UE and PE set.
The immediate byte defines several bit fields that control rounding operation. The effect and encoding of the RC field are listed in Table 5-12.
VEX.128 version: The source operand is a XMM register. The destination operand is a XMM register or 64-bit memory location. If the destination operand is a register then the upper bits (MAXVL-1:64) of corresponding register are zeroed.
VEX.256 version: The source operand is a YMM register. The destination operand is a XMM register or 128-bit memory location. If the destination operand is a register, the upper bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
+ "html": "
Convert packed single-precision floating values in the source operand to half-precision (16-bit) floating-point values and store to the destination operand. The rounding mode is specified using the immediate field (imm8).
Underflow results (i.e., tiny results) are converted to denormals. MXCSR.FTZ is ignored. If a source element is denormal relative to the input format with DM masked and at least one of PM or UM unmasked; a SIMD exception will be raised with DE, UE and PE set.
The immediate byte defines several bit fields that control rounding operation. The effect and encoding of the RC field are listed in Table 5-13.
VEX.128 version: The source operand is a XMM register. The destination operand is a XMM register or 64-bit memory location. If the destination operand is a register then the upper bits (MAXVL-1:64) of corresponding register are zeroed.
VEX.256 version: The source operand is a YMM register. The destination operand is a XMM register or 128-bit memory location. If the destination operand is a register, the upper bits (MAXVL-1:128) of the corresponding destination register are zeroed.
",
"tooltip": "Convert packed single-precision floating values in the source operand to half-precision (16-bit) floating-point values and store to the destination operand. The rounding mode is specified using the immediate field (imm8).",
"url": "https://www.felixcloutier.com/x86/VCVTPS2PH.html"
};
+ case "VCVTPS2PHX":
+ return {
+ "html": "
This instruction converts packed single precision floating values in the source operand to FP16 values and stores to the destination operand.
The VCVTPS2PHX instruction supports broadcasting.
This instruction uses MXCSR.DAZ for handling FP32 inputs. FP16 outputs can be normal or denormal numbers, and are not conditionally flushed based on MXCSR settings.
",
+ "tooltip": "This instruction converts packed single precision floating values in the source operand to FP16 values and stores to the destination operand.",
+ "url": "https://www.felixcloutier.com/x86/VCVTPS2PHX.html"
+ };
+
case "VCVTPS2QQ":
return {
- "html": "
Converts eight packed single-precision floating-point values in the source operand to eight signed quadword integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
The source operand is a YMM/XMM/XMM (low 64- bits) register or a 256/128/64-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts eight packed single-precision floating-point values in the source operand to eight signed quadword integers in the destination operand.",
+ "html": "
Converts eight packed single precision floating-point values in the source operand to eight signed quadword integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
The source operand is a YMM/XMM/XMM (low 64- bits) register or a 256/128/64-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts eight packed single precision floating-point values in the source operand to eight signed quadword integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VCVTPS2QQ.html"
};
case "VCVTPS2UDQ":
return {
- "html": "
Converts sixteen packed single-precision floating-point values in the source operand to sixteen unsigned double-word integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts sixteen packed single-precision floating-point values in the source operand to sixteen unsigned double-word integers in the destination operand.",
+ "html": "
Converts sixteen packed single precision floating-point values in the source operand to sixteen unsigned double-word integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts sixteen packed single precision floating-point values in the source operand to sixteen unsigned double-word integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VCVTPS2UDQ.html"
};
case "VCVTPS2UQQ":
return {
- "html": "
Converts up to eight packed single-precision floating-point values in the source operand to unsigned quadword integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a YMM/XMM/XMM (low 64- bits) register or a 256/128/64-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts up to eight packed single-precision floating-point values in the source operand to unsigned quadword integers in the destination operand.",
+ "html": "
Converts up to eight packed single precision floating-point values in the source operand to unsigned quadword integers in the destination operand.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a YMM/XMM/XMM (low 64- bits) register or a 256/128/64-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts up to eight packed single precision floating-point values in the source operand to unsigned quadword integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VCVTPS2UQQ.html"
};
case "VCVTQQ2PD":
return {
- "html": "
Converts packed quadword integers in the source operand (second operand) to packed double-precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts packed quadword integers in the source operand (second operand) to packed double-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts packed quadword integers in the source operand (second operand) to packed double precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts packed quadword integers in the source operand (second operand) to packed double precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTQQ2PD.html"
};
case "VCVTQQ2PS":
return {
- "html": "
Converts packed quadword integers in the source operand (second operand) to packed single-precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a YMM/XMM/XMM (lower 64 bits) register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts packed quadword integers in the source operand (second operand) to packed single-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts packed quadword integers in the source operand (second operand) to packed single precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a YMM/XMM/XMM (lower 64 bits) register conditionally updated with writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts packed quadword integers in the source operand (second operand) to packed single precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTQQ2PS.html"
};
case "VCVTSD2USI":
return {
- "html": "
Converts a double-precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
",
- "tooltip": "Converts a double-precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.",
+ "html": "
Converts a double precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
",
+ "tooltip": "Converts a double precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.",
"url": "https://www.felixcloutier.com/x86/VCVTSD2USI.html"
};
case "VCVTSS2USI":
return {
- "html": "
Converts a single-precision floating-point value in the source operand (the second operand) to an unsigned double-word integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
VEX.W1 and EVEX.W1 versions: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts a single-precision floating-point value in the source operand (the second operand) to an unsigned double-word integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.",
+ "html": "
Converts a single precision floating-point value in the source operand (the second operand) to an unsigned double-word integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
VEX.W1 and EVEX.W1 versions: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts a single precision floating-point value in the source operand (the second operand) to an unsigned double-word integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.",
"url": "https://www.felixcloutier.com/x86/VCVTSS2USI.html"
};
case "VCVTTPD2QQ":
return {
- "html": "
Converts with truncation packed double-precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts with truncation packed double-precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).",
+ "html": "
Converts with truncation packed double precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts with truncation packed double precision floating-point values in the source operand (second operand) to packed quadword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTTPD2QQ.html"
};
case "VCVTTPD2UDQ":
return {
- "html": "
Converts with truncation packed double-precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM/XMM/XMM (low 64 bits) register conditionally updated with writemask k1. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts with truncation packed double-precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).",
+ "html": "
Converts with truncation packed double precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM/XMM/XMM (low 64 bits) register conditionally updated with writemask k1. The upper bits (MAXVL-1:256) of the corresponding destination are zeroed.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts with truncation packed double precision floating-point values in the source operand (the second operand) to packed unsigned doubleword integers in the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTTPD2UDQ.html"
};
case "VCVTTPD2UQQ":
return {
- "html": "
Converts with truncation packed double-precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts with truncation packed double-precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).",
+ "html": "
Converts with truncation packed double precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operation is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts with truncation packed double precision floating-point values in the source operand (second operand) to packed unsigned quadword integers in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTTPD2UQQ.html"
};
case "VCVTTPS2QQ":
return {
- "html": "
Converts with truncation packed single-precision floating-point values in the source operand to eight signed quadword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64 bits) register or a 256/128/64-bit memory location. The destination operation is a vector register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts with truncation packed single-precision floating-point values in the source operand to eight signed quadword integers in the destination operand.",
+ "html": "
Converts with truncation packed single precision floating-point values in the source operand to eight signed quadword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned.
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64 bits) register or a 256/128/64-bit memory location. The destination operation is a vector register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts with truncation packed single precision floating-point values in the source operand to eight signed quadword integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VCVTTPS2QQ.html"
};
case "VCVTTPS2UDQ":
return {
- "html": "
Converts with truncation packed single-precision floating-point values in the source operand to sixteen unsigned doubleword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts with truncation packed single-precision floating-point values in the source operand to sixteen unsigned doubleword integers in the destination operand.",
+ "html": "
Converts with truncation packed single precision floating-point values in the source operand to sixteen unsigned doubleword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts with truncation packed single precision floating-point values in the source operand to sixteen unsigned doubleword integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VCVTTPS2UDQ.html"
};
case "VCVTTPS2UQQ":
return {
- "html": "
Converts with truncation up to eight packed single-precision floating-point values in the source operand to unsigned quadword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64 bits) register or a 256/128/64-bit memory location. The destination operation is a vector register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Converts with truncation up to eight packed single-precision floating-point values in the source operand to unsigned quadword integers in the destination operand.",
+ "html": "
Converts with truncation up to eight packed single precision floating-point values in the source operand to unsigned quadword integers in the destination operand.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX encoded versions: The source operand is a YMM/XMM/XMM (low 64 bits) register or a 256/128/64-bit memory location. The destination operation is a vector register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Converts with truncation up to eight packed single precision floating-point values in the source operand to unsigned quadword integers in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VCVTTPS2UQQ.html"
};
case "VCVTTSD2USI":
return {
- "html": "
Converts with truncation a double-precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX.W1 version: promotes the instruction to produce 64-bit data in 64-bit mode.
",
- "tooltip": "Converts with truncation a double-precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double-precision floating-point value is contained in the low quadword of the register.",
+ "html": "
Converts with truncation a double precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX.W1 version: promotes the instruction to produce 64-bit data in 64-bit mode.
",
+ "tooltip": "Converts with truncation a double precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a 64-bit memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the double precision floating-point value is contained in the low quadword of the register.",
"url": "https://www.felixcloutier.com/x86/VCVTTSD2USI.html"
};
case "VCVTTSS2USI":
return {
- "html": "
Converts with truncation a single-precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX.W1 version: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts with truncation a single-precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single-precision floating-point value is contained in the low doubleword of the register.",
+ "html": "
Converts with truncation a single precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.
When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the integer value 2w \u2013 1 is returned, where w represents the number of bits in the destination format.
EVEX.W1 version: promotes the instruction to produce 64-bit data in 64-bit mode.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts with truncation a single precision floating-point value in the source operand (the second operand) to an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the destination operand (the first operand). The source operand can be an XMM register or a memory location. The destination operand is a general-purpose register. When the source operand is an XMM register, the single precision floating-point value is contained in the low doubleword of the register.",
"url": "https://www.felixcloutier.com/x86/VCVTTSS2USI.html"
};
case "VCVTUDQ2PD":
return {
- "html": "
Converts packed unsigned doubleword integers in the source operand (second operand) to packed double-precision floating-point values in the destination operand (first operand).
The source operand is a YMM/XMM/XMM (low 64 bits) register, a 256/128/64-bit memory location or a 256/128/64-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Attempt to encode this instruction with EVEX embedded rounding is ignored.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts packed unsigned doubleword integers in the source operand (second operand) to packed double-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts packed unsigned doubleword integers in the source operand (second operand) to packed double precision floating-point values in the destination operand (first operand).
The source operand is a YMM/XMM/XMM (low 64 bits) register, a 256/128/64-bit memory location or a 256/128/64-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Attempt to encode this instruction with EVEX embedded rounding is ignored.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts packed unsigned doubleword integers in the source operand (second operand) to packed double precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTUDQ2PD.html"
};
case "VCVTUDQ2PS":
return {
- "html": "
Converts packed unsigned doubleword integers in the source operand (second operand) to single-precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts packed unsigned doubleword integers in the source operand (second operand) to single-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts packed unsigned doubleword integers in the source operand (second operand) to single precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts packed unsigned doubleword integers in the source operand (second operand) to single precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTUDQ2PS.html"
};
case "VCVTUQQ2PD":
return {
- "html": "
Converts packed unsigned quadword integers in the source operand (second operand) to packed double-precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts packed unsigned quadword integers in the source operand (second operand) to packed double-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts packed unsigned quadword integers in the source operand (second operand) to packed double precision floating-point values in the destination operand (first operand).
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM/YMM/XMM register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts packed unsigned quadword integers in the source operand (second operand) to packed double precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTUQQ2PD.html"
};
case "VCVTUQQ2PS":
return {
- "html": "
Converts packed unsigned quadword integers in the source operand (second operand) to single-precision floating-point values in the destination operand (first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a YMM/XMM/XMM (low 64 bits) register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
- "tooltip": "Converts packed unsigned quadword integers in the source operand (second operand) to single-precision floating-point values in the destination operand (first operand).",
+ "html": "
Converts packed unsigned quadword integers in the source operand (second operand) to single precision floating-point values in the destination operand (first operand).
EVEX encoded versions: The source operand is a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a YMM/XMM/XMM (low 64 bits) register conditionally updated with writemask k1.
Note: EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
",
+ "tooltip": "Converts packed unsigned quadword integers in the source operand (second operand) to single precision floating-point values in the destination operand (first operand).",
"url": "https://www.felixcloutier.com/x86/VCVTUQQ2PS.html"
};
case "VCVTUSI2SD":
return {
- "html": "
Converts an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the second source operand to a double-precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
The second source operand can be a general-purpose register or a 32/64-bit memory location. The first source and destination operands are XMM registers. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.W1 version: promotes the instruction to use 64-bit input value in 64-bit mode.
EVEX.W0 version: attempt to encode this instruction with EVEX embedded rounding is ignored.
",
- "tooltip": "Converts an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the second source operand to a double-precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.",
+ "html": "
Converts an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the second source operand to a double precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.
The second source operand can be a general-purpose register or a 32/64-bit memory location. The first source and destination operands are XMM registers. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.W1 version: promotes the instruction to use 64-bit input value in 64-bit mode.
EVEX.W0 version: attempt to encode this instruction with EVEX embedded rounding is ignored.
",
+ "tooltip": "Converts an unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the second source operand to a double precision floating-point value in the destination operand. The result is stored in the low quadword of the destination operand. When conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register.",
"url": "https://www.felixcloutier.com/x86/VCVTUSI2SD.html"
};
case "VCVTUSI2SS":
return {
- "html": "
Converts a unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the source operand (second operand) to a single-precision floating-point value in the destination operand (first operand). The source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.
The second source operand can be a general-purpose register or a 32/64-bit memory location. The first source and destination operands are XMM registers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.W1 version: promotes the instruction to use 64-bit input value in 64-bit mode.
",
- "tooltip": "Converts a unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the source operand (second operand) to a single-precision floating-point value in the destination operand (first operand). The source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.",
+ "html": "
Converts a unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the source operand (second operand) to a single precision floating-point value in the destination operand (first operand). The source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.
The second source operand can be a general-purpose register or a 32/64-bit memory location. The first source and destination operands are XMM registers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
EVEX.W1 version: promotes the instruction to use 64-bit input value in 64-bit mode.
",
+ "tooltip": "Converts a unsigned doubleword integer (or unsigned quadword integer if operand size is 64 bits) in the source operand (second operand) to a single precision floating-point value in the destination operand (first operand). The source operand can be a general-purpose register or a memory location. The destination operand is an XMM register. The result is stored in the low doubleword of the destination operand. When a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits.",
"url": "https://www.felixcloutier.com/x86/VCVTUSI2SS.html"
};
@@ -3762,29 +3798,29 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VEXP2PD":
return {
- "html": "
Computes the approximate base-2 exponential evaluation of the double-precision floating-point values in the source operand (the second operand) and stores the results to the destination operand (the first operand) using the writemask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.
Denormal input values are treated as zeros and do not signal #DE, irrespective of MXCSR.DAZ. Denormal results are flushed to zeros and do not signal #UE, irrespective of MXCSR.FTZ.
The source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Computes the approximate base-2 exponential evaluation of the double-precision floating-point values in the source operand (the second operand) and stores the results to the destination operand (the first operand) using the writemask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.",
+ "html": "
Computes the approximate base-2 exponential evaluation of the double precision floating-point values in the source operand (the second operand) and stores the results to the destination operand (the first operand) using the writemask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.
Denormal input values are treated as zeros and do not signal #DE, irrespective of MXCSR.DAZ. Denormal results are flushed to zeros and do not signal #UE, irrespective of MXCSR.FTZ.
The source operand is a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Computes the approximate base-2 exponential evaluation of the double precision floating-point values in the source operand (the second operand) and stores the results to the destination operand (the first operand) using the writemask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.",
"url": "https://www.felixcloutier.com/x86/VEXP2PD.html"
};
case "VEXP2PS":
return {
- "html": "
Computes the approximate base-2 exponential evaluation of the single-precision floating-point values in the source operand (the second operand) and store the results in the destination operand (the first operand) using the writemask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.
Denormal input values are treated as zeros and do not signal #DE, irrespective of MXCSR.DAZ. Denormal results are flushed to zeros and do not signal #UE, irrespective of MXCSR.FTZ.
The source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "Computes the approximate base-2 exponential evaluation of the single-precision floating-point values in the source operand (the second operand) and store the results in the destination operand (the first operand) using the writemask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.",
+ "html": "
Computes the approximate base-2 exponential evaluation of the single-precision floating-point values in the source operand (the second operand) and store the results in the destination operand (the first operand) using the write-mask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.
Denormal input values are treated as zeros and do not signal #DE, irrespective of MXCSR.DAZ. Denormal results are flushed to zeros and do not signal #UE, irrespective of MXCSR.FTZ.
The source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "Computes the approximate base-2 exponential evaluation of the single-precision floating-point values in the source operand (the second operand) and store the results in the destination operand (the first operand) using the write-mask k1. The approximate base-2 exponential is evaluated with less than 2^-23 of relative error.",
"url": "https://www.felixcloutier.com/x86/VEXP2PS.html"
};
case "VEXPANDPD":
return {
- "html": "
Expand (load) up to 8/4/2, contiguous, double-precision floating-point values of the input vector in the source operand (the second operand) to sparse elements in the destination operand (the first operand) selected by the writemask k1.
The destination operand is a ZMM/YMM/XMM register, the source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The input vector starts from the lowest element in the source operand. The writemask register k1 selects the destination elements (a partial vector or sparse elements if less than 8 elements) to be replaced by the ascending elements in the input vector. Destination elements not selected by the writemask k1 are either unmodified or zeroed, depending on EVEX.z.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
Note that the compressed displacement assumes a pre-scaling (N) corresponding to the size of one single element instead of the size of the full vector.
",
- "tooltip": "Expand (load) up to 8/4/2, contiguous, double-precision floating-point values of the input vector in the source operand (the second operand) to sparse elements in the destination operand (the first operand) selected by the writemask k1.",
+ "html": "
Expand (load) up to 8/4/2, contiguous, double precision floating-point values of the input vector in the source operand (the second operand) to sparse elements in the destination operand (the first operand) selected by the writemask k1.
The destination operand is a ZMM/YMM/XMM register, the source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The input vector starts from the lowest element in the source operand. The writemask register k1 selects the destination elements (a partial vector or sparse elements if less than 8 elements) to be replaced by the ascending elements in the input vector. Destination elements not selected by the writemask k1 are either unmodified or zeroed, depending on EVEX.z.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
Note that the compressed displacement assumes a pre-scaling (N) corresponding to the size of one single element instead of the size of the full vector.
",
+ "tooltip": "Expand (load) up to 8/4/2, contiguous, double precision floating-point values of the input vector in the source operand (the second operand) to sparse elements in the destination operand (the first operand) selected by the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VEXPANDPD.html"
};
case "VEXPANDPS":
return {
- "html": "
Expand (load) up to 16/8/4, contiguous, single-precision floating-point values of the input vector in the source operand (the second operand) to sparse elements of the destination operand (the first operand) selected by the writemask k1.
The destination operand is a ZMM/YMM/XMM register, the source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The input vector starts from the lowest element in the source operand. The writemask k1 selects the destination elements (a partial vector or sparse elements if less than 16 elements) to be replaced by the ascending elements in the input vector. Destination elements not selected by the writemask k1 are either unmodified or zeroed, depending on EVEX.z.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
Note that the compressed displacement assumes a pre-scaling (N) corresponding to the size of one single element instead of the size of the full vector.
",
- "tooltip": "Expand (load) up to 16/8/4, contiguous, single-precision floating-point values of the input vector in the source operand (the second operand) to sparse elements of the destination operand (the first operand) selected by the writemask k1.",
+ "html": "
Expand (load) up to 16/8/4, contiguous, single precision floating-point values of the input vector in the source operand (the second operand) to sparse elements of the destination operand (the first operand) selected by the writemask k1.
The destination operand is a ZMM/YMM/XMM register, the source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location.
The input vector starts from the lowest element in the source operand. The writemask k1 selects the destination elements (a partial vector or sparse elements if less than 16 elements) to be replaced by the ascending elements in the input vector. Destination elements not selected by the writemask k1 are either unmodified or zeroed, depending on EVEX.z.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
Note that the compressed displacement assumes a pre-scaling (N) corresponding to the size of one single element instead of the size of the full vector.
",
+ "tooltip": "Expand (load) up to 16/8/4, contiguous, single precision floating-point values of the input vector in the source operand (the second operand) to sparse elements of the destination operand (the first operand) selected by the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VEXPANDPS.html"
};
@@ -3793,8 +3829,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VEXTRACTF32X8":
case "VEXTRACTF64X2":
return {
- "html": "
VEXTRACTF128/VEXTRACTF32x4 and VEXTRACTF64x2 extract 128-bits of single-precision floating-point values from the source operand (the second operand) and store to the low 128-bit of the destination operand (the first operand). The 128-bit data extraction occurs at an 128-bit granular offset specified by imm8[0] (256-bit) or imm8[1:0] as the multiply factor. The destination may be either a vector register or an 128-bit memory location.
VEXTRACTF32x4: The low 128-bit of the destination operand is updated at 32-bit granularity according to the writemask.
VEXTRACTF32x8 and VEXTRACTF64x4 extract 256-bits of double-precision floating-point values from the source operand (second operand) and store to the low 256-bit of the destination operand (the first operand). The 256-bit data extraction occurs at an 256-bit granular offset specified by imm8[0] (256-bit) or imm8[0] as the multiply factor The destination may be either a vector register or a 256-bit memory location.
VEXTRACTF64x4: The low 256-bit of the destination operand is updated at 64-bit granularity according to the writemask.
VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "VEXTRACTF128/VEXTRACTF32x4 and VEXTRACTF64x2 extract 128-bits of single-precision floating-point values from the source operand (the second operand) and store to the low 128-bit of the destination operand (the first operand). The 128-bit data extraction occurs at an 128-bit granular offset specified by imm8[0] (256-bit) or imm8[1:0] as the multiply factor. The destination may be either a vector register or an 128-bit memory location.",
+ "html": "
VEXTRACTF128/VEXTRACTF32x4 and VEXTRACTF64x2 extract 128-bits of single precision floating-point values from the source operand (the second operand) and store to the low 128-bit of the destination operand (the first operand). The 128-bit data extraction occurs at an 128-bit granular offset specified by imm8[0] (256-bit) or imm8[1:0] as the multiply factor. The destination may be either a vector register or an 128-bit memory location.
VEXTRACTF32x4: The low 128-bit of the destination operand is updated at 32-bit granularity according to the writemask.
VEXTRACTF32x8 and VEXTRACTF64x4 extract 256-bits of double precision floating-point values from the source operand (second operand) and store to the low 256-bit of the destination operand (the first operand). The 256-bit data extraction occurs at an 256-bit granular offset specified by imm8[0] (256-bit) or imm8[0] as the multiply factor The destination may be either a vector register or a 256-bit memory location.
VEXTRACTF64x4: The low 256-bit of the destination operand is updated at 64-bit granularity according to the writemask.
VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "VEXTRACTF128/VEXTRACTF32x4 and VEXTRACTF64x2 extract 128-bits of single precision floating-point values from the source operand (the second operand) and store to the low 128-bit of the destination operand (the first operand). The 128-bit data extraction occurs at an 128-bit granular offset specified by imm8[0] (256-bit) or imm8[1:0] as the multiply factor. The destination may be either a vector register or an 128-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VEXTRACTF128%3AVEXTRACTF32x4%3AVEXTRACTF64x2%3AVEXTRACTF32x8%3AVEXTRACTF64x4.html"
};
@@ -3810,29 +3846,29 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFIXUPIMMPD":
return {
- "html": "
Perform fix-up of quad-word elements encoded in double-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).
The destination and the first source operands are ZMM/YMM/XMM registers. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
The two-level look-up table perform a fix-up of each DP FP input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPD can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
",
- "tooltip": "Perform fix-up of quad-word elements encoded in double-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).",
+ "html": "
Perform fix-up of quad-word elements encoded in double precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).
The destination and the first source operands are ZMM/YMM/XMM registers. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
The two-level look-up table perform a fix-up of each double precision floating-point input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPD can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
",
+ "tooltip": "Perform fix-up of quad-word elements encoded in double precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/VFIXUPIMMPD.html"
};
case "VFIXUPIMMPS":
return {
- "html": "
Perform fix-up of doubleword elements encoded in single-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).
The destination and the first source operands are ZMM/YMM/XMM registers. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
The two-level look-up table perform a fix-up of each SP FP input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPS can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
",
- "tooltip": "Perform fix-up of doubleword elements encoded in single-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).",
+ "html": "
Perform fix-up of doubleword elements encoded in single precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).
The destination and the first source operands are ZMM/YMM/XMM registers. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
The two-level look-up table perform a fix-up of each single precision floating-point input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPS can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
",
+ "tooltip": "Perform fix-up of doubleword elements encoded in single precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the corresponding doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The elements that are fixed-up are selected by mask bits of 1 specified in the opmask k1. Mask bits of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up elements from the first source operand and the preserved element in the first operand are combined as the final results in the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/VFIXUPIMMPS.html"
};
case "VFIXUPIMMSD":
return {
- "html": "
Perform a fix-up of the low quadword element encoded in double-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low quadword element of the destination operand (the first operand). Bits 127:64 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 64- bit memory location.
The two-level look-up table perform a fix-up of each DP FP input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPD can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
Imm8 is used to set the required flags reporting. It supports #ZE and #IE fault reporting (see details below).
",
- "tooltip": "Perform a fix-up of the low quadword element encoded in double-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low quadword element of the destination operand (the first operand). Bits 127:64 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 64- bit memory location.",
+ "html": "
Perform a fix-up of the low quadword element encoded in double precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low quadword element of the destination operand (the first operand). Bits 127:64 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 64- bit memory location.
The two-level look-up table perform a fix-up of each double precision floating-point input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPD can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
Imm8 is used to set the required flags reporting. It supports #ZE and #IE fault reporting (see details below).
",
+ "tooltip": "Perform a fix-up of the low quadword element encoded in double precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low quadword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low quadword element of the destination operand (the first operand). Bits 127:64 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 64- bit memory location.",
"url": "https://www.felixcloutier.com/x86/VFIXUPIMMSD.html"
};
case "VFIXUPIMMSS":
return {
- "html": "
Perform a fix-up of the low doubleword element encoded in single-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low doubleword element of the destination operand (the first operand) Bits 127:32 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 32-bit memory location.
The two-level look-up table perform a fix-up of each SP FP input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPD can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
Imm8 is used to set the required flags reporting. It supports #ZE and #IE fault reporting (see details below).
",
- "tooltip": "Perform a fix-up of the low doubleword element encoded in single-precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low doubleword element of the destination operand (the first operand) Bits 127:32 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 32-bit memory location.",
+ "html": "
Perform a fix-up of the low doubleword element encoded in single precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low doubleword element of the destination operand (the first operand) Bits 127:32 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 32-bit memory location.
The two-level look-up table perform a fix-up of each single precision floating-point input data in the first source operand by decoding the input data encoding into 8 token types. A response table is defined for each token type that converts the input encoding in the first source operand with one of 16 response actions.
This instruction is specifically intended for use in fixing up the results of arithmetic calculations involving one source so that they match the spec, although it is generally useful for fixing up the results of multiple-instruction sequences to reflect special-number inputs. For example, consider rcp(0). Input 0 to rcp, and you should get INF according to the DX10 spec. However, evaluating rcp via Newton-Raphson, where x=approx(1/0), yields an incorrect result. To deal with this, VFIXUPIMMPD can be used after the N-R reciprocal sequence to set the result to the correct value (i.e., INF when the input is 0).
If MXCSR.DAZ is not set, denormal input elements in the first source operand are considered as normal inputs and do not trigger any fixup nor fault reporting.
Imm8 is used to set the required flags reporting. It supports #ZE and #IE fault reporting (see details below).
",
+ "tooltip": "Perform a fix-up of the low doubleword element encoded in single precision floating-point format in the first source operand (the second operand) using a 32-bit, two-level look-up table specified in the low doubleword element of the second source operand (the third operand) with exception reporting specifier imm8. The element that is fixed-up is selected by mask bit of 1 specified in the opmask k1. Mask bit of 0 in the opmask k1 or table response action of 0000b preserves the corresponding element of the first operand. The fixed-up element from the first source operand or the preserved element in the first operand becomes the low doubleword element of the destination operand (the first operand) Bits 127:32 of the destination operand is copied from the corresponding bits of the first source operand. The destination and first source operands are XMM registers. The second source operand can be a XMM register or a 32-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VFIXUPIMMSS.html"
};
@@ -3840,8 +3876,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMADD213PD":
case "VFMADD231PD":
return {
- "html": "
Performs a set of SIMD multiply-add computation on packed double-precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMADD132PD: Multiplies the two, four or eight packed double-precision floating-point values from the first source operand to the two, four or eight packed double-precision floating-point values in the third source operand, adds the infinite precision intermediate result to the two, four or eight packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFMADD213PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source operand to the two, four or eight packed double-precision floating-point values in the first source operand, adds the infinite precision intermediate result to the two, four or eight packed double-precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFMADD231PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source to the two, four or eight packed double-precision floating-point values in the third source operand, adds the infinite precision intermediate result to the two, four or eight packed double-precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) is a ZMM register and encoded in reg_field. The second source operand is a ZMM register and encoded in EVEX.vvvv. The third source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
",
- "tooltip": "Performs a set of SIMD multiply-add computation on packed double-precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
+ "html": "
Performs a set of SIMD multiply-add computation on packed double precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMADD132PD: Multiplies the two, four or eight packed double precision floating-point values from the first source operand to the two, four or eight packed double precision floating-point values in the third source operand, adds the infinite precision intermediate result to the two, four or eight packed double precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFMADD213PD: Multiplies the two, four or eight packed double precision floating-point values from the second source operand to the two, four or eight packed double precision floating-point values in the first source operand, adds the infinite precision intermediate result to the two, four or eight packed double precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFMADD231PD: Multiplies the two, four or eight packed double precision floating-point values from the second source to the two, four or eight packed double precision floating-point values in the third source operand, adds the infinite precision intermediate result to the two, four or eight packed double precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) is a ZMM register and encoded in reg_field. The second source operand is a ZMM register and encoded in EVEX.vvvv. The third source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
",
+ "tooltip": "Performs a set of SIMD multiply-add computation on packed double precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
"url": "https://www.felixcloutier.com/x86/VFMADD132PD%3AVFMADD213PD%3AVFMADD231PD.html"
};
@@ -3849,8 +3885,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMADD213PS":
case "VFMADD231PS":
return {
- "html": "
Performs a set of SIMD multiply-add computation on packed single-precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMADD132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the four, eight or sixteen packed single-precision floating-point values in the third source operand, adds the infinite precision intermediate result to the four, eight or sixteen packed single-precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
VFMADD213PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the four, eight or sixteen packed single-precision floating-point values in the first source operand, adds the infinite precision intermediate result to the four, eight or sixteen packed single-precision floating-point values in the third source operand, performs rounding and stores the resulting the four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
VFMADD231PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the four, eight or sixteen packed single-precision floating-point values in the third source operand, adds the infinite precision intermediate result to the four, eight or sixteen packed single-precision floating-point values in the first source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) is a ZMM register and encoded in reg_field. The second source operand is a ZMM register and encoded in EVEX.vvvv. The third source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
",
- "tooltip": "Performs a set of SIMD multiply-add computation on packed single-precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
+ "html": "
Performs a set of SIMD multiply-add computation on packed single precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMADD132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the four, eight or sixteen packed single precision floating-point values in the third source operand, adds the infinite precision intermediate result to the four, eight or sixteen packed single precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
VFMADD213PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the four, eight or sixteen packed single precision floating-point values in the first source operand, adds the infinite precision intermediate result to the four, eight or sixteen packed single precision floating-point values in the third source operand, performs rounding and stores the resulting the four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
VFMADD231PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the four, eight or sixteen packed single precision floating-point values in the third source operand, adds the infinite precision intermediate result to the four, eight or sixteen packed single precision floating-point values in the first source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) is a ZMM register and encoded in reg_field. The second source operand is a ZMM register and encoded in EVEX.vvvv. The third source operand is a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
",
+ "tooltip": "Performs a set of SIMD multiply-add computation on packed single precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
"url": "https://www.felixcloutier.com/x86/VFMADD132PS%3AVFMADD213PS%3AVFMADD231PS.html"
};
@@ -3858,8 +3894,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMADD213SD":
case "VFMADD231SD":
return {
- "html": "
Performs a SIMD multiply-add computation on the low double-precision floating-point values using three source operands and writes the multiply-add result in the destination operand. The destination operand is also the first source operand. The first and second operand are XMM registers. The third source operand can be an XMM register or a 64-bit memory location.
VFMADD132SD: Multiplies the low double-precision floating-point value from the first source operand to the low double-precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low double-precision floating-point values in the second source operand, performs rounding and stores the resulting double-precision floating-point value to the destination operand (first source operand).
VFMADD213SD: Multiplies the low double-precision floating-point value from the second source operand to the low double-precision floating-point value in the first source operand, adds the infinite precision intermediate result to the low double-precision floating-point value in the third source operand, performs rounding and stores the resulting double-precision floating-point value to the destination operand (first source operand).
VFMADD231SD: Multiplies the low double-precision floating-point value from the second source to the low double-precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low double-precision floating-point value in the first source operand, performs rounding and stores the resulting double-precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
- "tooltip": "Performs a SIMD multiply-add computation on the low double-precision floating-point values using three source operands and writes the multiply-add result in the destination operand. The destination operand is also the first source operand. The first and second operand are XMM registers. The third source operand can be an XMM register or a 64-bit memory location.",
+ "html": "
Performs a SIMD multiply-add computation on the low double precision floating-point values using three source operands and writes the multiply-add result in the destination operand. The destination operand is also the first source operand. The first and second operand are XMM registers. The third source operand can be an XMM register or a 64-bit memory location.
VFMADD132SD: Multiplies the low double precision floating-point value from the first source operand to the low double precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low double precision floating-point values in the second source operand, performs rounding and stores the resulting double precision floating-point value to the destination operand (first source operand).
VFMADD213SD: Multiplies the low double precision floating-point value from the second source operand to the low double precision floating-point value in the first source operand, adds the infinite precision intermediate result to the low double precision floating-point value in the third source operand, performs rounding and stores the resulting double precision floating-point value to the destination operand (first source operand).
VFMADD231SD: Multiplies the low double precision floating-point value from the second source to the low double precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low double precision floating-point value in the first source operand, performs rounding and stores the resulting double precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
+ "tooltip": "Performs a SIMD multiply-add computation on the low double precision floating-point values using three source operands and writes the multiply-add result in the destination operand. The destination operand is also the first source operand. The first and second operand are XMM registers. The third source operand can be an XMM register or a 64-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VFMADD132SD%3AVFMADD213SD%3AVFMADD231SD.html"
};
@@ -3867,8 +3903,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMADD213SS":
case "VFMADD231SS":
return {
- "html": "
Performs a SIMD multiply-add computation on single-precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The first and second operands are XMM registers. The third source operand can be a XMM register or a 32-bit memory location.
VFMADD132SS: Multiplies the low single-precision floating-point value from the first source operand to the low single-precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low single-precision floating-point value in the second source operand, performs rounding and stores the resulting single-precision floating-point value to the destination operand (first source operand).
VFMADD213SS: Multiplies the low single-precision floating-point value from the second source operand to the low single-precision floating-point value in the first source operand, adds the infinite precision intermediate result to the low single-precision floating-point value in the third source operand, performs rounding and stores the resulting single-precision floating-point value to the destination operand (first source operand).
VFMADD231SS: Multiplies the low single-precision floating-point value from the second source operand to the low single-precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low single-precision floating-point value in the first source operand, performs rounding and stores the resulting single-precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:32 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
- "tooltip": "Performs a SIMD multiply-add computation on single-precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The first and second operands are XMM registers. The third source operand can be a XMM register or a 32-bit memory location.",
+ "html": "
Performs a SIMD multiply-add computation on single precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The first and second operands are XMM registers. The third source operand can be a XMM register or a 32-bit memory location.
VFMADD132SS: Multiplies the low single precision floating-point value from the first source operand to the low single precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low single precision floating-point value in the second source operand, performs rounding and stores the resulting single precision floating-point value to the destination operand (first source operand).
VFMADD213SS: Multiplies the low single precision floating-point value from the second source operand to the low single precision floating-point value in the first source operand, adds the infinite precision intermediate result to the low single precision floating-point value in the third source operand, performs rounding and stores the resulting single precision floating-point value to the destination operand (first source operand).
VFMADD231SS: Multiplies the low single precision floating-point value from the second source operand to the low single precision floating-point value in the third source operand, adds the infinite precision intermediate result to the low single precision floating-point value in the first source operand, performs rounding and stores the resulting single precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:32 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
+ "tooltip": "Performs a SIMD multiply-add computation on single precision floating-point values using three source operands and writes the multiply-add results in the destination operand. The destination operand is also the first source operand. The first and second operands are XMM registers. The third source operand can be a XMM register or a 32-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VFMADD132SS%3AVFMADD213SS%3AVFMADD231SS.html"
};
@@ -3876,8 +3912,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMADDSUB213PD":
case "VFMADDSUB231PD":
return {
- "html": "
VFMADDSUB132PD: Multiplies the two, four, or eight packed double-precision floating-point values from the first source operand to the two or four packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd double-precision floating-point elements and subtracts the even double-precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).
VFMADDSUB213PD: Multiplies the two, four, or eight packed double-precision floating-point values from the second source operand to the two or four packed double-precision floating-point values in the first source operand. From the infinite precision intermediate result, adds the odd double-precision floating-point elements and subtracts the even double-precision floating-point values in the third source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).
VFMADDSUB231PD: Multiplies the two, four, or eight packed double-precision floating-point values from the second source operand to the two or four packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd double-precision floating-point elements and subtracts the even double-precision floating-point values in the first source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
- "tooltip": "VFMADDSUB132PD: Multiplies the two, four, or eight packed double-precision floating-point values from the first source operand to the two or four packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd double-precision floating-point elements and subtracts the even double-precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).",
+ "html": "
VFMADDSUB132PD: Multiplies the two, four, or eight packed double precision floating-point values from the first source operand to the two or four packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd double precision floating-point elements and subtracts the even double precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).
VFMADDSUB213PD: Multiplies the two, four, or eight packed double precision floating-point values from the second source operand to the two or four packed double precision floating-point values in the first source operand. From the infinite precision intermediate result, adds the odd double precision floating-point elements and subtracts the even double precision floating-point values in the third source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).
VFMADDSUB231PD: Multiplies the two, four, or eight packed double precision floating-point values from the second source operand to the two or four packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd double precision floating-point elements and subtracts the even double precision floating-point values in the first source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
+ "tooltip": "VFMADDSUB132PD: Multiplies the two, four, or eight packed double precision floating-point values from the first source operand to the two or four packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd double precision floating-point elements and subtracts the even double precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFMADDSUB132PD%3AVFMADDSUB213PD%3AVFMADDSUB231PD.html"
};
@@ -3885,8 +3921,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMADDSUB213PS":
case "VFMADDSUB231PS":
return {
- "html": "
VFMADDSUB132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the corresponding packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd single-precision floating-point elements and subtracts the even single-precision floating-point values in the second source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).
VFMADDSUB213PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the corresponding packed single-precision floating-point values in the first source operand. From the infinite precision intermediate result, adds the odd single-precision floating-point elements and subtracts the even single-precision floating-point values in the third source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).
VFMADDSUB231PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the corresponding packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd single-precision floating-point elements and subtracts the even single-precision floating-point values in the first source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
- "tooltip": "VFMADDSUB132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the corresponding packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd single-precision floating-point elements and subtracts the even single-precision floating-point values in the second source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).",
+ "html": "
VFMADDSUB132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the corresponding packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd single precision floating-point elements and subtracts the even single precision floating-point values in the second source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).
VFMADDSUB213PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the corresponding packed single precision floating-point values in the first source operand. From the infinite precision intermediate result, adds the odd single precision floating-point elements and subtracts the even single precision floating-point values in the third source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).
VFMADDSUB231PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the corresponding packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd single precision floating-point elements and subtracts the even single precision floating-point values in the first source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
+ "tooltip": "VFMADDSUB132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the corresponding packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, adds the odd single precision floating-point elements and subtracts the even single precision floating-point values in the second source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFMADDSUB132PS%3AVFMADDSUB213PS%3AVFMADDSUB231PS.html"
};
@@ -3894,8 +3930,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMSUB213PD":
case "VFMSUB231PD":
return {
- "html": "
Performs a set of SIMD multiply-subtract computation on packed double-precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMSUB132PD: Multiplies the two, four or eight packed double-precision floating-point values from the first source operand to the two, four or eight packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the two, four or eight packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFMSUB213PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source operand to the two, four or eight packed double-precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the two, four or eight packed double-precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFMSUB231PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source to the two, four or eight packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the two, four or eight packed double-precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
",
- "tooltip": "Performs a set of SIMD multiply-subtract computation on packed double-precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
+ "html": "
Performs a set of SIMD multiply-subtract computation on packed double precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMSUB132PD: Multiplies the two, four or eight packed double precision floating-point values from the first source operand to the two, four or eight packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the two, four or eight packed double precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFMSUB213PD: Multiplies the two, four or eight packed double precision floating-point values from the second source operand to the two, four or eight packed double precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the two, four or eight packed double precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFMSUB231PD: Multiplies the two, four or eight packed double precision floating-point values from the second source to the two, four or eight packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the two, four or eight packed double precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
",
+ "tooltip": "Performs a set of SIMD multiply-subtract computation on packed double precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
"url": "https://www.felixcloutier.com/x86/VFMSUB132PD%3AVFMSUB213PD%3AVFMSUB231PD.html"
};
@@ -3903,8 +3939,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMSUB213PS":
case "VFMSUB231PS":
return {
- "html": "
Performs a set of SIMD multiply-subtract computation on packed single-precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMSUB132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the four, eight or sixteen packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the four, eight or sixteen packed single-precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
VFMSUB213PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the four, eight or sixteen packed single-precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the four, eight or sixteen packed single-precision floating-point values in the third source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
VFMSUB231PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source to the four, eight or sixteen packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the four, eight or sixteen packed single-precision floating-point values in the first source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
",
- "tooltip": "Performs a set of SIMD multiply-subtract computation on packed single-precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
+ "html": "
Performs a set of SIMD multiply-subtract computation on packed single precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.
VFMSUB132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the four, eight or sixteen packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the four, eight or sixteen packed single precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
VFMSUB213PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the four, eight or sixteen packed single precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the four, eight or sixteen packed single precision floating-point values in the third source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
VFMSUB231PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source to the four, eight or sixteen packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the four, eight or sixteen packed single precision floating-point values in the first source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
",
+ "tooltip": "Performs a set of SIMD multiply-subtract computation on packed single precision floating-point values using three source operands and writes the multiply-subtract results in the destination operand. The destination operand is also the first source operand. The second operand must be a SIMD register. The third source operand can be a SIMD register or a memory location.",
"url": "https://www.felixcloutier.com/x86/VFMSUB132PS%3AVFMSUB213PS%3AVFMSUB231PS.html"
};
@@ -3912,8 +3948,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMSUB213SD":
case "VFMSUB231SD":
return {
- "html": "
Performs a SIMD multiply-subtract computation on the low packed double-precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 64-bit memory location.
VFMSUB132SD: Multiplies the low packed double-precision floating-point value from the first source operand to the low packed double-precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VFMSUB213SD: Multiplies the low packed double-precision floating-point value from the second source operand to the low packed double-precision floating-point value in the first source operand. From the infinite precision intermediate result, subtracts the low packed double-precision floating-point value in the third source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VFMSUB231SD: Multiplies the low packed double-precision floating-point value from the second source to the low packed double-precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed double-precision floating-point value in the first source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
- "tooltip": "Performs a SIMD multiply-subtract computation on the low packed double-precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 64-bit memory location.",
+ "html": "
Performs a SIMD multiply-subtract computation on the low packed double precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 64-bit memory location.
VFMSUB132SD: Multiplies the low packed double precision floating-point value from the first source operand to the low packed double precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed double precision floating-point values in the second source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VFMSUB213SD: Multiplies the low packed double precision floating-point value from the second source operand to the low packed double precision floating-point value in the first source operand. From the infinite precision intermediate result, subtracts the low packed double precision floating-point value in the third source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VFMSUB231SD: Multiplies the low packed double precision floating-point value from the second source to the low packed double precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed double precision floating-point value in the first source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
+ "tooltip": "Performs a SIMD multiply-subtract computation on the low packed double precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 64-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VFMSUB132SD%3AVFMSUB213SD%3AVFMSUB231SD.html"
};
@@ -3921,8 +3957,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMSUB213SS":
case "VFMSUB231SS":
return {
- "html": "
Performs a SIMD multiply-subtract computation on the low packed single-precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 32-bit memory location.
VFMSUB132SS: Multiplies the low packed single-precision floating-point value from the first source operand to the low packed single-precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed single-precision floating-point values in the second source operand, performs rounding and stores the resulting packed single-precision floating-point value to the destination operand (first source operand).
VFMSUB213SS: Multiplies the low packed single-precision floating-point value from the second source operand to the low packed single-precision floating-point value in the first source operand. From the infinite precision intermediate result, subtracts the low packed single-precision floating-point value in the third source operand, performs rounding and stores the resulting packed single-precision floating-point value to the destination operand (first source operand).
VFMSUB231SS: Multiplies the low packed single-precision floating-point value from the second source to the low packed single-precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed single-precision floating-point value in the first source operand, performs rounding and stores the resulting packed single-precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:32 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
- "tooltip": "Performs a SIMD multiply-subtract computation on the low packed single-precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 32-bit memory location.",
+ "html": "
Performs a SIMD multiply-subtract computation on the low packed single precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 32-bit memory location.
VFMSUB132SS: Multiplies the low packed single precision floating-point value from the first source operand to the low packed single precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed single precision floating-point values in the second source operand, performs rounding and stores the resulting packed single precision floating-point value to the destination operand (first source operand).
VFMSUB213SS: Multiplies the low packed single precision floating-point value from the second source operand to the low packed single precision floating-point value in the first source operand. From the infinite precision intermediate result, subtracts the low packed single precision floating-point value in the third source operand, performs rounding and stores the resulting packed single precision floating-point value to the destination operand (first source operand).
VFMSUB231SS: Multiplies the low packed single precision floating-point value from the second source to the low packed single precision floating-point value in the third source operand. From the infinite precision intermediate result, subtracts the low packed single precision floating-point value in the first source operand, performs rounding and stores the resulting packed single precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:32 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
",
+ "tooltip": "Performs a SIMD multiply-subtract computation on the low packed single precision floating-point values using three source operands and writes the multiply-subtract result in the destination operand. The destination operand is also the first source operand. The second operand must be a XMM register. The third source operand can be a XMM register or a 32-bit memory location.",
"url": "https://www.felixcloutier.com/x86/VFMSUB132SS%3AVFMSUB213SS%3AVFMSUB231SS.html"
};
@@ -3930,8 +3966,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMSUBADD213PD":
case "VFMSUBADD231PD":
return {
- "html": "
VFMSUBADD132PD: Multiplies the two, four, or eight packed double-precision floating-point values from the first source operand to the two or four packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd double-precision floating-point elements and adds the even double-precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).
VFMSUBADD213PD: Multiplies the two, four, or eight packed double-precision floating-point values from the second source operand to the two or four packed double-precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the odd double-precision floating-point elements and adds the even double-precision floating-point values in the third source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).
VFMSUBADD231PD: Multiplies the two, four, or eight packed double-precision floating-point values from the second source operand to the two or four packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd double-precision floating-point elements and adds the even double-precision floating-point values in the first source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
- "tooltip": "VFMSUBADD132PD: Multiplies the two, four, or eight packed double-precision floating-point values from the first source operand to the two or four packed double-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd double-precision floating-point elements and adds the even double-precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double-precision floating-point values to the destination operand (first source operand).",
+ "html": "
VFMSUBADD132PD: Multiplies the two, four, or eight packed double precision floating-point values from the first source operand to the two or four packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd double precision floating-point elements and adds the even double precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).
VFMSUBADD213PD: Multiplies the two, four, or eight packed double precision floating-point values from the second source operand to the two or four packed double precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the odd double precision floating-point elements and adds the even double precision floating-point values in the third source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).
VFMSUBADD231PD: Multiplies the two, four, or eight packed double precision floating-point values from the second source operand to the two or four packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd double precision floating-point elements and adds the even double precision floating-point values in the first source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
+ "tooltip": "VFMSUBADD132PD: Multiplies the two, four, or eight packed double precision floating-point values from the first source operand to the two or four packed double precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd double precision floating-point elements and adds the even double precision floating-point values in the second source operand, performs rounding and stores the resulting two or four packed double precision floating-point values to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFMSUBADD132PD%3AVFMSUBADD213PD%3AVFMSUBADD231PD.html"
};
@@ -3939,8 +3975,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFMSUBADD213PS":
case "VFMSUBADD231PS":
return {
- "html": "
VFMSUBADD132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the corresponding packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd single-precision floating-point elements and adds the even single-precision floating-point values in the second source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).
VFMSUBADD213PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the corresponding packed single-precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the odd single-precision floating-point elements and adds the even single-precision floating-point values in the third source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).
VFMSUBADD231PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the corresponding packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd single-precision floating-point elements and adds the even single-precision floating-point values in the first source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
- "tooltip": "VFMSUBADD132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the corresponding packed single-precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd single-precision floating-point elements and adds the even single-precision floating-point values in the second source operand, performs rounding and stores the resulting packed single-precision floating-point values to the destination operand (first source operand).",
+ "html": "
VFMSUBADD132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the corresponding packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd single precision floating-point elements and adds the even single precision floating-point values in the second source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).
VFMSUBADD213PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the corresponding packed single precision floating-point values in the first source operand. From the infinite precision intermediate result, subtracts the odd single precision floating-point elements and adds the even single precision floating-point values in the third source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).
VFMSUBADD231PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the corresponding packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd single precision floating-point elements and adds the even single precision floating-point values in the first source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
+ "tooltip": "VFMSUBADD132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the corresponding packed single precision floating-point values in the third source operand. From the infinite precision intermediate result, subtracts the odd single precision floating-point elements and adds the even single precision floating-point values in the second source operand, performs rounding and stores the resulting packed single precision floating-point values to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFMSUBADD132PS%3AVFMSUBADD213PS%3AVFMSUBADD231PS.html"
};
@@ -3948,8 +3984,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFNMADD213PD":
case "VFNMADD231PD":
return {
- "html": "
VFNMADD132PD: Multiplies the two, four or eight packed double-precision floating-point values from the first source operand to the two, four or eight packed double-precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the two, four or eight packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFNMADD213PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source operand to the two, four or eight packed double-precision floating-point values in the first source operand, adds the negated infinite precision intermediate result to the two, four or eight packed double-precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFNMADD231PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source to the two, four or eight packed double-precision floating-point values in the third source operand, the negated infinite precision intermediate result to the two, four or eight packed double-precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
- "tooltip": "VFNMADD132PD: Multiplies the two, four or eight packed double-precision floating-point values from the first source operand to the two, four or eight packed double-precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the two, four or eight packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).",
+ "html": "
VFNMADD132PD: Multiplies the two, four or eight packed double precision floating-point values from the first source operand to the two, four or eight packed double precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the two, four or eight packed double precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFNMADD213PD: Multiplies the two, four or eight packed double precision floating-point values from the second source operand to the two, four or eight packed double precision floating-point values in the first source operand, adds the negated infinite precision intermediate result to the two, four or eight packed double precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFNMADD231PD: Multiplies the two, four or eight packed double precision floating-point values from the second source to the two, four or eight packed double precision floating-point values in the third source operand, the negated infinite precision intermediate result to the two, four or eight packed double precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
+ "tooltip": "VFNMADD132PD: Multiplies the two, four or eight packed double precision floating-point values from the first source operand to the two, four or eight packed double precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the two, four or eight packed double precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFNMADD132PD%3AVFNMADD213PD%3AVFNMADD231PD.html"
};
@@ -3957,8 +3993,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFNMADD213PS":
case "VFNMADD231PS":
return {
- "html": "
VFNMADD132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the four, eight or sixteen packed single-precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single-precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
VFNMADD213PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the four, eight or sixteen packed single-precision floating-point values in the first source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single-precision floating-point values in the third source operand, performs rounding and stores the resulting the four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
VFNMADD231PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the second source operand to the four, eight or sixteen packed single-precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single-precision floating-point values in the first source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
- "tooltip": "VFNMADD132PS: Multiplies the four, eight or sixteen packed single-precision floating-point values from the first source operand to the four, eight or sixteen packed single-precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single-precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single-precision floating-point values to the destination operand (first source operand).",
+ "html": "
VFNMADD132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the four, eight or sixteen packed single precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
VFNMADD213PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the four, eight or sixteen packed single precision floating-point values in the first source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single precision floating-point values in the third source operand, performs rounding and stores the resulting the four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
VFNMADD231PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the second source operand to the four, eight or sixteen packed single precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single precision floating-point values in the first source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
+ "tooltip": "VFNMADD132PS: Multiplies the four, eight or sixteen packed single precision floating-point values from the first source operand to the four, eight or sixteen packed single precision floating-point values in the third source operand, adds the negated infinite precision intermediate result to the four, eight or sixteen packed single precision floating-point values in the second source operand, performs rounding and stores the resulting four, eight or sixteen packed single precision floating-point values to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFNMADD132PS%3AVFNMADD213PS%3AVFNMADD231PS.html"
};
@@ -3966,8 +4002,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFNMADD213SD":
case "VFNMADD231SD":
return {
- "html": "
VFNMADD132SD: Multiplies the low packed double-precision floating-point value from the first source operand to the low packed double-precision floating-point value in the third source operand, adds the negated infinite precision intermediate result to the low packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VFNMADD213SD: Multiplies the low packed double-precision floating-point value from the second source operand to the low packed double-precision floating-point value in the first source operand, adds the negated infinite precision intermediate result to the low packed double-precision floating-point value in the third source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VFNMADD231SD: Multiplies the low packed double-precision floating-point value from the second source to the low packed double-precision floating-point value in the third source operand, adds the negated infinite precision intermediate result to the low packed double-precision floating-point value in the first source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination is updated according to the writemask.
",
- "tooltip": "VFNMADD132SD: Multiplies the low packed double-precision floating-point value from the first source operand to the low packed double-precision floating-point value in the third source operand, adds the negated infinite precision intermediate result to the low packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).",
+ "html": "
VFNMADD132SD: Multiplies the low packed double precision floating-point value from the first source operand to the low packed double precision floating-point value in the third source operand, adds the negated infinite precision intermediate result to the low packed double precision floating-point values in the second source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VFNMADD213SD: Multiplies the low packed double precision floating-point value from the second source operand to the low packed double precision floating-point value in the first source operand, adds the negated infinite precision intermediate result to the low packed double precision floating-point value in the third source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VFNMADD231SD: Multiplies the low packed double precision floating-point value from the second source to the low packed double precision floating-point value in the third source operand, adds the negated infinite precision intermediate result to the low packed double precision floating-point value in the first source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination is updated according to the writemask.
",
+ "tooltip": "VFNMADD132SD: Multiplies the low packed double precision floating-point value from the first source operand to the low packed double precision floating-point value in the third source operand, adds the negated infinite precision intermediate result to the low packed double precision floating-point values in the second source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFNMADD132SD%3AVFNMADD213SD%3AVFNMADD231SD.html"
};
@@ -3984,8 +4020,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFNMSUB213PD":
case "VFNMSUB231PD":
return {
- "html": "
VFNMSUB132PD: Multiplies the two, four or eight packed double-precision floating-point values from the first source operand to the two, four or eight packed double-precision floating-point values in the third source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFNMSUB213PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source operand to the two, four or eight packed double-precision floating-point values in the first source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double-precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
VFNMSUB231PD: Multiplies the two, four or eight packed double-precision floating-point values from the second source to the two, four or eight packed double-precision floating-point values in the third source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double-precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
- "tooltip": "VFNMSUB132PD: Multiplies the two, four or eight packed double-precision floating-point values from the first source operand to the two, four or eight packed double-precision floating-point values in the third source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double-precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double-precision floating-point values to the destination operand (first source operand).",
+ "html": "
VFNMSUB132PD: Multiplies the two, four or eight packed double precision floating-point values from the first source operand to the two, four or eight packed double precision floating-point values in the third source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFNMSUB213PD: Multiplies the two, four or eight packed double precision floating-point values from the second source operand to the two, four or eight packed double precision floating-point values in the first source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double precision floating-point values in the third source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
VFNMSUB231PD: Multiplies the two, four or eight packed double precision floating-point values from the second source to the two, four or eight packed double precision floating-point values in the third source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double precision floating-point values in the first source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).
EVEX encoded versions: The destination operand (also first source operand) and the second source operand are ZMM/YMM/XMM register. The third source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. The destination operand is conditionally updated with write mask k1.
VEX.256 encoded version: The destination operand (also first source operand) is a YMM register and encoded in reg_field. The second source operand is a YMM register and encoded in VEX.vvvv. The third source operand is a YMM register or a 256-bit memory location and encoded in rm_field.
",
+ "tooltip": "VFNMSUB132PD: Multiplies the two, four or eight packed double precision floating-point values from the first source operand to the two, four or eight packed double precision floating-point values in the third source operand. From negated infinite precision intermediate results, subtracts the two, four or eight packed double precision floating-point values in the second source operand, performs rounding and stores the resulting two, four or eight packed double precision floating-point values to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFNMSUB132PD%3AVFNMSUB213PD%3AVFNMSUB231PD.html"
};
@@ -4002,8 +4038,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFNMSUB213SD":
case "VFNMSUB231SD":
return {
- "html": "
VFNMSUB132SD: Multiplies the low packed double-precision floating-point value from the first source operand to the low packed double-precision floating-point value in the third source operand. From negated infinite precision intermediate result, subtracts the low double-precision floating-point value in the second source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VFNMSUB213SD: Multiplies the low packed double-precision floating-point value from the second source operand to the low packed double-precision floating-point value in the first source operand. From negated infinite precision intermediate result, subtracts the low double-precision floating-point value in the third source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VFNMSUB231SD: Multiplies the low packed double-precision floating-point value from the second source to the low packed double-precision floating-point value in the third source operand. From negated infinite precision intermediate result, subtracts the low double-precision floating-point value in the first source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination is updated according to the writemask.
",
- "tooltip": "VFNMSUB132SD: Multiplies the low packed double-precision floating-point value from the first source operand to the low packed double-precision floating-point value in the third source operand. From negated infinite precision intermediate result, subtracts the low double-precision floating-point value in the second source operand, performs rounding and stores the resulting packed double-precision floating-point value to the destination operand (first source operand).",
+ "html": "
VFNMSUB132SD: Multiplies the low packed double precision floating-point value from the first source operand to the low packed double precision floating-point value in the third source operand. From negated infinite precision intermediate result, subtracts the low double precision floating-point value in the second source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VFNMSUB213SD: Multiplies the low packed double precision floating-point value from the second source operand to the low packed double precision floating-point value in the first source operand. From negated infinite precision intermediate result, subtracts the low double precision floating-point value in the third source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VFNMSUB231SD: Multiplies the low packed double precision floating-point value from the second source to the low packed double precision floating-point value in the third source operand. From negated infinite precision intermediate result, subtracts the low double precision floating-point value in the first source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).
VEX.128 and EVEX encoded version: The destination operand (also first source operand) is encoded in reg_field. The second source operand is encoded in VEX.vvvv/EVEX.vvvv. The third source operand is encoded in rm_field. Bits 127:64 of the destination are unchanged. Bits MAXVL-1:128 of the destination register are zeroed.
EVEX encoded version: The low quadword element of the destination is updated according to the writemask.
",
+ "tooltip": "VFNMSUB132SD: Multiplies the low packed double precision floating-point value from the first source operand to the low packed double precision floating-point value in the third source operand. From negated infinite precision intermediate result, subtracts the low double precision floating-point value in the second source operand, performs rounding and stores the resulting packed double precision floating-point value to the destination operand (first source operand).",
"url": "https://www.felixcloutier.com/x86/VFNMSUB132SD%3AVFNMSUB213SD%3AVFNMSUB231SD.html"
};
@@ -4018,37 +4054,37 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VFPCLASSPD":
return {
- "html": "
The FPCLASSPD instruction checks the packed double precision floating point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:8/4/2] of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-13.
Classifier Checks for Checks for Checks for Checks for Checks for Checks for Checks for Checks for QNaN +0 0 +INF INF Denormal Negative finite SNaN
",
- "tooltip": "The FPCLASSPD instruction checks the packed double precision floating point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:8/4/2] of the destination are cleared.",
+ "html": "
The FPCLASSPD instruction checks the packed double precision floating-point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:8/4/2] of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-14.
Classifier Checks for Checks for Checks for Checks for Checks for Checks for Checks for Checks for QNaN +0 0 +INF INF Denormal Negative finite SNaN
",
+ "tooltip": "The FPCLASSPD instruction checks the packed double precision floating-point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:8/4/2] of the destination are cleared.",
"url": "https://www.felixcloutier.com/x86/VFPCLASSPD.html"
};
case "VFPCLASSPS":
return {
- "html": "
The FPCLASSPS instruction checks the packed single-precision floating point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:16/8/4] of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-13.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "The FPCLASSPS instruction checks the packed single-precision floating point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:16/8/4] of the destination are cleared.",
+ "html": "
The FPCLASSPS instruction checks the packed single-precision floating-point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:16/8/4] of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-14.
The source operand is a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "The FPCLASSPS instruction checks the packed single-precision floating-point values for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result of each element is written to the corresponding bit in a mask register k2 according to the writemask k1. Bits [MAX_KL-1:16/8/4] of the destination are cleared.",
"url": "https://www.felixcloutier.com/x86/VFPCLASSPS.html"
};
case "VFPCLASSSD":
return {
- "html": "
The FPCLASSSD instruction checks the low double precision floating point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-13.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "The FPCLASSSD instruction checks the low double precision floating point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.",
+ "html": "
The FPCLASSSD instruction checks the low double precision floating-point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-14.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "The FPCLASSSD instruction checks the low double precision floating-point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.",
"url": "https://www.felixcloutier.com/x86/VFPCLASSSD.html"
};
case "VFPCLASSSS":
return {
- "html": "
The FPCLASSSS instruction checks the low single-precision floating point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-13.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
- "tooltip": "The FPCLASSSS instruction checks the low single-precision floating point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.",
+ "html": "
The FPCLASSSS instruction checks the low single-precision floating-point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.
The classification categories specified by imm8 are shown in Figure 5-13. The classification test for each category is listed in Table 5-14.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
",
+ "tooltip": "The FPCLASSSS instruction checks the low single-precision floating-point value in the source operand for special categories, specified by the set bits in the imm8 byte. Each set bit in imm8 specifies a category of floating-point values that the input data element is classified against. The classified results of all specified categories of an input value are ORed together to form the final boolean result for the input element. The result is written to the low bit in a mask register k2 according to the writemask k1. Bits MAX_KL-1: 1 of the destination are cleared.",
"url": "https://www.felixcloutier.com/x86/VFPCLASSSS.html"
};
case "VGATHERDPD":
case "VGATHERQPD":
return {
- "html": "
The instruction conditionally loads up to 2 or 4 double-precision floating-point values from memory addresses specified by the memory operand (the second operand) and using qword indices. The memory operand uses the VSIB form of the SIB byte to specify a general purpose register operand as the common base, a vector register for an array of indices relative to the base and a constant scale factor.
The mask operand (the third operand) specifies the conditional load operation from each memory address and the corresponding update of each data element of the destination operand (the first operand). Conditionality is specified by the most significant bit of each data element of the mask register. If an element\u2019s mask bit is not set, the corresponding element of the destination register is left unchanged. The width of data element in the destination register and mask register are identical. The entire mask register will be set to zero by this instruction unless the instruction causes an exception.
Using dword indices in the lower half of the mask register, the instruction conditionally loads up to 2 or 4 double-precision floating-point values from the VSIB addressing memory operand, and updates the destination register.
This instruction can be suspended by an exception if at least one element is already gathered (i.e., if the exception is triggered by an element other than the rightmost one with its mask bit set). When this happens, the destination register and the mask operand are partially updated; those elements that have been gathered are placed into the destination register and have their mask bits set to zero. If any traps or interrupts are pending from already gathered elements, they will be delivered in lieu of the exception; in this case, EFLAG.RF is set to one so an instruction breakpoint is not re-triggered when the instruction is continued.
If the data size and index size are different, part of the destination register and part of the mask register do not correspond to any elements being gathered. This instruction sets those parts to zero. It may do this to one or both of those registers even if the instruction triggers an exception, and even if the instruction triggers the exception before gathering any elements.
",
- "tooltip": "The instruction conditionally loads up to 2 or 4 double-precision floating-point values from memory addresses specified by the memory operand (the second operand) and using qword indices. The memory operand uses the VSIB form of the SIB byte to specify a general purpose register operand as the common base, a vector register for an array of indices relative to the base and a constant scale factor.",
+ "html": "
The instruction conditionally loads up to 2 or 4 double precision floating-point values from memory addresses specified by the memory operand (the second operand) and using qword indices. The memory operand uses the VSIB form of the SIB byte to specify a general purpose register operand as the common base, a vector register for an array of indices relative to the base and a constant scale factor.
The mask operand (the third operand) specifies the conditional load operation from each memory address and the corresponding update of each data element of the destination operand (the first operand). Conditionality is specified by the most significant bit of each data element of the mask register. If an element\u2019s mask bit is not set, the corresponding element of the destination register is left unchanged. The width of data element in the destination register and mask register are identical. The entire mask register will be set to zero by this instruction unless the instruction causes an exception.
Using dword indices in the lower half of the mask register, the instruction conditionally loads up to 2 or 4 double precision floating-point values from the VSIB addressing memory operand, and updates the destination register.
This instruction can be suspended by an exception if at least one element is already gathered (i.e., if the exception is triggered by an element other than the rightmost one with its mask bit set). When this happens, the destination register and the mask operand are partially updated; those elements that have been gathered are placed into the destination register and have their mask bits set to zero. If any traps or interrupts are pending from already gathered elements, they will be delivered in lieu of the exception; in this case, EFLAG.RF is set to one so an instruction breakpoint is not re-triggered when the instruction is continued.
If the data size and index size are different, part of the destination register and part of the mask register do not correspond to any elements being gathered. This instruction sets those parts to zero. It may do this to one or both of those registers even if the instruction triggers an exception, and even if the instruction triggers the exception before gathering any elements.
",
+ "tooltip": "The instruction conditionally loads up to 2 or 4 double precision floating-point values from memory addresses specified by the memory operand (the second operand) and using qword indices. The memory operand uses the VSIB form of the SIB byte to specify a general purpose register operand as the common base, a vector register for an array of indices relative to the base and a constant scale factor.",
"url": "https://www.felixcloutier.com/x86/VGATHERDPD%3AVGATHERQPD.html"
};
@@ -4082,57 +4118,57 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VGETEXPPD":
return {
- "html": "
Extracts the biased exponents from the normalized DP FP representation of each qword data element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to double-precision FP value and written to the corresponding qword elements of the destination operand (the first operand) as DP FP numbers.
The destination operand is a ZMM/YMM/XMM register and updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
Each GETEXP operation converts the exponent value into a FP number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-14.
",
- "tooltip": "Extracts the biased exponents from the normalized DP FP representation of each qword data element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to double-precision FP value and written to the corresponding qword elements of the destination operand (the first operand) as DP FP numbers.",
+ "html": "
Extracts the biased exponents from the normalized double precision floating-point representation of each qword data element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to double precision floating-point value and written to the corresponding qword elements of the destination operand (the first operand) as double precision floating-point numbers.
The destination operand is a ZMM/YMM/XMM register and updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
Each GETEXP operation converts the exponent value into a floating-point number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-15.
",
+ "tooltip": "Extracts the biased exponents from the normalized double precision floating-point representation of each qword data element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to double precision floating-point value and written to the corresponding qword elements of the destination operand (the first operand) as double precision floating-point numbers.",
"url": "https://www.felixcloutier.com/x86/VGETEXPPD.html"
};
case "VGETEXPPS":
return {
- "html": "
Extracts the biased exponents from the normalized SP FP representation of each dword element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to single-precision FP value and written to the corresponding dword elements of the destination operand (the first operand) as SP FP numbers.
The destination operand is a ZMM/YMM/XMM register and updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location.
EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
Each GETEXP operation converts the exponent value into a FP number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-15.
",
- "tooltip": "Extracts the biased exponents from the normalized SP FP representation of each dword element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to single-precision FP value and written to the corresponding dword elements of the destination operand (the first operand) as SP FP numbers.",
+ "html": "
Extracts the biased exponents from the normalized single-precision floating-point representation of each dword element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to single-precision floating-point value and written to the corresponding dword elements of the destination operand (the first operand) as single-precision floating-point numbers.
The destination operand is a ZMM/YMM/XMM register and updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location.
EVEX.vvvv is reserved and must be 1111b, otherwise instructions will #UD.
Each GETEXP operation converts the exponent value into a floating-point number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-17.
",
+ "tooltip": "Extracts the biased exponents from the normalized single-precision floating-point representation of each dword element of the source operand (the second operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. Each integer value of the unbiased exponent is converted to single-precision floating-point value and written to the corresponding dword elements of the destination operand (the first operand) as single-precision floating-point numbers.",
"url": "https://www.felixcloutier.com/x86/VGETEXPPS.html"
};
case "VGETEXPSD":
return {
- "html": "
Extracts the biased exponent from the normalized DP FP representation of the low qword data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to double-precision FP value and written to the destination operand (the first operand) as DP FP numbers. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand.
The destination must be a XMM register, the source operand can be a XMM register or a float64 memory location.
If writemasking is used, the low quadword element of the destination operand is conditionally updated depending on the value of writemask register k1. If writemasking is not used, the low quadword element of the destination operand is unconditionally updated.
Each GETEXP operation converts the exponent value into a FP number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-14.
",
- "tooltip": "Extracts the biased exponent from the normalized DP FP representation of the low qword data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to double-precision FP value and written to the destination operand (the first operand) as DP FP numbers. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand.",
+ "html": "
Extracts the biased exponent from the normalized double precision floating-point representation of the low qword data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to double precision floating-point value and written to the destination operand (the first operand) as double precision floating-point numbers. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand.
The destination must be a XMM register, the source operand can be a XMM register or a float64 memory location.
If writemasking is used, the low quadword element of the destination operand is conditionally updated depending on the value of writemask register k1. If writemasking is not used, the low quadword element of the destination operand is unconditionally updated.
Each GETEXP operation converts the exponent value into a floating-point number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-15.
",
+ "tooltip": "Extracts the biased exponent from the normalized double precision floating-point representation of the low qword data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to double precision floating-point value and written to the destination operand (the first operand) as double precision floating-point numbers. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand.",
"url": "https://www.felixcloutier.com/x86/VGETEXPSD.html"
};
case "VGETEXPSS":
return {
- "html": "
Extracts the biased exponent from the normalized SP FP representation of the low doubleword data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to single-precision FP value and written to the destination operand (the first operand) as SP FP numbers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand.
The destination must be a XMM register, the source operand can be a XMM register or a float32 memory location.
If writemasking is used, the low doubleword element of the destination operand is conditionally updated depending on the value of writemask register k1. If writemasking is not used, the low doubleword element of the destination operand is unconditionally updated.
Each GETEXP operation converts the exponent value into a FP number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-15.
",
- "tooltip": "Extracts the biased exponent from the normalized SP FP representation of the low doubleword data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to single-precision FP value and written to the destination operand (the first operand) as SP FP numbers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand.",
+ "html": "
Extracts the biased exponent from the normalized single-precision floating-point representation of the low double-word data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to single-precision floating-point value and written to the destination operand (the first operand) as single-precision floating-point numbers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand.
The destination must be a XMM register, the source operand can be a XMM register or a float32 memory location.
If writemasking is used, the low doubleword element of the destination operand is conditionally updated depending on the value of writemask register k1. If writemasking is not used, the low doubleword element of the destination operand is unconditionally updated.
Each GETEXP operation converts the exponent value into a floating-point number (permitting input value in denormal representation). Special cases of input values are listed in Table 5-17.
",
+ "tooltip": "Extracts the biased exponent from the normalized single-precision floating-point representation of the low double-word data element of the source operand (the third operand) as unbiased signed integer value, or convert the denormal representation of input data to unbiased negative integer values. The integer value of the unbiased exponent is converted to single-precision floating-point value and written to the destination operand (the first operand) as single-precision floating-point numbers. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand.",
"url": "https://www.felixcloutier.com/x86/VGETEXPSS.html"
};
case "VGETMANTPD":
return {
- "html": "
Convert double-precision floating values in the source operand (the second operand) to DP FP values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The destination operand is a ZMM/YMM/XMM register updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
For each input DP FP value x, The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
- "tooltip": "Convert double-precision floating values in the source operand (the second operand) to DP FP values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
+ "html": "
Convert double precision floating values in the source operand (the second operand) to double precision floating-point values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The destination operand is a ZMM/YMM/XMM register updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
For each input double precision floating-point value x, The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
+ "tooltip": "Convert double precision floating values in the source operand (the second operand) to double precision floating-point values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
"url": "https://www.felixcloutier.com/x86/VGETMANTPD.html"
};
case "VGETMANTPS":
return {
- "html": "
Convert single-precision floating values in the source operand (the second operand) to SP FP values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The destination operand is a ZMM/YMM/XMM register updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location.
For each input SP FP value x, The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
- "tooltip": "Convert single-precision floating values in the source operand (the second operand) to SP FP values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
+ "html": "
Convert single-precision floating values in the source operand (the second operand) to single-precision floating-point values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The destination operand is a ZMM/YMM/XMM register updated under the writemask. The source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 32-bit memory location.
For each input single-precision floating-point value x, The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
+ "tooltip": "Convert single-precision floating values in the source operand (the second operand) to single-precision floating-point values with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted results are written to the destination operand (the first operand) using writemask k1. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
"url": "https://www.felixcloutier.com/x86/VGETMANTPS.html"
};
case "VGETMANTSD":
return {
- "html": "
Convert the double-precision floating values in the low quadword element of the second source operand (the third operand) to DP FP value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low quadword element of the destination operand (the first operand) using writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
- "tooltip": "Convert the double-precision floating values in the low quadword element of the second source operand (the third operand) to DP FP value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low quadword element of the destination operand (the first operand) using writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
+ "html": "
Convert the double precision floating values in the low quadword element of the second source operand (the third operand) to double precision floating-point value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low quadword element of the destination operand (the first operand) using writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
+ "tooltip": "Convert the double precision floating values in the low quadword element of the second source operand (the third operand) to double precision floating-point value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low quadword element of the destination operand (the first operand) using writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
"url": "https://www.felixcloutier.com/x86/VGETMANTSD.html"
};
case "VGETMANTSS":
return {
- "html": "
Convert the single-precision floating values in the low doubleword element of the second source operand (the third operand) to SP FP value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low doubleword element of the destination operand (the first operand) using writemask k1. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
- "tooltip": "Convert the single-precision floating values in the low doubleword element of the second source operand (the third operand) to SP FP value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low doubleword element of the destination operand (the first operand) using writemask k1. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
+ "html": "
Convert the single-precision floating values in the low doubleword element of the second source operand (the third operand) to single-precision floating-point value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low doubleword element of the destination operand (the first operand) using writemask k1. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.
The conversion operation is:
GetMant(x) = \u00b12k|x.significand|
",
+ "tooltip": "Convert the single-precision floating values in the low doubleword element of the second source operand (the third operand) to single-precision floating-point value with the mantissa normalization and sign control specified by the imm8 byte, see Figure 5-15. The converted result is written to the low doubleword element of the destination operand (the first operand) using writemask k1. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand. The normalized mantissa is specified by interv (imm8[1:0]) and the sign control (sc) is specified by bits 3:2 of the immediate byte.",
"url": "https://www.felixcloutier.com/x86/VGETMANTSS.html"
};
@@ -4153,7 +4189,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VINSERTI64X2":
case "VINSERTI64X4":
return {
- "html": "
VINSERTI32x4 and VINSERTI64x2 inserts 128-bits of packed integer values from the second source operand (the third operand) into the destination operand (the first operand) at an 128-bit granular offset multiplied by imm8[0] (256-bit) or imm8[1:0]. The remaining portions of the destination are copied from the corresponding fields of the first source operand (the second operand). The second source operand can be either an XMM register or a 128-bit memory location. The high 6/7bits of the immediate are ignored. The destination operand is a ZMM/YMM register and updated at 32 and 64-bit granularity according to the writemask.
VINSERTI32x8 and VINSERTI64x4 inserts 256-bits of packed integer values from the second source operand (the third operand) into the destination operand (the first operand) at a 256-bit granular offset multiplied by imm8[0]. The remaining portions of the destination are copied from the corresponding fields of the first source operand (the second operand). The second source operand can be either an YMM register or a 256-bit memory location. The upper bits of the immediate are ignored. The destination operand is a ZMM register and updated at 32 and 64-bit granularity according to the writemask.
VINSERTI128 inserts 128-bits of packed integer data from the second source operand (the third operand) into the destination operand (the first operand) at a 128-bit granular offset multiplied by imm8[0]. The remaining portions of the destination are copied from the corresponding fields of the first source operand (the second operand). The second source operand can be either an XMM register or a 128-bit memory location. The high 7 bits of the immediate are ignored. VEX.L must be 1, otherwise attempt to execute this instruction with VEX.L=0 will cause #UD.
",
+ "html": "
VINSERTI32x4 and VINSERTI64x2 inserts 128-bits of packed integer values from the second source operand (the third operand) into the destination operand (the first operand) at an 128-bit granular offset multiplied by imm8[0] (256-bit) or imm8[1:0]. The remaining portions of the destination are copied from the corresponding fields of the first source operand (the second operand). The second source operand can be either an XMM register or a 128-bit memory location. The high 6/7bits of the immediate are ignored. The destination operand is a ZMM/YMM register and updated at 32 and 64-bit granularity according to the writemask.
VINSERTI32x8 and VINSERTI64x4 inserts 256-bits of packed integer values from the second source operand (the third operand) into the destination operand (the first operand) at a 256-bit granular offset multiplied by imm8[0]. The remaining portions of the destination are copied from the corresponding fields of the first source operand (the second operand). The second source operand can be either an YMM register or a 256-bit memory location. The upper bits of the immediate are ignored. The destination operand is a ZMM register and updated at 32 and 64-bit granularity according to the writemask.
VINSERTI128 inserts 128-bits of packed integer data from the second source operand (the third operand) into the destination operand (the first operand) at a 128-bit granular offset multiplied by imm8[0]. The remaining portions of the destination are copied from the corresponding fields of the first source operand (the second operand). The
second source operand can be either an XMM register or a 128-bit memory location. The high 7 bits of the immediate are ignored. VEX.L must be 1, otherwise attempt to execute this instruction with VEX.L=0 will cause #UD.
",
"tooltip": "VINSERTI32x4 and VINSERTI64x2 inserts 128-bits of packed integer values from the second source operand (the third operand) into the destination operand (the first operand) at an 128-bit granular offset multiplied by imm8[0] (256-bit) or imm8[1:0]. The remaining portions of the destination are copied from the corresponding fields of the first source operand (the second operand). The second source operand can be either an XMM register or a 128-bit memory location. The high 6/7bits of the immediate are ignored. The destination operand is a ZMM/YMM register and updated at 32 and 64-bit granularity according to the writemask.",
"url": "https://www.felixcloutier.com/x86/VINSERTI128%3AVINSERTI32x4%3AVINSERTI64x2%3AVINSERTI32x8%3AVINSERTI64x4.html"
};
@@ -4176,8 +4212,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VP4DPWSSD":
return {
- "html": "
This instruction computes 4 sequential register source-block dot-products of two signed word operands with doubleword accumulation; see Figure 7-1 below. The memory operand is sequentially selected in each of the four steps.
In the above box, the notation of \u201c+3\u201d' is used to denote that the instruction accesses 4 source registers based on that operand; sources are consecutive, start in a multiple of 4 boundary, and contain the encoded register operand.
This instruction supports memory fault suppression. The entire memory operand is loaded if any bit of the lowest 16-bits of the mask is set to 1 or if a \u201cno masking\u201d encoding is used.
The tuple type Tuple1_4X implies that four 32-bit elements (16 bytes) are referenced by the memory operation portion of this instruction.
",
- "tooltip": "This instruction computes 4 sequential register source-block dot-products of two signed word operands with doubleword accumulation; see Figure 7-1 below. The memory operand is sequentially selected in each of the four steps.",
+ "html": "
This instruction computes 4 sequential register source-block dot-products of two signed word operands with doubleword accumulation; see Figure 8-1 below. The memory operand is sequentially selected in each of the four steps.
In the above box, the notation of \u201c+3\u201d' is used to denote that the instruction accesses 4 source registers based on that operand; sources are consecutive, start in a multiple of 4 boundary, and contain the encoded register operand.
This instruction supports memory fault suppression. The entire memory operand is loaded if any bit of the lowest 16-bits of the mask is set to 1 or if a \u201cno masking\u201d encoding is used.
The tuple type Tuple1_4X implies that four 32-bit elements (16 bytes) are referenced by the memory operation portion of this instruction.
",
+ "tooltip": "This instruction computes 4 sequential register source-block dot-products of two signed word operands with doubleword accumulation; see Figure 8-1 below. The memory operand is sequentially selected in each of the four steps.",
"url": "https://www.felixcloutier.com/x86/VP4DPWSSD.html"
};
@@ -4190,8 +4226,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPBLENDD":
return {
- "html": "
Dword elements from the source operand (second operand) are conditionally written to the destination operand (first operand) depending on bits in the immediate operand (third operand). The immediate bits (bits 7:0) form a mask that determines whether the corresponding word in the destination is copied from the source. If a bit in the mask, corresponding to a word, is \u201c1\", then the word is copied, else the word is unchanged.
VEX.128 encoded version: The second source operand can be an XMM register or a 128-bit memory location. The first source and destination operands are XMM registers. Bits (MAXVL-1:128) of the corresponding YMM register are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
- "tooltip": "Dword elements from the source operand (second operand) are conditionally written to the destination operand (first operand) depending on bits in the immediate operand (third operand). The immediate bits (bits 7:0) form a mask that determines whether the corresponding word in the destination is copied from the source. If a bit in the mask, corresponding to a word, is \u201c1\", then the word is copied, else the word is unchanged.",
+ "html": "
Dword elements from the source operand (second operand) are conditionally written to the destination operand (first operand) depending on bits in the immediate operand (third operand). The immediate bits (bits 7:0) form a mask that determines whether the corresponding dword in the destination is copied from the source. If a bit in the mask, corresponding to a dword, is \u201c1\", then the dword is copied, else the dword is unchanged.
VEX.128 encoded version: The second source operand can be an XMM register or a 128-bit memory location. The first source and destination operands are XMM registers. Bits (MAXVL-1:128) of the corresponding YMM register are zeroed.
VEX.256 encoded version: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register.
",
+ "tooltip": "Dword elements from the source operand (second operand) are conditionally written to the destination operand (first operand) depending on bits in the immediate operand (third operand). The immediate bits (bits 7:0) form a mask that determines whether the corresponding dword in the destination is copied from the source. If a bit in the mask, corresponding to a dword, is \u201c1\", then the dword is copied, else the dword is unchanged.",
"url": "https://www.felixcloutier.com/x86/VPBLENDD.html"
};
@@ -4221,7 +4257,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPBROADCASTQ":
case "VPBROADCASTW":
return {
- "html": "
Load integer data from the source operand (the second operand) and broadcast to all elements of the destination operand (the first operand).
VEX256-encoded VPBROADCASTB/W/D/Q: The source operand is 8-bit, 16-bit, 32-bit, 64-bit memory location or the low 8-bit, 16-bit 32-bit, 64-bit data in an XMM register. The destination operand is a YMM register. VPBROADCASTI128 support the source operand of 128-bit memory location. Register source encodings for VPBROADCASTI128 is reserved and will #UD. Bits (MAXVL-1:256) of the destination register are zeroed.
EVEX-encoded VPBROADCASTD/Q: The source operand is a 32-bit, 64-bit memory location or the low 32-bit, 64-bit data in an XMM register. The destination operand is a ZMM/YMM/XMM register and updated according to the writemask k1.
VPBROADCASTI32X4 and VPBROADCASTI64X4: The destination operand is a ZMM register and updated according to the writemask k1. The source operand is 128-bit or 256-bit memory location. Register source encodings for VBROADCASTI32X4 and VBROADCASTI64X4 are reserved and will #UD.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
",
+ "html": "
Load integer data from the source operand (the second operand) and broadcast to all elements of the destination operand (the first operand).
VEX256-encoded VPBROADCASTB/W/D/Q: The source operand is 8-bit, 16-bit, 32-bit, 64-bit memory location or the low 8-bit, 16-bit 32-bit, 64-bit data in an XMM register. The destination operand is a YMM register. VPBROAD-CASTI128 support the source operand of 128-bit memory location. Register source encodings for VPBROADCAS-TI128 is reserved and will #UD. Bits (MAXVL-1:256) of the destination register are zeroed.
EVEX-encoded VPBROADCASTD/Q: The source operand is a 32-bit, 64-bit memory location or the low 32-bit, 64-bit data in an XMM register. The destination operand is a ZMM/YMM/XMM register and updated according to the writemask k1.
VPBROADCASTI32X4 and VPBROADCASTI64X4: The destination operand is a ZMM register and updated according to the writemask k1. The source operand is 128-bit or 256-bit memory location. Register source encodings for VBROADCASTI32X4 and VBROADCASTI64X4 are reserved and will #UD.
Note: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
",
"tooltip": "Load integer data from the source operand (the second operand) and broadcast to all elements of the destination operand (the first operand).",
"url": "https://www.felixcloutier.com/x86/VPBROADCAST.html"
};
@@ -4237,7 +4273,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPCMPB":
case "VPCMPUB":
return {
- "html": "
Performs a SIMD compare of the packed byte values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPB performs a comparison between pairs of signed byte values.
VPCMPUB performs a comparison between pairs of unsigned byte values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand (first operand) is a mask register k1. Up to 64/32/16 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-17.
",
+ "html": "
Performs a SIMD compare of the packed byte values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPB performs a comparison between pairs of signed byte values.
VPCMPUB performs a comparison between pairs of unsigned byte values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand (first operand) is a mask register k1. Up to 64/32/16 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-21.
",
"tooltip": "Performs a SIMD compare of the packed byte values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).",
"url": "https://www.felixcloutier.com/x86/VPCMPB%3AVPCMPUB.html"
};
@@ -4245,7 +4281,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPCMPD":
case "VPCMPUD":
return {
- "html": "
Performs a SIMD compare of the packed integer values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPD/VPCMPUD performs a comparison between pairs of signed/unsigned doubleword integer values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand (first operand) is a mask register k1. Up to 16/8/4 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-17.
",
+ "html": "
Performs a SIMD compare of the packed integer values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPD/VPCMPUD performs a comparison between pairs of signed/unsigned doubleword integer values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location or a 512-bit vector broadcasted from a 32-bit memory location. The destination operand (first operand) is a mask register k1. Up to 16/8/4 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-21.
",
"tooltip": "Performs a SIMD compare of the packed integer values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).",
"url": "https://www.felixcloutier.com/x86/VPCMPD%3AVPCMPUD.html"
};
@@ -4253,7 +4289,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPCMPQ":
case "VPCMPUQ":
return {
- "html": "
Performs a SIMD compare of the packed integer values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPQ/VPCMPUQ performs a comparison between pairs of signed/unsigned quadword integer values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand (first operand) is a mask register k1. Up to 8/4/2 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-17.
",
+ "html": "
Performs a SIMD compare of the packed integer values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPQ/VPCMPUQ performs a comparison between pairs of signed/unsigned quadword integer values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand (first operand) is a mask register k1. Up to 8/4/2 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-21.
",
"tooltip": "Performs a SIMD compare of the packed integer values in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).",
"url": "https://www.felixcloutier.com/x86/VPCMPQ%3AVPCMPUQ.html"
};
@@ -4261,7 +4297,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPCMPUW":
case "VPCMPW":
return {
- "html": "
Performs a SIMD compare of the packed integer word in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPW performs a comparison between pairs of signed word values.
VPCMPUW performs a comparison between pairs of unsigned word values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand (first operand) is a mask register k1. Up to 32/16/8 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-17.
",
+ "html": "
Performs a SIMD compare of the packed integer word in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).
VPCMPW performs a comparison between pairs of signed word values.
VPCMPUW performs a comparison between pairs of unsigned word values.
The first source operand (second operand) is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand (first operand) is a mask register k1. Up to 32/16/8 comparisons are performed with results written to the destination operand under the writemask k2.
The comparison predicate operand is an 8-bit immediate: bits 2:0 define the type of comparison to be performed. Bits 3 through 7 of the immediate are reserved. Compiler can implement the pseudo-op mnemonic listed in Table 5-21.
",
"tooltip": "Performs a SIMD compare of the packed integer word in the second source operand and the first source operand and returns the results of the comparison to the mask destination operand. The comparison predicate operand (immediate byte) specifies the type of comparison performed on each pair of packed values in the two source operands. The result of each comparison is a single mask bit result of 1 (comparison true) or 0 (comparison false).",
"url": "https://www.felixcloutier.com/x86/VPCMPW%3AVPCMPUW.html"
};
@@ -4373,22 +4409,22 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPERMILPD":
return {
- "html": "
(variable control version)
Permute pairs of double-precision floating-point values in the first source operand (second operand), each using a 1-bit control field residing in the corresponding quadword element of the second source operand (third operand). Permuted results are stored in the destination operand (first operand).
The control bits are located at bit 0 of each quadword element (see Figure 5-24). Each control determines which of the source element in an input pair is selected for the destination element. Each pair of source elements must lie in the same 128-bit region as the destination.
EVEX version: The second source operand (third operand) is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. Permuted results are written to the destination under the writemask.
VEX.256 encoded version: Bits (MAXVL-1:256) of the corresponding ZMM register are zeroed.
",
+ "html": "
(variable control version)
Permute pairs of double precision floating-point values in the first source operand (second operand), each using a 1-bit control field residing in the corresponding quadword element of the second source operand (third operand). Permuted results are stored in the destination operand (first operand).
The control bits are located at bit 0 of each quadword element (see Figure 5-24). Each control determines which of the source element in an input pair is selected for the destination element. Each pair of source elements must lie in the same 128-bit region as the destination.
EVEX version: The second source operand (third operand) is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 64-bit memory location. Permuted results are written to the destination under the writemask.
VEX.256 encoded version: Bits (MAXVL-1:256) of the corresponding ZMM register are zeroed.
",
"tooltip": "(variable control version)",
"url": "https://www.felixcloutier.com/x86/VPERMILPD.html"
};
case "VPERMILPS":
return {
- "html": "
(variable control version)
Permute quadruples of single-precision floating-point values in the first source operand (second operand), each quadruplet using a 2-bit control field in the corresponding dword element of the second source operand. Permuted results are stored in the destination operand (first operand).
The 2-bit control fields are located at the low two bits of each dword element (see Figure 5-26). Each control determines which of the source element in an input quadruple is selected for the destination element. Each quadruple of source elements must lie in the same 128-bit region as the destination.
EVEX version: The second source operand (third operand) is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. Permuted results are written to the destination under the writemask.
(immediate control version)
",
- "tooltip": "(variable control version)",
+ "html": "
Variable control version:
Permute quadruples of single-precision floating-point values in the first source operand (second operand), each quadruplet using a 2-bit control field in the corresponding dword element of the second source operand. Permuted results are stored in the destination operand (first operand).
The 2-bit control fields are located at the low two bits of each dword element (see Figure 5-26). Each control determines which of the source element in an input quadruple is selected for the destination element. Each quadruple of source elements must lie in the same 128-bit region as the destination.
EVEX version: The second source operand (third operand) is a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32-bit memory location. Permuted results are written to the destination under the writemask.
(immediate control version)
",
+ "tooltip": "Variable control version",
"url": "https://www.felixcloutier.com/x86/VPERMILPS.html"
};
case "VPERMPD":
return {
- "html": "
The imm8 version: Copies quadword elements of double-precision floating-point values from the source operand (the second operand) to the destination operand (the first operand) according to the indices specified by the immediate operand (the third operand). Each two-bit value in the immediate byte selects a qword element in the source operand.
VEX version: The source operand can be a YMM register or a memory location. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
In EVEX.512 encoded version, The elements in the destination are updated using the writemask k1 and the imm8 bits are reused as control bits for the upper 256-bit half when the control bits are coming from immediate. The source operand can be a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location.
The imm8 versions: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
The vector control version: Copies quadword elements of double-precision floating-point values from the second source operand (the third operand) to the destination operand (the first operand) according to the indices in the first source operand (the second operand). The first 3 bits of each 64 bit element in the index operand selects which quadword in the second source operand to copy. The first and second operands are ZMM registers, the third operand can be a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The elements in the destination are updated using the writemask k1.
",
- "tooltip": "The imm8 version: Copies quadword elements of double-precision floating-point values from the source operand (the second operand) to the destination operand (the first operand) according to the indices specified by the immediate operand (the third operand). Each two-bit value in the immediate byte selects a qword element in the source operand.",
+ "html": "
The imm8 version: Copies quadword elements of double precision floating-point values from the source operand (the second operand) to the destination operand (the first operand) according to the indices specified by the immediate operand (the third operand). Each two-bit value in the immediate byte selects a qword element in the source operand.
VEX version: The source operand can be a YMM register or a memory location. Bits (MAXVL-1:256) of the corresponding destination register are zeroed.
In EVEX.512 encoded version, The elements in the destination are updated using the writemask k1 and the imm8 bits are reused as control bits for the upper 256-bit half when the control bits are coming from immediate. The source operand can be a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location.
The imm8 versions: VEX.vvvv and EVEX.vvvv are reserved and must be 1111b otherwise instructions will #UD.
The vector control version: Copies quadword elements of double precision floating-point values from the second source operand (the third operand) to the destination operand (the first operand) according to the indices in the first source operand (the second operand). The first 3 bits of each 64 bit element in the index operand selects which quadword in the second source operand to copy. The first and second operands are ZMM registers, the third operand can be a ZMM register, a 512-bit memory location or a 512-bit vector broadcasted from a 64-bit memory location. The elements in the destination are updated using the writemask k1.
",
+ "tooltip": "The imm8 version: Copies quadword elements of double precision floating-point values from the source operand (the second operand) to the destination operand (the first operand) according to the indices specified by the immediate operand (the third operand). Each two-bit value in the immediate byte selects a qword element in the source operand.",
"url": "https://www.felixcloutier.com/x86/VPERMPD.html"
};
@@ -4686,8 +4722,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPTERNLOGD":
case "VPTERNLOGQ":
return {
- "html": "
VPTERNLOGD/Q takes three bit vectors of 512-bit length (in the first, second and third operand) as input data to form a set of 512 indices, each index is comprised of one bit from each input vector. The imm8 byte specifies a boolean logic table producing a binary value for each 3-bit index value. The final 512-bit boolean result is written to the destination operand (the first operand) using the writemask k1 with the granularity of doubleword element or quadword element into the destination.
The destination operand is a ZMM (EVEX.512)/YMM (EVEX.256)/XMM (EVEX.128) register. The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location The destination operand is a ZMM register conditionally updated with writemask k1.
Table 5-18 shows two examples of Boolean functions specified by immediate values 0xE2 and 0xE4, with the look up result listed in the fourth column following the three columns containing all possible values of the 3-bit index.
Specifying different values in imm8 will allow any arbitrary three-input Boolean functions to be implemented in software using VPTERNLOGD/Q. Table 5-10 and Table 5-11 provide a mapping of all 256 possible imm8 values to various Boolean expressions.
",
- "tooltip": "VPTERNLOGD/Q takes three bit vectors of 512-bit length (in the first, second and third operand) as input data to form a set of 512 indices, each index is comprised of one bit from each input vector. The imm8 byte specifies a boolean logic table producing a binary value for each 3-bit index value. The final 512-bit boolean result is written to the destination operand (the first operand) using the writemask k1 with the granularity of doubleword element or quadword element into the destination.",
+ "html": "
VPTERNLOGD/Q takes three bit vectors of 512-bit length (in the first, second, and third operand) as input data to form a set of 512 indices, each index is comprised of one bit from each input vector. The imm8 byte specifies a boolean logic table producing a binary value for each 3-bit index value. The final 512-bit boolean result is written to the destination operand (the first operand) using the writemask k1 with the granularity of doubleword element or quadword element into the destination.
The destination operand is a ZMM (EVEX.512)/YMM (EVEX.256)/XMM (EVEX.128) register. The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location The destination operand is a ZMM register conditionally updated with writemask k1.
Table 5-22 shows two examples of Boolean functions specified by immediate values 0xE2 and 0xE4, with the look up result listed in the fourth column following the three columns containing all possible values of the 3-bit index.
Specifying different values in imm8 will allow any arbitrary three-input Boolean functions to be implemented in software using VPTERNLOGD/Q. Table 5-11 and Table 5-12 provide a mapping of all 256 possible imm8 values to various Boolean expressions.
",
+ "tooltip": "VPTERNLOGD/Q takes three bit vectors of 512-bit length (in the first, second, and third operand) as input data to form a set of 512 indices, each index is comprised of one bit from each input vector. The imm8 byte specifies a boolean logic table producing a binary value for each 3-bit index value. The final 512-bit boolean result is written to the destination operand (the first operand) using the writemask k1 with the granularity of doubleword element or quadword element into the destination.",
"url": "https://www.felixcloutier.com/x86/VPTERNLOGD%3AVPTERNLOGQ.html"
};
@@ -4696,8 +4732,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VPTESTMQ":
case "VPTESTMW":
return {
- "html": "
Performs a bitwise logical AND operation on the first source operand (the second operand) and second source operand (the third operand) and stores the result in the destination operand (the first operand) under the writemask. Each bit of the result is set to 1 if the bitwise AND of the corresponding elements of the first and second src operands is non-zero; otherwise it is set to 0.
VPTESTMD/VPTESTMQ: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location. The destination operand is a mask register updated under the writemask.
VPTESTMB/VPTESTMW: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a mask register updated under the writemask.
",
- "tooltip": "Performs a bitwise logical AND operation on the first source operand (the second operand) and second source operand (the third operand) and stores the result in the destination operand (the first operand) under the writemask. Each bit of the result is set to 1 if the bitwise AND of the corresponding elements of the first and second src operands is non-zero; otherwise it is set to 0.",
+ "html": "
Performs a bitwise logical AND operation on the first source operand (the second operand) and second source operand (the third operand) and stores the result in the destination operand (the first operand) under the write-mask. Each bit of the result is set to 1 if the bitwise AND of the corresponding elements of the first and second src operands is non-zero; otherwise it is set to 0.
VPTESTMD/VPTESTMQ: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location or a 512/256/128-bit vector broadcasted from a 32/64-bit memory location. The destination operand is a mask register updated under the writemask.
VPTESTMB/VPTESTMW: The first source operand is a ZMM/YMM/XMM register. The second source operand can be a ZMM/YMM/XMM register or a 512/256/128-bit memory location. The destination operand is a mask register updated under the writemask.
",
+ "tooltip": "Performs a bitwise logical AND operation on the first source operand (the second operand) and second source operand (the third operand) and stores the result in the destination operand (the first operand) under the write-mask. Each bit of the result is set to 1 if the bitwise AND of the corresponding elements of the first and second src operands is non-zero; otherwise it is set to 0.",
"url": "https://www.felixcloutier.com/x86/VPTESTMB%3AVPTESTMW%3AVPTESTMD%3AVPTESTMQ.html"
};
@@ -4713,36 +4749,36 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VRANGEPD":
return {
- "html": "
This instruction calculates 2/4/8 range operation outputs from two sets of packed input double-precision FP values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of Imm8[1:0] and Imm8[3:2] are shown in Figure 5-27.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-19. If the comparison raises an IE, the sign select control (Imm8[3:2] has no effect to the range operation output, this is indicated also in Table 5-19.
When both input values are zeros of opposite signs, the comparison operation of MIN/MAX in the range compare operation is slightly different from the conceptually similar FP MIN/MAX operation that are found in the instructions VMAXPD/VMINPD. The details of MIN/MAX/MIN_ABS/MAX_ABS operation for VRANGEPD/PS/SD/SS for magni-tude-0, opposite-signed input cases are listed in Table 5-20.
",
- "tooltip": "This instruction calculates 2/4/8 range operation outputs from two sets of packed input double-precision FP values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.",
+ "html": "
This instruction calculates 2/4/8 range operation outputs from two sets of packed input double precision floating-point values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of imm8[1:0] and imm8[3:2] are shown in Figure 5-27.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-23. If the comparison raises an IE, the sign select control (imm8[3:2]) has no effect to the range operation output; this is indicated also in Table 5-23.
When both input values are zeros of opposite signs, the comparison operation of MIN/MAX in the range compare operation is slightly different from the conceptually similar floating-point MIN/MAX operation that are found in the instructions VMAXPD/VMINPD. The details of MIN/MAX/MIN_ABS/MAX_ABS operation for VRANGEPD/PS/SD/SS for magnitude-0, opposite-signed input cases are listed in Table 5-24.
",
+ "tooltip": "This instruction calculates 2/4/8 range operation outputs from two sets of packed input double precision floating-point values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VRANGEPD.html"
};
case "VRANGEPS":
return {
- "html": "
This instruction calculates 4/8/16 range operation outputs from two sets of packed input single-precision FP values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of Imm8[1:0] and Imm8[3:2] are shown in Figure 5-27.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-19. If the comparison raises an IE, the sign select control (Imm8[3:2]) has no effect to the range operation output, this is indicated also in Table 5-19.
When both input values are zeros of opposite signs, the comparison operation of MIN/MAX in the range compare operation is slightly different from the conceptually similar FP MIN/MAX operation that are found in the instructions VMAXPD/VMINPD. The details of MIN/MAX/MIN_ABS/MAX_ABS operation for VRANGEPD/PS/SD/SS for magni-tude-0, opposite-signed input cases are listed in Table 5-20.
",
- "tooltip": "This instruction calculates 4/8/16 range operation outputs from two sets of packed input single-precision FP values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.",
+ "html": "
This instruction calculates 4/8/16 range operation outputs from two sets of packed input single-precision floating-point values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of imm8[1:0] and imm8[3:2] are shown in Figure 5-27.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-23. If the comparison raises an IE, the sign select control (imm8[3:2]) has no effect to the range operation output; this is indicated also in Table 5-23.
When both input values are zeros of opposite signs, the comparison operation of MIN/MAX in the range compare operation is slightly different from the conceptually similar floating-point MIN/MAX operation that are found in the instructions VMAXPD/VMINPD. The details of MIN/MAX/MIN_ABS/MAX_ABS operation for VRANGEPD/PS/SD/SS for magnitude-0, opposite-signed input cases are listed in Table 5-24.
",
+ "tooltip": "This instruction calculates 4/8/16 range operation outputs from two sets of packed input single-precision floating-point values in the first source operand (the second operand) and the second source operand (the third operand). The range outputs are written to the destination operand (the first operand) under the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VRANGEPS.html"
};
case "VRANGESD":
return {
- "html": "
This instruction calculates a range operation output from two input double-precision FP values in the low qword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low qword element of the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of Imm8[1:0] and Imm8[3:2] are shown in Figure 5-27.
Bits 128:63 of the destination operand are copied from the respective element of the first source operand.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-19. If the comparison raises an IE, the sign select control (Imm8[3:2] has no effect to the range operation output, this is indicated also in Table 5-19.
",
- "tooltip": "This instruction calculates a range operation output from two input double-precision FP values in the low qword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low qword element of the destination operand (the first operand) under the writemask k1.",
+ "html": "
This instruction calculates a range operation output from two input double precision floating-point values in the low qword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low qword element of the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of imm8[1:0] and imm8[3:2] are shown in Figure 5-27.
Bits 128:63 of the destination operand are copied from the respective element of the first source operand.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-23. If the comparison raises an IE, the sign select control (imm8[3:2]) has no effect to the range operation output; this is indicated also in Table 5-23.
",
+ "tooltip": "This instruction calculates a range operation output from two input double precision floating-point values in the low qword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low qword element of the destination operand (the first operand) under the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VRANGESD.html"
};
case "VRANGESS":
return {
- "html": "
This instruction calculates a range operation output from two input single-precision FP values in the low dword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low dword element of the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of Imm8[1:0] and Imm8[3:2] are shown in Figure 5-27.
Bits 128:31 of the destination operand are copied from the respective elements of the first source operand.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-19. If the comparison raises an IE, the sign select control (Imm8[3:2]) has no effect to the range operation output, this is indicated also in Table 5-19.
",
- "tooltip": "This instruction calculates a range operation output from two input single-precision FP values in the low dword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low dword element of the destination operand (the first operand) under the writemask k1.",
+ "html": "
This instruction calculates a range operation output from two input single-precision floating-point values in the low dword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low dword element of the destination operand (the first operand) under the writemask k1.
Bits7:4 of imm8 byte must be zero. The range operation output is performed in two parts, each configured by a two-bit control field within imm8[3:0]:
The encodings of imm8[1:0] and imm8[3:2] are shown in Figure 5-27.
Bits 128:31 of the destination operand are copied from the respective elements of the first source operand.
When one or more of the input value is a NAN, the comparison operation may signal invalid exception (IE). Details with one of more input value is NAN is listed in Table 5-23. If the comparison raises an IE, the sign select control (imm8[3:2]) has no effect to the range operation output; this is indicated also in Table 5-23.
",
+ "tooltip": "This instruction calculates a range operation output from two input single-precision floating-point values in the low dword element of the first source operand (the second operand) and second source operand (the third operand). The range output is written to the low dword element of the destination operand (the first operand) under the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VRANGESS.html"
};
case "VRCP14PD":
return {
- "html": "
This instruction performs a SIMD computation of the approximate reciprocals of eight/four/two packed double-precision floating-point values in the source operand (the second operand) and stores the packed double-precision floating-point results in the destination operand. The maximum relative error for this approximation is less than 2-14.
The source operand can be a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register conditionally updated according to the writemask.
The VRCP14PD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. A denormal source value will be treated as zero only in case of DAZ bit set in MXCSR. Otherwise it is treated correctly (i.e., not as a 0.0). Underflow results are flushed to zero only in case of FTZ bit set in MXCSR. Otherwise it will be treated correctly (i.e., correct underflow result is written) with the sign of the operand. When a source value is a SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
",
- "tooltip": "This instruction performs a SIMD computation of the approximate reciprocals of eight/four/two packed double-precision floating-point values in the source operand (the second operand) and stores the packed double-precision floating-point results in the destination operand. The maximum relative error for this approximation is less than 2-14.",
+ "html": "
This instruction performs a SIMD computation of the approximate reciprocals of eight/four/two packed double precision floating-point values in the source operand (the second operand) and stores the packed double precision floating-point results in the destination operand. The maximum relative error for this approximation is less than 2-14.
The source operand can be a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register conditionally updated according to the writemask.
The VRCP14PD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. A denormal source value will be treated as zero only in case of DAZ bit set in MXCSR. Otherwise it is treated correctly (i.e., not as a 0.0). Underflow results are flushed to zero only in case of FTZ bit set in MXCSR. Otherwise it will be treated correctly (i.e., correct underflow result is written) with the sign of the operand. When a source value is a SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
EVEX.vvvv is reserved and must be 1111b otherwise instructions will #UD.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
",
+ "tooltip": "This instruction performs a SIMD computation of the approximate reciprocals of eight/four/two packed double precision floating-point values in the source operand (the second operand) and stores the packed double precision floating-point results in the destination operand. The maximum relative error for this approximation is less than 2-14.",
"url": "https://www.felixcloutier.com/x86/VRCP14PD.html"
};
@@ -4755,14 +4791,14 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VRCP14SD":
return {
- "html": "
This instruction performs a SIMD computation of the approximate reciprocal of the low double-precision floating-point value in the second source operand (the third operand) stores the result in the low quadword element of the destination operand (the first operand) according to the writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand (the second operand). The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 64-bit memory location. The destination operand is an XMM register.
The VRCP14SD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. A denormal source value will be treated as zero only in case of DAZ bit set in MXCSR. Otherwise it is treated correctly (i.e., not as a 0.0). Underflow results are flushed to zero only in case of FTZ bit set in MXCSR. Otherwise it will be treated correctly (i.e., correct underflow result is written) with the sign of the operand. When a source value is a SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned. See Table 5-22 for special-case input values.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
A numerically exact implementation of VRCP14xx can be found at:
",
- "tooltip": "This instruction performs a SIMD computation of the approximate reciprocal of the low double-precision floating-point value in the second source operand (the third operand) stores the result in the low quadword element of the destination operand (the first operand) according to the writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand (the second operand). The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 64-bit memory location. The destination operand is an XMM register.",
+ "html": "
This instruction performs a SIMD computation of the approximate reciprocal of the low double precision floating-point value in the second source operand (the third operand) stores the result in the low quadword element of the destination operand (the first operand) according to the writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand (the second operand). The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 64-bit memory location. The destination operand is an XMM register.
The VRCP14SD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. A denormal source value will be treated as zero only in case of DAZ bit set in MXCSR. Otherwise it is treated correctly (i.e., not as a 0.0). Underflow results are flushed to zero only in case of FTZ bit set in MXCSR. Otherwise it will be treated correctly (i.e., correct underflow result is written) with the sign of the operand. When a source value is a SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned. See Table 5-26 for special-case input values.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
A numerically exact implementation of VRCP14xx can be found at:
",
+ "tooltip": "This instruction performs a SIMD computation of the approximate reciprocal of the low double precision floating-point value in the second source operand (the third operand) stores the result in the low quadword element of the destination operand (the first operand) according to the writemask k1. Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand (the second operand). The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 64-bit memory location. The destination operand is an XMM register.",
"url": "https://www.felixcloutier.com/x86/VRCP14SD.html"
};
case "VRCP14SS":
return {
- "html": "
This instruction performs a SIMD computation of the approximate reciprocal of the low single-precision floating-point value in the second source operand (the third operand) and stores the result in the low quadword element of the destination operand (the first operand) according to the writemask k1. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand (the second operand). The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register.
The VRCP14SS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. A denormal source value will be treated as zero only in case of DAZ bit set in MXCSR. Otherwise it is treated correctly (i.e., not as a 0.0). Underflow results are flushed to zero only in case of FTZ bit set in MXCSR. Otherwise it will be treated correctly (i.e., correct underflow result is written) with the sign of the operand. When a source value is a SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned. See Table 5-23 for special-case input values.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
",
+ "html": "
This instruction performs a SIMD computation of the approximate reciprocal of the low single-precision floating-point value in the second source operand (the third operand) and stores the result in the low quadword element of the destination operand (the first operand) according to the writemask k1. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand (the second operand). The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register.
The VRCP14SS instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. A denormal source value will be treated as zero only in case of DAZ bit set in MXCSR. Otherwise it is treated correctly (i.e., not as a 0.0). Underflow results are flushed to zero only in case of FTZ bit set in MXCSR. Otherwise it will be treated correctly (i.e., correct underflow result is written) with the sign of the operand. When a source value is a SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned. See Table 5-27 for special-case input values.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
",
"tooltip": "This instruction performs a SIMD computation of the approximate reciprocal of the low single-precision floating-point value in the second source operand (the third operand) and stores the result in the low quadword element of the destination operand (the first operand) according to the writemask k1. Bits (127:32) of the XMM register destination are copied from corresponding bits in the first source operand (the second operand). The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register.",
"url": "https://www.felixcloutier.com/x86/VRCP14SS.html"
};
@@ -4797,64 +4833,64 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VREDUCEPD":
return {
- "html": "
Perform reduction transformation of the packed binary encoded double-precision FP values in the source operand (the second operand) and store the reduced results in binary FP format to the destination operand (the first operand) under the writemask k1.
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary FP source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary FP numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
- "tooltip": "Perform reduction transformation of the packed binary encoded double-precision FP values in the source operand (the second operand) and store the reduced results in binary FP format to the destination operand (the first operand) under the writemask k1.",
+ "html": "
Perform reduction transformation of the packed binary encoded double precision floating-point values in the source operand (the second operand) and store the reduced results in binary floating-point format to the destination operand (the first operand) under the writemask k1.
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary floating-point source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary floating-point numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
+ "tooltip": "Perform reduction transformation of the packed binary encoded double precision floating-point values in the source operand (the second operand) and store the reduced results in binary floating-point format to the destination operand (the first operand) under the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VREDUCEPD.html"
};
case "VREDUCEPS":
return {
- "html": "
Perform reduction transformation of the packed binary encoded single-precision FP values in the source operand (the second operand) and store the reduced results in binary FP format to the destination operand (the first operand) under the writemask k1.
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary FP source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary FP numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
- "tooltip": "Perform reduction transformation of the packed binary encoded single-precision FP values in the source operand (the second operand) and store the reduced results in binary FP format to the destination operand (the first operand) under the writemask k1.",
+ "html": "
Perform reduction transformation of the packed binary encoded single-precision floating-point values in the source operand (the second operand) and store the reduced results in binary floating-point format to the destination operand (the first operand) under the writemask k1.
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary floating-point source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary floating-point numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
+ "tooltip": "Perform reduction transformation of the packed binary encoded single-precision floating-point values in the source operand (the second operand) and store the reduced results in binary floating-point format to the destination operand (the first operand) under the writemask k1.",
"url": "https://www.felixcloutier.com/x86/VREDUCEPS.html"
};
case "VREDUCESD":
return {
- "html": "
Perform a reduction transformation of the binary encoded double-precision FP value in the low qword element of the second source operand (the third operand) and store the reduced result in binary FP format to the low qword element of the destination operand (the first operand) under the writemask k1. Bits 127:64 of the destination operand are copied from respective qword elements of the first source operand (the second operand).
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary FP source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary FP numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
- "tooltip": "Perform a reduction transformation of the binary encoded double-precision FP value in the low qword element of the second source operand (the third operand) and store the reduced result in binary FP format to the low qword element of the destination operand (the first operand) under the writemask k1. Bits 127:64 of the destination operand are copied from respective qword elements of the first source operand (the second operand).",
+ "html": "
Perform a reduction transformation of the binary encoded double precision floating-point value in the low qword element of the second source operand (the third operand) and store the reduced result in binary floating-point format to the low qword element of the destination operand (the first operand) under the writemask k1. Bits 127:64 of the destination operand are copied from respective qword elements of the first source operand (the second operand).
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary floating-point source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary floating-point numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
+ "tooltip": "Perform a reduction transformation of the binary encoded double precision floating-point value in the low qword element of the second source operand (the third operand) and store the reduced result in binary floating-point format to the low qword element of the destination operand (the first operand) under the writemask k1. Bits 127:64 of the destination operand are copied from respective qword elements of the first source operand (the second operand).",
"url": "https://www.felixcloutier.com/x86/VREDUCESD.html"
};
case "VREDUCESS":
return {
- "html": "
Perform a reduction transformation of the binary encoded single-precision FP value in the low dword element of the second source operand (the third operand) and store the reduced result in binary FP format to the low dword element of the destination operand (the first operand) under the writemask k1. Bits 127:32 of the destination operand are copied from respective dword elements of the first source operand (the second operand).
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary FP source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary FP numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
- "tooltip": "Perform a reduction transformation of the binary encoded single-precision FP value in the low dword element of the second source operand (the third operand) and store the reduced result in binary FP format to the low dword element of the destination operand (the first operand) under the writemask k1. Bits 127:32 of the destination operand are copied from respective dword elements of the first source operand (the second operand).",
+ "html": "
Perform a reduction transformation of the binary encoded single-precision floating-point value in the low dword element of the second source operand (the third operand) and store the reduced result in binary floating-point format to the low dword element of the destination operand (the first operand) under the writemask k1. Bits 127:32 of the destination operand are copied from respective dword elements of the first source operand (the second operand).
The reduction transformation subtracts the integer part and the leading M fractional bits from the binary floating-point source value, where M is a unsigned integer specified by imm8[7:4], see Figure 5-28. Specifically, the reduction transformation can be expressed as:
dest = src \u2013 (ROUND(2M*src))*2-M;
where \u201cRound()\u201d treats \u201csrc\u201d, \u201c2M\u201d, and their product as binary floating-point numbers with normalized significand and biased exponents.
The magnitude of the reduced result can be expressed by considering src= 2p*man2,
",
+ "tooltip": "Perform a reduction transformation of the binary encoded single-precision floating-point value in the low dword element of the second source operand (the third operand) and store the reduced result in binary floating-point format to the low dword element of the destination operand (the first operand) under the writemask k1. Bits 127:32 of the destination operand are copied from respective dword elements of the first source operand (the second operand).",
"url": "https://www.felixcloutier.com/x86/VREDUCESS.html"
};
case "VRNDSCALEPD":
return {
- "html": "
Round the double-precision floating-point values in the source operand by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the destination operand.
The destination operand (the first operand) is a ZMM/YMM/XMM register conditionally updated according to the writemask. The source operand (the second operand) can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a double-precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Immediate control table below lists the encoded values for rounding-mode field).
",
- "tooltip": "Round the double-precision floating-point values in the source operand by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the destination operand.",
+ "html": "
Round the double precision floating-point values in the source operand by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the destination operand.
The destination operand (the first operand) is a ZMM/YMM/XMM register conditionally updated according to the writemask. The source operand (the second operand) can be a ZMM/YMM/XMM register, a 512/256/128-bit memory location, or a 512/256/128-bit vector broadcasted from a 64-bit memory location.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a double precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (immediate control table below lists the encoded values for rounding-mode field).
",
+ "tooltip": "Round the double precision floating-point values in the source operand by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VRNDSCALEPD.html"
};
case "VRNDSCALEPS":
return {
- "html": "
Round the single-precision floating-point values in the source operand by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the destination operand.
The destination operand (the first operand) is a ZMM register conditionally updated according to the writemask. The source operand (the second operand) can be a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a single-precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Immediate control table below lists the encoded values for rounding-mode field).
",
+ "html": "
Round the single-precision floating-point values in the source operand by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the destination operand.
The destination operand (the first operand) is a ZMM register conditionally updated according to the writemask. The source operand (the second operand) can be a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 32-bit memory location.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a single-precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (immediate control table below lists the encoded values for rounding-mode field).
",
"tooltip": "Round the single-precision floating-point values in the source operand by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/VRNDSCALEPS.html"
};
case "VRNDSCALESD":
return {
- "html": "
Rounds a double-precision floating-point value in the low quadword (see Figure 5-29) element of the second source operand (the third operand) by the rounding mode specified in the immediate operand and places the result in the corresponding element of the destination operand (the first operand) according to the writemask. The quadword element at bits 127:64 of the destination is copied from the first source operand (the second operand).
The destination and first source operands are XMM registers, the 2nd source operand can be an XMM register or memory location. Bits MAXVL-1:128 of the destination register are cleared.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a double-precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Immediate control table below lists the encoded values for rounding-mode field).
",
- "tooltip": "Rounds a double-precision floating-point value in the low quadword (see Figure 5-29) element of the second source operand (the third operand) by the rounding mode specified in the immediate operand and places the result in the corresponding element of the destination operand (the first operand) according to the writemask. The quadword element at bits 127:64 of the destination is copied from the first source operand (the second operand).",
+ "html": "
Rounds a double precision floating-point value in the low quadword (see Figure 5-29) element of the second source operand (the third operand) by the rounding mode specified in the immediate operand and places the result in the corresponding element of the destination operand (the first operand) according to the writemask. The quadword element at bits 127:64 of the destination is copied from the first source operand (the second operand).
The destination and first source operands are XMM registers, the 2nd source operand can be an XMM register or memory location. Bits MAXVL-1:128 of the destination register are cleared.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a double precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (immediate control table below lists the encoded values for rounding-mode field).
",
+ "tooltip": "Rounds a double precision floating-point value in the low quadword (see Figure 5-29) element of the second source operand (the third operand) by the rounding mode specified in the immediate operand and places the result in the corresponding element of the destination operand (the first operand) according to the writemask. The quadword element at bits 127:64 of the destination is copied from the first source operand (the second operand).",
"url": "https://www.felixcloutier.com/x86/VRNDSCALESD.html"
};
case "VRNDSCALESS":
return {
- "html": "
Rounds the single-precision floating-point value in the low doubleword element of the second source operand (the third operand) by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the corresponding element of the destination operand (the first operand) according to the writemask. The double-word elements at bits 127:32 of the destination are copied from the first source operand (the second operand).
The destination and first source operands are XMM registers, the 2nd source operand can be an XMM register or memory location. Bits MAXVL-1:128 of the destination register are cleared.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a single-precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (Immediate control tables below lists the encoded values for rounding-mode field).
",
+ "html": "
Rounds the single-precision floating-point value in the low doubleword element of the second source operand (the third operand) by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the corresponding element of the destination operand (the first operand) according to the writemask. The double-word elements at bits 127:32 of the destination are copied from the first source operand (the second operand).
The destination and first source operands are XMM registers, the 2nd source operand can be an XMM register or memory location. Bits MAXVL-1:128 of the destination register are cleared.
The rounding process rounds the input to an integral value, plus number bits of fraction that are specified by imm8[7:4] (to be included in the result) and returns the result as a single-precision floating-point value.
It should be noticed that no overflow is induced while executing this instruction (although the source is scaled by the imm8[7:4] value).
The immediate operand also specifies control fields for the rounding operation, three bit fields are defined and shown in the \u201cImmediate Control Description\u201d figure below. Bit 3 of the immediate byte controls the processor behavior for a precision exception, bit 2 selects the source of rounding mode control. Bits 1:0 specify a non-sticky rounding-mode value (immediate control tables below lists the encoded values for rounding-mode field).
",
"tooltip": "Rounds the single-precision floating-point value in the low doubleword element of the second source operand (the third operand) by the rounding mode specified in the immediate operand (see Figure 5-29) and places the result in the corresponding element of the destination operand (the first operand) according to the writemask. The double-word elements at bits 127:32 of the destination are copied from the first source operand (the second operand).",
"url": "https://www.felixcloutier.com/x86/VRNDSCALESS.html"
};
case "VRSQRT14PD":
return {
- "html": "
This instruction performs a SIMD computation of the approximate reciprocals of the square roots of the eight packed double-precision floating-point values in the source operand (the second operand) and stores the packed double-precision floating-point results in the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14.
EVEX.512 encoded version: The source operand can be a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
EVEX.256 encoded version: The source operand is a YMM register, a 256-bit memory location, or a 256-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM register, conditionally updated using writemask k1.
EVEX.128 encoded version: The source operand is a XMM register, a 128-bit memory location, or a 128-bit vector broadcasted from a 64-bit memory location. The destination operand is a XMM register, conditionally updated using writemask k1.
The VRSQRT14PD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. When the source operand is an +\u221e then +ZERO value is returned. A denormal source value is treated as zero only if DAZ bit is set in MXCSR. Otherwise it is treated correctly and performs the approximation with the specified masked response. When a source value is a negative value (other than 0.0) a floating-point QNaN_indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
",
- "tooltip": "This instruction performs a SIMD computation of the approximate reciprocals of the square roots of the eight packed double-precision floating-point values in the source operand (the second operand) and stores the packed double-precision floating-point results in the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14.",
+ "html": "
This instruction performs a SIMD computation of the approximate reciprocals of the square roots of the eight packed double precision floating-point values in the source operand (the second operand) and stores the packed double precision floating-point results in the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14.
EVEX.512 encoded version: The source operand can be a ZMM register, a 512-bit memory location, or a 512-bit vector broadcasted from a 64-bit memory location. The destination operand is a ZMM register, conditionally updated using writemask k1.
EVEX.256 encoded version: The source operand is a YMM register, a 256-bit memory location, or a 256-bit vector broadcasted from a 64-bit memory location. The destination operand is a YMM register, conditionally updated using writemask k1.
EVEX.128 encoded version: The source operand is a XMM register, a 128-bit memory location, or a 128-bit vector broadcasted from a 64-bit memory location. The destination operand is a XMM register, conditionally updated using writemask k1.
The VRSQRT14PD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. When the source operand is an +\u221e then +ZERO value is returned. A denormal source value is treated as zero only if DAZ bit is set in MXCSR. Otherwise it is treated correctly and performs the approximation with the specified masked response. When a source value is a negative value (other than 0.0) a floating-point QNaN_indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
",
+ "tooltip": "This instruction performs a SIMD computation of the approximate reciprocals of the square roots of the eight packed double precision floating-point values in the source operand (the second operand) and stores the packed double precision floating-point results in the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14.",
"url": "https://www.felixcloutier.com/x86/VRSQRT14PD.html"
};
@@ -4867,8 +4903,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VRSQRT14SD":
return {
- "html": "
Computes the approximate reciprocal of the square roots of the scalar double-precision floating-point value in the low quadword element of the source operand (the second operand) and stores the result in the low quadword element of the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register.
Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
The VRSQRT14SD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. When the source operand is an +\u221e then +ZERO value is returned. A denormal source value is treated as zero only if DAZ bit is set in MXCSR. Otherwise it is treated correctly and performs the approximation with the specified masked response. When a source value is a negative value (other than 0.0) a floating-point QNaN_indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
",
- "tooltip": "Computes the approximate reciprocal of the square roots of the scalar double-precision floating-point value in the low quadword element of the source operand (the second operand) and stores the result in the low quadword element of the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register.",
+ "html": "
Computes the approximate reciprocal of the square roots of the scalar double precision floating-point value in the low quadword element of the source operand (the second operand) and stores the result in the low quadword element of the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register.
Bits (127:64) of the XMM register destination are copied from corresponding bits in the first source operand. Bits (MAXVL-1:128) of the destination register are zeroed.
The VRSQRT14SD instruction is not affected by the rounding control bits in the MXCSR register. When a source value is a 0.0, an \u221e with the sign of the source value is returned. When the source operand is an +\u221e then +ZERO value is returned. A denormal source value is treated as zero only if DAZ bit is set in MXCSR. Otherwise it is treated correctly and performs the approximation with the specified masked response. When a source value is a negative value (other than 0.0) a floating-point QNaN_indefinite is returned. When a source value is an SNaN or QNaN, the SNaN is converted to a QNaN or the source QNaN is returned.
MXCSR exception flags are not affected by this instruction and floating-point exceptions are not reported.
",
+ "tooltip": "Computes the approximate reciprocal of the square roots of the scalar double precision floating-point value in the low quadword element of the source operand (the second operand) and stores the result in the low quadword element of the destination operand (the first operand) according to the writemask. The maximum relative error for this approximation is less than 2-14. The source operand can be an XMM register or a 32-bit memory location. The destination operand is an XMM register.",
"url": "https://www.felixcloutier.com/x86/VRSQRT14SD.html"
};
@@ -4909,28 +4945,28 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VSCALEFPD":
return {
- "html": "
Performs a floating-point scale of the packed double-precision floating-point values in the first source operand by multiplying them by 2 to the power of the double-precision floating-point values in second source operand.
The equation of this operation is given by:
zmm1 := zmm2*2floor(zmm3).
Floor(zmm3) means maximum integer value \u2264 zmm3.
If the result cannot be represented in double precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
- "tooltip": "Performs a floating-point scale of the packed double-precision floating-point values in the first source operand by multiplying them by 2 to the power of the double-precision floating-point values in second source operand.",
+ "html": "
Performs a floating-point scale of the packed double precision floating-point values in the first source operand by multiplying them by 2 to the power of the double precision floating-point values in second source operand.
The equation of this operation is given by:
zmm1 := zmm2*2floor(zmm3).
Floor(zmm3) means maximum integer value \u2264 zmm3.
If the result cannot be represented in double precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
+ "tooltip": "Performs a floating-point scale of the packed double precision floating-point values in the first source operand by multiplying them by 2 to the power of the double precision floating-point values in second source operand.",
"url": "https://www.felixcloutier.com/x86/VSCALEFPD.html"
};
case "VSCALEFPS":
return {
- "html": "
Performs a floating-point scale of the packed single-precision floating-point values in the first source operand by multiplying them by 2 to the power of the float32 values in second source operand.
The equation of this operation is given by:
zmm1 := zmm2*2floor(zmm3).
Floor(zmm3) means maximum integer value \u2264 zmm3.
If the result cannot be represented in single precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
+ "html": "
Performs a floating-point scale of the packed single-precision floating-point values in the first source operand by multiplying them by 2 to the power of the float32 values in second source operand.
The equation of this operation is given by:
zmm1 := zmm2*2floor(zmm3).
Floor(zmm3) means maximum integer value \u2264 zmm3.
If the result cannot be represented in single-precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
"tooltip": "Performs a floating-point scale of the packed single-precision floating-point values in the first source operand by multiplying them by 2 to the power of the float32 values in second source operand.",
"url": "https://www.felixcloutier.com/x86/VSCALEFPS.html"
};
case "VSCALEFSD":
return {
- "html": "
Performs a floating-point scale of the scalar double-precision floating-point value in the first source operand by multiplying it by 2 to the power of the double-precision floating-point value in second source operand.
The equation of this operation is given by:
xmm1 := xmm2*2floor(xmm3).
Floor(xmm3) means maximum integer value \u2264 xmm3.
If the result cannot be represented in double precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
- "tooltip": "Performs a floating-point scale of the scalar double-precision floating-point value in the first source operand by multiplying it by 2 to the power of the double-precision floating-point value in second source operand.",
+ "html": "
Performs a floating-point scale of the scalar double precision floating-point value in the first source operand by multiplying it by 2 to the power of the double precision floating-point value in second source operand.
The equation of this operation is given by:
xmm1 := xmm2*2floor(xmm3).
Floor(xmm3) means maximum integer value \u2264 xmm3.
If the result cannot be represented in double precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
+ "tooltip": "Performs a floating-point scale of the scalar double precision floating-point value in the first source operand by multiplying it by 2 to the power of the double precision floating-point value in second source operand.",
"url": "https://www.felixcloutier.com/x86/VSCALEFSD.html"
};
case "VSCALEFSS":
return {
- "html": "
Performs a floating-point scale of the scalar single-precision floating-point value in the first source operand by multiplying it by 2 to the power of the float32 value in second source operand.
The equation of this operation is given by:
xmm1 := xmm2*2floor(xmm3).
Floor(xmm3) means maximum integer value \u2264 xmm3.
If the result cannot be represented in single precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
+ "html": "
Performs a floating-point scale of the scalar single-precision floating-point value in the first source operand by multiplying it by 2 to the power of the float32 value in second source operand.
The equation of this operation is given by:
xmm1 := xmm2*2floor(xmm3).
Floor(xmm3) means maximum integer value \u2264 xmm3.
If the result cannot be represented in single-precision, then the proper overflow response (for positive scaling operand), or the proper underflow response (for negative scaling operand) is issued. The overflow and underflow responses are dependent on the rounding mode (for IEEE-compliant rounding), as well as on other settings in MXCSR (exception mask bits, FTZ bit), and on the SAE bit.
",
"tooltip": "Performs a floating-point scale of the scalar single-precision floating-point value in the first source operand by multiplying it by 2 to the power of the float32 value in second source operand.",
"url": "https://www.felixcloutier.com/x86/VSCALEFSS.html"
};
@@ -4978,7 +5014,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VTESTPD":
case "VTESTPS":
return {
- "html": "
VTESTPS performs a bitwise comparison of all the sign bits of the packed single-precision elements in the first source operation and corresponding sign bits in the second source operand. If the AND of the source sign bits with the dest sign bits produces all zeros, the ZF is set else the ZF is clear. If the AND of the source sign bits with the inverted dest sign bits produces all zeros the CF is set else the CF is clear. An attempt to execute VTESTPS with VEX.W=1 will cause #UD.
VTESTPD performs a bitwise comparison of all the sign bits of the double-precision elements in the first source operation and corresponding sign bits in the second source operand. If the AND of the source sign bits with the dest sign bits produces all zeros, the ZF is set else the ZF is clear. If the AND the source sign bits with the inverted dest sign bits produces all zeros the CF is set else the CF is clear. An attempt to execute VTESTPS with VEX.W=1 will cause #UD.
The first source register is specified by the ModR/M reg field.
128-bit version: The first source register is an XMM register. The second source register can be an XMM register or a 128-bit memory location. The destination register is not modified.
VEX.256 encoded version: The first source register is a YMM register. The second source register can be a YMM register or a 256-bit memory location. The destination register is not modified.
",
+ "html": "
VTESTPS performs a bitwise comparison of all the sign bits of the packed single-precision elements in the first source operation and corresponding sign bits in the second source operand. If the AND of the source sign bits with the dest sign bits produces all zeros, the ZF is set else the ZF is clear. If the AND of the source sign bits with the inverted dest sign bits produces all zeros the CF is set else the CF is clear. An attempt to execute VTESTPS with VEX.W=1 will cause #UD.
VTESTPD performs a bitwise comparison of all the sign bits of the double precision elements in the first source operation and corresponding sign bits in the second source operand. If the AND of the source sign bits with the dest sign bits produces all zeros, the ZF is set else the ZF is clear. If the AND the source sign bits with the inverted dest sign bits produces all zeros the CF is set else the CF is clear. An attempt to execute VTESTPS with VEX.W=1 will cause #UD.
The first source register is specified by the ModR/M reg field.
128-bit version: The first source register is an XMM register. The second source register can be an XMM register or a 128-bit memory location. The destination register is not modified.
VEX.256 encoded version: The first source register is a YMM register. The second source register can be a YMM register or a 256-bit memory location. The destination register is not modified.
",
"tooltip": "VTESTPS performs a bitwise comparison of all the sign bits of the packed single-precision elements in the first source operation and corresponding sign bits in the second source operand. If the AND of the source sign bits with the dest sign bits produces all zeros, the ZF is set else the ZF is clear. If the AND of the source sign bits with the inverted dest sign bits produces all zeros the CF is set else the CF is clear. An attempt to execute VTESTPS with VEX.W=1 will cause #UD.",
"url": "https://www.felixcloutier.com/x86/VTESTPD%3AVTESTPS.html"
};
@@ -5000,21 +5036,21 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "FWAIT":
case "WAIT":
return {
- "html": "
Causes the processor to check for and handle pending, unmasked, floating-point exceptions before proceeding. (FWAIT is an alternate mnemonic for WAIT.)
This instruction is useful for synchronizing exceptions in critical sections of code. Coding a WAIT instruction after a floating-point instruction ensures that any unmasked floating-point exceptions the instruction may raise are handled before the processor can modify the instruction\u2019s results. See the section titled \u201cFloating-Point Exception Synchronization\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information on using the WAIT/FWAIT instruction.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Causes the processor to check for and handle pending, unmasked, floating-point exceptions before proceeding. (FWAIT is an alternate mnemonic for WAIT.)
This instruction is useful for synchronizing exceptions in critical sections of code. Coding a WAIT instruction after a floating-point instruction ensures that any unmasked floating-point exceptions the instruction may raise are handled before the processor can modify the instruction\u2019s results. See the section titled \u201cFloating-Point Exception Synchronization\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, for more information on using the WAIT/FWAIT instruction.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Causes the processor to check for and handle pending, unmasked, floating-point exceptions before proceeding. (FWAIT is an alternate mnemonic for WAIT.)",
"url": "https://www.felixcloutier.com/x86/WAIT%3AFWAIT.html"
};
case "WBINVD":
return {
- "html": "
Writes back all modified cache lines in the processor\u2019s internal cache to main memory and invalidates (flushes) the internal caches. The instruction then issues a special-function bus cycle that directs external caches to also write back modified data and another bus cycle to indicate that the external caches should be invalidated.
After executing this instruction, the processor does not wait for the external caches to complete their write-back and flushing operations before proceeding with instruction execution. It is the responsibility of hardware to respond to the cache write-back and flush signals. The amount of time or cycles for WBINVD to complete will vary due to size and other factors of different cache hierarchies. As a consequence, the use of the WBINVD instruction can have an impact on logical processor interrupt/event response time. Additional information of WBINVD behavior in a cache hierarchy with hierarchical sharing topology can be found in Chapter 2 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
The WBINVD instruction is a privileged instruction. When the processor is running in protected mode, the CPL of a program or procedure must be 0 to execute this instruction. This instruction is also a serializing instruction (see \u201cSerializing Instructions\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
In situations where cache coherency with main memory is not a concern, software can use the INVD instruction.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
Writes back all modified cache lines in the processor\u2019s internal cache to main memory and invalidates (flushes) the internal caches. The instruction then issues a special-function bus cycle that directs external caches to also write back modified data and another bus cycle to indicate that the external caches should be invalidated.
After executing this instruction, the processor does not wait for the external caches to complete their write-back and flushing operations before proceeding with instruction execution. It is the responsibility of hardware to respond to the cache write-back and flush signals. The amount of time or cycles for WBINVD to complete will vary due to size and other factors of different cache hierarchies. As a consequence, the use of the WBINVD instruction can have an impact on logical processor interrupt/event response time. Additional information of WBINVD behavior in a cache hierarchy with hierarchical sharing topology can be found in Chapter 2 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A.
The WBINVD instruction is a privileged instruction. When the processor is running in protected mode, the CPL of a program or procedure must be 0 to execute this instruction. This instruction is also a serializing instruction (see \u201cSerializing Instructions\u201d in Chapter 9 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
In situations where cache coherency with main memory is not a concern, software can use the INVD instruction.
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "Writes back all modified cache lines in the processor\u2019s internal cache to main memory and invalidates (flushes) the internal caches. The instruction then issues a special-function bus cycle that directs external caches to also write back modified data and another bus cycle to indicate that the external caches should be invalidated.",
"url": "https://www.felixcloutier.com/x86/WBINVD.html"
};
case "WBNOINVD":
return {
- "html": "
The WBNOINVD instruction writes back all modified cache lines in the processor\u2019s internal cache to main memory but does not invalidate (flush) the internal caches.
After executing this instruction, the processor does not wait for the external caches to complete their write-back operation before proceeding with instruction execution. It is the responsibility of hardware to respond to the cache write-back signal. The amount of time or cycles for WBNOINVD to complete will vary due to size and other factors of different cache hierarchies. As a consequence, the use of the WBNOINVD instruction can have an impact on logical processor interrupt/event response time.
The WBNOINVD instruction is a privileged instruction. When the processor is running in protected mode, the CPL of a program or procedure must be 0 to execute this instruction. This instruction is also a serializing instruction (see \u201cSerializing Instructions\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
+ "html": "
The WBNOINVD instruction writes back all modified cache lines in the processor\u2019s internal cache to main memory but does not invalidate (flush) the internal caches.
After executing this instruction, the processor does not wait for the external caches to complete their write-back operation before proceeding with instruction execution. It is the responsibility of hardware to respond to the cache write-back signal. The amount of time or cycles for WBNOINVD to complete will vary due to size and other factors of different cache hierarchies. As a consequence, the use of the WBNOINVD instruction can have an impact on logical processor interrupt/event response time.
The WBNOINVD instruction is a privileged instruction. When the processor is running in protected mode, the CPL of a program or procedure must be 0 to execute this instruction. This instruction is also a serializing instruction (see \u201cSerializing Instructions\u201d in Chapter 9 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
This instruction\u2019s operation is the same in non-64-bit modes and 64-bit mode.
",
"tooltip": "The WBNOINVD instruction writes back all modified cache lines in the processor\u2019s internal cache to main memory but does not invalidate (flush) the internal caches.",
"url": "https://www.felixcloutier.com/x86/WBNOINVD.html"
};
@@ -5029,14 +5065,14 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "WRMSR":
return {
- "html": "
Writes the contents of registers EDX:EAX into the 64-bit model specific register (MSR) specified in the ECX register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The contents of the EDX register are copied to high-order 32 bits of the selected MSR and the contents of the EAX register are copied to low-order 32 bits of the MSR. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an MSR should be set to values previously read.
This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) is generated. Specifying a reserved or unimplemented MSR address in ECX will also cause a general protection exception. The processor will also generate a general protection exception if software attempts to write to bits in a reserved MSR.
When the WRMSR instruction is used to write to an MTRR, the TLBs are invalidated. This includes global entries (see \u201cTranslation Lookaside Buffers (TLBs)\u201d in Chapter 3 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
MSRs control functions for testability, execution tracing, performance-monitoring and machine check errors. Chapter 2, \u201cModel-Specific Registers (MSRs)\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 4, lists all MSRs that can be written with this instruction and their addresses. Note that each processor family has its own set of MSRs.
The WRMSR instruction is a serializing instruction (see \u201cSerializing Instructions\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A). Note that WRMSR to the IA32_TSC_DEADLINE MSR (MSR index 6E0H) and the X2APIC MSRs (MSR indices 802H to 83FH) are not serializing.
",
+ "html": "
Writes the contents of registers EDX:EAX into the 64-bit model specific register (MSR) specified in the ECX register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The contents of the EDX register are copied to high-order 32 bits of the selected MSR and the contents of the EAX register are copied to low-order 32 bits of the MSR. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an MSR should be set to values previously read.
This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) is generated. Specifying a reserved or unimplemented MSR address in ECX will also cause a general protection exception. The processor will also generate a general protection exception if software attempts to write to bits in a reserved MSR.
When the WRMSR instruction is used to write to an MTRR, the TLBs are invalidated. This includes global entries (see \u201cTranslation Lookaside Buffers (TLBs)\u201d in Chapter 3 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A).
MSRs control functions for testability, execution tracing, performance-monitoring and machine check errors. Chapter 2, \u201cModel-Specific Registers (MSRs),\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 4, lists all MSRs that can be written with this instruction and their addresses. Note that each processor family has its own set of MSRs.
The WRMSR instruction is a serializing instruction (see \u201cSerializing Instructions\u201d in Chapter 9 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A). Note that WRMSR to the IA32_TSC_DEADLINE MSR (MSR index 6E0H) and the X2APIC MSRs (MSR indices 802H to 83FH) are not serializing.
",
"tooltip": "Writes the contents of registers EDX:EAX into the 64-bit model specific register (MSR) specified in the ECX register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The contents of the EDX register are copied to high-order 32 bits of the selected MSR and the contents of the EAX register are copied to low-order 32 bits of the MSR. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an MSR should be set to values previously read.",
"url": "https://www.felixcloutier.com/x86/WRMSR.html"
};
case "WRPKRU":
return {
- "html": "
Writes the value of EAX into PKRU. ECX and EDX must be 0 when WRPKRU is executed; otherwise, a general-protection exception (#GP) occurs.
WRPKRU can be executed only if CR4.PKE = 1; otherwise, an invalid-opcode exception (#UD) occurs. Software can discover the value of CR4.PKE by examining CPUID.(EAX=07H,ECX=0H):ECX.OSPKE [bit 4].
On processors that support the Intel 64 Architecture, the high-order 32-bits of RCX, RDX and RAX are ignored.
WRPKRU will never execute speculatively. Memory accesses affected by PKRU register will not execute (even speculatively) until all prior executions of WRPKRU have completed execution and updated the PKRU register.
",
+ "html": "
Writes the value of EAX into PKRU. ECX and EDX must be 0 when WRPKRU is executed; otherwise, a general-protection exception (#GP) occurs.
WRPKRU can be executed only if CR4.PKE = 1; otherwise, an invalid-opcode exception (#UD) occurs. Software can discover the value of CR4.PKE by examining CPUID.(EAX=07H,ECX=0H):ECX.OSPKE [bit 4].
On processors that support the Intel 64 Architecture, the high-order 32-bits of RCX, RDX, and RAX are ignored.
WRPKRU will never execute speculatively. Memory accesses affected by PKRU register will not execute (even speculatively) until all prior executions of WRPKRU have completed execution and updated the PKRU register.
",
"tooltip": "Writes the value of EAX into PKRU. ECX and EDX must be 0 when WRPKRU is executed; otherwise, a general-protection exception (#GP) occurs.",
"url": "https://www.felixcloutier.com/x86/WRPKRU.html"
};
@@ -5051,7 +5087,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "XACQUIRE":
case "XRELEASE":
return {
- "html": "
The XACQUIRE prefix is a hint to start lock elision on the memory address specified by the instruction and the XRELEASE prefix is a hint to end lock elision on the memory address specified by the instruction.
The XACQUIRE prefix hint can only be used with the following instructions (these instructions are also referred to as XACQUIRE-enabled when used with the XACQUIRE prefix):
The XRELEASE prefix hint can only be used with the following instructions (also referred to as XRELEASE-enabled when used with the XRELEASE prefix):
The lock variables must satisfy the guidelines described in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, Section 16.3.3, for elision to be successful, otherwise an HLE abort may be signaled.
If an encoded byte sequence that meets XACQUIRE/XRELEASE requirements includes both prefixes, then the HLE semantic is determined by the prefix byte that is placed closest to the instruction opcode. For example, an F3F2C6 will not be treated as a XRELEASE-enabled instruction since the F2H (XACQUIRE) is closest to the instruction opcode C6. Similarly, an F2F3F0 prefixed instruction will be treated as a XRELEASE-enabled instruction since F3H (XRELEASE) is closest to the instruction opcode.
",
+ "html": "
The XACQUIRE prefix is a hint to start lock elision on the memory address specified by the instruction and the XRELEASE prefix is a hint to end lock elision on the memory address specified by the instruction.
The XACQUIRE prefix hint can only be used with the following instructions (these instructions are also referred to as XACQUIRE-enabled when used with the XACQUIRE prefix):
The XRELEASE prefix hint can only be used with the following instructions (also referred to as XRELEASE-enabled when used with the XRELEASE prefix):
The lock variables must satisfy the guidelines described in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1, Section 16.3.3, for elision to be successful, otherwise an HLE abort may be signaled.
If an encoded byte sequence that meets XACQUIRE/XRELEASE requirements includes both prefixes, then the HLE semantic is determined by the prefix byte that is placed closest to the instruction opcode. For example, an F3F2C6 will not be treated as a XRELEASE-enabled instruction since the F2H (XACQUIRE) is closest to the instruction opcode C6. Similarly, an F2F3F0 prefixed instruction will be treated as a XRELEASE-enabled instruction since F3H (XRELEASE) is closest to the instruction opcode.
",
"tooltip": "The XACQUIRE prefix is a hint to start lock elision on the memory address specified by the instruction and the XRELEASE prefix is a hint to end lock elision on the memory address specified by the instruction.",
"url": "https://www.felixcloutier.com/x86/XACQUIRE%3AXRELEASE.html"
};
@@ -5065,28 +5101,28 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "XBEGIN":
return {
- "html": "
The XBEGIN instruction specifies the start of an RTM code region. If the logical processor was not already in transactional execution, then the XBEGIN instruction causes the logical processor to transition into transactional execution. The XBEGIN instruction that transitions the logical processor into transactional execution is referred to as the outermost XBEGIN instruction. The instruction also specifies a relative offset to compute the address of the fallback code path following a transactional abort. (Use of the 16-bit operand size does not cause this address to be truncated to 16 bits, unlike a near jump to a relative offset.)
On an RTM abort, the logical processor discards all architectural register and memory updates performed during the RTM execution and restores architectural state to that corresponding to the outermost XBEGIN instruction. The fallback address following an abort is computed from the outermost XBEGIN instruction.
",
+ "html": "
The XBEGIN instruction specifies the start of an RTM code region. If the logical processor was not already in transactional execution, then the XBEGIN instruction causes the logical processor to transition into transactional execution. The XBEGIN instruction that transitions the logical processor into transactional execution is referred to as the outermost XBEGIN instruction. The instruction also specifies a relative offset to compute the address of the fallback code path following a transactional abort. (Use of the 16-bit operand size does not cause this address to be truncated to 16 bits, unlike a near jump to a relative offset.)
On an RTM abort, the logical processor discards all architectural register and memory updates performed during the RTM execution and restores architectural state to that corresponding to the outermost XBEGIN instruction. The fallback address following an abort is computed from the outermost XBEGIN instruction.
Execution of XBEGIN while in a suspend read address tracking region causes a transactional abort.
",
"tooltip": "The XBEGIN instruction specifies the start of an RTM code region. If the logical processor was not already in transactional execution, then the XBEGIN instruction causes the logical processor to transition into transactional execution. The XBEGIN instruction that transitions the logical processor into transactional execution is referred to as the outermost XBEGIN instruction. The instruction also specifies a relative offset to compute the address of the fallback code path following a transactional abort. (Use of the 16-bit operand size does not cause this address to be truncated to 16 bits, unlike a near jump to a relative offset.)",
"url": "https://www.felixcloutier.com/x86/XBEGIN.html"
};
case "XCHG":
return {
- "html": "
Exchanges the contents of the destination (first) and source (second) operands. The operands can be two general-purpose registers or a register and a memory location. If a memory operand is referenced, the processor\u2019s locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. (See the LOCK prefix description in this chapter for more information on the locking protocol.)
This instruction is useful for implementing semaphores or similar data structures for process synchronization. (See \u201cBus Locking\u201d in Chapter 8 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for more information on bus locking.)
The XCHG instruction can also be used instead of the BSWAP instruction for 16-bit operands.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Using a REX prefix in the form of REX.R permits access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
+ "html": "
Exchanges the contents of the destination (first) and source (second) operands. The operands can be two general-purpose registers or a register and a memory location. If a memory operand is referenced, the processor\u2019s locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. (See the LOCK prefix description in this chapter for more information on the locking protocol.)
This instruction is useful for implementing semaphores or similar data structures for process synchronization. (See \u201cBus Locking\u201d in Chapter 9 of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 3A, for more information on bus locking.)
The XCHG instruction can also be used instead of the BSWAP instruction for 16-bit operands.
In 64-bit mode, the instruction\u2019s default operation size is 32 bits. Using a REX prefix in the form of REX.R permits access to additional registers (R8-R15). Using a REX prefix in the form of REX.W promotes operation to 64 bits. See the summary chart at the beginning of this section for encoding data and limits.
",
"tooltip": "Exchanges the contents of the destination (first) and source (second) operands. The operands can be two general-purpose registers or a register and a memory location. If a memory operand is referenced, the processor\u2019s locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. (See the LOCK prefix description in this chapter for more information on the locking protocol.)",
"url": "https://www.felixcloutier.com/x86/XCHG.html"
};
case "XEND":
return {
- "html": "
The instruction marks the end of an RTM code region. If this corresponds to the outermost scope (that is, including this XEND instruction, the number of XBEGIN instructions is the same as number of XEND instructions), the logical processor will attempt to commit the logical processor state atomically. If the commit fails, the logical processor will rollback all architectural register and memory updates performed during the RTM execution. The logical processor will resume execution at the fallback address computed from the outermost XBEGIN instruction. The EAX register is updated to reflect RTM abort information.
XEND executed outside a transactional region will cause a #GP (General Protection Fault).
",
+ "html": "
The instruction marks the end of an RTM code region. If this corresponds to the outermost scope (that is, including this XEND instruction, the number of XBEGIN instructions is the same as number of XEND instructions), the logical processor will attempt to commit the logical processor state atomically. If the commit fails, the logical processor will rollback all architectural register and memory updates performed during the RTM execution. The logical processor will resume execution at the fallback address computed from the outermost XBEGIN instruction. The EAX register is updated to reflect RTM abort information.
Execution of XEND outside a transactional region causes a general-protection exception (#GP). Execution of XEND while in a suspend read address tracking region causes a transactional abort.
",
"tooltip": "The instruction marks the end of an RTM code region. If this corresponds to the outermost scope (that is, including this XEND instruction, the number of XBEGIN instructions is the same as number of XEND instructions), the logical processor will attempt to commit the logical processor state atomically. If the commit fails, the logical processor will rollback all architectural register and memory updates performed during the RTM execution. The logical processor will resume execution at the fallback address computed from the outermost XBEGIN instruction. The EAX register is updated to reflect RTM abort information.",
"url": "https://www.felixcloutier.com/x86/XEND.html"
};
case "XGETBV":
return {
- "html": "
Reads the contents of the extended control register (XCR) specified in the ECX register into registers EDX:EAX. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The EDX register is loaded with the high-order 32 bits of the XCR and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.) If fewer than 64 bits are implemented in the XCR being read, the values returned to EDX:EAX in unimplemented bit locations are undefined.
XCR0 is supported on any processor that supports the XGETBV instruction. If CPUID.(EAX=0DH,ECX=1):EAX.XG1[bit 2] = 1, executing XGETBV with ECX = 1 returns in EDX:EAX the logicalAND of XCR0 and the current value of the XINUSE state-component bitmap. This allows software to discover the state of the init optimization used by XSAVEOPT and XSAVES. See Chapter 13, \u201cManaging State Using the XSAVE Feature Set\u201a\u201d in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Use of any other value for ECX results in a general-protection (#GP) exception.
",
+ "html": "
Reads the contents of the extended control register (XCR) specified in the ECX register into registers EDX:EAX. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The EDX register is loaded with the high-order 32 bits of the XCR and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.) If fewer than 64 bits are implemented in the XCR being read, the values returned to EDX:EAX in unimplemented bit locations are undefined.
XCR0 is supported on any processor that supports the XGETBV instruction. If CPUID.(EAX=0DH,ECX=1):EAX.XG1[bit 2] = 1, executing XGETBV with ECX = 1 returns in EDX:EAX the logicalAND of XCR0 and the current value of the XINUSE state-component bitmap. This allows software to discover the state of the init optimization used by XSAVEOPT and XSAVES. See Chapter 13, \u201cManaging State Using the XSAVE Feature Set\u201a\u201d in Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Use of any other value for ECX results in a general-protection (#GP) exception.
",
"tooltip": "Reads the contents of the extended control register (XCR) specified in the ECX register into registers EDX:EAX. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The EDX register is loaded with the high-order 32 bits of the XCR and the EAX register is loaded with the low-order 32 bits. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are cleared.) If fewer than 64 bits are implemented in the XCR being read, the values returned to EDX:EAX in unimplemented bit locations are undefined.",
"url": "https://www.felixcloutier.com/x86/XGETBV.html"
};
@@ -5109,68 +5145,82 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "VXORPD":
case "XORPD":
return {
- "html": "
Performs a bitwise logical XOR of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand can be a ZMM register or a vector memory location. The destination operand is a ZMM register conditionally updated with writemask k1.
VEX.256 and EVEX.256 encoded versions: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 and EVEX.128 encoded versions: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
- "tooltip": "Performs a bitwise logical XOR of the two, four or eight packed double-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
+ "html": "
Performs a bitwise logical XOR of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand can be a ZMM register or a vector memory location. The destination operand is a ZMM register conditionally updated with write-mask k1.
VEX.256 and EVEX.256 encoded versions: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 and EVEX.128 encoded versions: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "tooltip": "Performs a bitwise logical XOR of the two, four or eight packed double precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand.",
"url": "https://www.felixcloutier.com/x86/XORPD.html"
};
case "VXORPS":
case "XORPS":
return {
- "html": "
Performs a bitwise logical XOR of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand can be a ZMM register or a vector memory location. The destination operand is a ZMM register conditionally updated with writemask k1.
VEX.256 and EVEX.256 encoded versions: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 and EVEX.128 encoded versions: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
+ "html": "
Performs a bitwise logical XOR of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand
EVEX.512 encoded version: The first source operand is a ZMM register. The second source operand can be a ZMM register or a vector memory location. The destination operand is a ZMM register conditionally updated with write-mask k1.
VEX.256 and EVEX.256 encoded versions: The first source operand is a YMM register. The second source operand is a YMM register or a 256-bit memory location. The destination operand is a YMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:256) of the corresponding ZMM register destination are zeroed.
VEX.128 and EVEX.128 encoded versions: The first source operand is an XMM register. The second source operand is an XMM register or 128-bit memory location. The destination operand is an XMM register (conditionally updated with writemask k1 in case of EVEX). The upper bits (MAXVL-1:128) of the corresponding ZMM register destination are zeroed.
128-bit Legacy SSE version: The second source can be an XMM register or an 128-bit memory location. The destination is not distinct from the first source XMM register and the upper bits (MAXVL-1:128) of the corresponding register destination are unmodified.
",
"tooltip": "Performs a bitwise logical XOR of the four, eight or sixteen packed single-precision floating-point values from the first source operand and the second source operand, and stores the result in the destination operand",
"url": "https://www.felixcloutier.com/x86/XORPS.html"
};
+ case "XRESLDTRK":
+ return {
+ "html": "
The instruction marks the end of an Intel TSX (RTM) suspend load address tracking region. If the instruction is used inside a suspend load address tracking region it will end the suspend region and all following load addresses will be added to the transaction read set. If this instruction is used inside an active transaction but not in a suspend region it will cause transaction abort.
If the instruction is used outside of a transactional region it behaves like a NOP.
Chapter 16, \u201cProgramming with Intel\u00ae Transactional Synchronization Extensions\u201a\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides additional information on Intel\u00ae TSX Suspend Load Address Tracking.
",
+ "tooltip": "The instruction marks the end of an Intel TSX (RTM) suspend load address tracking region. If the instruction is used inside a suspend load address tracking region it will end the suspend region and all following load addresses will be added to the transaction read set. If this instruction is used inside an active transaction but not in a suspend region it will cause transaction abort.",
+ "url": "https://www.felixcloutier.com/x86/XRESLDTRK.html"
+ };
+
case "XRSTOR":
return {
- "html": "
Performs a full or partial restore of processor state components from the XSAVE area located at the memory address specified by the source operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components restored correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.8, \u201cOperation of XRSTOR,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XRSTOR instruction. The following items provide a highlevel outline:
Use of a source operand not aligned to 64-byte boundary (for 64-bit and 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmaps XINUSE and XMODIFIED and of the quantity XRSTOR_INFO.
",
+ "html": "
Performs a full or partial restore of processor state components from the XSAVE area located at the memory address specified by the source operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components restored correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.8, \u201cOperation of XRSTOR,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XRSTOR instruction. The following items provide a highlevel outline:
Use of a source operand not aligned to 64-byte boundary (for 64-bit and 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmaps XINUSE and XMODIFIED and of the quantity XRSTOR_INFO.
",
"tooltip": "Performs a full or partial restore of processor state components from the XSAVE area located at the memory address specified by the source operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components restored correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.",
"url": "https://www.felixcloutier.com/x86/XRSTOR.html"
};
case "XRSTORS":
return {
- "html": "
Performs a full or partial restore of processor state components from the XSAVE area located at the memory address specified by the source operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components restored correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XRSTORS may be executed only if CPL = 0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.12, \u201cOperation of XRSTORS,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XRSTOR instruction. The following items provide a high-level outline:
Use of a source operand not aligned to 64-byte boundary (for 64-bit and 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmaps XINUSE and XMODIFIED and of the quantity XRSTOR_INFO.
",
+ "html": "
Performs a full or partial restore of processor state components from the XSAVE area located at the memory address specified by the source operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components restored correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XRSTORS may be executed only if CPL = 0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.12, \u201cOperation of XRSTORS,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XRSTOR instruction. The following items provide a high-level outline:
Use of a source operand not aligned to 64-byte boundary (for 64-bit and 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmaps XINUSE and XMODIFIED and of the quantity XRSTOR_INFO.
",
"tooltip": "Performs a full or partial restore of processor state components from the XSAVE area located at the memory address specified by the source operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components restored correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XRSTORS may be executed only if CPL = 0.",
"url": "https://www.felixcloutier.com/x86/XRSTORS.html"
};
case "XSAVE":
return {
- "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.7, \u201cOperation of XSAVE,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVE instruction. The following items provide a high-level outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
",
+ "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.7, \u201cOperation of XSAVE,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVE instruction. The following items provide a high-level outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
",
"tooltip": "Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.",
"url": "https://www.felixcloutier.com/x86/XSAVE.html"
};
case "XSAVEC":
return {
- "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.10, \u201cOperation of XSAVEC,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVEC instruction. The following items provide a highlevel outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
",
+ "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.10, \u201cOperation of XSAVEC,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVEC instruction. The following items provide a highlevel outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
",
"tooltip": "Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.",
"url": "https://www.felixcloutier.com/x86/XSAVEC.html"
};
case "XSAVEOPT":
return {
- "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.9, \u201cOperation of XSAVEOPT,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVEOPT instruction. The following items provide a high-level outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) will result in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmap XMODIFIED and of the quantity XRSTOR_INFO.
",
+ "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.9, \u201cOperation of XSAVEOPT,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVEOPT instruction. The following items provide a highlevel outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) will result in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmap XMODIFIED and of the quantity XRSTOR_INFO.
",
"tooltip": "Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), which is the logical-AND of EDX:EAX and XCR0.",
"url": "https://www.felixcloutier.com/x86/XSAVEOPT.html"
};
case "XSAVES":
return {
- "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), the logicalAND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XSAVES may be executed only if CPL = 0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.11, \u201cOperation of XSAVES,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVES instruction. The following items provide a highlevel outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmap XMODIFIED and of the quantity XRSTOR_INFO.
",
+ "html": "
Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), the logicalAND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XSAVES may be executed only if CPL = 0.
The format of the XSAVE area is detailed in Section 13.4, \u201cXSAVE Area,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1. Like FXRSTOR and FXSAVE, the memory format used for x87 state depends on a REX.W prefix; see Section 13.5.1, \u201cx87 State,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
Section 13.11, \u201cOperation of XSAVES,\u201d of the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides a detailed description of the operation of the XSAVES instruction. The following items provide a high-level outline:
Use of a destination operand not aligned to 64-byte boundary (in either 64-bit or 32-bit modes) results in a general-protection (#GP) exception. In 64-bit mode, the upper 32 bits of RDX and RAX are ignored.
See Section 13.6, \u201cProcessor Tracking of XSAVE-Managed State,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 for discussion of the bitmap XMODIFIED and of the quantity XRSTOR_INFO.
",
"tooltip": "Performs a full or partial save of processor state components to the XSAVE area located at the memory address specified by the destination operand. The implicit EDX:EAX register pair specifies a 64-bit instruction mask. The specific state components saved correspond to the bits set in the requested-feature bitmap (RFBM), the logicalAND of EDX:EAX and the logical-OR of XCR0 with the IA32_XSS MSR. XSAVES may be executed only if CPL = 0.",
"url": "https://www.felixcloutier.com/x86/XSAVES.html"
};
case "XSETBV":
return {
- "html": "
Writes the contents of registers EDX:EAX into the 64-bit extended control register (XCR) specified in the ECX register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The contents of the EDX register are copied to high-order 32 bits of the selected XCR and the contents of the EAX register are copied to low-order 32 bits of the XCR. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an XCR should be set to values previously read.
This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) is generated. Specifying a reserved or unimplemented XCR in ECX will also cause a general protection exception. The processor will also generate a general protection exception if software attempts to write to reserved bits in an XCR.
Currently, only XCR0 is supported. Thus, all other values of ECX are reserved and will cause a #GP(0). Note that bit 0 of XCR0 (corresponding to x87 state) must be set to 1; the instruction will cause a #GP(0) if an attempt is made to clear this bit. In addition, the instruction causes a #GP(0) if an attempt is made to set XCR0[2] (AVX state) while clearing XCR0[1] (SSE state); it is necessary to set both bits to use AVX instructions; Section 13.3, \u201cEnabling the XSAVE Feature Set and XSAVE-Enabled Features,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
",
+ "html": "
Writes the contents of registers EDX:EAX into the 64-bit extended control register (XCR) specified in the ECX register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The contents of the EDX register are copied to high-order 32 bits of the selected XCR and the contents of the EAX register are copied to low-order 32 bits of the XCR. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an XCR should be set to values previously read.
This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) is generated. Specifying a reserved or unimplemented XCR in ECX will also cause a general protection exception. The processor will also generate a general protection exception if software attempts to write to reserved bits in an XCR.
Currently, only XCR0 is supported. Thus, all other values of ECX are reserved and will cause a #GP(0). Note that bit 0 of XCR0 (corresponding to x87 state) must be set to 1; the instruction will cause a #GP(0) if an attempt is made to clear this bit. In addition, the instruction causes a #GP(0) if an attempt is made to set XCR0[2] (AVX state) while clearing XCR0[1] (SSE state); it is necessary to set both bits to use AVX instructions; Section 13.3, \u201cEnabling the XSAVE Feature Set and XSAVE-Enabled Features,\u201d of Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1.
",
"tooltip": "Writes the contents of registers EDX:EAX into the 64-bit extended control register (XCR) specified in the ECX register. (On processors that support the Intel 64 architecture, the high-order 32 bits of RCX are ignored.) The contents of the EDX register are copied to high-order 32 bits of the selected XCR and the contents of the EAX register are copied to low-order 32 bits of the XCR. (On processors that support the Intel 64 architecture, the high-order 32 bits of each of RAX and RDX are ignored.) Undefined or reserved bits in an XCR should be set to values previously read.",
"url": "https://www.felixcloutier.com/x86/XSETBV.html"
};
+ case "XSUSLDTRK":
+ return {
+ "html": "
The instruction marks the start of an Intel TSX (RTM) suspend load address tracking region. If the instruction is used inside a transactional region, subsequent loads are not added to the read set of the transaction. If the instruction is used inside a suspend load address tracking region it will cause transaction abort.
If the instruction is used outside of a transactional region it behaves like a NOP.
Chapter 16, \u201cProgramming with Intel\u00ae Transactional Synchronization Extensions\u201a\u201d in the Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual, Volume 1 provides additional information on Intel\u00ae TSX Suspend Load Address Tracking.
",
+ "tooltip": "The instruction marks the start of an Intel TSX (RTM) suspend load address tracking region. If the instruction is used inside a transactional region, subsequent loads are not added to the read set of the transaction. If the instruction is used inside a suspend load address tracking region it will cause transaction abort.",
+ "url": "https://www.felixcloutier.com/x86/XSUSLDTRK.html"
+ };
+
case "XTEST":
return {
"html": "
The XTEST instruction queries the transactional execution status. If the instruction executes inside a transactionally executing RTM region or a transactionally executing HLE region, then the ZF flag is cleared, else it is set.
Adds two registers and the contents of the C flag and places the result in the destination register Rd.
",
"tooltip": "Add with Carry",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=24",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=24",
};
case "ADD":
return {
"html": "
Adds two registers without the C flag and places the result in the destination register Rd.
",
"tooltip": "Add without Carry",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=25",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=25",
};
case "ADIW":
return {
"html": "
Adds an immediate value (0-63) to a register pair and places the result in the register pair. This instruction operates on the upper four register pairs and is well suited for operations on the Pointer Registers.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Add Immediate to Word",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=26",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=26",
};
case "AND":
return {
"html": "
Performs the logical AND between the contents of register Rd and register Rr, and places the result in the destination register Rd.
Performs the logical AND between the contents of register Rd and a constant, and places the result in the destination register Rd.
",
"tooltip": "Logical AND with Immediate",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=28",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=27",
};
case "ASR":
return {
"html": "
Shifts all bits in Rd one place to the right. Bit 7 is held constant. Bit 0 is loaded into the C flag of the SREG. This operation effectively divides a signed value by two without changing its sign. The Carry flag can be used to round the result.
",
"tooltip": "Bit Clear in SREG",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=30",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=29",
};
case "BLD":
return {
"html": "
Copies the T bit in the SREG (Status Register) to bit b in register Rd.
",
"tooltip": "Bit Load from the T Bit in SREG to a Bit in Register",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=31",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=30",
};
case "BRBC":
return {
- "html": "
Conditional relative branch. Tests a single bit in SREG and branches relatively to the PC if the bit is cleared. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form.
",
+ "html": "
Conditional relative branch. Tests a single bit in SREG and branches relatively to the PC if the bit is cleared. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form.
",
"tooltip": "Branch if Bit in SREG is Cleared",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=32",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=31",
};
case "BRBS":
return {
- "html": "
Conditional relative branch. Tests a single bit in SREG and branches relatively to the PC if the bit is set. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form.
",
+ "html": "
Conditional relative branch. Tests a single bit in SREG and branches relatively to the PC if the bit is set. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form.
",
"tooltip": "Branch if Bit in SREG is Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=33",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=32",
};
case "BRCC":
return {
- "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is cleared. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 0,k.)
",
+ "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is cleared. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 0,k.)
",
"tooltip": "Branch if Carry Cleared",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=34",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=32",
};
case "BRCS":
return {
- "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is set. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 0,k.)
",
+ "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is set. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 0,k.)
",
"tooltip": "Branch if Carry Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=35",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=33",
};
case "BREAK":
return {
"html": "
The BREAK instruction is used by the On-chip Debug system and not used by the application software. When the BREAK instruction is executed, the AVR CPU is set in the Stopped state. This gives the On-chip Debugger access to internal resources.
If the device is locked, or the on-chip debug system is not enabled, the CPU will treat the BREAK instruction as a NOP and will not enter the Stopped state.
This instruction is not available on all devices. Refer to Appendix A.
Conditional relative branch. Tests the Zero (Z) flag and branches relatively to the PC if Z is set. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned or signed binary number represented in Rd was equal to the unsigned or signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 1,k.)
",
+ "html": "
Conditional relative branch. Tests the Zero (Z) flag and branches relatively to the PC if Z is set. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned or signed binary number represented in Rd was equal to the unsigned or signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 1,k.)
",
"tooltip": "Branch if Equal",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=36",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=35",
};
case "BRGE":
return {
- "html": "
Conditional relative branch. Tests the Sign (S) flag and branches relatively to the PC if S is cleared. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the signed binary number represented in Rd was greater than or equal to the signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 4,k.)
",
+ "html": "
Conditional relative branch. Tests the Sign (S) flag and branches relatively to the PC if S is cleared. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the signed binary number represented in Rd was greater than or equal to the signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 4,k.)
",
"tooltip": "Branch if Greater or Equal (Signed)",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=37",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=35",
};
case "BRHC":
return {
- "html": "
Conditional relative branch. Tests the Half Carry (H) flag and branches relatively to the PC if H is cleared. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 5,k.)
",
+ "html": "
Conditional relative branch. Tests the Half Carry (H) flag and branches relatively to the PC if H is cleared. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 5,k.)
",
"tooltip": "Branch if Half Carry Flag is Cleared",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=38",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=36",
};
case "BRHS":
return {
- "html": "
Conditional relative branch. Tests the Half Carry (H) flag and branches relatively to the PC if H is set. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 5,k.)
",
+ "html": "
Conditional relative branch. Tests the Half Carry (H) flag and branches relatively to the PC if H is set. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 5,k.)
",
"tooltip": "Branch if Half Carry Flag is Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=39",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=37",
};
case "BRID":
return {
- "html": "
Conditional relative branch. Tests the Global Interrupt Enable (I) bit and branches relatively to the PC if I is cleared. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 7,k.)
",
+ "html": "
Conditional relative branch. Tests the Global Interrupt Enable (I) bit and branches relatively to the PC if I is cleared. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 7,k.)
",
"tooltip": "Branch if Global Interrupt is Disabled",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=40",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=38",
};
case "BRIE":
return {
- "html": "
Conditional relative branch. Tests the Global Interrupt Enable (I) bit and branches relatively to the PC if I is set. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 7,k.)
",
+ "html": "
Conditional relative branch. Tests the Global Interrupt Enable (I) bit and branches relatively to the PC if I is set. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 7,k.)
",
"tooltip": "Branch if Global Interrupt is Enabled",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=41",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=39",
};
case "BRLO":
return {
- "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is set. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned binary number represented in Rd was smaller than the unsigned binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 0,k.)
",
+ "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is set. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned binary number represented in Rd was smaller than the unsigned binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 0,k.)
",
"tooltip": "Branch if Lower (Unsigned)",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=42",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=39",
};
case "BRLT":
return {
- "html": "
Conditional relative branch. Tests the Sign (S) flag and branches relatively to the PC if S is set. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the signed binary number represented in Rd was less than the signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 4,k.)
",
+ "html": "
Conditional relative branch. Tests the Sign (S) flag and branches relatively to the PC if S is set. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the signed binary number represented in Rd was less than the signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 4,k.)
",
"tooltip": "Branch if Less Than (Signed)",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=43",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=40",
};
case "BRMI":
return {
- "html": "
Conditional relative branch. Tests the Negative (N) flag and branches relatively to the PC if N is set. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 2,k.)
",
+ "html": "
Conditional relative branch. Tests the Negative (N) flag and branches relatively to the PC if N is set. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 2,k.)
",
"tooltip": "Branch if Minus",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=44",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=41",
};
case "BRNE":
return {
- "html": "
Conditional relative branch. Tests the Zero (Z) flag and branches relatively to the PC if Z is cleared. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned or signed binary number represented in Rd was not equal to the unsigned or signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 1,k.)
",
+ "html": "
Conditional relative branch. Tests the Zero (Z) flag and branches relatively to the PC if Z is cleared. If the instruction is executed immediately after any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned or signed binary number represented in Rd was not equal to the unsigned or signed binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 1,k.)
",
"tooltip": "Branch if Not Equal",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=45",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=42",
};
case "BRPL":
return {
- "html": "
Conditional relative branch. Tests the Negative (N) flag and branches relatively to the PC if N is cleared. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 2,k.)
",
+ "html": "
Conditional relative branch. Tests the Negative (N) flag and branches relatively to the PC if N is cleared. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 2,k.)
",
"tooltip": "Branch if Plus",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=46",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=43",
};
case "BRSH":
return {
- "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is cleared. If the instruction is executed immediately after execution of any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned binary number represented in Rd was greater than or equal to the unsigned binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 0,k.)
",
+ "html": "
Conditional relative branch. Tests the Carry (C) flag and branches relatively to the PC if C is cleared. If the instruction is executed immediately after execution of any of the instructions CP, CPI, SUB, or SUBI, the branch will occur only if the unsigned binary number represented in Rd was greater than or equal to the unsigned binary number represented in Rr. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 0,k.)
",
"tooltip": "Branch if Same or Higher (Unsigned)",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=47",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=44",
};
case "BRTC":
return {
- "html": "
Conditional relative branch. Tests the T bit and branches relatively to the PC if T is cleared. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 6,k.)
",
+ "html": "
Conditional relative branch. Tests the T bit and branches relatively to the PC if T is cleared. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 6,k.)
",
"tooltip": "Branch if the T Bit is Cleared",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=48",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=44",
};
case "BRTS":
return {
- "html": "
Conditional relative branch. Tests the T bit and branches relatively to the PC if T is set. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 6,k.)
",
+ "html": "
Conditional relative branch. Tests the T bit and branches relatively to the PC if T is set. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 6,k.)
",
"tooltip": "Branch if the T Bit is Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=49",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=45",
};
case "BRVC":
return {
- "html": "
Conditional relative branch. Tests the Overflow (V) flag and branches relatively to the PC if V is cleared. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBC 3,k.)
",
+ "html": "
Conditional relative branch. Tests the Overflow (V) flag and branches relatively to the PC if V is cleared. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBC 3,k.)
",
"tooltip": "Branch if Overflow Cleared",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=50",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=46",
};
case "BRVS":
return {
- "html": "
Conditional relative branch. Tests the Overflow (V) flag and branches relatively to the PC if V is set. This instruction branches relatively to the PC in either direction (PC - 63 ≤ destination ≤ PC + 64). Parameter k is the offset from the PC and is represented in two’s complement form. (Equivalent to instruction BRBS 3,k.)
",
+ "html": "
Conditional relative branch. Tests the Overflow (V) flag and branches relatively to the PC if V is set. This instruction branches relatively to the PC in either direction (PC - 63 destination PC + 64). Parameter k is the offset from the PC and is represented in two's complement form. (Equivalent to instruction BRBS 3,k.)
",
"tooltip": "Branch if Overflow Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=51",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=47",
};
case "BSET":
return {
"html": "
Sets a single flag or bit in SREG.
",
"tooltip": "Bit Set in SREG",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=52",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=48",
};
case "BST":
return {
"html": "
Stores bit b from Rd to the T bit in SREG (Status Register).
",
"tooltip": "Bit Store from Bit in Register to T Bit in SREG",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=53",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=48",
};
case "CALL":
return {
"html": "
Calls to a subroutine within the entire program memory. The return address (to the instruction after the CALL) will be stored on the Stack. (See also RCALL.) The Stack Pointer uses a post-decrement scheme during CALL.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Long Call to a Subroutine",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=54",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=49",
};
case "CBI":
return {
- "html": "
Clears a specified bit in an I/O Register. This instruction operates on the lower 32 I/O Registers – addresses 0-31.
",
+ "html": "
Clears a specified bit in an I/O Register. This instruction operates on the lower 32 I/O Registers - addresses 0-31.
",
"tooltip": "Clear Bit in I/O Register",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=55",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=50",
};
case "CBR":
return {
"html": "
Clears the specified bits in register Rd. Performs the logical AND between the contents of register Rd and the complement of the constant mask K. The result will be placed in register Rd. (Equivalent to ANDI Rd,(0xFF - K).)
",
"tooltip": "Clear Bits in Register",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=56",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=51",
};
case "CLC":
return {
"html": "
Clears the Carry (C) flag in SREG (Status Register). (Equivalent to instruction BCLR 0.)
Clears the Global Interrupt Enable (I) bit in SREG (Status Register). The interrupts will be immediately disabled. No interrupt will be executed after the CLI instruction, even if it occurs simultaneously with the CLI instruction. (Equivalent to instruction BCLR 7.)
",
"tooltip": "Clear Global Interrupt Enable Bit",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=58",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=53",
};
case "CLN":
return {
"html": "
Clears the Negative (N) flag in SREG (Status Register). (Equivalent to instruction BCLR 2.)
Clears a register. This instruction performs an Exclusive OR between a register and itself. This will clear all bits in the register. (Equivalent to instruction EOR Rd,Rd.)
This instruction performs a compare between two registers Rd and Rr. None of the registers are changed. All conditional branches can be used after this instruction.
This instruction performs a compare between two registers Rd and Rr and also takes into account the previous carry. None of the registers are changed. All conditional branches can be used after this instruction.
",
"tooltip": "Compare with Carry",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=66",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=60",
};
case "CPI":
return {
"html": "
This instruction performs a compare between register Rd and a constant. The register is not changed. All conditional branches can be used after this instruction.
",
"tooltip": "Compare with Immediate",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=67",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=61",
};
case "CPSE":
return {
"html": "
This instruction performs a compare between two registers Rd and Rr and skips the next instruction if Rd == Rr.
",
"tooltip": "Compare Skip if Equal",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=68",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=62",
};
case "DEC":
return {
- "html": "
Subtracts one -1- from the contents of register Rd and places the result in the destination register Rd.
The C flag in SREG is not affected by the operation, thus allowing the DEC instruction to be used on a loop counter in multiple-precision computations.
When operating on unsigned values, only BREQ and BRNE branches can be expected to perform consistently. When operating on two’s complement values, all signed branches are available.
",
+ "html": "
Subtracts one -1- from the contents of register Rd and places the result in the destination register Rd.
The C flag in SREG is not affected by the operation, thus allowing the DEC instruction to be used on a loop counter in multiple-precision computations.
When operating on unsigned values, only BREQ and BRNE branches can be expected to perform consistently. When operating on two's complement values, all signed branches are available.
The module is an instruction set extension to the AVR CPU, performing DES iterations. The 64-bit data block (plaintext or ciphertext) is placed in the CPU Register File, registers R0-R7, where the LSB of data is placed in the LSB of R0 and the MSB of data is placed in the MSB of R7. The full 64-bit key (including parity bits) is placed in registers R8-R15, organized in the Register File with the LSB of the key in the LSB of R8 and the MSB of the key in the MSB of R15. Executing one DES instruction performs one round in the DES algorithm. Sixteen rounds must be executed in increasing order to form the correct DES ciphertext or plaintext. Intermediate results are stored in the Register File (R0-R15) after each DES instruction. The instruction's operand (K) determines which round is executed, and the Half Carry (H) flag determines whether encryption or decryption is performed.
The DES algorithm is described in “Specifications for the Data Encryption Standard” (Federal Information Processing Standards Publication 46). Intermediate results in this implementation differ from the standard because the initial permutation and the inverse initial permutation are performed in each iteration. This does not affect the result in the final ciphertext or plaintext but reduces the execution time.
",
+ "html": "
The module is an instruction set extension to the AVR CPU, performing DES iterations. The 64-bit data block (plaintext or ciphertext) is placed in the CPU Register File, registers R0-R7, where the LSB of data is placed in the LSB of R0 and the MSB of data is placed in the MSB of R7. The full 64-bit key (including parity bits) is placed in registers R8-R15, organized in the Register File with the LSB of the key in the LSB of R8 and the MSB of the key in the MSB of R15. Executing one DES instruction performs one round in the DES algorithm. Sixteen rounds must be executed in increasing order to form the correct DES ciphertext or plaintext. Intermediate results are stored in the Register File (R0-R15) after each DES instruction. The instruction's operand (K) determines which round is executed, and the Half Carry (H) flag determines whether encryption or decryption is performed.
The DES algorithm is described in \"Specifications for the Data Encryption Standard\" (Federal Information Processing Standards Publication 46). Intermediate results in this implementation differ from the standard because the initial permutation and the inverse initial permutation are performed in each iteration. This does not affect the result in the final ciphertext or plaintext but reduces the execution time.
Indirect call of a subroutine pointed to by the Z (16-bit) Pointer Register in the Register File and the EIND Register in the I/O space. This instruction allows for indirect calls to the entire 4M (words) program memory space. See also ICALL. The Stack Pointer uses a post-decrement scheme during EICALL.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Extended Indirect Call to Subroutine",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=72",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=65",
};
case "EIJMP":
return {
"html": "
Indirect jump to the address pointed to by the Z (16-bit) Pointer Register in the Register File and the EIND Register in the I/O space. This instruction allows for indirect jumps to the entire 4M (words) program memory space. See also IJMP.
This instruction is not available on all devices. Refer to Appendix A.
Loads one byte pointed to by the Z-register and the RAMPZ Register in the I/O space, and places this byte in the destination register Rd. This instruction features a 100% space-effective constant initialization or constant data fetch. The program memory is organized in 16-bit words while the Z-pointer is a byte address. Thus, the least significant bit of the Z-pointer selects either low byte (ZLSB == 0) or high byte (ZLSB == 1). This instruction can address theentire program memory space. The Z-Pointer Register can either be left unchanged by the operation, or it can be incremented. The incrementation applies to the entire 24-bit concatenation of the RAMPZ and Z-Pointer Registers.
Devices with self-programming capability can use the ELPM instruction to read the Fuse and Lock bit value. Refer to the device documentation for a detailed description.
This instruction is not available on all devices. Refer to Appendix A.
The result of these combinations is undefined:
ELPM r30, Z+
ELPM r31, Z+
",
+ "html": "
Loads one byte pointed to by the Z-register and the RAMPZ Register in the I/O space, and places this byte in the destination register Rd. This instruction features a 100% space-effective constant initialization or constant data fetch. The program memory is organized in 16-bit words while the Z-pointer is a byte address. Thus, the least significant bit of the Z-pointer selects either low byte (ZLSB == 0) or high byte (ZLSB == 1). This instruction can address the entire program memory space.The Z-Pointer Register can either be left unchanged by the operation, or it can be incremented. The incrementation applies to the entire 24-bit concatenation of the RAMPZ and Z-Pointer Registers.
Devices with self-programming capability can use the ELPM instruction to read the Fuse and Lock bit value. Refer to the device documentation for a detailed description.
This instruction is not available on all devices. Refer to Appendix A.
The result of these combinations is undefined:
ELPM r30, Z+
ELPM r31, Z+
",
"tooltip": "Extended Load Program Memory",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=73",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=66",
};
case "EOR":
return {
"html": "
Performs the logical EOR between the contents of register Rd and register Rr and places the result in the destination register Rd.
This instruction performs 8-bit × 8-bit → 16-bit unsigned multiplication and shifts the result one bit left.
Let (N.Q) denote a fractional number with N binary digits left of the radix point, and Q binary digits right of the radix point. A multiplication between two numbers in the formats (N1.Q1) and (N2.Q2) results in the format ((N1+N2). (Q1+Q2)). For signal processing applications, the format (1.7) is widely used for the inputs, resulting in a (2.14) format for the product. A left shift is required for the high byte of the product to be in the same format as the inputs. The FMUL instruction incorporates the shift operation in the same number of cycles as MUL.
The (1.7) format is most commonly used with signed numbers, while FMUL performs an unsigned multiplication. This instruction is, therefore, most useful for calculating one of the partial products when performing a signed multiplication with 16-bit inputs in the (1.15) format, yielding a result in the (1.31) format.
Note: The result of the FMUL operation may suffer from a 2’s complement overflow if interpreted as a number in the (1.15) format. The MSB of the multiplication before shifting must be taken into account and is found in the carry bit. See the following example.
The multiplicand Rd and the multiplier Rr are two registers containing unsigned fractional numbers where the implicit radix point lies between bit 6 and bit 7. The 16-bit unsigned fractional product with the implicit radix point between bit 14 and bit 15 is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
",
+ "html": "
This instruction performs 8-bit 8-bit 16-bit unsigned multiplication and shifts the result one bit left.
8
Let (N.Q) denote a fractional number with N binary digits left of the radix point, and Q binary digits right of the radix point. A multiplication between two numbers in the formats (N1.Q1) and (N2.Q2) results in the format ((N1+N2).(Q1+Q2)). For signal processing applications, the format (1.7) is widely used for the inputs, resulting in a (2.14) format for the product. A left shift is required for the high byte of the product to be in the same format as the inputs. The FMUL instruction incorporates the shift operation in the same number of cycles as MUL.
The (1.7) format is most commonly used with signed numbers, while FMUL performs an unsigned multiplication. This instruction is, therefore, most useful for calculating one of the partial products when performing a signed multiplication with 16-bit inputs in the (1.15) format, yielding a result in the (1.31) format.
Note:The result of the FMUL operation may suffer from a 2's complement overflow if interpreted as a number in the (1.15) format. The MSB of the multiplication before shifting must be taken into account and is found in the carry bit. See the following example.
The multiplicand Rd and the multiplier Rr are two registers containing unsigned fractional numbers where the implicit radix point lies between bit 6 and bit 7. The 16-bit unsigned fractional product with the implicit radix point between bit 14 and bit 15 is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
This instruction performs 8-bit × 8-bit → 16-bit signed multiplication and shifts the result one bit left.
Let (N.Q) denote a fractional number with N binary digits left of the radix point, and Q binary digits right of the radix point. A multiplication between two numbers in the formats (N1.Q1) and (N2.Q2) results in the format ((N1+N2). (Q1+Q2)). For signal processing applications, the format (1.7) is widely used for the inputs, resulting in a (2.14)format for the product. A left shift is required for the high byte of the product to be in the same format as the inputs. The FMULS instruction incorporates the shift operation in the same number of cycles as MULS.
The multiplicand Rd and the multiplier Rr are two registers containing signed fractional numbers where the implicit radix point lies between bit 6 and bit 7. The 16-bit signed fractional product with the implicit radix point between bit 14 and bit 15 is placed in R1 (high byte) and R0 (low byte).
Note: That when multiplying 0x80 (-1) with 0x80 (-1), the result of the shift operation is 0x8000 (-1). The shift operation thus gives a two’s complement overflow. This must be checked and handled by software.
This instruction is not available on all devices. Refer to Appendix A.
",
+ "html": "
This instruction performs 8-bit 8-bit 16-bit signed multiplication and shifts the result one bit left.
Let (N.Q) denote a fractional number with N binary digits left of the radix point, and Q binary digits right of the radix point. A multiplication between two numbers in the formats (N1.Q1) and (N2.Q2) results in the format ((N1+N2).(Q1+Q2)). For signal processing applications, the format (1.7) is widely used for the inputs, resulting in a (2.14) format for the product. A left shift is required for the high byte of the product to be in the same format as the inputs. The FMULS instruction incorporates the shift operation in the same number of cycles as MULS.
The multiplicand Rd and the multiplier Rr are two registers containing signed fractional numbers where the implicit radix point lies between bit 6 and bit 7. The 16-bit signed fractional product with the implicit radix point between bit 14 and bit 15 is placed in R1 (high byte) and R0 (low byte).
Note:That when multiplying 0x80 (-1) with 0x80 (-1), the result of the shift operation is 0x8000 (-1). The shift operation thus gives a two's complement overflow. This must be checked and handled by software.
This instruction is not available on all devices. Refer to Appendix A.
This instruction performs 8-bit × 8-bit → 16-bit signed multiplication and shifts the result one bit left.
Let (N.Q) denote a fractional number with N binary digits left of the radix point, and Q binary digits right of the radix point. A multiplication between two numbers in the formats (N1.Q1) and (N2.Q2) results in the format ((N1+N2). (Q1+Q2)). For signal processing applications, the format (1.7) is widely used for the inputs, resulting in a (2.14) format for the product. A left shift is required for the high byte of the product to be in the same format as the inputs. The FMULSU instruction incorporates the shift operation in the same number of cycles as MULSU.
The (1.7) format is most commonly used with signed numbers, while FMULSU performs a multiplication with one unsigned and one signed input. This instruction is, therefore, most useful for calculating two of the partial products when performing a signed multiplication with 16-bit inputs in the (1.15) format, yielding a result in the (1.31) format.
Note: The result of the FMULSU operation may suffer from a 2's complement overflow if interpreted as a number in the (1.15) format. The MSB of the multiplication before shifting must be taken into account and is found in the carry bit. See the following example.
The multiplicand Rd and the multiplier Rr are two registers containing fractional numbers where the implicit radix point lies between bit 6 and bit 7. The multiplicand Rd is a signed fractional number, and the multiplier Rr is an unsigned fractional number. The 16-bit signed fractional product with the implicit radix point between bit 14 and bit 15 is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
",
+ "html": "
This instruction performs 8-bit 8-bit 16-bit signed multiplication and shifts the result one bit left.
Let (N.Q) denote a fractional number with N binary digits left of the radix point, and Q binary digits right of the radix point. A multiplication between two numbers in the formats (N1.Q1) and (N2.Q2) results in the format ((N1+N2).(Q1+Q2)). For signal processing applications, the format (1.7) is widely used for the inputs, resulting in a (2.14) format for the product. A left shift is required for the high byte of the product to be in the same format as the inputs. The FMULSU instruction incorporates the shift operation in the same number of cycles as MULSU.
The (1.7) format is most commonly used with signed numbers, while FMULSU performs a multiplication with one unsigned and one signed input. This instruction is, therefore, most useful for calculating two of the partial products when performing a signed multiplication with 16-bit inputs in the (1.15) format, yielding a result in the (1.31) format.
Note:The result of the FMULSU operation may suffer from a 2's complement overflow if interpreted as a number in the (1.15) format. The MSB of the multiplication before shifting must be taken into account and is found in the carry bit. See the following example.
The multiplicand Rd and the multiplier Rr are two registers containing fractional numbers where the implicit radix point lies between bit 6 and bit 7. The multiplicand Rd is a signed fractional number,and the multiplier Rr is an unsigned fractional number. The 16-bit signed fractional product with the implicit radix point between bit 14 and bit 15 is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Fractional Multiply Signed with Unsigned",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=79",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=71",
};
case "ICALL":
return {
"html": "
Indirect call of a subroutine pointed to by the Z (16-bit) Pointer Register in the Register File. The Z-Pointer Register is 16 bits wide and allows a call to a subroutine within the lowest 64K words (128 KB) section in the program memory space. The Stack Pointer uses a post-decrement scheme during ICALL.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Indirect Call to Subroutine",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=80",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=73",
};
case "IJMP":
return {
"html": "
Indirect jump to the address pointed to by the Z (16-bit) Pointer Register in the Register File. The Z-Pointer Register is 16 bits wide and allows jump within the lowest 64K words (128 KB) section of program memory.
This instruction is not available on all devices. Refer to Appendix A.
Loads data from the I/O space into register Rd in the Register File.
",
"tooltip": "Load an I/O Location to Register",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=82",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=74",
};
case "INC":
return {
- "html": "
Adds one -1- to the contents of register Rd and places the result in the destination register Rd.
The C flag in SREG is not affected by the operation, thus allowing the INC instruction to be used on a loop counter in multiple-precision computations.
When operating on unsigned numbers, only BREQ and BRNE branches can be expected to perform consistently. When operating on two’s complement values, all signed branches are available.
",
+ "html": "
Adds one -1- to the contents of register Rd and places the result in the destination register Rd.
The C flag in SREG is not affected by the operation, thus allowing the INC instruction to be used on a loop counter in multiple-precision computations.
When operating on unsigned numbers, only BREQ and BRNE branches can be expected to perform consistently. When operating on two's complement values, all signed branches are available.
Load one byte indirect from data space to register and stores and clear the bits in data space specified by the register. The instruction can only be used towards internal SRAM.
The data location is pointed to by the Z (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPZ in the register in the I/O area has to be changed.
The Z-Pointer Register is left unchanged by the operation. This instruction is especially suited for clearing status bits stored in SRAM.
",
"tooltip": "Load and Clear",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=85",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=77",
};
case "LAS":
return {
"html": "
Load one byte indirect from data space to register and set bits in the data space specified by the register. The instruction can only be used towards internal SRAM.
The data location is pointed to by the Z (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPZ in the register in the I/O area has to be changed.
The Z-Pointer Register is left unchanged by the operation. This instruction is especially suited for setting status bits stored in SRAM.
",
"tooltip": "Load and Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=86",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=77",
};
case "LAT":
return {
"html": "
Load one byte indirect from data space to register and toggles bits in the data space specified by the register. The instruction can only be used towards SRAM.
The data location is pointed to by the Z (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPZ in the register in the I/O area has to be changed.
The Z-Pointer Register is left unchanged by the operation. This instruction is especially suited for changing status bits stored in SRAM.
",
"tooltip": "Load and Toggle",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=86",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=78",
};
case "LD":
case "LDD":
return {
- "html": "
Loads one byte indirect from the data space to a register. The data space usually consists of the Register File, I/O memory, and SRAM, refer to the device data sheet for a detailed definition of the data space.
The data location is pointed to by the X (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPX in the register in the I/O area has to be changed.
The X-Pointer Register can either be left unchanged by the operation, or it can be post-incremented or pre- decremented. These features are especially suited for accessing arrays, tables, and Stack Pointer usage of the X-Pointer Register. Note that only the low byte of the X-pointer is updated in devices with no more than 256 bytes of data space. For such devices, the high byte of the pointer is not used by this instruction and can be used for other purposes. The RAMPX Register in the I/O area is updated in parts with more than 64 KB data space or more than 64 KB program memory, and the increment/decrement is added to the entire 24-bit address on such devices.
Not all variants of this instruction are available on all devices.
In the Reduced Core AVRrc, the LD instruction can be used to achieve the same operation as LPM since the program memory is mapped to the data memory space.
The result of these combinations is undefined:
LD r26, X+
LD r27, X+
LD r26, -X
LD r27, -X
Using the X-pointer:
",
+ "html": "
Loads one byte indirect with or without displacement from the data space to a register. The data space usually consists of the Register File, I/O memory, and SRAM, refer to the device data sheet for a detailed definition of the data space.
The data location is pointed to by the Z (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPZ in the register in the I/O area has to be changed.
The Z-Pointer Register can either be left unchanged by the operation, or it can be post-incremented or pre-decremented. These features are especially suited for Stack Pointer usage of the Z-pointer Register. However, because the Z-Pointer Register can be used for indirect subroutine calls, indirect jumps, and table look-up, it is often more convenient to use the X- or Y-pointer as a dedicated Stack Pointer. Note that only the low byte of the Z-pointer is updated in devices with no more than 256 bytes of data space. For such devices, the high byte of the pointer is not used by this instruction and can be used for other purposes. The RAMPZ Register in the I/O area is updated in parts with more than 64 KB data space or more than 64 KB program memory, and the increment/decrement/ displacement is added to the entire 24-bit address on such devices.
Not all variants of this instruction are available on all devices.
In the Reduced Core AVRrc, the LD instruction can be used to achieve the same operation as LPM since the program memory is mapped to the data memory space.
For using the Z-pointer for table look-up in program memory, see the LPM and ELPM instructions.
The result of these combinations is undefined:
LD r30, Z+
LD r31, Z+
LD r30, -Z
LD r31, -Z
Using the Z-pointer:
",
"tooltip": "Load Indirect from Data Space to Register using X",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=87",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=82",
};
case "LDI":
return {
"html": "
Loads an 8-bit constant directly to register 16 to 31.
Loads one byte from the data space to a register. The data space usually consists of the Register File, I/O memory, and SRAM, refer to the device data sheet for a detailed definition of the data space.
A 16-bit address must be supplied. Memory access is limited to the current data segment of 64 KB. The LDS instruction uses the RAMPD Register to access memory above 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPD in the register in the I/O area has to be changed.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Load Direct from Data Space",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=93",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=84",
};
case "LPM":
return {
"html": "
Loads one byte pointed to by the Z-register into the destination register Rd. This instruction features a 100% space-effective constant initialization or constant data fetch. The program memory is organized in 16-bit words while the Z-pointer is a byte address. Thus, the least significant bit of the Z-pointer selects either low byte (ZLSb == 0) or high byte (ZLSb == 1). This instruction can address the first 64 KB (32K words) of program memory. The Z-Pointer Register can either be left unchanged by the operation, or it can be incremented. The incrementation does not apply to the RAMPZ Register.
Devices with self-programming capability can use the LPM instruction to read the Fuse and Lock bit values. Refer to the device documentation for a detailed description.
The LPM instruction is not available on all devices. Refer to Appendix A.
The result of these combinations is undefined:
LPM r30, Z+
LPM r31, Z+
",
"tooltip": "Load Program Memory",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=95",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=86",
};
case "LSL":
return {
"html": "
Shifts all bits in Rd one place to the left. Bit 0 is cleared. Bit 7 is loaded into the C flag of the SREG. This operation effectively multiplies signed and unsigned values by two.
Shifts all bits in Rd one place to the right. Bit 7 is cleared. Bit 0 is loaded into the C flag of the SREG. This operation effectively divides an unsigned value by two. The C flag can be used to round the result.
This instruction makes a copy of one register into another. The source register Rr is left unchanged, while the destination register Rd is loaded with a copy of Rr.
This instruction makes a copy of one register pair into another register pair. The source register pair Rr+1:Rr is left unchanged, while the destination register pair Rd+1:Rd is loaded with a copy of Rr + 1:Rr.
This instruction is not available on all devices. Refer to Appendix A.
This instruction performs 8-bit × 8-bit → 16-bit unsigned multiplication.
The multiplicand Rd and the multiplier Rr are two registers containing unsigned numbers. The 16-bit unsigned product is placed in R1 (high byte) and R0 (low byte). Note that if the multiplicand or the multiplier is selected from R0 or R1, the result will overwrite those after multiplication.
This instruction is not available on all devices. Refer to Appendix A.
",
+ "html": "
This instruction performs 8-bit 8-bit 16-bit unsigned multiplication.
The multiplicand Rd and the multiplier Rr are two registers containing unsigned numbers. The 16-bit unsigned product is placed in R1 (high byte) and R0 (low byte). Note that if the multiplicand or the multiplier is selected from R0 or R1, the result will overwrite those after multiplication.
This instruction is not available on all devices. Refer to Appendix A.
This instruction performs 8-bit × 8-bit → 16-bit signed multiplication.
The multiplicand Rd and the multiplier Rr are two registers containing signed numbers. The 16-bit signed product is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
",
+ "html": "
This instruction performs 8-bit 8-bit 16-bit signed multiplication.
The multiplicand Rd and the multiplier Rr are two registers containing signed numbers. The 16-bit signed product is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
This instruction performs 8-bit × 8-bit → 16-bit multiplication of a signed and an unsigned number.
The multiplicand Rd and the multiplier Rr are two registers. The multiplicand Rd is a signed number, and the multiplier Rr is unsigned. The 16-bit signed product is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
",
+ "html": "
This instruction performs 8-bit 8-bit 16-bit multiplication of a signed and an unsigned number.
The multiplicand Rd and the multiplier Rr are two registers. The multiplicand Rd is a signed number, and the multiplier Rr is unsigned. The 16-bit signed product is placed in R1 (high byte) and R0 (low byte).
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Multiply Signed with Unsigned",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=102",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=92",
};
case "NEG":
return {
- "html": "
Replaces the contents of register Rd with its two’s complement; the value 0x80 is left unchanged.
",
+ "html": "
Replaces the contents of register Rd with its two's complement; the value 0x80 is left unchanged.
Performs the logical OR between the contents of register Rd and a constant, and places the result in the destination register Rd.
",
"tooltip": "Logical OR with Immediate",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=106",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=96",
};
case "OUT":
return {
"html": "
Stores data from register Rr in the Register File to I/O space.
",
"tooltip": "Store Register to I/O Location",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=107",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=97",
};
case "POP":
return {
"html": "
This instruction loads register Rd with a byte from the STACK. The Stack Pointer is pre-incremented by 1 before the POP.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Pop Register from Stack",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=108",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=97",
};
case "PUSH":
return {
- "html": "
This instruction stores the contents of register Rr on the STACK. The Stack Pointer is post-decremented by 1 after the PUSH.
This instruction is not available on all devices. Refer to Appendix A.
",
+ "html": "
This instruction stores the contents of register Rr on the STACK. The Stack Pointer is post- decremented by 1 after the PUSH.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Push Register on Stack",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=109",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=98",
};
case "RCALL":
return {
"html": "
Relative call to an address within PC - 2K + 1 and PC + 2K (words). The return address (the instruction after the RCALL) is stored onto the Stack. See also CALL. For AVR microcontrollers with program memory not exceeding 4K words (8 KB), this instruction can address the entire memory from every address location. The Stack Pointer uses a post-decrement scheme during RCALL.
",
"tooltip": "Relative Call to Subroutine",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=110",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=99",
};
case "RET":
return {
"html": "
Returns from the subroutine. The return address is loaded from the STACK. The Stack Pointer uses a pre-increment scheme during RET.
",
"tooltip": "Return from Subroutine",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=111",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=100",
};
case "RETI":
return {
- "html": "
Returns from the interrupt. The return address is loaded from the STACK, and the Global Interrupt Enable bit is set.
Note that the Status Register is not automatically stored when entering an interrupt routine, and it is not restored when returning from an interrupt routine. This must be handled by the application program. The Stack Pointer uses a pre-increment scheme during RETI.
",
+ "html": "
Returns from the interrupt. The return address is loaded from the STACK, and the Global Interrupt Enable bit is set.
Note:The Status Register is not automatically stored when entering an interrupt routine and is not restored when returning from one. The application program must handle this. The Stack Pointer uses a pre-increment scheme during RETI.
Note:For AVRxm and AVRxt devices, the interrupt controller status (CPUINT.STATUS) register contains the interrupt state information that ensures return to the correct interrupt level when the RETI instruction is executed at the end of the interrupt handler. The flag corresponding to the processed interrupt is cleared when RETI is executed.
",
"tooltip": "Return from Interrupt",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=112",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=101",
};
case "RJMP":
return {
"html": "
Relative jump to an address within PC - 2K +1 and PC + 2K (words). For AVR microcontrollers with pogram memory not exceeding 4K words (8 KB), this instruction can address the entire memory from every address location. See also JMP.
Shifts all bits in Rd one place to the left. The C flag is shifted into bit 0 of Rd. Bit 7 is shifted into the C flag. This operation, combined with LSL, effectively multiplies multi-byte signed and unsigned values by two.
",
"tooltip": "Rotate Left trough Carry",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=114",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=103",
};
case "ROR":
return {
"html": "
Shifts all bits in Rd one place to the right. The C flag is shifted into bit 7 of Rd. Bit 0 is shifted into the C flag. This operation, combined with ASR, effectively divides multi-byte signed values by two. Combined with LSR, it effectively divides multi-byte unsigned values by two. The Carry flag can be used to round the result.
",
"tooltip": "Rotate Right through Carry",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=115",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=104",
};
case "SBC":
return {
"html": "
Subtracts two registers and subtracts with the C flag, and places the result in the destination register Rd.
",
"tooltip": "Subtract with Carry",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=116",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=105",
};
case "SBCI":
return {
"html": "
Subtracts a constant from a register and subtracts with the C flag, and places the result in the destination register Rd.
",
"tooltip": "Subtract Immediate with Carry SBI – Set Bit in I/O Register",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=117",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=106",
};
case "SBI":
return {
- "html": "
Sets a specified bit in an I/O Register. This instruction operates on the lower 32 I/O Registers – addresses 0-31.
",
+ "html": "
Sets a specified bit in an I/O Register. This instruction operates on the lower 32 I/O Registers - addresses 0-31.
",
"tooltip": "Set Bit in I/O Register",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=118",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=107",
};
case "SBIC":
return {
- "html": "
This instruction tests a single bit in an I/O Register and skips the next instruction if the bit is cleared. This instruction operates on the lower 32 I/O Registers – addresses 0-31.
",
+ "html": "
This instruction tests a single bit in an I/O Register and skips the next instruction if the bit is cleared. This instruction operates on the lower 32 I/O Registers - addresses 0-31.
",
"tooltip": "Skip if Bit in I/O Register is Cleared",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=119",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=107",
};
case "SBIS":
return {
- "html": "
This instruction tests a single bit in an I/O Register and skips the next instruction if the bit is set. This instruction operates on the lower 32 I/O Registers – addresses 0-31.
",
+ "html": "
This instruction tests a single bit in an I/O Register and skips the next instruction if the bit is set. This instruction operates on the lower 32 I/O Registers - addresses 0-31.
",
"tooltip": "Skip if Bit in I/O Register is Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=120",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=108",
};
case "SBIW":
return {
"html": "
Subtracts an immediate value (0-63) from a register pair and places the result in the register pair. This instruction operates on the upper four register pairs and is well suited for operations on the Pointer Registers.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Subtract Immediate from Word",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=121",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=109",
};
case "SBR":
return {
"html": "
Sets specified bits in register Rd. Performs the logical ORI between the contents of register Rd and a constant mask K, and places the result in the destination register Rd. (Equivalent to ORI Rd,K.)
",
"tooltip": "Set Bits in Register",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=122",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=110",
};
case "SBRC":
return {
"html": "
This instruction tests a single bit in a register and skips the next instruction if the bit is cleared.
",
"tooltip": "Skip if Bit in Register is Cleared",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=123",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=111",
};
case "SBRS":
return {
"html": "
This instruction tests a single bit in a register and skips the next instruction if the bit is set.
",
"tooltip": "Skip if Bit in Register is Set",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=124",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=112",
};
case "SEC":
return {
"html": "
Sets the Carry (C) flag in SREG (Status Register). (Equivalent to instruction BSET 0.)
Sets the Zero (Z) flag in SREG (Status Register). (Equivalent to instruction BSET 1.)
",
"tooltip": "Set Zero Flag",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=132",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=118",
};
case "SPM":
return {
- "html": "
SPM can be used to erase a page in the program memory, to write a page in the program memory (that is already erased), and to set Boot Loader Lock bits. In some devices, the Program memory can be written one word at a time. In other devices, an entire page can be programmed simultaneously after first filling a temporary page buffer. In all cases, the program memory must be erased one page at a time. When erasing the program memory, the RAMPZ and Z-register are used as page address. When writing the program memory, the RAMPZ and Z-register are used as page or word address, and the R1:R0 register pair is used as data(1). The Flash is word-accessed for code space write operations, so the least significant bit of the RAMPZ register concatenated with the Z register should be set to ‘0’. When setting the Boot Loader Lock bits, the R1:R0 register pair is used as data. Refer to the device documentation for the detailed description of SPM usage. This instruction can address the entire program memory.
The SPM instruction is not available on all devices. Refer to Appendix A.
Note: 1. R1 determines the instruction high byte, and R0 determines the instruction low byte.
",
+ "html": "
SPM can be used to erase a page in the program memory, to write a page in the program memory (that is already erased), and to set Boot Loader Lock bits. In some devices, the Program memory can be written one word at a time. In other devices, an entire page can be programmed simultaneously after first filling a temporary page buffer. In all cases, the program memory must be erased one page at a time. When erasing the program memory, the RAMPZ and Z-register are used as page address. When writing the program memory, the RAMPZ and Z-register are used as page or word address, and the R1:R0 register pair is used as data(1). The Flash is word-accessed for code space write operations, so the least significant bit of the RAMPZ register concatenated with the Z register should be set to '0'. When setting the Boot Loader Lock bits, the R1:R0 register pair is used as data.Refer to the device documentation for the detailed description of SPM usage. This instruction can address the entire program memory.
The SPM instruction is not available on all devices. Refer to Appendix A.
Note:1. R1 determines the instruction high byte, and R0 determines the instruction low byte.
",
"tooltip": "Store Program Memory",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=133",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=119",
};
case "ST":
case "STD":
return {
- "html": "
Stores one byte indirect from a register to data space. The data space usually consists of the Register File, I/O memory, and SRAM, refer to the device data sheet for a detailed definition of the data space.
The data location is pointed to by the X (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPX in the register in the I/O area has to be changed.
The X-Pointer Register can either be left unchanged by the operation, or it can be post-incremented or pre- decremented. These features are especially suited for accessing arrays, tables, and Stack Pointer usage of the X-Pointer Register. Note that only the low byte of the X-pointer is updated in devices with no more than 256 bytes of data space. For such devices, the high byte of the pointer is not used by this instruction and can be used for otherpurposes. The RAMPX Register in the I/O area is updated in parts with more than 64 KB data space or more than 64 KB program memory, and the increment/ decrement is added to the entire 24-bit address on such devices.
Not all variants of this instruction are available on all devices.
The result of these combinations is undefined:
ST X+, r26
ST X+, r27
ST -X, r26
ST -X, r27
Using the X-pointer:
",
+ "html": "
Stores one byte indirect with or without displacement from a register to data space. The data space usually consists of the Register File, I/O memory, and SRAM, refer to the device data sheet for a detailed definition of the data space.
The data location is pointed to by the Z (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPZ in the register in the I/O area has to be changed.
The Z-Pointer Register can either be left unchanged by the operation, or it can be post-incremented or pre-decremented. These features are especially suited for Stack Pointer usage of the Z-PointerRegister. However, because the Z-Pointer Register can be used for indirect subroutine calls, indirect jumps, and table look-up, it is often more convenient to use the X- or Y-pointer as a dedicated Stack Pointer. Note that only the low byte of the Z-pointer is updated in devices with no more than 256 bytes of data space. For such devices, the high byte of the pointer is not used by this instruction and can be used for other purposes. The RAMPZ Register in the I/O area is updated in parts with more than 64 KB data space or more than 64 KB program memory, and the increment/decrement/ displacement is added to the entire 24-bit address on such devices.
Not all variants of this instruction are available on all devices.
The result of these combinations is undefined:
ST Z+, r30
ST Z+, r31
ST -Z, r30
ST -Z, r31
Using the Z-pointer:
",
"tooltip": "Store Indirect From Register to Data Space using Index X",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=136",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=125",
};
case "STS":
return {
"html": "
Stores one byte from a Register to the data space. The data space usually consists of the Register File, I/O memory, and SRAM, refer to the device data sheet for a detailed definition of the data space.
A 16-bit address must be supplied. Memory access is limited to the current data segment of 64 KB. The STS instruction uses the RAMPD Register to access memory above 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPD in the register in the I/O area has to be changed.
This instruction is not available on all devices. Refer to Appendix A.
",
"tooltip": "Store Direct to Data Space",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=141",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=127",
};
case "SUB":
return {
"html": "
Subtracts two registers and places the result in the destination register Rd.
",
"tooltip": "Subtract Without Carry",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=143",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=129",
};
case "SUBI":
return {
"html": "
Subtracts a register and a constant, and places the result in the destination register Rd. This instruction is working on Register R16 to R31 and is very well suited for operations on the X, Y, and Z-pointers.
Tests if a register is zero or negative. Performs a logical AND between a register and itself. The register will remain unchanged. (Equivalent to instruction AND Rd,Rd.)
",
"tooltip": "Test for Zero or Minus",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=146",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=131",
};
case "WDR":
return {
"html": "
This instruction resets the Watchdog Timer. This instruction must be executed within a limited time given by the WD prescaler. See the Watchdog Timer hardware specification.
Exchanges one byte indirect between the register and data space.
The data location is pointed to by the Z (16-bit) Pointer Register in the Register File. Memory access is limited to the current data segment of 64 KB. To access another data segment in devices with more than 64 KB data space, the RAMPZ in the register in the I/O area has to be changed.
The Z-Pointer Register is left unchanged by the operation. This instruction is especially suited for writing/reading status bits stored in SRAM.
",
"tooltip": "Exchange",
- "url": "https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf#page=148",
+ "url": "https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReferenceManuals/AVR-InstructionSet-Manual-DS40002198.pdf#page=133",
};
}
diff --git a/lib/asm-docs/generated/asm-docs-evm.ts b/lib/asm-docs/generated/asm-docs-evm.ts
index b591327400e..e6038491699 100644
--- a/lib/asm-docs/generated/asm-docs-evm.ts
+++ b/lib/asm-docs/generated/asm-docs-evm.ts
@@ -124,8 +124,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "ISZERO":
return {
- "html": "Simple not operator\nInput: a\nOutput: a == 0",
- "tooltip": "Simple not operator",
+ "html": "Is-zero comparison\nInput: a\nOutput: a == 0",
+ "tooltip": "Is-zero comparison",
"url": "https://www.evm.codes/#15"
};
@@ -929,22 +929,22 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "SLOADBYTES":
return {
- "html": "\nInput: -\nOutput: -",
- "tooltip": "",
+ "html": "Conditionally alter the program counter to relative offset\nInput: condition\nOutput: -",
+ "tooltip": "Conditionally alter the program counter to relative offset",
"url": "https://www.evm.codes/#e1"
};
case "SSTOREBYTES":
return {
- "html": "\nInput: -\nOutput: -",
- "tooltip": "",
+ "html": "Alter the program counter to a relative offset in jump table\nInput: case\nOutput: -",
+ "tooltip": "Alter the program counter to a relative offset in jump table",
"url": "https://www.evm.codes/#e2"
};
case "SSIZE":
return {
- "html": "\nInput: -\nOutput: -",
- "tooltip": "",
+ "html": "Call into a function\nInput: -\nOutput: -",
+ "tooltip": "Call into a function",
"url": "https://www.evm.codes/#e3"
};
diff --git a/lib/asm-docs/generated/asm-docs-llvm.ts b/lib/asm-docs/generated/asm-docs-llvm.ts
index ac3975577ca..fe4e8ed0fcd 100644
--- a/lib/asm-docs/generated/asm-docs-llvm.ts
+++ b/lib/asm-docs/generated/asm-docs-llvm.ts
@@ -6,391 +6,3952 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case 'RET':
return {
url: `https://llvm.org/docs/LangRef.html#ret-instruction`,
- html: `
The ‘ret’ instruction is used to return control flow (and optionallya value) from a function back to the caller.
There are two forms of the ‘ret’ instruction: one that returns avalue and then causes control flow, and one that just causes controlflow to occur.
Arguments:
The ‘ret’ instruction optionally accepts a single argument, thereturn value. The type of the return value must be a ‘firstclass’ type.
A function is not well formed if it has a non-voidreturn type and contains a ‘ret’ instruction with no return value ora return value with a type that does not match its type, or if it has avoid return type and contains a ‘ret’ instruction with a returnvalue.
Semantics:
When the ‘ret’ instruction is executed, control flow returns back tothe calling function’s context. If the caller is a“call” instruction, execution continues at theinstruction after the call. If the caller was an“invoke” instruction, execution continues at thebeginning of the “normal” destination block. If the instruction returnsa value, that value shall set the call or invoke instruction’s returnvalue.
Example:
reti325; Return an integer value of 5retvoid; Return from a void functionret{i32,i8}{i324,i82}; Return a struct of values 4 and 2
The ‘ret’ instruction is used to return control flow (and optionally
+a value) from a function back to the caller.
+
There are two forms of the ‘ret’ instruction: one that returns a
+value and then causes control flow, and one that just causes control
+flow to occur.
+
+
+
Arguments:
+
The ‘ret’ instruction optionally accepts a single argument, the
+return value. The type of the return value must be a ‘first
+class’ type.
+
A function is not well formed if it has a non-void
+return type and contains a ‘ret’ instruction with no return value or
+a return value with a type that does not match its type, or if it has a
+void return type and contains a ‘ret’ instruction with a return
+value.
+
+
+
Semantics:
+
When the ‘ret’ instruction is executed, control flow returns back to
+the calling function’s context. If the caller is a
+“call” instruction, execution continues at the
+instruction after the call. If the caller was an
+“invoke” instruction, execution continues at the
+beginning of the “normal” destination block. If the instruction returns
+a value, that value shall set the call or invoke instruction’s return
+value.
+
+
+
Example:
+
reti325; Return an integer value of 5
+retvoid; Return from a void function
+ret{i32,i8}{i324,i82}; Return a struct of values 4 and 2
+
+
+
+`,
tooltip: `The ‘ret’ instruction is used to return control flow (and optionallya value) from a function back to the caller.There are two forms of the ‘ret’ instruction: one that returns avalue and then causes control flow, and one that just causes controlflow to occur.`,
};
case 'BR':
return {
url: `https://llvm.org/docs/LangRef.html#br-instruction`,
- html: `
The ‘br’ instruction is used to cause control flow to transfer to adifferent basic block in the current function. There are two forms ofthis instruction, corresponding to a conditional branch and anunconditional branch.
Arguments:
The conditional branch form of the ‘br’ instruction takes a single‘i1’ value and two ‘label’ values. The unconditional form of the‘br’ instruction takes a single ‘label’ value as a target.
Semantics:
Upon execution of a conditional ‘br’ instruction, the ‘i1’argument is evaluated. If the value is true, control flows to the‘iftrue’ label argument. If “cond” is false, control flowsto the ‘iffalse’ label argument.If ‘cond’ is poison or undef, this instruction has undefinedbehavior.
The ‘br’ instruction is used to cause control flow to transfer to a
+different basic block in the current function. There are two forms of
+this instruction, corresponding to a conditional branch and an
+unconditional branch.
+
+
+
Arguments:
+
The conditional branch form of the ‘br’ instruction takes a single
+‘i1’ value and two ‘label’ values. The unconditional form of the
+‘br’ instruction takes a single ‘label’ value as a target.
+
+
+
Semantics:
+
Upon execution of a conditional ‘br’ instruction, the ‘i1’
+argument is evaluated. If the value is true, control flows to the
+‘iftrue’ label argument. If “cond” is false, control flows
+to the ‘iffalse’ label argument.
+If ‘cond’ is poison or undef, this instruction has undefined
+behavior.
+
+`,
tooltip: `The ‘br’ instruction is used to cause control flow to transfer to adifferent basic block in the current function. There are two forms ofthis instruction, corresponding to a conditional branch and anunconditional branch.`,
};
case 'SWITCH':
return {
url: `https://llvm.org/docs/LangRef.html#switch-instruction`,
- html: `
The ‘switch’ instruction is used to transfer control flow to one ofseveral different places. It is a generalization of the ‘br’instruction, allowing a branch to occur to one of many possibledestinations.
Arguments:
The ‘switch’ instruction uses three parameters: an integercomparison value ‘value’, a default ‘label’ destination, and anarray of pairs of comparison value constants and ‘label’s. The tableis not allowed to contain duplicate constant entries.
Semantics:
The switch instruction specifies a table of values and destinations.When the ‘switch’ instruction is executed, this table is searchedfor the given value. If the value is found, control flow is transferredto the corresponding destination; otherwise, control flow is transferredto the default destination.If ‘value’ is poison or undef, this instruction has undefinedbehavior.
Implementation:
Depending on properties of the target machine and the particularswitch instruction, this instruction may be code generated indifferent ways. For example, it could be generated as a series ofchained conditional branches or with a lookup table.
Example:
; Emulate a conditional br instruction%Val=zexti1%valuetoi32switchi32%Val,label%truedest[i320,label%falsedest]; Emulate an unconditional br instructionswitchi320,label%dest[]; Implement a jump table:switchi32%val,label%otherwise[i320,label%onzeroi321,label%ononei322,label%ontwo]
The ‘switch’ instruction is used to transfer control flow to one of
+several different places. It is a generalization of the ‘br’
+instruction, allowing a branch to occur to one of many possible
+destinations.
+
+
+
Arguments:
+
The ‘switch’ instruction uses three parameters: an integer
+comparison value ‘value’, a default ‘label’ destination, and an
+array of pairs of comparison value constants and ‘label’s. The table
+is not allowed to contain duplicate constant entries.
+
+
+
Semantics:
+
The switch instruction specifies a table of values and destinations.
+When the ‘switch’ instruction is executed, this table is searched
+for the given value. If the value is found, control flow is transferred
+to the corresponding destination; otherwise, control flow is transferred
+to the default destination.
+If ‘value’ is poison or undef, this instruction has undefined
+behavior.
+
+
+
Implementation:
+
Depending on properties of the target machine and the particular
+switch instruction, this instruction may be code generated in
+different ways. For example, it could be generated as a series of
+chained conditional branches or with a lookup table.
+
+
+
Example:
+
; Emulate a conditional br instruction
+%Val=zexti1%valuetoi32
+switchi32%Val,label%truedest[i320,label%falsedest]
+
+; Emulate an unconditional br instruction
+switchi320,label%dest[]
+
+; Implement a jump table:
+switchi32%val,label%otherwise[i320,label%onzero
+i321,label%onone
+i322,label%ontwo]
+
+
+
+`,
tooltip: `The ‘switch’ instruction is used to transfer control flow to one ofseveral different places. It is a generalization of the ‘br’instruction, allowing a branch to occur to one of many possibledestinations.`,
};
case 'INDIRECTBR':
return {
url: `https://llvm.org/docs/LangRef.html#indirectbr-instruction`,
- html: `
The ‘indirectbr’ instruction implements an indirect branch to alabel within the current function, whose address is specified by“address”. Address must be derived from ablockaddress constant.
Arguments:
The ‘address’ argument is the address of the label to jump to. Therest of the arguments indicate the full set of possible destinationsthat the address may point to. Blocks are allowed to occur multipletimes in the destination list, though this isn’t particularly useful.
This destination list is required so that dataflow analysis has anaccurate understanding of the CFG.
Semantics:
Control transfers to the block specified in the address argument. Allpossible destination blocks must be listed in the label list, otherwisethis instruction has undefined behavior. This implies that jumps tolabels defined in other functions have undefined behavior as well.If ‘address’ is poison or undef, this instruction has undefinedbehavior.
Implementation:
This is typically implemented with a jump through a register.
The ‘indirectbr’ instruction implements an indirect branch to a
+label within the current function, whose address is specified by
+“address”. Address must be derived from a
+blockaddress constant.
+
+
+
Arguments:
+
The ‘address’ argument is the address of the label to jump to. The
+rest of the arguments indicate the full set of possible destinations
+that the address may point to. Blocks are allowed to occur multiple
+times in the destination list, though this isn’t particularly useful.
+
This destination list is required so that dataflow analysis has an
+accurate understanding of the CFG.
+
+
+
Semantics:
+
Control transfers to the block specified in the address argument. All
+possible destination blocks must be listed in the label list, otherwise
+this instruction has undefined behavior. This implies that jumps to
+labels defined in other functions have undefined behavior as well.
+If ‘address’ is poison or undef, this instruction has undefined
+behavior.
+
+
+
Implementation:
+
This is typically implemented with a jump through a register.
+
+`,
tooltip: `The ‘indirectbr’ instruction implements an indirect branch to alabel within the current function, whose address is specified by“address”. Address must be derived from ablockaddress constant.`,
};
case 'INVOKE':
return {
url: `https://llvm.org/docs/LangRef.html#invoke-instruction`,
- html: `
The ‘invoke’ instruction causes control to transfer to a specifiedfunction, with the possibility of control flow transfer to either the‘normal’ label or the ‘exception’ label. If the callee functionreturns with the “ret” instruction, control flow will return to the“normal” label. If the callee (or any indirect callees) returns via the“resume” instruction or other exception handlingmechanism, control is interrupted and continued at the dynamicallynearest “exception” label.
The ‘exception’ label is a landingpad for the exception. As such,‘exception’ label is required to have the“landingpad” instruction, which contains theinformation about the behavior of the program after unwinding happens,as its first non-PHI instruction. The restrictions on the“landingpad” instruction’s tightly couples it to the “invoke”instruction, so that the important information contained within the“landingpad” instruction can’t be lost through normal code motion.
Arguments:
This instruction requires several arguments:
The optional “cconv” marker indicates which callingconvention the call should use. If none isspecified, the call defaults to using C calling conventions.
The optional Parameter Attributes list for returnvalues. Only ‘zeroext’, ‘signext’, ‘noext’, and ‘inreg’attributes are valid here.
The optional addrspace attribute can be used to indicate the address spaceof the called function. If it is not specified, the program address spacefrom the datalayout string will be used.
‘ty’: the type of the call instruction itself which is also thetype of the return value. Functions that return no value are markedvoid.
‘fnty’: shall be the signature of the function being invoked. Theargument types must match the types implied by this signature. Thistype can be omitted if the function is not varargs.
‘fnptrval’: An LLVM value containing a pointer to a function tobe invoked. In most cases, this is a direct function invocation, butindirect invoke’s are just as possible, calling an arbitrary pointerto function value.
‘functionargs’: argument list whose types match the functionsignature argument types and parameter attributes. All arguments mustbe of first class type. If the function signatureindicates the function accepts a variable number of arguments, theextra arguments can be specified.
‘normallabel’: the label reached when the called functionexecutes a ‘ret’ instruction.
‘exceptionlabel’: the label reached when a callee returns viathe resume instruction or other exception handlingmechanism.
This instruction is designed to operate as a standard ‘call’instruction in most regards. The primary difference is that itestablishes an association with a label, which is used by the runtimelibrary to unwind the stack.
This instruction is used in languages with destructors to ensure thatproper cleanup is performed in the case of either a longjmp or athrown exception. Additionally, this is important for implementation of‘catch’ clauses in high-level languages that support them.
For the purposes of the SSA form, the definition of the value returnedby the ‘invoke’ instruction is deemed to occur on the edge from thecurrent block to the “normal” label. If the callee unwinds then noreturn value is available.
Example:
%retval=invokei32@Test(i3215)tolabel%Continueunwindlabel%TestCleanup; i32:retval set%retval=invokecoldcci32%Testfnptr(i3215)tolabel%Continueunwindlabel%TestCleanup; i32:retval set
The ‘invoke’ instruction causes control to transfer to a specified
+function, with the possibility of control flow transfer to either the
+‘normal’ label or the ‘exception’ label. If the callee function
+returns with the “ret” instruction, control flow will return to the
+“normal” label. If the callee (or any indirect callees) returns via the
+“resume” instruction or other exception handling
+mechanism, control is interrupted and continued at the dynamically
+nearest “exception” label.
+
The ‘exception’ label is a landing
+pad for the exception. As such,
+‘exception’ label is required to have the
+“landingpad” instruction, which contains the
+information about the behavior of the program after unwinding happens,
+as its first non-PHI instruction. The restrictions on the
+“landingpad” instruction’s tightly couples it to the “invoke”
+instruction, so that the important information contained within the
+“landingpad” instruction can’t be lost through normal code motion.
+
+
+
Arguments:
+
This instruction requires several arguments:
+
+
The optional “cconv” marker indicates which calling
+convention the call should use. If none is
+specified, the call defaults to using C calling conventions.
+
The optional Parameter Attributes list for return
+values. Only ‘zeroext’, ‘signext’, ‘noext’, and ‘inreg’
+attributes are valid here.
+
The optional addrspace attribute can be used to indicate the address space
+of the called function. If it is not specified, the program address space
+from the datalayout string will be used.
+
‘ty’: the type of the call instruction itself which is also the
+type of the return value. Functions that return no value are marked
+void. The signature is computed based on the return type and argument
+types.
+
‘fnty’: shall be the signature of the function being invoked. The
+argument types must match the types implied by this signature. This
+is only required if the signature specifies a varargs type.
+
‘fnptrval’: An LLVM value containing a pointer to a function to
+be invoked. In most cases, this is a direct function invocation, but
+indirect invoke’s are just as possible, calling an arbitrary pointer
+to function value.
+
‘functionargs’: argument list whose types match the function
+signature argument types and parameter attributes. All arguments must
+be of first class type. If the function signature
+indicates the function accepts a variable number of arguments, the
+extra arguments can be specified.
+
‘normallabel’: the label reached when the called function
+executes a ‘ret’ instruction.
+
‘exceptionlabel’: the label reached when a callee returns via
+the resume instruction or other exception handling
+mechanism.
This instruction is designed to operate as a standard ‘call’
+instruction in most regards. The primary difference is that it
+establishes an association with a label, which is used by the runtime
+library to unwind the stack.
+
This instruction is used in languages with destructors to ensure that
+proper cleanup is performed in the case of either a longjmp or a
+thrown exception. Additionally, this is important for implementation of
+‘catch’ clauses in high-level languages that support them.
+
For the purposes of the SSA form, the definition of the value returned
+by the ‘invoke’ instruction is deemed to occur on the edge from the
+current block to the “normal” label. If the callee unwinds then no
+return value is available.
+
+
+
Example:
+
%retval=invokei32@Test(i3215)tolabel%Continue
+unwindlabel%TestCleanup; i32:retval set
+%retval=invokecoldcci32%Testfnptr(i3215)tolabel%Continue
+unwindlabel%TestCleanup; i32:retval set
+
+
+
+`,
tooltip: `The ‘invoke’ instruction causes control to transfer to a specifiedfunction, with the possibility of control flow transfer to either the‘normal’ label or the ‘exception’ label. If the callee functionreturns with the “ret” instruction, control flow will return to the“normal” label. If the callee (or any indirect callees) returns via the“resume” instruction or other exception handlingmechanism, control is interrupted and continued at the dynamicallynearest “exception” label.The ‘exception’ label is a landingpad for the exception. As such,‘exception’ label is required to have the“landingpad” instruction, which contains theinformation about the behavior of the program after unwinding happens,as its first non-PHI instruction. The restrictions on the“landingpad” instruction’s tightly couples it to the “invoke”instruction, so that the important information contained within the“landingpad” instruction can’t be lost through normal code motion.`,
};
case 'CALLBR':
return {
url: `https://llvm.org/docs/LangRef.html#callbr-instruction`,
- html: `
The ‘callbr’ instruction causes control to transfer to a specifiedfunction, with the possibility of control flow transfer to either the‘fallthrough’ label or one of the ‘indirect’ labels.
This instruction should only be used to implement the “goto” feature of gccstyle inline assembly. Any other usage is an error in the IR verifier.
Note that in order to support outputs along indirect edges, LLVM may need tosplit critical edges, which may require synthesizing a replacement block forthe indirectlabels. Therefore, the address of a label as seen by anothercallbr instruction, or for a blockaddress constant,may not be equal to the address provided for the same block to thisinstruction’s indirectlabels operand. The assembly code may only transfercontrol to addresses provided via this instruction’s indirectlabels.
Arguments:
This instruction requires several arguments:
The optional “cconv” marker indicates which callingconvention the call should use. If none isspecified, the call defaults to using C calling conventions.
The optional Parameter Attributes list for returnvalues. Only ‘zeroext’, ‘signext’, ‘noext’, and ‘inreg’attributes are valid here.
The optional addrspace attribute can be used to indicate the address spaceof the called function. If it is not specified, the program address spacefrom the datalayout string will be used.
‘ty’: the type of the call instruction itself which is also thetype of the return value. Functions that return no value are markedvoid.
‘fnty’: shall be the signature of the function being called. Theargument types must match the types implied by this signature. Thistype can be omitted if the function is not varargs.
‘fnptrval’: An LLVM value containing a pointer to a function tobe called. In most cases, this is a direct function call, butother callbr’s are just as possible, calling an arbitrary pointerto function value.
‘functionargs’: argument list whose types match the functionsignature argument types and parameter attributes. All arguments mustbe of first class type. If the function signatureindicates the function accepts a variable number of arguments, theextra arguments can be specified.
‘fallthroughlabel’: the label reached when the inline assembly’sexecution exits the bottom.
‘indirectlabels’: the labels reached when a callee transfers controlto a location other than the ‘fallthroughlabel’. Label constraintsrefer to these destinations.
This instruction is designed to operate as a standard ‘call’instruction in most regards. The primary difference is that itestablishes an association with additional labels to define where controlflow goes after the call.
The output values of a ‘callbr’ instruction are available both in thethe ‘fallthrough’ block, and any ‘indirect’ blocks(s).
The only use of this today is to implement the “goto” feature of gcc inlineassembly where additional labels can be provided as locations for the inlineassembly to jump to.
Example:
; "asm goto" without output constraints.callbr void asm "", "r,!i"(i32 %x) to label %fallthrough [label %indirect]; "asm goto" with output constraints.<result> = callbr i32 asm "", "=r,r,!i"(i32 %x) to label %fallthrough [label %indirect]
`,
- tooltip: `The ‘callbr’ instruction causes control to transfer to a specifiedfunction, with the possibility of control flow transfer to either the‘fallthrough’ label or one of the ‘indirect’ labels.This instruction should only be used to implement the “goto” feature of gccstyle inline assembly. Any other usage is an error in the IR verifier.Note that in order to support outputs along indirect edges, LLVM may need tosplit critical edges, which may require synthesizing a replacement block forthe indirect labels. Therefore, the address of a label as seen by anothercallbr instruction, or for a blockaddress constant,may not be equal to the address provided for the same block to thisinstruction’s indirect labels operand. The assembly code may only transfercontrol to addresses provided via this instruction’s indirect labels.`,
+ html: `
The ‘callbr’ instruction causes control to transfer to a specified
+function, with the possibility of control flow transfer to either the
+‘fallthrough’ label or one of the ‘indirect’ labels.
+
This instruction should only be used to implement the “goto” feature of gcc
+style inline assembly. Any other usage is an error in the IR verifier.
+
Note that in order to support outputs along indirect edges, LLVM may need to
+split critical edges, which may require synthesizing a replacement block for
+the indirectlabels. Therefore, the address of a label as seen by another
+callbr instruction, or for a blockaddress constant,
+may not be equal to the address provided for the same block to this
+instruction’s indirectlabels operand. The assembly code may only transfer
+control to addresses provided via this instruction’s indirectlabels.
+
On target architectures that implement branch target enforcement by requiring
+indirect (register-controlled) branch instructions to jump only to locations
+marked by a special instruction (such as AArch64 bti), the called code is
+expected not to use such an indirect branch to transfer control to the
+locations in indirectlabels. Therefore, including a label in the
+indirectlabels of a callbr does not require the compiler to put a
+bti or equivalent instruction at the label.
+
+
+
Arguments:
+
This instruction requires several arguments:
+
+
The optional “cconv” marker indicates which calling
+convention the call should use. If none is
+specified, the call defaults to using C calling conventions.
+
The optional Parameter Attributes list for return
+values. Only ‘zeroext’, ‘signext’, ‘noext’, and ‘inreg’
+attributes are valid here.
+
The optional addrspace attribute can be used to indicate the address space
+of the called function. If it is not specified, the program address space
+from the datalayout string will be used.
+
‘ty’: the type of the call instruction itself which is also the
+type of the return value. Functions that return no value are marked
+void. The signature is computed based on the return type and argument
+types.
+
‘fnty’: shall be the signature of the function being called. The
+argument types must match the types implied by this signature. This
+is only required if the signature specifies a varargs type.
+
‘fnptrval’: An LLVM value containing a pointer to a function to
+be called. In most cases, this is a direct function call, but
+other callbr’s are just as possible, calling an arbitrary pointer
+to function value.
+
‘functionargs’: argument list whose types match the function
+signature argument types and parameter attributes. All arguments must
+be of first class type. If the function signature
+indicates the function accepts a variable number of arguments, the
+extra arguments can be specified.
+
‘fallthroughlabel’: the label reached when the inline assembly’s
+execution exits the bottom.
+
‘indirectlabels’: the labels reached when a callee transfers control
+to a location other than the ‘fallthroughlabel’. Label constraints
+refer to these destinations.
This instruction is designed to operate as a standard ‘call’
+instruction in most regards. The primary difference is that it
+establishes an association with additional labels to define where control
+flow goes after the call.
+
The output values of a ‘callbr’ instruction are available both in the
+the ‘fallthrough’ block, and any ‘indirect’ blocks(s).
+
The only use of this today is to implement the “goto” feature of gcc inline
+assembly where additional labels can be provided as locations for the inline
+assembly to jump to.
+
+
+
Example:
+
; "asm goto" without output constraints.
+callbrvoidasm"","r,!i"(i32%x)
+tolabel%fallthrough[label%indirect]
+
+; "asm goto" with output constraints.
+<result>=callbri32asm"","=r,r,!i"(i32%x)
+tolabel%fallthrough[label%indirect]
+
+
+
+`,
+ tooltip: `The ‘callbr’ instruction causes control to transfer to a specifiedfunction, with the possibility of control flow transfer to either the‘fallthrough’ label or one of the ‘indirect’ labels.This instruction should only be used to implement the “goto” feature of gccstyle inline assembly. Any other usage is an error in the IR verifier.Note that in order to support outputs along indirect edges, LLVM may need tosplit critical edges, which may require synthesizing a replacement block forthe indirect labels. Therefore, the address of a label as seen by anothercallbr instruction, or for a blockaddress constant,may not be equal to the address provided for the same block to thisinstruction’s indirect labels operand. The assembly code may only transfercontrol to addresses provided via this instruction’s indirect labels.On target architectures that implement branch target enforcement by requiringindirect (register-controlled) branch instructions to jump only to locationsmarked by a special instruction (such as AArch64 bti), the called code isexpected not to use such an indirect branch to transfer control to thelocations in indirect labels. Therefore, including a label in theindirect labels of a callbr does not require the compiler to put abti or equivalent instruction at the label.`,
};
case 'RESUME':
return {
url: `https://llvm.org/docs/LangRef.html#resume-instruction`,
- html: `
The ‘resume’ instruction is a terminator instruction that has no
+successors.
+
+
+
Arguments:
+
The ‘resume’ instruction requires one argument, which must have the
+same type as the result of any ‘landingpad’ instruction in the same
+function.
+
+
+
Semantics:
+
The ‘resume’ instruction resumes propagation of an existing
+(in-flight) exception whose unwinding was interrupted with a
+landingpad instruction.
+
+
+
Example:
+
resume{ptr,i32}%exn
+
+
+
+`,
tooltip: `The ‘resume’ instruction is a terminator instruction that has nosuccessors.`,
};
case 'CATCHSWITCH':
return {
url: `https://llvm.org/docs/LangRef.html#catchswitch-instruction`,
- html: `
The parent argument is the token of the funclet that contains thecatchswitch instruction. If the catchswitch is not inside a funclet,this operand may be the token none.
The default argument is the label of another basic block beginning witheither a cleanuppad or catchswitch instruction. This unwind destinationmust be a legal target with respect to the parent links, as described inthe exception handling documentation.
The handlers are a nonempty list of successor blocks that each begin with acatchpad instruction.
Semantics:
Executing this instruction transfers control to one of the successors inhandlers, if appropriate, or continues to unwind via the unwind label ifpresent.
The catchswitch is both a terminator and a “pad” instruction, meaning thatit must be both the first non-phi instruction and last instruction in the basicblock. Therefore, it must be the only non-phi instruction in the block.
Example:
dispatch1: %cs1 = catchswitch within none [label %handler0, label %handler1] unwind to callerdispatch2: %cs2 = catchswitch within %parenthandler [label %handler0] unwind label %cleanup
The parent argument is the token of the funclet that contains the
+catchswitch instruction. If the catchswitch is not inside a funclet,
+this operand may be the token none.
+
The default argument is the label of another basic block beginning with
+either a cleanuppad or catchswitch instruction. This unwind destination
+must be a legal target with respect to the parent links, as described in
+the exception handling documentation.
+
The handlers are a nonempty list of successor blocks that each begin with a
+catchpad instruction.
+
+
+
Semantics:
+
Executing this instruction transfers control to one of the successors in
+handlers, if appropriate, or continues to unwind via the unwind label if
+present.
+
The catchswitch is both a terminator and a “pad” instruction, meaning that
+it must be both the first non-phi instruction and last instruction in the basic
+block. Therefore, it must be the only non-phi instruction in the block.
+
+
+
Example:
+
dispatch1:
+ %cs1 = catchswitch within none [label %handler0, label %handler1] unwind to caller
+dispatch2:
+ %cs2 = catchswitch within %parenthandler [label %handler0] unwind label %cleanup
+
+
+
+`,
tooltip: `The ‘catchswitch’ instruction is used by LLVM’s exception handling system to describe the set of possible catch handlersthat may be executed by the EH personality routine.`,
};
case 'CATCHRET':
return {
url: `https://llvm.org/docs/LangRef.html#catchret-instruction`,
- html: `
The ‘catchret’ instruction is a terminator instruction that has asingle successor.
Arguments:
The first argument to a ‘catchret’ indicates which catchpad itexits. It must be a catchpad.The second argument to a ‘catchret’ specifies where control willtransfer to next.
Semantics:
The ‘catchret’ instruction ends an existing (in-flight) exception whoseunwinding was interrupted with a catchpad instruction. Thepersonality function gets a chance to execute arbitrarycode to, for example, destroy the active exception. Control then transfers tonormal.
The token argument must be a token produced by a catchpad instruction.If the specified catchpad is not the most-recently-entered not-yet-exitedfunclet pad (as described in the EH documentation),the catchret’s behavior is undefined.
The ‘catchret’ instruction is a terminator instruction that has a
+single successor.
+
+
+
Arguments:
+
The first argument to a ‘catchret’ indicates which catchpad it
+exits. It must be a catchpad.
+The second argument to a ‘catchret’ specifies where control will
+transfer to next.
+
+
+
Semantics:
+
The ‘catchret’ instruction ends an existing (in-flight) exception whose
+unwinding was interrupted with a catchpad instruction. The
+personality function gets a chance to execute arbitrary
+code to, for example, destroy the active exception. Control then transfers to
+normal.
+
The token argument must be a token produced by a catchpad instruction.
+If the specified catchpad is not the most-recently-entered not-yet-exited
+funclet pad (as described in the EH documentation),
+the catchret’s behavior is undefined.
+
+
+
Example:
+
catchret from %catch to label %continue
+
+
+
+`,
tooltip: `The ‘catchret’ instruction is a terminator instruction that has asingle successor.`,
};
case 'CLEANUPRET':
return {
url: `https://llvm.org/docs/LangRef.html#cleanupret-instruction`,
- html: `
The ‘cleanupret’ instruction is a terminator instruction that hasan optional successor.
Arguments:
The ‘cleanupret’ instruction requires one argument, which indicateswhich cleanuppad it exits, and must be a cleanuppad.If the specified cleanuppad is not the most-recently-entered not-yet-exitedfunclet pad (as described in the EH documentation),the cleanupret’s behavior is undefined.
The ‘cleanupret’ instruction also has an optional successor, continue,which must be the label of another basic block beginning with either acleanuppad or catchswitch instruction. This unwind destination mustbe a legal target with respect to the parent links, as described in theexception handling documentation.
Semantics:
The ‘cleanupret’ instruction indicates to thepersonality function that onecleanuppad it transferred control to has ended.It transfers control to continue or unwinds out of the function.
Example:
cleanupret from %cleanup unwind to callercleanupret from %cleanup unwind label %continue
The ‘cleanupret’ instruction is a terminator instruction that has
+an optional successor.
+
+
+
Arguments:
+
The ‘cleanupret’ instruction requires one argument, which indicates
+which cleanuppad it exits, and must be a cleanuppad.
+If the specified cleanuppad is not the most-recently-entered not-yet-exited
+funclet pad (as described in the EH documentation),
+the cleanupret’s behavior is undefined.
+
The ‘cleanupret’ instruction also has an optional successor, continue,
+which must be the label of another basic block beginning with either a
+cleanuppad or catchswitch instruction. This unwind destination must
+be a legal target with respect to the parent links, as described in the
+exception handling documentation.
+
+
+
Semantics:
+
The ‘cleanupret’ instruction indicates to the
+personality function that one
+cleanuppad it transferred control to has ended.
+It transfers control to continue or unwinds out of the function.
+
+
+
Example:
+
cleanupret from %cleanup unwind to caller
+cleanupret from %cleanup unwind label %continue
+
+
+
+`,
tooltip: `The ‘cleanupret’ instruction is a terminator instruction that hasan optional successor.`,
};
case 'UNREACHABLE':
return {
url: `https://llvm.org/docs/LangRef.html#unreachable-instruction`,
- html: `
The ‘unreachable’ instruction has no defined semantics. Thisinstruction is used to inform the optimizer that a particular portion ofthe code is not reachable. This can be used to indicate that the codeafter a no-return function cannot be reached, and other facts.
Semantics:
The ‘unreachable’ instruction has no defined semantics.
The ‘unreachable’ instruction has no defined semantics. This
+instruction is used to inform the optimizer that a particular portion of
+the code is not reachable. This can be used to indicate that the code
+after a no-return function cannot be reached, and other facts.
+
+
+
Semantics:
+
The ‘unreachable’ instruction has no defined semantics.
+
+`,
tooltip: `The ‘unreachable’ instruction has no defined semantics. Thisinstruction is used to inform the optimizer that a particular portion ofthe code is not reachable. This can be used to indicate that the codeafter a no-return function cannot be reached, and other facts.`,
};
case 'FNEG':
return {
url: `https://llvm.org/docs/LangRef.html#fneg-instruction`,
- html: `
The ‘fneg’ instruction returns the negation of its operand.
Arguments:
The argument to the ‘fneg’ instruction must be afloating-point or vector offloating-point values.
Semantics:
The value produced is a copy of the operand with its sign bit flipped.The value is otherwise completely identical; in particular, if the input is aNaN, then the quiet/signaling bit and payload are perfectly preserved.
This instruction can also take any number of fast-mathflags, which are optimization hints to enable otherwiseunsafe floating-point optimizations:
The ‘fneg’ instruction returns the negation of its operand.
+
+
+
Arguments:
+
The argument to the ‘fneg’ instruction must be a
+floating-point or vector of
+floating-point values.
+
+
+
Semantics:
+
The value produced is a copy of the operand with its sign bit flipped.
+The value is otherwise completely identical; in particular, if the input is a
+NaN, then the quiet/signaling bit and payload are perfectly preserved.
+
This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations:
The ‘add’ instruction returns the sum of its two operands.
Arguments:
The two arguments to the ‘add’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
The value produced is the integer sum of the two operands.
If the sum has unsigned overflow, the result returned is themathematical result modulo 2n, where n is the bit width ofthe result.
Because LLVM integers use a two’s complement representation, thisinstruction is appropriate for both signed and unsigned integers.
nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”,respectively. If the nuw and/or nsw keywords are present, theresult value of the add is a poison value ifunsigned and/or signed overflow, respectively, occurs.
The ‘add’ instruction returns the sum of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘add’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the integer sum of the two operands.
+
If the sum has unsigned overflow, the result returned is the
+mathematical result modulo 2n, where n is the bit width of
+the result.
+
Because LLVM integers use a two’s complement representation, this
+instruction is appropriate for both signed and unsigned integers.
+
nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”,
+respectively. If the nuw and/or nsw keywords are present, the
+result value of the add is a poison value if
+unsigned and/or signed overflow, respectively, occurs.
+
+`,
tooltip: `The ‘add’ instruction returns the sum of its two operands.`,
};
case 'FADD':
return {
url: `https://llvm.org/docs/LangRef.html#fadd-instruction`,
- html: `
The ‘fadd’ instruction returns the sum of its two operands.
Arguments:
The two arguments to the ‘fadd’ instruction must befloating-point or vector offloating-point values. Both arguments must have identical types.
Semantics:
The value produced is the floating-point sum of the two operands.This instruction is assumed to execute in the default floating-pointenvironment.This instruction can also take any number of fast-mathflags, which are optimization hints to enable otherwiseunsafe floating-point optimizations:
The ‘fadd’ instruction returns the sum of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘fadd’ instruction must be
+floating-point or vector of
+floating-point values. Both arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the floating-point sum of the two operands.
+This instruction is assumed to execute in the default floating-point
+environment.
+This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations:
+
+`,
tooltip: `The ‘fadd’ instruction returns the sum of its two operands.`,
};
case 'SUB':
return {
url: `https://llvm.org/docs/LangRef.html#sub-instruction`,
- html: `
The ‘sub’ instruction returns the difference of its two operands.
Note that the ‘sub’ instruction is used to represent the ‘neg’instruction present in most other intermediate representations.
Arguments:
The two arguments to the ‘sub’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
The value produced is the integer difference of the two operands.
If the difference has unsigned overflow, the result returned is themathematical result modulo 2n, where n is the bit width ofthe result.
Because LLVM integers use a two’s complement representation, thisinstruction is appropriate for both signed and unsigned integers.
nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”,respectively. If the nuw and/or nsw keywords are present, theresult value of the sub is a poison value ifunsigned and/or signed overflow, respectively, occurs.
The ‘sub’ instruction returns the difference of its two operands.
+
Note that the ‘sub’ instruction is used to represent the ‘neg’
+instruction present in most other intermediate representations.
+
+
+
Arguments:
+
The two arguments to the ‘sub’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the integer difference of the two operands.
+
If the difference has unsigned overflow, the result returned is the
+mathematical result modulo 2n, where n is the bit width of
+the result.
+
Because LLVM integers use a two’s complement representation, this
+instruction is appropriate for both signed and unsigned integers.
+
nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”,
+respectively. If the nuw and/or nsw keywords are present, the
+result value of the sub is a poison value if
+unsigned and/or signed overflow, respectively, occurs.
+
+`,
tooltip: `The ‘sub’ instruction returns the difference of its two operands.Note that the ‘sub’ instruction is used to represent the ‘neg’instruction present in most other intermediate representations.`,
};
case 'FSUB':
return {
url: `https://llvm.org/docs/LangRef.html#fsub-instruction`,
- html: `
The ‘fsub’ instruction returns the difference of its two operands.
Arguments:
The two arguments to the ‘fsub’ instruction must befloating-point or vector offloating-point values. Both arguments must have identical types.
Semantics:
The value produced is the floating-point difference of the two operands.This instruction is assumed to execute in the default floating-pointenvironment.This instruction can also take any number of fast-mathflags, which are optimization hints to enable otherwiseunsafe floating-point optimizations:
The ‘fsub’ instruction returns the difference of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘fsub’ instruction must be
+floating-point or vector of
+floating-point values. Both arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the floating-point difference of the two operands.
+This instruction is assumed to execute in the default floating-point
+environment.
+This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations:
+
+`,
tooltip: `The ‘fsub’ instruction returns the difference of its two operands.`,
};
case 'MUL':
return {
url: `https://llvm.org/docs/LangRef.html#mul-instruction`,
- html: `
The ‘mul’ instruction returns the product of its two operands.
Arguments:
The two arguments to the ‘mul’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
The value produced is the integer product of the two operands.
If the result of the multiplication has unsigned overflow, the resultreturned is the mathematical result modulo 2n, where n is thebit width of the result.
Because LLVM integers use a two’s complement representation, and theresult is the same width as the operands, this instruction returns thecorrect result for both signed and unsigned integers. If a full product(e.g. i32 * i32 -> i64) is needed, the operands should besign-extended or zero-extended as appropriate to the width of the fullproduct.
nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”,respectively. If the nuw and/or nsw keywords are present, theresult value of the mul is a poison value ifunsigned and/or signed overflow, respectively, occurs.
The ‘mul’ instruction returns the product of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘mul’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the integer product of the two operands.
+
If the result of the multiplication has unsigned overflow, the result
+returned is the mathematical result modulo 2n, where n is the
+bit width of the result.
+
Because LLVM integers use a two’s complement representation, and the
+result is the same width as the operands, this instruction returns the
+correct result for both signed and unsigned integers. If a full product
+(e.g., i32 * i32 -> i64) is needed, the operands should be
+sign-extended or zero-extended as appropriate to the width of the full
+product.
+
nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”,
+respectively. If the nuw and/or nsw keywords are present, the
+result value of the mul is a poison value if
+unsigned and/or signed overflow, respectively, occurs.
+
+`,
tooltip: `The ‘mul’ instruction returns the product of its two operands.`,
};
case 'FMUL':
return {
url: `https://llvm.org/docs/LangRef.html#fmul-instruction`,
- html: `
The ‘fmul’ instruction returns the product of its two operands.
Arguments:
The two arguments to the ‘fmul’ instruction must befloating-point or vector offloating-point values. Both arguments must have identical types.
Semantics:
The value produced is the floating-point product of the two operands.This instruction is assumed to execute in the default floating-pointenvironment.This instruction can also take any number of fast-mathflags, which are optimization hints to enable otherwiseunsafe floating-point optimizations:
The ‘fmul’ instruction returns the product of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘fmul’ instruction must be
+floating-point or vector of
+floating-point values. Both arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the floating-point product of the two operands.
+This instruction is assumed to execute in the default floating-point
+environment.
+This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations:
+
+`,
tooltip: `The ‘fmul’ instruction returns the product of its two operands.`,
};
case 'UDIV':
return {
url: `https://llvm.org/docs/LangRef.html#udiv-instruction`,
- html: `
The ‘udiv’ instruction returns the quotient of its two operands.
Arguments:
The two arguments to the ‘udiv’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
The value produced is the unsigned integer quotient of the two operands.
Note that unsigned integer division and signed integer division aredistinct operations; for signed integer division, use ‘sdiv’.
Division by zero is undefined behavior. For vectors, if any elementof the divisor is zero, the operation has undefined behavior.
If the exact keyword is present, the result value of the udiv isa poison value if %op1 is not a multiple of %op2 (assuch, “((a udiv exact b) mul b) == a”).
The ‘udiv’ instruction returns the quotient of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘udiv’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the unsigned integer quotient of the two operands.
+
Note that unsigned integer division and signed integer division are
+distinct operations; for signed integer division, use ‘sdiv’.
+
Division by zero is undefined behavior. For vectors, if any element
+of the divisor is zero, the operation has undefined behavior.
+
If the exact keyword is present, the result value of the udiv is
+a poison value if %op1 is not a multiple of %op2 (as
+such, “((a udiv exact b) mul b) == a”).
+
+`,
tooltip: `The ‘udiv’ instruction returns the quotient of its two operands.`,
};
case 'SDIV':
return {
url: `https://llvm.org/docs/LangRef.html#sdiv-instruction`,
- html: `
The ‘sdiv’ instruction returns the quotient of its two operands.
Arguments:
The two arguments to the ‘sdiv’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
The value produced is the signed integer quotient of the two operandsrounded towards zero.
Note that signed integer division and unsigned integer division aredistinct operations; for unsigned integer division, use ‘udiv’.
Division by zero is undefined behavior. For vectors, if any elementof the divisor is zero, the operation has undefined behavior.Overflow also leads to undefined behavior; this is a rare case, but canoccur, for example, by doing a 32-bit division of -2147483648 by -1.
If the exact keyword is present, the result value of the sdiv isa poison value if the result would be rounded.
The ‘sdiv’ instruction returns the quotient of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘sdiv’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the signed integer quotient of the two operands
+rounded towards zero.
+
Note that signed integer division and unsigned integer division are
+distinct operations; for unsigned integer division, use ‘udiv’.
+
Division by zero is undefined behavior. For vectors, if any element
+of the divisor is zero, the operation has undefined behavior.
+Overflow also leads to undefined behavior; this is a rare case, but can
+occur, for example, by doing a 32-bit division of -2147483648 by -1.
+
If the exact keyword is present, the result value of the sdiv is
+a poison value if the result would be rounded.
+
+`,
tooltip: `The ‘sdiv’ instruction returns the quotient of its two operands.`,
};
case 'FDIV':
return {
url: `https://llvm.org/docs/LangRef.html#fdiv-instruction`,
- html: `
The ‘fdiv’ instruction returns the quotient of its two operands.
Arguments:
The two arguments to the ‘fdiv’ instruction must befloating-point or vector offloating-point values. Both arguments must have identical types.
Semantics:
The value produced is the floating-point quotient of the two operands.This instruction is assumed to execute in the default floating-pointenvironment.This instruction can also take any number of fast-mathflags, which are optimization hints to enable otherwiseunsafe floating-point optimizations:
The ‘fdiv’ instruction returns the quotient of its two operands.
+
+
+
Arguments:
+
The two arguments to the ‘fdiv’ instruction must be
+floating-point or vector of
+floating-point values. Both arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the floating-point quotient of the two operands.
+This instruction is assumed to execute in the default floating-point
+environment.
+This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations:
+
+`,
tooltip: `The ‘fdiv’ instruction returns the quotient of its two operands.`,
};
case 'UREM':
return {
url: `https://llvm.org/docs/LangRef.html#urem-instruction`,
- html: `
The ‘urem’ instruction returns the remainder from the unsigneddivision of its two arguments.
Arguments:
The two arguments to the ‘urem’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
This instruction returns the unsigned integer remainder of a division.This instruction always performs an unsigned division to get theremainder.
Note that unsigned integer remainder and signed integer remainder aredistinct operations; for signed integer remainder, use ‘srem’.
Taking the remainder of a division by zero is undefined behavior.For vectors, if any element of the divisor is zero, the operation hasundefined behavior.
The ‘urem’ instruction returns the remainder from the unsigned
+division of its two arguments.
+
+
+
Arguments:
+
The two arguments to the ‘urem’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
This instruction returns the unsigned integer remainder of a division.
+This instruction always performs an unsigned division to get the
+remainder.
+
Note that unsigned integer remainder and signed integer remainder are
+distinct operations; for signed integer remainder, use ‘srem’.
+
Taking the remainder of a division by zero is undefined behavior.
+For vectors, if any element of the divisor is zero, the operation has
+undefined behavior.
+
+`,
tooltip: `The ‘urem’ instruction returns the remainder from the unsigneddivision of its two arguments.`,
};
case 'SREM':
return {
url: `https://llvm.org/docs/LangRef.html#srem-instruction`,
- html: `
The ‘srem’ instruction returns the remainder from the signeddivision of its two operands. This instruction can also takevector versions of the values in which case the elementsmust be integers.
Arguments:
The two arguments to the ‘srem’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
This instruction returns the remainder of a division (where the resultis either zero or has the same sign as the dividend, op1), not themodulo operator (where the result is either zero or has the same signas the divisor, op2) of a value. For more information about thedifference, see The MathForum. For atable of how this is implemented in various languages, please seeWikipedia: modulooperation.
Note that signed integer remainder and unsigned integer remainder aredistinct operations; for unsigned integer remainder, use ‘urem’.
Taking the remainder of a division by zero is undefined behavior.For vectors, if any element of the divisor is zero, the operation hasundefined behavior.Overflow also leads to undefined behavior; this is a rare case, but canoccur, for example, by taking the remainder of a 32-bit division of-2147483648 by -1. (The remainder doesn’t actually overflow, but thisrule lets srem be implemented using instructions that return both theresult of the division and the remainder.)
The ‘srem’ instruction returns the remainder from the signed
+division of its two operands. This instruction can also take
+vector versions of the values in which case the elements
+must be integers.
+
+
+
Arguments:
+
The two arguments to the ‘srem’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
This instruction returns the remainder of a division (where the result
+is either zero or has the same sign as the dividend, op1), not the
+modulo operator (where the result is either zero or has the same sign
+as the divisor, op2) of a value. For more information about the
+difference, see The Math
+Forum. For a
+table of how this is implemented in various languages, please see
+Wikipedia: modulo
+operation.
+
Note that signed integer remainder and unsigned integer remainder are
+distinct operations; for unsigned integer remainder, use ‘urem’.
+
Taking the remainder of a division by zero is undefined behavior.
+For vectors, if any element of the divisor is zero, the operation has
+undefined behavior.
+Overflow also leads to undefined behavior; this is a rare case, but can
+occur, for example, by taking the remainder of a 32-bit division of
+-2147483648 by -1. (The remainder doesn’t actually overflow, but this
+rule lets srem be implemented using instructions that return both the
+result of the division and the remainder.)
+
+`,
tooltip: `The ‘srem’ instruction returns the remainder from the signeddivision of its two operands. This instruction can also takevector versions of the values in which case the elementsmust be integers.`,
};
case 'FREM':
return {
url: `https://llvm.org/docs/LangRef.html#frem-instruction`,
- html: `
The ‘frem’ instruction returns the remainder from the division ofits two operands.
Note
The instruction is implemented as a call to libm’s ‘fmod’for some targets, and using the instruction may thus require linking libm.
Arguments:
The two arguments to the ‘frem’ instruction must befloating-point or vector offloating-point values. Both arguments must have identical types.
Semantics:
The value produced is the floating-point remainder of the two operands.This is the same output as a libm ‘fmod’ function, but without anypossibility of setting errno. The remainder has the same sign as thedividend.This instruction is assumed to execute in the default floating-pointenvironment.This instruction can also take any number of fast-mathflags, which are optimization hints to enable otherwiseunsafe floating-point optimizations:
The ‘frem’ instruction returns the remainder from the division of
+its two operands.
+
+
Note
+
The instruction is implemented as a call to libm’s ‘fmod’
+for some targets, and using the instruction may thus require linking libm.
+
+
+
+
Arguments:
+
The two arguments to the ‘frem’ instruction must be
+floating-point or vector of
+floating-point values. Both arguments must have identical types.
+
+
+
Semantics:
+
The value produced is the floating-point remainder of the two operands.
+This is the same output as a libm ‘fmod’ function, but without any
+possibility of setting errno. The remainder has the same sign as the
+dividend.
+This instruction is assumed to execute in the default floating-point
+environment.
+This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations:
+
+`,
tooltip: `The ‘frem’ instruction returns the remainder from the division ofits two operands.`,
};
case 'SHL':
return {
url: `https://llvm.org/docs/LangRef.html#shl-instruction`,
- html: `
The ‘shl’ instruction returns the first operand shifted to the lefta specified number of bits.
Arguments:
Both arguments to the ‘shl’ instruction must be the sameinteger or vector of integer type.‘op2’ is treated as an unsigned value.
Semantics:
The value produced is op1 * 2op2 mod 2n,where n is the width of the result. If op2 is (statically ordynamically) equal to or larger than the number of bits inop1, this instruction returns a poison value.If the arguments are vectors, each vector element of op1 is shiftedby the corresponding shift amount in op2.
If the nuw keyword is present, then the shift produces a poisonvalue if it shifts out any non-zero bits.If the nsw keyword is present, then the shift produces a poisonvalue if it shifts out any bits that disagree with the resultant sign bit.
The ‘shl’ instruction returns the first operand shifted to the left
+a specified number of bits.
+
+
+
Arguments:
+
Both arguments to the ‘shl’ instruction must be the same
+integer or vector of integer type.
+‘op2’ is treated as an unsigned value.
+
+
+
Semantics:
+
The value produced is op1 * 2op2 mod 2n,
+where n is the width of the result. If op2 is (statically or
+dynamically) equal to or larger than the number of bits in
+op1, this instruction returns a poison value.
+If the arguments are vectors, each vector element of op1 is shifted
+by the corresponding shift amount in op2.
+
If the nuw keyword is present, then the shift produces a poison
+value if it shifts out any non-zero bits.
+If the nsw keyword is present, then the shift produces a poison
+value if it shifts out any bits that disagree with the resultant sign bit.
+
+`,
tooltip: `The ‘shl’ instruction returns the first operand shifted to the lefta specified number of bits.`,
};
case 'LSHR':
return {
url: `https://llvm.org/docs/LangRef.html#lshr-instruction`,
- html: `
The ‘lshr’ instruction (logical shift right) returns the firstoperand shifted to the right a specified number of bits with zero fill.
Arguments:
Both arguments to the ‘lshr’ instruction must be the sameinteger or vector of integer type.‘op2’ is treated as an unsigned value.
Semantics:
This instruction always performs a logical shift right operation. Themost significant bits of the result will be filled with zero bits afterthe shift. If op2 is (statically or dynamically) equal to or largerthan the number of bits in op1, this instruction returns a poisonvalue. If the arguments are vectors, each vector elementof op1 is shifted by the corresponding shift amount in op2.
If the exact keyword is present, the result value of the lshr isa poison value if any of the bits shifted out are non-zero.
The ‘lshr’ instruction (logical shift right) returns the first
+operand shifted to the right a specified number of bits with zero fill.
+
+
+
Arguments:
+
Both arguments to the ‘lshr’ instruction must be the same
+integer or vector of integer type.
+‘op2’ is treated as an unsigned value.
+
+
+
Semantics:
+
This instruction always performs a logical shift right operation. The
+most significant bits of the result will be filled with zero bits after
+the shift. If op2 is (statically or dynamically) equal to or larger
+than the number of bits in op1, this instruction returns a poison
+value. If the arguments are vectors, each vector element
+of op1 is shifted by the corresponding shift amount in op2.
+
If the exact keyword is present, the result value of the lshr is
+a poison value if any of the bits shifted out are non-zero.
+
+`,
tooltip: `The ‘lshr’ instruction (logical shift right) returns the firstoperand shifted to the right a specified number of bits with zero fill.`,
};
case 'ASHR':
return {
url: `https://llvm.org/docs/LangRef.html#ashr-instruction`,
- html: `
The ‘ashr’ instruction (arithmetic shift right) returns the firstoperand shifted to the right a specified number of bits with signextension.
Arguments:
Both arguments to the ‘ashr’ instruction must be the sameinteger or vector of integer type.‘op2’ is treated as an unsigned value.
Semantics:
This instruction always performs an arithmetic shift right operation,The most significant bits of the result will be filled with the sign bitof op1. If op2 is (statically or dynamically) equal to or largerthan the number of bits in op1, this instruction returns a poisonvalue. If the arguments are vectors, each vector elementof op1 is shifted by the corresponding shift amount in op2.
If the exact keyword is present, the result value of the ashr isa poison value if any of the bits shifted out are non-zero.
The ‘ashr’ instruction (arithmetic shift right) returns the first
+operand shifted to the right a specified number of bits with sign
+extension.
+
+
+
Arguments:
+
Both arguments to the ‘ashr’ instruction must be the same
+integer or vector of integer type.
+‘op2’ is treated as an unsigned value.
+
+
+
Semantics:
+
This instruction always performs an arithmetic shift right operation,
+The most significant bits of the result will be filled with the sign bit
+of op1. If op2 is (statically or dynamically) equal to or larger
+than the number of bits in op1, this instruction returns a poison
+value. If the arguments are vectors, each vector element
+of op1 is shifted by the corresponding shift amount in op2.
+
If the exact keyword is present, the result value of the ashr is
+a poison value if any of the bits shifted out are non-zero.
+
+`,
tooltip: `The ‘ashr’ instruction (arithmetic shift right) returns the firstoperand shifted to the right a specified number of bits with signextension.`,
};
case 'AND':
return {
url: `https://llvm.org/docs/LangRef.html#and-instruction`,
- html: `
+
+`,
tooltip: `The ‘and’ instruction returns the bitwise logical and of its twooperands.`,
};
case 'OR':
return {
url: `https://llvm.org/docs/LangRef.html#or-instruction`,
- html: `
The ‘or’ instruction returns the bitwise logical inclusive or of itstwo operands.
Arguments:
The two arguments to the ‘or’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
The truth table used for the ‘or’ instruction is:
In0
In1
Out
0
0
0
0
1
1
1
0
1
1
1
1
disjoint means that for each bit, that bit is zero in at least one of theinputs. This allows the Or to be treated as an Add since no carry can occur fromany bit. If the disjoint keyword is present, the result value of the or is apoison value if both inputs have a one in the same bitposition. For vectors, only the element containing the bit is poison.
The ‘or’ instruction returns the bitwise logical inclusive or of its
+two operands.
+
+
+
Arguments:
+
The two arguments to the ‘or’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
The truth table used for the ‘or’ instruction is:
+
+
+
In0
+
In1
+
Out
+
+
0
+
0
+
0
+
+
0
+
1
+
1
+
+
1
+
0
+
1
+
+
1
+
1
+
1
+
+
+
+
disjoint means that for each bit, that bit is zero in at least one of the
+inputs. This allows the Or to be treated as an Add since no carry can occur from
+any bit. If the disjoint keyword is present, the result value of the or is a
+poison value if both inputs have a one in the same bit
+position. For vectors, only the element containing the bit is poison.
The ‘xor’ instruction returns the bitwise logical exclusive or ofits two operands. The xor is used to implement the “one’scomplement” operation, which is the “~” operator in C.
Arguments:
The two arguments to the ‘xor’ instruction must beinteger or vector of integer values. Botharguments must have identical types.
Semantics:
The truth table used for the ‘xor’ instruction is:
The ‘xor’ instruction returns the bitwise logical exclusive or of
+its two operands. The xor is used to implement the “one’s
+complement” operation, which is the “~” operator in C.
+
+
+
Arguments:
+
The two arguments to the ‘xor’ instruction must be
+integer or vector of integer values. Both
+arguments must have identical types.
+
+
+
Semantics:
+
The truth table used for the ‘xor’ instruction is:
+
+`,
tooltip: `The ‘xor’ instruction returns the bitwise logical exclusive or ofits two operands. The xor is used to implement the “one’scomplement” operation, which is the “~” operator in C.`,
};
case 'EXTRACTELEMENT':
return {
url: `https://llvm.org/docs/LangRef.html#extractelement-instruction`,
- html: `
The ‘extractelement’ instruction extracts a single scalar elementfrom a vector at a specified index.
Arguments:
The first operand of an ‘extractelement’ instruction is a value ofvector type. The second operand is an index indicatingthe position from which to extract the element. The index may be avariable of any integer type, and will be treated as an unsigned integer.
Semantics:
The result is a scalar of the same type as the element type of val.Its value is the value at position idx of val. If idxexceeds the length of val for a fixed-length vector, the result is apoison value. For a scalable vector, if the valueof idx exceeds the runtime length of the vector, the result is apoison value.
The ‘extractelement’ instruction extracts a single scalar element
+from a vector at a specified index.
+
+
+
Arguments:
+
The first operand of an ‘extractelement’ instruction is a value of
+vector type. The second operand is an index indicating
+the position from which to extract the element. The index may be a
+variable of any integer type, and will be treated as an unsigned integer.
+
+
+
Semantics:
+
The result is a scalar of the same type as the element type of val.
+Its value is the value at position idx of val. If idx
+exceeds the length of val for a fixed-length vector, the result is a
+poison value. For a scalable vector, if the value
+of idx exceeds the runtime length of the vector, the result is a
+poison value.
+
+`,
tooltip: `The ‘extractelement’ instruction extracts a single scalar elementfrom a vector at a specified index.`,
};
case 'INSERTELEMENT':
return {
url: `https://llvm.org/docs/LangRef.html#insertelement-instruction`,
- html: `
The ‘insertelement’ instruction inserts a scalar element into avector at a specified index.
Arguments:
The first operand of an ‘insertelement’ instruction is a value ofvector type. The second operand is a scalar value whosetype must equal the element type of the first operand. The third operandis an index indicating the position at which to insert the value. Theindex may be a variable of any integer type, and will be treated as anunsigned integer.
Semantics:
The result is a vector of the same type as val. Its element valuesare those of val except at position idx, where it gets the valueelt. If idx exceeds the length of val for a fixed-length vector,the result is a poison value. For a scalable vector,if the value of idx exceeds the runtime length of the vector, the resultis a poison value.
Example:
<result> = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4 x i32>
The ‘insertelement’ instruction inserts a scalar element into a
+vector at a specified index.
+
+
+
Arguments:
+
The first operand of an ‘insertelement’ instruction is a value of
+vector type. The second operand is a scalar value whose
+type must equal the element type of the first operand. The third operand
+is an index indicating the position at which to insert the value. The
+index may be a variable of any integer type, and will be treated as an
+unsigned integer.
+
+
+
Semantics:
+
The result is a vector of the same type as val. Its element values
+are those of val except at position idx, where it gets the value
+elt. If idx exceeds the length of val for a fixed-length vector,
+the result is a poison value. For a scalable vector,
+if the value of idx exceeds the runtime length of the vector, the result
+is a poison value.
+
+
+
Example:
+
<result> = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4 x i32>
+
+
+
+`,
tooltip: `The ‘insertelement’ instruction inserts a scalar element into avector at a specified index.`,
};
case 'SHUFFLEVECTOR':
return {
url: `https://llvm.org/docs/LangRef.html#shufflevector-instruction`,
- html: `
The ‘shufflevector’ instruction constructs a permutation of elementsfrom two input vectors, returning a vector with the same element type asthe input and length that is the same as the shuffle mask.
Arguments:
The first two operands of a ‘shufflevector’ instruction are vectorswith the same type. The third argument is a shuffle mask vector constantwhose element type is i32. The mask vector elements must be constantintegers or poison values. The result of the instruction is a vectorwhose length is the same as the shuffle mask and whose element type is thesame as the element type of the first two operands.
Semantics:
The elements of the two input vectors are numbered from left to rightacross both of the vectors. For each element of the result vector, theshuffle mask selects an element from one of the input vectors to copyto the result. Non-negative elements in the mask represent an indexinto the concatenated pair of input vectors.
A poison element in the mask vector specifies that the resulting elementis poison.For backwards-compatibility reasons, LLVM temporarily also accepts undefmask elements, which will be interpreted the same way as poison elements.If the shuffle mask selects an undef element from one of the inputvectors, the resulting element is undef.
For scalable vectors, the only valid mask values at present arezeroinitializer, undef and poison, since we cannot write all indices asliterals for a vector with a length unknown at compile time.
Example:
<result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, <4 x i32> <i32 0, i32 4, i32 1, i32 5> ; yields <4 x i32><result> = shufflevector <4 x i32> %v1, <4 x i32> poison, <4 x i32> <i32 0, i32 1, i32 2, i32 3> ; yields <4 x i32> - Identity shuffle.<result> = shufflevector <8 x i32> %v1, <8 x i32> poison, <4 x i32> <i32 0, i32 1, i32 2, i32 3> ; yields <4 x i32><result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > ; yields <8 x i32>
The ‘shufflevector’ instruction constructs a permutation of elements
+from two input vectors, returning a vector with the same element type as
+the input and length that is the same as the shuffle mask.
+
+
+
Arguments:
+
The first two operands of a ‘shufflevector’ instruction are vectors
+with the same type. The third argument is a shuffle mask vector constant
+whose element type is i32. The mask vector elements must be constant
+integers or poison values. The result of the instruction is a vector
+whose length is the same as the shuffle mask and whose element type is the
+same as the element type of the first two operands.
+
+
+
Semantics:
+
The elements of the two input vectors are numbered from left to right
+across both of the vectors. For each element of the result vector, the
+shuffle mask selects an element from one of the input vectors to copy
+to the result. Non-negative elements in the mask represent an index
+into the concatenated pair of input vectors.
+
A poison element in the mask vector specifies that the resulting element
+is poison.
+For backwards-compatibility reasons, LLVM temporarily also accepts undef
+mask elements, which will be interpreted the same way as poison elements.
+If the shuffle mask selects an undef element from one of the input
+vectors, the resulting element is undef.
+
For scalable vectors, the only valid mask values at present are
+zeroinitializer, undef and poison, since we cannot write all indices as
+literals for a vector with a length unknown at compile time.
+
+
+
Example:
+
<result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
+ <4 x i32> <i32 0, i32 4, i32 1, i32 5> ; yields <4 x i32>
+<result> = shufflevector <4 x i32> %v1, <4 x i32> poison,
+ <4 x i32> <i32 0, i32 1, i32 2, i32 3> ; yields <4 x i32> - Identity shuffle.
+<result> = shufflevector <8 x i32> %v1, <8 x i32> poison,
+ <4 x i32> <i32 0, i32 1, i32 2, i32 3> ; yields <4 x i32>
+<result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
+ <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > ; yields <8 x i32>
+
+
+
+`,
tooltip: `The ‘shufflevector’ instruction constructs a permutation of elementsfrom two input vectors, returning a vector with the same element type asthe input and length that is the same as the shuffle mask.`,
};
case 'EXTRACTVALUE':
return {
url: `https://llvm.org/docs/LangRef.html#extractvalue-instruction`,
- html: `
The ‘extractvalue’ instruction extracts the value of a member fieldfrom an aggregate value.
Arguments:
The first operand of an ‘extractvalue’ instruction is a value ofstruct or array type. The other operands areconstant indices to specify which value to extract in a similar manneras indices in a ‘getelementptr’ instruction.
The major differences to getelementptr indexing are:
Since the value being indexed is not a pointer, the first index isomitted and assumed to be zero.
At least one index must be specified.
Not only struct indices but also array indices must be in bounds.
Semantics:
The result is the value at the position in the aggregate specified bythe index operands.
The ‘extractvalue’ instruction extracts the value of a member field
+from an aggregate value.
+
+
+
Arguments:
+
The first operand of an ‘extractvalue’ instruction is a value of
+struct or array type. The other operands are
+constant indices to specify which value to extract in a similar manner
+as indices in a ‘getelementptr’ instruction.
+
The major differences to getelementptr indexing are:
+
+
Since the value being indexed is not a pointer, the first index is
+omitted and assumed to be zero.
+
At least one index must be specified.
+
Not only struct indices but also array indices must be in bounds.
+
+
+
+
Semantics:
+
The result is the value at the position in the aggregate specified by
+the index operands.
+
+`,
tooltip: `The ‘extractvalue’ instruction extracts the value of a member fieldfrom an aggregate value.`,
};
case 'INSERTVALUE':
return {
url: `https://llvm.org/docs/LangRef.html#insertvalue-instruction`,
- html: `
The ‘insertvalue’ instruction inserts a value into a member field inan aggregate value.
Arguments:
The first operand of an ‘insertvalue’ instruction is a value ofstruct or array type. The second operand isa first-class value to insert. The following operands are constantindices indicating the position at which to insert the value in asimilar manner as indices in a ‘extractvalue’ instruction. The valueto insert must have the same type as the value identified by theindices.
Semantics:
The result is an aggregate of the same type as val. Its value isthat of val except that the value at the position specified by theindices is that of elt.
The ‘insertvalue’ instruction inserts a value into a member field in
+an aggregate value.
+
+
+
Arguments:
+
The first operand of an ‘insertvalue’ instruction is a value of
+struct or array type. The second operand is
+a first-class value to insert. The following operands are constant
+indices indicating the position at which to insert the value in a
+similar manner as indices in a ‘extractvalue’ instruction. The value
+to insert must have the same type as the value identified by the
+indices.
+
+
+
Semantics:
+
The result is an aggregate of the same type as val. Its value is
+that of val except that the value at the position specified by the
+indices is that of elt.
+
+`,
tooltip: `The ‘insertvalue’ instruction inserts a value into a member field inan aggregate value.`,
};
case 'ALLOCA':
return {
url: `https://llvm.org/docs/LangRef.html#alloca-instruction`,
- html: `
The ‘alloca’ instruction allocates memory on the stack frame of thecurrently executing function, to be automatically released when thisfunction returns to its caller. If the address space is not explicitlyspecified, the object is allocated in the alloca address space from thedatalayout string.
Arguments:
The ‘alloca’ instruction allocates sizeof(<type>)*NumElementsbytes of memory on the runtime stack, returning a pointer of theappropriate type to the program. If “NumElements” is specified, it isthe number of elements allocated, otherwise “NumElements” is defaultedto be one.
If a constant alignment is specified, the value result of theallocation is guaranteed to be aligned to at least that boundary. Thealignment may not be greater than 1<<32.
The alignment is only optional when parsing textual IR; for in-memory IR,it is always present. If not specified, the target can choose to align theallocation on any convenient boundary compatible with the type.
‘type’ may be any sized type.
Structs containing scalable vectors cannot be used in allocas unless allfields are the same scalable vector type (e.g. {<vscalex2xi32>,<vscalex2xi32>} contains the same type while {<vscalex2xi32>,<vscalex2xi64>} doesn’t).
Semantics:
Memory is allocated; a pointer is returned. The allocated memory isuninitialized, and loading from uninitialized memory produces an undefinedvalue. The operation itself is undefined if there is insufficient stackspace for the allocation.’alloca’d memory is automatically releasedwhen the function returns. The ‘alloca’ instruction is commonly usedto represent automatic variables that must have an address available. Whenthe function returns (either with the ret or resume instructions),the memory is reclaimed. Allocating zero bytes is legal, but the returnedpointer may not be unique. The order in which memory is allocated (ie.,which way the stack grows) is not specified.
Note that ‘alloca’ outside of the alloca address space from thedatalayout string is meaningful only if thetarget has assigned it a semantics.
`,
- tooltip: `The ‘alloca’ instruction allocates memory on the stack frame of thecurrently executing function, to be automatically released when thisfunction returns to its caller. If the address space is not explicitlyspecified, the object is allocated in the alloca address space from thedatalayout string.`,
+ html: `
The ‘alloca’ instruction allocates memory on the stack frame of the
+currently executing function, to be automatically released when this
+function returns to its caller. If the address space is not explicitly
+specified, the default address space 0 is used.
+
+
+
Arguments:
+
The ‘alloca’ instruction allocates sizeof(<type>)*NumElements
+bytes of memory on the runtime stack, returning a pointer of the
+appropriate type to the program. If “NumElements” is specified, it is
+the number of elements allocated, otherwise “NumElements” is defaulted
+to be one.
+
If a constant alignment is specified, the value result of the
+allocation is guaranteed to be aligned to at least that boundary. The
+alignment may not be greater than 1<<32.
+
The alignment is only optional when parsing textual IR; for in-memory IR,
+it is always present. If not specified, the target can choose to align the
+allocation on any convenient boundary compatible with the type.
+
‘type’ may be any sized type.
+
Structs containing scalable vectors cannot be used in allocas unless all
+fields are the same scalable vector type (e.g., {<vscalex2xi32>,
+<vscalex2xi32>} contains the same type while {<vscalex2xi32>,
+<vscalex2xi64>} doesn’t).
+
+
+
Semantics:
+
Memory is allocated; a pointer is returned. The allocated memory is
+uninitialized, and loading from uninitialized memory produces an undefined
+value. The operation itself is undefined if there is insufficient stack
+space for the allocation.’alloca’d memory is automatically released
+when the function returns. The ‘alloca’ instruction is commonly used
+to represent automatic variables that must have an address available. When
+the function returns (either with the ret or resume instructions),
+the memory is reclaimed. Allocating zero bytes is legal, but the returned
+pointer may not be unique. The order in which memory is allocated (ie.,
+which way the stack grows) is not specified.
+
Note that ‘alloca’ outside of the alloca address space from the
+datalayout string is meaningful only if the
+target has assigned it a semantics. For targets that specify a non-zero alloca
+address space in the datalayout string, the alloca
+address space needs to be explicitly specified in the instruction if it is to be
+used.
+
+`,
+ tooltip: `The ‘alloca’ instruction allocates memory on the stack frame of thecurrently executing function, to be automatically released when thisfunction returns to its caller. If the address space is not explicitlyspecified, the default address space 0 is used.`,
};
case 'LOAD':
return {
url: `https://llvm.org/docs/LangRef.html#load-instruction`,
- html: `
The ‘load’ instruction is used to read from memory.
Arguments:
The argument to the load instruction specifies the memory address from whichto load. The type specified must be a first class type ofknown size (i.e. not containing an opaque structural type). Ifthe load is marked as volatile, then the optimizer is not allowed tomodify the number or order of execution of this load with othervolatile operations.
If the load is marked as atomic, it takes an extra ordering and optional syncscope("<target-scope>") argument. Therelease and acq_rel orderings are not valid on load instructions.Atomic loads produce defined results when they may seemultiple atomic stores. The type of the pointee must be an integer, pointer, orfloating-point type whose bit width is a power of two greater than or equal toeight and less than or equal to a target-specific size limit. align must beexplicitly specified on atomic loads. Note: if the alignment is not greater orequal to the size of the <value> type, the atomic operation is likely torequire a lock and have poor performance. !nontemporal does not have anydefined semantics for atomic loads.
The optional constant align argument specifies the alignment of theoperation (that is, the alignment of the memory address). It is theresponsibility of the code emitter to ensure that the alignment information iscorrect. Overestimating the alignment results in undefined behavior.Underestimating the alignment may produce less efficient code. An alignment of1 is always safe. The maximum possible alignment is 1<<32. An alignmentvalue higher than the size of the loaded type implies memory up to thealignment value bytes can be safely loaded without trapping in the defaultaddress space. Access of the high bytes can interfere with debugging tools, soshould not be accessed if the function has the sanitize_thread orsanitize_address attributes.
The alignment is only optional when parsing textual IR; for in-memory IR, it isalways present. An omitted align argument means that the operation has theABI alignment for the target.
The optional !nontemporal metadata must reference a singlemetadata name <nontemp_node> corresponding to a metadata node with onei32 entry of value 1. The existence of the !nontemporalmetadata on the instruction tells the optimizer and code generatorthat this load is not expected to be reused in the cache. The codegenerator may select special instructions to save cache bandwidth, suchas the MOVNT instruction on x86.
The optional !invariant.load metadata must reference a singlemetadata name <empty_node> corresponding to a metadata node with noentries. If a load instruction tagged with the !invariant.loadmetadata is executed, the memory location referenced by the load hasto contain the same value at all points in the program where thememory location is dereferenceable; otherwise, the behavior isundefined.
The optional !invariant.group metadata must reference a single metadata name
<empty_node> corresponding to a metadata node with no entries.See invariant.group metadata invariant.group.
The optional !nonnull metadata must reference a singlemetadata name <empty_node> corresponding to a metadata node with noentries. The existence of the !nonnull metadata on theinstruction tells the optimizer that the value loaded is known tonever be null. If the value is null at runtime, a poison value is returnedinstead. This is analogous to the nonnull attribute on parameters andreturn values. This metadata can only be applied to loads of a pointer type.
The optional !dereferenceable metadata must reference a single metadataname <deref_bytes_node> corresponding to a metadata node with one i64entry.See dereferenceable metadata dereferenceable.
The optional !dereferenceable_or_null metadata must reference a singlemetadata name <deref_bytes_node> corresponding to a metadata node with onei64 entry.See dereferenceable_or_null metadata dereferenceable_or_null.
The optional !align metadata must reference a single metadata name<align_node> corresponding to a metadata node with one i64 entry.The existence of the !align metadata on the instruction tells theoptimizer that the value loaded is known to be aligned to a boundary specifiedby the integer value in the metadata node. The alignment must be a power of 2.This is analogous to the ‘’align’’ attribute on parameters and return values.This metadata can only be applied to loads of a pointer type. If the returnedvalue is not appropriately aligned at runtime, a poison value is returnedinstead.
The optional !noundef metadata must reference a single metadata name<empty_node> corresponding to a node with no entries. The existence of!noundef metadata on the instruction tells the optimizer that the valueloaded is known to be well defined.If the value isn’t well defined, the behavior is undefined. If the !noundefmetadata is combined with poison-generating metadata like !nonnull,violation of that metadata constraint will also result in undefined behavior.
Semantics:
The location of memory pointed to is loaded. If the value being loadedis of scalar type then the number of bytes read does not exceed theminimum number of bytes needed to hold all bits of the type. Forexample, loading an i24 reads at most three bytes. When loading avalue of a type like i20 with a size that is not an integral numberof bytes, the result is undefined if the value was not originallywritten using a store of the same type.If the value being loaded is of aggregate type, the bytes that correspond topadding may be accessed but are ignored, because it is impossible to observepadding from the loaded aggregate value.If <pointer> is not a well-defined value, the behavior is undefined.
The ‘load’ instruction is used to read from memory.
+
+
+
Arguments:
+
The argument to the load instruction specifies the memory address from which
+to load. The type specified must be a first class type of
+known size (i.e., not containing an opaque structural type). If
+the load is marked as volatile, then the optimizer is not allowed to
+modify the number or order of execution of this load with other
+volatile operations.
+
If the load is marked as atomic, it takes an extra ordering and optional syncscope("<target-scope>") argument. The
+release and acq_rel orderings are not valid on load instructions.
+Atomic loads produce defined results when they may see
+multiple atomic stores. The type of the pointee must be an integer, pointer,
+floating-point, or vector type whose bit width is a power of two greater than
+or equal to eight. align must be
+explicitly specified on atomic loads. Note: if the alignment is not greater or
+equal to the size of the <value> type, the atomic operation is likely to
+require a lock and have poor performance. !nontemporal does not have any
+defined semantics for atomic loads.
+
The optional constant align argument specifies the alignment of the
+operation (that is, the alignment of the memory address). It is the
+responsibility of the code emitter to ensure that the alignment information is
+correct. Overestimating the alignment results in undefined behavior.
+Underestimating the alignment may produce less efficient code. An alignment of
+1 is always safe. The maximum possible alignment is 1<<32. An alignment
+value higher than the size of the loaded type does not imply (without target
+specific knowledge) that memory up to the alignment value bytes can be safely
+loaded without trapping.
+
The alignment is only optional when parsing textual IR; for in-memory IR, it is
+always present. An omitted align argument means that the operation has the
+ABI alignment for the target.
+
The optional !nontemporal metadata must reference a single
+metadata name <nontemp_node> corresponding to a metadata node with one
+i32 entry of value 1. The existence of the !nontemporal
+metadata on the instruction tells the optimizer and code generator
+that this load is not expected to be reused in the cache. The code
+generator may select special instructions to save cache bandwidth, such
+as the MOVNT instruction on x86.
+
The optional !invariant.load metadata must reference a single
+metadata name <empty_node> corresponding to a metadata node with no
+entries. If a load instruction tagged with the !invariant.load
+metadata is executed, the memory location referenced by the load has
+to contain the same value at all points in the program where the
+memory location is dereferenceable; otherwise, the behavior is
+undefined.
+
+
The optional !invariant.group metadata must reference a single metadata name
<empty_node> corresponding to a metadata node with no entries.
+See invariant.group metadata invariant.group.
+
+
+
The optional !nonnull metadata must reference a single
+metadata name <empty_node> corresponding to a metadata node with no
+entries. The existence of the !nonnull metadata on the
+instruction tells the optimizer that the value loaded is known to
+never be null. If the value is null at runtime, a poison value is returned
+instead. This is analogous to the nonnull attribute on parameters and
+return values. This metadata can only be applied to loads of a pointer type.
+
The optional !dereferenceable metadata must reference a single metadata
+name <deref_bytes_node> corresponding to a metadata node with one i64
+entry.
+See dereferenceable metadata dereferenceable.
+
The optional !dereferenceable_or_null metadata must reference a single
+metadata name <deref_bytes_node> corresponding to a metadata node with one
+i64 entry.
+See dereferenceable_or_null metadata dereferenceable_or_null.
+
The optional !align metadata must reference a single metadata name
+<align_node> corresponding to a metadata node with one i64 entry.
+The existence of the !align metadata on the instruction tells the
+optimizer that the value loaded is known to be aligned to a boundary specified
+by the integer value in the metadata node. The alignment must be a power of 2.
+This is analogous to the ‘’align’’ attribute on parameters and return values.
+This metadata can only be applied to loads of a pointer type. If the returned
+value is not appropriately aligned at runtime, a poison value is returned
+instead.
+
The optional !noundef metadata must reference a single metadata name
+<empty_node> corresponding to a node with no entries. The existence of
+!noundef metadata on the instruction tells the optimizer that the value
+loaded is known to be well defined.
+If the value isn’t well defined, the behavior is undefined. If the !noundef
+metadata is combined with poison-generating metadata like !nonnull,
+violation of that metadata constraint will also result in undefined behavior.
+
+
+
Semantics:
+
The location of memory pointed to is loaded. If the value being loaded
+is of scalar type then the number of bytes read does not exceed the
+minimum number of bytes needed to hold all bits of the type. For
+example, loading an i24 reads at most three bytes. When loading a
+value of a type like i20 with a size that is not an integral number
+of bytes, the result is undefined if the value was not originally
+written using a store of the same type.
+If the value being loaded is of aggregate type, the bytes that correspond to
+padding may be accessed but are ignored, because it is impossible to observe
+padding from the loaded aggregate value.
+If <pointer> is not a well-defined value, the behavior is undefined.
+
+`,
tooltip: `The ‘load’ instruction is used to read from memory.`,
};
case 'STORE':
return {
url: `https://llvm.org/docs/LangRef.html#store-instruction`,
- html: `
The ‘store’ instruction is used to write to memory.
Arguments:
There are two arguments to the store instruction: a value to store and anaddress at which to store it. The type of the <pointer> operand must be apointer to the first class type of the <value>operand. If the store is marked as volatile, then the optimizer is notallowed to modify the number or order of execution of this store with othervolatile operations. Only values of first class types of known size (i.e. not containing an opaquestructural type) can be stored.
If the store is marked as atomic, it takes an extra ordering and optional syncscope("<target-scope>") argument. Theacquire and acq_rel orderings aren’t valid on store instructions.Atomic loads produce defined results when they may seemultiple atomic stores. The type of the pointee must be an integer, pointer, orfloating-point type whose bit width is a power of two greater than or equal toeight and less than or equal to a target-specific size limit. align must beexplicitly specified on atomic stores. Note: if the alignment is not greater orequal to the size of the <value> type, the atomic operation is likely torequire a lock and have poor performance. !nontemporal does not have anydefined semantics for atomic stores.
The optional constant align argument specifies the alignment of theoperation (that is, the alignment of the memory address). It is theresponsibility of the code emitter to ensure that the alignment information iscorrect. Overestimating the alignment results in undefined behavior.Underestimating the alignment may produce less efficient code. An alignment of1 is always safe. The maximum possible alignment is 1<<32. An alignmentvalue higher than the size of the loaded type implies memory up to thealignment value bytes can be safely loaded without trapping in the defaultaddress space. Access of the high bytes can interfere with debugging tools, soshould not be accessed if the function has the sanitize_thread orsanitize_address attributes.
The alignment is only optional when parsing textual IR; for in-memory IR, it isalways present. An omitted align argument means that the operation has theABI alignment for the target.
The optional !nontemporal metadata must reference a single metadataname <nontemp_node> corresponding to a metadata node with one i32 entryof value 1. The existence of the !nontemporal metadata on the instructiontells the optimizer and code generator that this load is not expected tobe reused in the cache. The code generator may select specialinstructions to save cache bandwidth, such as the MOVNT instruction onx86.
The optional !invariant.group metadata must reference asingle metadata name <empty_node>. See invariant.group metadata.
Semantics:
The contents of memory are updated to contain <value> at thelocation specified by the <pointer> operand. If <value> isof scalar type then the number of bytes written does not exceed theminimum number of bytes needed to hold all bits of the type. Forexample, storing an i24 writes at most three bytes. When writing avalue of a type like i20 with a size that is not an integral numberof bytes, it is unspecified what happens to the extra bits that do notbelong to the type, but they will typically be overwritten.If <value> is of aggregate type, padding is filled withundef.If <pointer> is not a well-defined value, the behavior is undefined.
The ‘store’ instruction is used to write to memory.
+
+
+
Arguments:
+
There are two arguments to the store instruction: a value to store and an
+address at which to store it. The type of the <pointer> operand must be a
+pointer to the first class type of the <value>
+operand. If the store is marked as volatile, then the optimizer is not
+allowed to modify the number or order of execution of this store with other
+volatile operations. Only values of first class types of known size (i.e., not containing an opaque
+structural type) can be stored.
+
If the store is marked as atomic, it takes an extra ordering and optional syncscope("<target-scope>") argument. The
+acquire and acq_rel orderings aren’t valid on store instructions.
+Atomic loads produce defined results when they may see
+multiple atomic stores. The type of the pointee must be an integer, pointer,
+floating-point, or vector type whose bit width is a power of two greater than
+or equal to eight. align must be
+explicitly specified on atomic stores. Note: if the alignment is not greater or
+equal to the size of the <value> type, the atomic operation is likely to
+require a lock and have poor performance. !nontemporal does not have any
+defined semantics for atomic stores.
+
The optional constant align argument specifies the alignment of the
+operation (that is, the alignment of the memory address). It is the
+responsibility of the code emitter to ensure that the alignment information is
+correct. Overestimating the alignment results in undefined behavior.
+Underestimating the alignment may produce less efficient code. An alignment of
+1 is always safe. The maximum possible alignment is 1<<32. An alignment
+value higher than the size of the stored type does not imply (without target
+specific knowledge) that memory up to the alignment value bytes can be safely
+loaded without trapping.
+
The alignment is only optional when parsing textual IR; for in-memory IR, it is
+always present. An omitted align argument means that the operation has the
+ABI alignment for the target.
+
The optional !nontemporal metadata must reference a single metadata
+name <nontemp_node> corresponding to a metadata node with one i32 entry
+of value 1. The existence of the !nontemporal metadata on the instruction
+tells the optimizer and code generator that this load is not expected to
+be reused in the cache. The code generator may select special
+instructions to save cache bandwidth, such as the MOVNT instruction on
+x86.
+
The optional !invariant.group metadata must reference a
+single metadata name <empty_node>. See invariant.group metadata.
+
+
+
Semantics:
+
The contents of memory are updated to contain <value> at the
+location specified by the <pointer> operand. If <value> is
+of scalar type then the number of bytes written does not exceed the
+minimum number of bytes needed to hold all bits of the type. For
+example, storing an i24 writes at most three bytes. When writing a
+value of a type like i20 with a size that is not an integral number
+of bytes, it is unspecified what happens to the extra bits that do not
+belong to the type, but they will typically be overwritten.
+If <value> is of aggregate type, padding is filled with
+undef.
+If <pointer> is not a well-defined value, the behavior is undefined.
+
+`,
tooltip: `The ‘store’ instruction is used to write to memory.`,
};
case 'FENCE':
return {
url: `https://llvm.org/docs/LangRef.html#fence-instruction`,
- html: `
The ‘fence’ instruction is used to introduce happens-before edgesbetween operations.
Arguments:
‘fence’ instructions take an ordering argument whichdefines what synchronizes-with edges they add. They can only be givenacquire, release, acq_rel, and seq_cst orderings.
Semantics:
A fence A which has (at least) release ordering semanticssynchronizes with a fence B with (at least) acquire orderingsemantics if and only if there exist atomic operations X and Y, bothoperating on some atomic object M, such that A is sequenced before X, Xmodifies M (either directly or through some side effect of a sequenceheaded by X), Y is sequenced before B, and Y observes M. This provides ahappens-before dependency between A and B. Rather than an explicitfence, one (but not both) of the atomic operations X or Y mightprovide a release or acquire (resp.) ordering constraint andstill synchronize-with the explicit fence and establish thehappens-before edge.
A fence which has seq_cst ordering, in addition to having bothacquire and release semantics specified above, participates inthe global program order of other seq_cst operations and/orfences. Furthermore, the global ordering created by a seq_cstfence must be compatible with the individual total orders ofmonotonic (or stronger) memory accesses occurring before and aftersuch a fence. The exact semantics of this interaction are somewhatcomplicated, see the C++ standard’s [atomics.order] section for more details.
A fence instruction can also take an optional“syncscope” argument.
The ‘fence’ instruction is used to introduce happens-before edges
+between operations.
+
+
+
Arguments:
+
‘fence’ instructions take an ordering argument which
+defines what synchronizes-with edges they add. They can only be given
+acquire, release, acq_rel, and seq_cst orderings.
+
+
+
Semantics:
+
A fence A which has (at least) release ordering semantics
+synchronizes with a fence B with (at least) acquire ordering
+semantics if and only if there exist atomic operations X and Y, both
+operating on some atomic object M, such that A is sequenced before X, X
+modifies M (either directly or through some side effect of a sequence
+headed by X), Y is sequenced before B, and Y observes M. This provides a
+happens-before dependency between A and B. Rather than an explicit
+fence, one (but not both) of the atomic operations X or Y might
+provide a release or acquire (resp.) ordering constraint and
+still synchronize-with the explicit fence and establish the
+happens-before edge.
+
A fence which has seq_cst ordering, in addition to having both
+acquire and release semantics specified above, participates in
+the global program order of other seq_cst operations and/or
+fences. Furthermore, the global ordering created by a seq_cst
+fence must be compatible with the individual total orders of
+monotonic (or stronger) memory accesses occurring before and after
+such a fence. The exact semantics of this interaction are somewhat
+complicated, see the C++ standard’s [atomics.order] section for more details.
+
A fence instruction can also take an optional
+“syncscope” argument.
The ‘cmpxchg’ instruction is used to atomically modify memory. Itloads a value in memory and compares it to a given value. If they areequal, it tries to store a new value into the memory.
Arguments:
There are three arguments to the ‘cmpxchg’ instruction: an addressto operate on, a value to compare to the value currently be at thataddress, and a new value to place at that address if the compared valuesare equal. The type of ‘<cmp>’ must be an integer or pointer type whosebit width is a power of two greater than or equal to eight and lessthan or equal to a target-specific size limit. ‘<cmp>’ and ‘<new>’ musthave the same type, and the type of ‘<pointer>’ must be a pointer tothat type. If the cmpxchg is marked as volatile, then theoptimizer is not allowed to modify the number or order of execution ofthis cmpxchg with other volatile operations.
The success and failure ordering arguments specify how thiscmpxchg synchronizes with other atomic operations. Both ordering parametersmust be at least monotonic, the failure ordering cannot be eitherrelease or acq_rel.
A cmpxchg instruction can also take an optional“syncscope” argument.
Note: if the alignment is not greater or equal to the size of the <value>type, the atomic operation is likely to require a lock and have poorperformance.
The alignment is only optional when parsing textual IR; for in-memory IR, it isalways present. If unspecified, the alignment is assumed to be equal to thesize of the ‘<value>’ type. Note that this default alignment assumption isdifferent from the alignment used for the load/store instructions when alignisn’t specified.
The pointer passed into cmpxchg must have alignment greater than orequal to the size in memory of the operand.
Semantics:
The contents of memory at the location specified by the ‘<pointer>’ operandis read and compared to ‘<cmp>’; if the values are equal, ‘<new>’ iswritten to the location. The original value at the location is returned,together with a flag indicating success (true) or failure (false).
If the cmpxchg operation is marked as weak then a spurious failure ispermitted: the operation may not write <new> even if the comparisonmatched.
If the cmpxchg operation is strong (the default), the i1 value is 1 if and onlyif the value loaded equals cmp.
A successful cmpxchg is a read-modify-write instruction for the purpose ofidentifying release sequences. A failed cmpxchg is equivalent to an atomicload with an ordering parameter determined the second ordering parameter.
The ‘cmpxchg’ instruction is used to atomically modify memory. It
+loads a value in memory and compares it to a given value. If they are
+equal, it tries to store a new value into the memory.
+
+
+
Arguments:
+
There are three arguments to the ‘cmpxchg’ instruction: an address
+to operate on, a value to compare to the value currently be at that
+address, and a new value to place at that address if the compared values
+are equal. The type of ‘<cmp>’ must be an integer or pointer type whose
+bit width is a power of two greater than or equal to eight.
+‘<cmp>’ and ‘<new>’ must
+have the same type, and the type of ‘<pointer>’ must be a pointer to
+that type. If the cmpxchg is marked as volatile, then the
+optimizer is not allowed to modify the number or order of execution of
+this cmpxchg with other volatile operations.
+
The success and failure ordering arguments specify how this
+cmpxchg synchronizes with other atomic operations. Both ordering parameters
+must be at least monotonic, the failure ordering cannot be either
+release or acq_rel.
+
A cmpxchg instruction can also take an optional
+“syncscope” argument.
+
Note: if the alignment is not greater or equal to the size of the <value>
+type, the atomic operation is likely to require a lock and have poor
+performance.
+
The alignment is only optional when parsing textual IR; for in-memory IR, it is
+always present. If unspecified, the alignment is assumed to be equal to the
+size of the ‘<value>’ type. Note that this default alignment assumption is
+different from the alignment used for the load/store instructions when align
+isn’t specified.
+
The pointer passed into cmpxchg must have alignment greater than or
+equal to the size in memory of the operand.
+
+
+
Semantics:
+
The contents of memory at the location specified by the ‘<pointer>’ operand
+is read and compared to ‘<cmp>’; if the values are equal, ‘<new>’ is
+written to the location. The original value at the location is returned,
+together with a flag indicating success (true) or failure (false).
+
If the cmpxchg operation is marked as weak then a spurious failure is
+permitted: the operation may not write <new> even if the comparison
+matched.
+
If the cmpxchg operation is strong (the default), the i1 value is 1 if and only
+if the value loaded equals cmp.
+
A successful cmpxchg is a read-modify-write instruction for the purpose of
+identifying release sequences. A failed cmpxchg is equivalent to an atomic
+load with an ordering parameter determined the second ordering parameter.
+
+`,
tooltip: `The ‘cmpxchg’ instruction is used to atomically modify memory. Itloads a value in memory and compares it to a given value. If they areequal, it tries to store a new value into the memory.`,
};
case 'ATOMICRMW':
return {
url: `https://llvm.org/docs/LangRef.html#atomicrmw-instruction`,
- html: `
The ‘atomicrmw’ instruction is used to atomically modify memory.
Arguments:
There are three arguments to the ‘atomicrmw’ instruction: anoperation to apply, an address whose value to modify, an argument to theoperation. The operation must be one of the following keywords:
xchg
add
sub
and
nand
or
xor
max
min
umax
umin
fadd
fsub
fmax
fmin
uinc_wrap
udec_wrap
usub_cond
usub_sat
For most of these operations, the type of ‘<value>’ must be an integertype whose bit width is a power of two greater than or equal to eightand less than or equal to a target-specific size limit. For xchg, thismay also be a floating point or a pointer type with the same size constraintsas integers. For fadd/fsub/fmax/fmin, this must be a floating-pointor fixed vector of floating-point type. The type of the ‘<pointer>’operand must be a pointer to that type. If the atomicrmw is markedas volatile, then the optimizer is not allowed to modify thenumber or order of execution of this atomicrmw with othervolatile operations.
Note: if the alignment is not greater or equal to the size of the <value>type, the atomic operation is likely to require a lock and have poorperformance.
The alignment is only optional when parsing textual IR; for in-memory IR, it isalways present. If unspecified, the alignment is assumed to be equal to thesize of the ‘<value>’ type. Note that this default alignment assumption isdifferent from the alignment used for the load/store instructions when alignisn’t specified.
A atomicrmw instruction can also take an optional“syncscope” argument.
Semantics:
The contents of memory at the location specified by the ‘<pointer>’operand are atomically read, modified, and written back. The originalvalue at the location is returned. The modification is specified by theoperation argument:
xchg: *ptr=val
add: *ptr=*ptr+val
sub: *ptr=*ptr-val
and: *ptr=*ptr&val
nand: *ptr=~(*ptr&val)
or: *ptr=*ptr|val
xor: *ptr=*ptr^val
max: *ptr=*ptr>val?*ptr:val (using a signed comparison)
min: *ptr=*ptr<val?*ptr:val (using a signed comparison)
umax: *ptr=*ptr>val?*ptr:val (using an unsigned comparison)
umin: *ptr=*ptr<val?*ptr:val (using an unsigned comparison)
fadd: *ptr=*ptr+val (using floating point arithmetic)
fsub: *ptr=*ptr-val (using floating point arithmetic)
fmax: *ptr=maxnum(*ptr,val) (match the llvm.maxnum.*\` intrinsic)
fmin: *ptr=minnum(*ptr,val) (match the llvm.minnum.*\` intrinsic)
uinc_wrap: *ptr=(*ptru>=val)?0:(*ptr+1) (increment value with wraparound to zero when incremented above input value)
udec_wrap: *ptr=((*ptr==0)||(*ptru>val))?val:(*ptr-1) (decrement with wraparound to input value when decremented below zero).
usub_cond: *ptr=(*ptru>=val)?*ptr-val:*ptr (subtract only if no unsigned overflow).
usub_sat: *ptr=(*ptru>=val)?*ptr-val:0 (subtract with unsigned clamping to zero).
The ‘atomicrmw’ instruction is used to atomically modify memory.
+
+
+
Arguments:
+
There are three arguments to the ‘atomicrmw’ instruction: an
+operation to apply, an address whose value to modify, an argument to the
+operation. The operation must be one of the following keywords:
+
+
xchg
+
add
+
sub
+
and
+
nand
+
or
+
xor
+
max
+
min
+
umax
+
umin
+
fadd
+
fsub
+
fmax
+
fmin
+
fmaximum
+
fminimum
+
uinc_wrap
+
udec_wrap
+
usub_cond
+
usub_sat
+
+
For most of these operations, the type of ‘<value>’ must be an integer
+type whose bit width is a power of two greater than or equal to eight.
+For xchg, this
+may also be a floating point or a pointer type with the same size constraints
+as integers. For fadd/fsub/fmax/fmin/fmaximum/fminimum, this must be a floating-point
+or fixed vector of floating-point type. The type of the ‘<pointer>’
+operand must be a pointer to that type. If the atomicrmw is marked
+as volatile, then the optimizer is not allowed to modify the
+number or order of execution of this atomicrmw with other
+volatile operations.
+
Note: if the alignment is not greater or equal to the size of the <value>
+type, the atomic operation is likely to require a lock and have poor
+performance.
+
The alignment is only optional when parsing textual IR; for in-memory IR, it is
+always present. If unspecified, the alignment is assumed to be equal to the
+size of the ‘<value>’ type. Note that this default alignment assumption is
+different from the alignment used for the load/store instructions when align
+isn’t specified.
+
An atomicrmw instruction can also take an optional
+“syncscope” argument.
+
+
+
Semantics:
+
The contents of memory at the location specified by the ‘<pointer>’
+operand are atomically read, modified, and written back. The original
+value at the location is returned. The modification is specified by the
+operation argument:
+
+
xchg: *ptr=val
+
add: *ptr=*ptr+val
+
sub: *ptr=*ptr-val
+
and: *ptr=*ptr&val
+
nand: *ptr=~(*ptr&val)
+
or: *ptr=*ptr|val
+
xor: *ptr=*ptr^val
+
max: *ptr=*ptr>val?*ptr:val (using a signed comparison)
+
min: *ptr=*ptr<val?*ptr:val (using a signed comparison)
+
umax: *ptr=*ptr>val?*ptr:val (using an unsigned comparison)
+
umin: *ptr=*ptr<val?*ptr:val (using an unsigned comparison)
+
fadd: *ptr=*ptr+val (using floating point arithmetic)
+
fsub: *ptr=*ptr-val (using floating point arithmetic)
+
fmax: *ptr=maxnum(*ptr,val) (match the llvm.maxnum.* intrinsic)
+
fmin: *ptr=minnum(*ptr,val) (match the llvm.minnum.* intrinsic)
+
fmaximum: *ptr=maximum(*ptr,val) (match the llvm.maximum.* intrinsic)
+
fminimum: *ptr=minimum(*ptr,val) (match the llvm.minimum.* intrinsic)
+
uinc_wrap: *ptr=(*ptru>=val)?0:(*ptr+1) (increment value with wraparound to zero when incremented above input value)
+
udec_wrap: *ptr=((*ptr==0)||(*ptru>val))?val:(*ptr-1) (decrement with wraparound to input value when decremented below zero).
+
usub_cond: *ptr=(*ptru>=val)?*ptr-val:*ptr (subtract only if no unsigned overflow).
+
usub_sat: *ptr=(*ptru>=val)?*ptr-val:0 (subtract with unsigned clamping to zero).
The ‘getelementptr’ instruction is used to get the address of asubelement of an aggregate data structure. It performsaddress calculation only and does not access memory. The instruction can alsobe used to calculate a vector of such addresses.
Arguments:
The first argument is always a type used as the basis for the calculations.The second argument is always a pointer or a vector of pointers, and is thebase address to start from. The remaining arguments are indicesthat indicate which of the elements of the aggregate object are indexed.The interpretation of each index is dependent on the type being indexedinto. The first index always indexes the pointer value given as thesecond argument, the second index indexes a value of the type pointed to(not necessarily the value directly pointed to, since the first indexcan be non-zero), etc. The first type indexed into must be a pointervalue, subsequent types can be arrays, vectors, and structs. Note thatsubsequent types being indexed into can never be pointers, since thatwould require loading the pointer before continuing calculation.
The type of each index argument depends on the type it is indexing into.When indexing into a (optionally packed) structure, only i32 integerconstants are allowed (when using a vector of indices they must allbe the samei32 integer constant). When indexing into an array,pointer or vector, integers of any width are allowed, and they are notrequired to be constant. These integers are treated as signed valueswhere relevant.
For example, let’s consider a C code fragment and how it gets compiledto LLVM:
In the example above, the first index is indexing into the‘%struct.ST*’ type, which is a pointer, yielding a ‘%struct.ST’= ‘{i32,double,%struct.RT}’ type, a structure. The second indexindexes into the third element of the structure, yielding a‘%struct.RT’ = ‘{i8,[10x[20xi32]],i8}’ type, anotherstructure. The third index indexes into the second element of thestructure, yielding a ‘[10x[20xi32]]’ type, an array. The twodimensions of the array are subscripted into, yielding an ‘i32’type. The ‘getelementptr’ instruction returns a pointer to thiselement.
Note that it is perfectly legal to index partially through a structure,returning a pointer to an inner element. Because of this, the LLVM codefor the given testcase is equivalent to:
The indices are first converted to offsets in the pointer’s index type. If thecurrently indexed type is a struct type, the struct offset corresponding to theindex is sign-extended or truncated to the pointer index type. Otherwise, theindex itself is sign-extended or truncated, and then multiplied by the typeallocation size (that is, the size rounded up to the ABI alignment) of thecurrently indexed type.
The offsets are then added to the low bits of the base address up to the indextype width, with silently-wrapping two’s complement arithmetic. If the pointersize is larger than the index size, this means that the bits outside the indextype width will not be affected.
The result value of the getelementptr may be outside the object pointedto by the base pointer. The result value may not necessarily be used to accessmemory though, even if it happens to point into allocated storage. See thePointer Aliasing Rules section for moreinformation.
The getelementptr instruction may have a number of attributes that imposeadditional rules. If any of the rules are violated, the result value is apoison value. In cases where the base is a vector ofpointers, the attributes apply to each computation element-wise.
For nusw (no unsigned signed wrap):
If the type of an index is larger than the pointer index type, thetruncation to the pointer index type preserves the signed value(truncnsw).
The multiplication of an index by the type size does not wrap the pointerindex type in a signed sense (mulnsw).
The successive addition of each offset (without adding the base address)does not wrap the pointer index type in a signed sense (addnsw).
The successive addition of the current address, truncated to the pointerindex type and interpreted as an unsigned number, and each offset,interpreted as a signed number, does not wrap the pointer index type.
For nuw (no unsigned wrap):
If the type of an index is larger than the pointer index type, thetruncation to the pointer index type preserves the unsigned value(truncnuw).
The multiplication of an index by the type size does not wrap the pointerindex type in an unsigned sense (mulnuw).
The successive addition of each offset (without adding the base address)does not wrap the pointer index type in an unsigned sense (addnuw).
The successive addition of the current address, truncated to the pointerindex type and interpreted as an unsigned number, and each offset, alsointerpreted as an unsigned number, does not wrap the pointer index type(addnuw).
For inbounds all rules of the nusw attribute apply. Additionally,if the getelementptr has any non-zero indices, the following rules apply:
The base pointer has an in bounds address of the allocated object that itis based on. This means that it points into thatallocated object, or to its end. Note that the object does not have to belive anymore; being in-bounds of a deallocated object is sufficient.
During the successive addition of offsets to the address, the resultingpointer must remain in bounds of the allocated object at each step.
Note that getelementptr with all-zero indices is always considered to beinbounds, even if the base pointer does not point to an allocated object.As a corollary, the only pointer in bounds of the null pointer in the defaultaddress space is the null pointer itself.
These rules are based on the assumption that no allocated object may crossthe unsigned address space boundary, and no allocated object may be largerthan half the pointer index type space.
If inbounds is present on a getelementptr instruction, the nuswattribute will be automatically set as well. For this reason, the nuswwill also not be printed in textual IR if inbounds is already present.
If the inrange(Start,End) attribute is present, loading from orstoring to any pointer derived from the getelementptr has undefinedbehavior if the load or store would access memory outside the half-open range[Start,End) from the getelementptr expression result. The result ofa pointer comparison or ptrtoint (including ptrtoint-like operationsinvolving memory) involving a pointer derived from a getelementptr withthe inrange keyword is undefined, with the exception of comparisonsin the case where both operands are in the closed range [Start,End].Note that the inrange keyword is currently only allowedin constant getelementptr expressions.
The getelementptr instruction is often confusing. For some more insightinto how it works, see the getelementptr FAQ.
The getelementptr returns a vector of pointers, instead of a single address,when one or more of its arguments is a vector. In such cases, all vectorarguments should have the same number of elements, and every scalar argumentwill be effectively broadcast into a vector during address calculation.
; All arguments are vectors:; A[i] = ptrs[i] + offsets[i]*sizeof(i8)%A=getelementptri8,<4xi8*>%ptrs,<4xi64>%offsets; Add the same scalar offset to each pointer of a vector:; A[i] = ptrs[i] + offset*sizeof(i8)%A=getelementptri8,<4xptr>%ptrs,i64%offset; Add distinct offsets to the same pointer:; A[i] = ptr + offsets[i]*sizeof(i8)%A=getelementptri8,ptr%ptr,<4xi64>%offsets; In all cases described above the type of the result is <4 x ptr>
Let’s look at the C code, where the vector version of getelementptrmakes sense:
// Let's assume that we vectorize the following loop:double*A,*B;int*C;for(inti=0;i<size;++i){A[i]=B[C[i]];}
; get pointers for 8 elements from array B%ptrs=getelementptrdouble,ptr%B,<8xi32>%C; load 8 elements from array B into A%A=call<8xdouble>@llvm.masked.gather.v8f64.v8p0f64(<8xptr>%ptrs,i328,<8xi1>%mask,<8xdouble>%passthru)
The ‘getelementptr’ instruction is used to get the address of a
+subelement of an aggregate data structure. It performs
+address calculation only and does not access memory. The instruction can also
+be used to calculate a vector of such addresses.
+
+
+
Arguments:
+
The first argument is always a type used as the basis for the calculations.
+The second argument is always a pointer or a vector of pointers, and is the
+base address to start from. The remaining arguments are indices
+that indicate which of the elements of the aggregate object are indexed.
+The interpretation of each index is dependent on the type being indexed
+into. The first index always indexes the pointer value given as the
+second argument, the second index indexes a value of the type pointed to
+(not necessarily the value directly pointed to, since the first index
+can be non-zero), etc. The first type indexed into must be a pointer
+value, subsequent types can be arrays, vectors, and structs. Note that
+subsequent types being indexed into can never be pointers, since that
+would require loading the pointer before continuing calculation.
+
The type of each index argument depends on the type it is indexing into.
+When indexing into a (optionally packed) structure, only i32 integer
+constants are allowed (when using a vector of indices they must all
+be the samei32 integer constant). When indexing into an array,
+pointer or vector, integers of any width are allowed, and they are not
+required to be constant. These integers are treated as signed values
+where relevant.
+
For example, let’s consider a C code fragment and how it gets compiled
+to LLVM:
In the example above, the first index is indexing into the
+‘%struct.ST*’ type, which is a pointer, yielding a ‘%struct.ST’
+= ‘{i32,double,%struct.RT}’ type, a structure. The second index
+indexes into the third element of the structure, yielding a
+‘%struct.RT’ = ‘{i8,[10x[20xi32]],i8}’ type, another
+structure. The third index indexes into the second element of the
+structure, yielding a ‘[10x[20xi32]]’ type, an array. The two
+dimensions of the array are subscripted into, yielding an ‘i32’
+type. The ‘getelementptr’ instruction returns a pointer to this
+element.
+
Note that it is perfectly legal to index partially through a structure,
+returning a pointer to an inner element. Because of this, the LLVM code
+for the given testcase is equivalent to:
The indices are first converted to offsets in the pointer’s index type. If the
+currently indexed type is a struct type, the struct offset corresponding to the
+index is sign-extended or truncated to the pointer index type. Otherwise, the
+index itself is sign-extended or truncated, and then multiplied by the type
+allocation size (that is, the size rounded up to the ABI alignment) of the
+currently indexed type.
+
The offsets are then added to the low bits of the base address up to the index
+type width, with silently-wrapping two’s complement arithmetic. If the pointer
+size is larger than the index size, this means that the bits outside the index
+type width will not be affected.
+
The result value of the getelementptr may be outside the object pointed
+to by the base pointer. The result value may not necessarily be used to access
+memory though, even if it happens to point into allocated storage. See the
+Pointer Aliasing Rules section for more
+information.
+
The getelementptr instruction may have a number of attributes that impose
+additional rules. If any of the rules are violated, the result value is a
+poison value. In cases where the base is a vector of
+pointers, the attributes apply to each computation element-wise.
+
For nusw (no unsigned signed wrap):
+
+
+
If the type of an index is larger than the pointer index type, the
+truncation to the pointer index type preserves the signed value
+(truncnsw).
+
The multiplication of an index by the type size does not wrap the pointer
+index type in a signed sense (mulnsw).
+
The successive addition of each offset (without adding the base address)
+does not wrap the pointer index type in a signed sense (addnsw).
+
The successive addition of the current address, truncated to the pointer
+index type and interpreted as an unsigned number, and each offset,
+interpreted as a signed number, does not wrap the pointer index type.
+
+
+
For nuw (no unsigned wrap):
+
+
+
If the type of an index is larger than the pointer index type, the
+truncation to the pointer index type preserves the unsigned value
+(truncnuw).
+
The multiplication of an index by the type size does not wrap the pointer
+index type in an unsigned sense (mulnuw).
+
The successive addition of each offset (without adding the base address)
+does not wrap the pointer index type in an unsigned sense (addnuw).
+
The successive addition of the current address, truncated to the pointer
+index type and interpreted as an unsigned number, and each offset, also
+interpreted as an unsigned number, does not wrap the pointer index type
+(addnuw).
+
+
+
For inbounds all rules of the nusw attribute apply. Additionally,
+if the getelementptr has any non-zero indices, the following rules apply:
+
+
+
The base pointer has an in bounds address of the
+allocated object that it is
+based on. This means that it points into that
+allocated object, or to its end. Note that the object does not have to be
+live anymore; being in-bounds of a deallocated object is sufficient.
+If the allocated object can grow, then the relevant size for being in
+bounds is the maximal size the object could have while satisfying the
+allocated object rules, not its current size.
+
During the successive addition of offsets to the address, the resulting
+pointer must remain in bounds of the allocated object at each step.
+
+
+
Note that getelementptr with all-zero indices is always considered to be
+inbounds, even if the base pointer does not point to an allocated object.
+As a corollary, the only pointer in bounds of the null pointer in the default
+address space is the null pointer itself.
+
If inbounds is present on a getelementptr instruction, the nusw
+attribute will be automatically set as well. For this reason, the nusw
+will also not be printed in textual IR if inbounds is already present.
+
If the inrange(Start,End) attribute is present, loading from or
+storing to any pointer derived from the getelementptr has undefined
+behavior if the load or store would access memory outside the half-open range
+[Start,End) from the getelementptr expression result. The result of
+a pointer comparison or ptrtoint (including ptrtoint-like operations
+involving memory) involving a pointer derived from a getelementptr with
+the inrange keyword is undefined, with the exception of comparisons
+in the case where both operands are in the closed range [Start,End].
+Note that the inrange keyword is currently only allowed
+in constant getelementptr expressions.
+
The getelementptr instruction is often confusing. For some more insight
+into how it works, see the getelementptr FAQ.
The getelementptr returns a vector of pointers, instead of a single address,
+when one or more of its arguments is a vector. In such cases, all vector
+arguments should have the same number of elements, and every scalar argument
+will be effectively broadcast into a vector during address calculation.
+
; All arguments are vectors:
+; A[i] = ptrs[i] + offsets[i]*sizeof(i8)
+%A=getelementptri8,<4xi8*>%ptrs,<4xi64>%offsets
+
+; Add the same scalar offset to each pointer of a vector:
+; A[i] = ptrs[i] + offset*sizeof(i8)
+%A=getelementptri8,<4xptr>%ptrs,i64%offset
+
+; Add distinct offsets to the same pointer:
+; A[i] = ptr + offsets[i]*sizeof(i8)
+%A=getelementptri8,ptr%ptr,<4xi64>%offsets
+
+; In all cases described above the type of the result is <4 x ptr>
+
Let’s look at the C code, where the vector version of getelementptr
+makes sense:
+
// Let's assume that we vectorize the following loop:
+double*A,*B;int*C;
+for(inti=0;i<size;++i){
+A[i]=B[C[i]];
+}
+
+
+
; get pointers for 8 elements from array B
+%ptrs=getelementptrdouble,ptr%B,<8xi32>%C
+; load 8 elements from array B into A
+%A=call<8xdouble>@llvm.masked.gather.v8f64.v8p0f64(
+<8xptr>align8%ptrs,<8xi1>%mask,<8xdouble>%passthru)
+
+
+
+`,
tooltip: `The ‘getelementptr’ instruction is used to get the address of asubelement of an aggregate data structure. It performsaddress calculation only and does not access memory. The instruction can alsobe used to calculate a vector of such addresses.`,
};
- case 'TRUNC-TO':
+ case 'TRUNC':
return {
url: `https://llvm.org/docs/LangRef.html#trunc-to-instruction`,
- html: `
The ‘trunc’ instruction truncates its operand to the type ty2.
Arguments:
The ‘trunc’ instruction takes a value to trunc, and a type to truncit to. Both types must be of integer types, or vectorsof the same number of integers. The bit size of the value must belarger than the bit size of the destination type, ty2. Equal sizedtypes are not allowed.
Semantics:
The ‘trunc’ instruction truncates the high order bits in valueand converts the remaining bits to ty2. Since the source size mustbe larger than the destination size, trunc cannot be a no-op cast.It will always truncate bits.
If the nuw keyword is present, and any of the truncated bits are non-zero,the result is a poison value. If the nsw keywordis present, and any of the truncated bits are not the same as the top bitof the truncation result, the result is a poison value.
The ‘trunc’ instruction truncates its operand to the type ty2.
+
+
+
Arguments:
+
The ‘trunc’ instruction takes a value to trunc, and a type to trunc
+it to. Both types must be of integer types, or vectors
+of the same number of integers. The bit size of the value must be
+larger than the bit size of the destination type, ty2. Equal sized
+types are not allowed.
+
+
+
Semantics:
+
The ‘trunc’ instruction truncates the high order bits in value
+and converts the remaining bits to ty2. Since the source size must
+be larger than the destination size, trunc cannot be a no-op cast.
+It will always truncate bits.
+
If the nuw keyword is present, and any of the truncated bits are non-zero,
+the result is a poison value. If the nsw keyword
+is present, and any of the truncated bits are not the same as the top bit
+of the truncation result, the result is a poison value.
+
+`,
tooltip: `The ‘trunc’ instruction truncates its operand to the type ty2.`,
};
- case 'ZEXT-TO':
+ case 'ZEXT':
return {
url: `https://llvm.org/docs/LangRef.html#zext-to-instruction`,
- html: `
The ‘zext’ instruction zero extends its operand to type ty2.
The nneg (non-negative) flag, if present, specifies that the operand isnon-negative. This property may be used by optimization passes to laterconvert the zext into a sext.
Arguments:
The ‘zext’ instruction takes a value to cast, and a type to cast itto. Both types must be of integer types, or vectors ofthe same number of integers. The bit size of the value must besmaller than the bit size of the destination type, ty2.
Semantics:
The zext fills the high order bits of the value with zero bitsuntil it reaches the size of the destination type, ty2.
When zero extending from i1, the result will always be either 0 or 1.
If the nneg flag is set, and the zext argument is negative, the resultis a poison value.
Example:
%X = zext i32 257 to i64 ; yields i64:257%Y = zext i1 true to i32 ; yields i32:1%Z = zext <2 x i16> <i16 8, i16 7> to <2 x i32> ; yields <i32 8, i32 7>%a = zext nneg i8 127 to i16 ; yields i16 127%b = zext nneg i8 -1 to i16 ; yields i16 poison
The ‘zext’ instruction zero extends its operand to type ty2.
+
The nneg (non-negative) flag, if present, specifies that the operand is
+non-negative. This property may be used by optimization passes to later
+convert the zext into a sext.
+
+
+
Arguments:
+
The ‘zext’ instruction takes a value to cast, and a type to cast it
+to. Both types must be of integer types, or vectors of
+the same number of integers. The bit size of the value must be
+smaller than the bit size of the destination type, ty2.
+
+
+
Semantics:
+
The zext fills the high order bits of the value with zero bits
+until it reaches the size of the destination type, ty2.
+
When zero extending from i1, the result will always be either 0 or 1.
+
If the nneg flag is set, and the zext argument is negative, the result
+is a poison value.
+
+`,
tooltip: `The ‘zext’ instruction zero extends its operand to type ty2.The nneg (non-negative) flag, if present, specifies that the operand isnon-negative. This property may be used by optimization passes to laterconvert the zext into a sext.`,
};
- case 'SEXT-TO':
+ case 'SEXT':
return {
url: `https://llvm.org/docs/LangRef.html#sext-to-instruction`,
- html: `
The ‘sext’ instruction takes a value to cast, and a type to cast itto. Both types must be of integer types, or vectors ofthe same number of integers. The bit size of the value must besmaller than the bit size of the destination type, ty2.
Semantics:
The ‘sext’ instruction performs a sign extension by copying the signbit (highest order bit) of the value until it reaches the bit sizeof the type ty2.
When sign extending from i1, the extension always results in -1 or 0.
The ‘sext’ instruction takes a value to cast, and a type to cast it
+to. Both types must be of integer types, or vectors of
+the same number of integers. The bit size of the value must be
+smaller than the bit size of the destination type, ty2.
+
+
+
Semantics:
+
The ‘sext’ instruction performs a sign extension by copying the sign
+bit (highest order bit) of the value until it reaches the bit size
+of the type ty2.
+
When sign extending from i1, the extension always results in -1 or 0.
+
+`,
tooltip: `The ‘sext’ sign extends value to the type ty2.`,
};
- case 'FPTRUNC-TO':
+ case 'FPTRUNC':
return {
url: `https://llvm.org/docs/LangRef.html#fptrunc-to-instruction`,
- html: `
The ‘fptrunc’ instruction truncates value to type ty2.
Arguments:
The ‘fptrunc’ instruction takes a floating-pointvalue to cast and a floating-point type to cast it to.The size of value must be larger than the size of ty2. Thisimplies that fptrunc cannot be used to make a no-op cast.
NaN values follow the usual NaN behaviors, except that _if_ aNaN payload is propagated from the input (“Quieting NaN propagation” or“Unchanged NaN propagation” cases), then the low order bits of the NaN payloadwhich cannot fit in the resulting type are discarded. Note that if discardingthe low order bits leads to an all-0 payload, this cannot be represented as asignaling NaN (it would represent an infinity instead), so in that case“Unchanged NaN propagation” is not possible.
The ‘fptrunc’ instruction truncates value to type ty2.
+
+
+
Arguments:
+
The ‘fptrunc’ instruction takes a floating-point
+value to cast and a floating-point type to cast it to.
+The size of value must be larger than the size of ty2. This
+implies that fptrunc cannot be used to make a no-op cast.
NaN values follow the usual NaN behaviors, except that _if_ a
+NaN payload is propagated from the input (“Quieting NaN propagation” or
+“Unchanged NaN propagation” cases), then the low order bits of the NaN payload
+which cannot fit in the resulting type are discarded. Note that if discarding
+the low order bits leads to an all-0 payload, this cannot be represented as a
+signaling NaN (it would represent an infinity instead), so in that case
+“Unchanged NaN propagation” is not possible.
+
This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations.
+
+`,
tooltip: `The ‘fptrunc’ instruction truncates value to type ty2.`,
};
- case 'FPEXT-TO':
+ case 'FPEXT':
return {
url: `https://llvm.org/docs/LangRef.html#fpext-to-instruction`,
- html: `
The ‘fpext’ extends a floating-point value to a larger floating-pointvalue.
Arguments:
The ‘fpext’ instruction takes a floating-pointvalue to cast, and a floating-point type to cast itto. The source type must be smaller than the destination type.
Semantics:
The ‘fpext’ instruction extends the value from a smallerfloating-point type to a larger floating-point type. The fpext cannot be used to make ano-op cast because it always changes bits. Use bitcast to make ano-op cast for a floating-point cast.
NaN values follow the usual NaN behaviors, except that _if_ aNaN payload is propagated from the input (“Quieting NaN propagation” or“Unchanged NaN propagation” cases), then it is copied to the high order bits ofthe resulting payload, and the remaining low order bits are zero.
The ‘fpext’ extends a floating-point value to a larger floating-point
+value.
+
+
+
Arguments:
+
The ‘fpext’ instruction takes a floating-point
+value to cast, and a floating-point type to cast it
+to. The source type must be smaller than the destination type.
+
+
+
Semantics:
+
The ‘fpext’ instruction extends the value from a smaller
+floating-point type to a larger floating-point type. The fpext cannot be used to make a
+no-op cast because it always changes bits. Use bitcast to make a
+no-op cast for a floating-point cast.
+
NaN values follow the usual NaN behaviors, except that _if_ a
+NaN payload is propagated from the input (“Quieting NaN propagation” or
+“Unchanged NaN propagation” cases), then it is copied to the high order bits of
+the resulting payload, and the remaining low order bits are zero.
+
This instruction can also take any number of fast-math
+flags, which are optimization hints to enable otherwise
+unsafe floating-point optimizations.
+
+`,
tooltip: `The ‘fpext’ extends a floating-point value to a larger floating-pointvalue.`,
};
- case 'FPTOUI-TO':
+ case 'FPTOUI':
return {
url: `https://llvm.org/docs/LangRef.html#fptoui-to-instruction`,
- html: `
The ‘fptoui’ converts a floating-point value to its unsignedinteger equivalent of type ty2.
Arguments:
The ‘fptoui’ instruction takes a value to cast, which must be ascalar or vector floating-point value, and a type tocast it to ty2, which must be an integer type. Ifty is a vector floating-point type, ty2 must be a vector integertype with the same number of elements as ty
Semantics:
The ‘fptoui’ instruction converts its floating-point operand into the nearest (rounding towards zero)unsigned integer value. If the value cannot fit in ty2, the resultis a poison value.
The ‘fptoui’ converts a floating-point value to its unsigned
+integer equivalent of type ty2.
+
+
+
Arguments:
+
The ‘fptoui’ instruction takes a value to cast, which must be a
+scalar or vector floating-point value, and a type to
+cast it to ty2, which must be an integer type. If
+ty is a vector floating-point type, ty2 must be a vector integer
+type with the same number of elements as ty
+
+
+
Semantics:
+
The ‘fptoui’ instruction converts its floating-point operand into the nearest (rounding towards zero)
+unsigned integer value. If the value cannot fit in ty2, the result
+is a poison value.
+
+`,
tooltip: `The ‘fptoui’ converts a floating-point value to its unsignedinteger equivalent of type ty2.`,
};
- case 'FPTOSI-TO':
+ case 'FPTOSI':
return {
url: `https://llvm.org/docs/LangRef.html#fptosi-to-instruction`,
- html: `
The ‘fptosi’ instruction converts floating-pointvalue to type ty2.
Arguments:
The ‘fptosi’ instruction takes a value to cast, which must be ascalar or vector floating-point value, and a type tocast it to ty2, which must be an integer type. Ifty is a vector floating-point type, ty2 must be a vector integertype with the same number of elements as ty
Semantics:
The ‘fptosi’ instruction converts its floating-point operand into the nearest (rounding towards zero)signed integer value. If the value cannot fit in ty2, the resultis a poison value.
The ‘fptosi’ instruction converts floating-point
+value to type ty2.
+
+
+
Arguments:
+
The ‘fptosi’ instruction takes a value to cast, which must be a
+scalar or vector floating-point value, and a type to
+cast it to ty2, which must be an integer type. If
+ty is a vector floating-point type, ty2 must be a vector integer
+type with the same number of elements as ty
+
+
+
Semantics:
+
The ‘fptosi’ instruction converts its floating-point operand into the nearest (rounding towards zero)
+signed integer value. If the value cannot fit in ty2, the result
+is a poison value.
The ‘uitofp’ instruction regards value as an unsigned integerand converts that value to the ty2 type.
The nneg (non-negative) flag, if present, specifies that theoperand is non-negative. This property may be used by optimizationpasses to later convert the uitofp into a sitofp.
Arguments:
The ‘uitofp’ instruction takes a value to cast, which must be ascalar or vector integer value, and a type to cast it toty2, which must be an floating-point type. Ifty is a vector integer type, ty2 must be a vector floating-pointtype with the same number of elements as ty
Semantics:
The ‘uitofp’ instruction interprets its operand as an unsignedinteger quantity and converts it to the corresponding floating-pointvalue. If the value cannot be exactly represented, it is rounded usingthe default rounding mode.
If the nneg flag is set, and the uitofp argument is negative,the result is a poison value.
Example:
%X = uitofp i32 257 to float ; yields float:257.0%Y = uitofp i8 -1 to double ; yields double:255.0%a = uitofp nneg i32 256 to i32 ; yields float:256.0%b = uitofp nneg i32 -256 to i32 ; yields i32 poison
The ‘uitofp’ instruction regards value as an unsigned integer
+and converts that value to the ty2 type.
+
The nneg (non-negative) flag, if present, specifies that the
+operand is non-negative. This property may be used by optimization
+passes to later convert the uitofp into a sitofp.
+
+
+
Arguments:
+
The ‘uitofp’ instruction takes a value to cast, which must be a
+scalar or vector integer value, and a type to cast it to
+ty2, which must be an floating-point type. If
+ty is a vector integer type, ty2 must be a vector floating-point
+type with the same number of elements as ty
+
+
+
Semantics:
+
The ‘uitofp’ instruction interprets its operand as an unsigned
+integer quantity and converts it to the corresponding floating-point
+value. If the value cannot be exactly represented, it is rounded using
+the default rounding mode.
+
If the nneg flag is set, and the uitofp argument is negative,
+the result is a poison value.
+
+`,
tooltip: `The ‘uitofp’ instruction regards value as an unsigned integerand converts that value to the ty2 type.The nneg (non-negative) flag, if present, specifies that theoperand is non-negative. This property may be used by optimizationpasses to later convert the uitofp into a sitofp.`,
};
- case 'SITOFP-TO':
+ case 'SITOFP':
return {
url: `https://llvm.org/docs/LangRef.html#sitofp-to-instruction`,
- html: `
The ‘sitofp’ instruction regards value as a signed integer andconverts that value to the ty2 type.
Arguments:
The ‘sitofp’ instruction takes a value to cast, which must be ascalar or vector integer value, and a type to cast it toty2, which must be an floating-point type. Ifty is a vector integer type, ty2 must be a vector floating-pointtype with the same number of elements as ty
Semantics:
The ‘sitofp’ instruction interprets its operand as a signed integerquantity and converts it to the corresponding floating-point value. If thevalue cannot be exactly represented, it is rounded using the default roundingmode.
The ‘sitofp’ instruction regards value as a signed integer and
+converts that value to the ty2 type.
+
+
+
Arguments:
+
The ‘sitofp’ instruction takes a value to cast, which must be a
+scalar or vector integer value, and a type to cast it to
+ty2, which must be an floating-point type. If
+ty is a vector integer type, ty2 must be a vector floating-point
+type with the same number of elements as ty
+
+
+
Semantics:
+
The ‘sitofp’ instruction interprets its operand as a signed integer
+quantity and converts it to the corresponding floating-point value. If the
+value cannot be exactly represented, it is rounded using the default rounding
+mode.
+
+`,
tooltip: `The ‘sitofp’ instruction regards value as a signed integer andconverts that value to the ty2 type.`,
};
- case 'PTRTOINT-TO':
+ case 'PTRTOINT':
return {
url: `https://llvm.org/docs/LangRef.html#ptrtoint-to-instruction`,
- html: `
The ‘ptrtoint’ instruction converts the pointer or a vector ofpointers value to the integer (or vector of integers) type ty2.
Arguments:
The ‘ptrtoint’ instruction takes a value to cast, which must bea value of type pointer or a vector of pointers, and atype to cast it to ty2, which must be an integer ora vector of integers type.
Semantics:
The ‘ptrtoint’ instruction converts value to integer typety2 by interpreting the pointer value as an integer and eithertruncating or zero extending that value to the size of the integer type.If value is smaller than ty2 then a zero extension is done. Ifvalue is larger than ty2 then a truncation is done. If they arethe same size, then nothing is done (no-op cast) other than a typechange.
Example:
%X=ptrtointptr%Ptoi8; yields truncation on 32-bit architecture%Y=ptrtointptr%Ptoi64; yields zero extension on 32-bit architecture%Z=ptrtoint<4xptr>%Pto<4xi64>; yields vector zero extension for a vector of addresses on 32-bit architecture
The ‘ptrtoint’ instruction converts the pointer or a vector of
+pointers value to the integer (or vector of integers) type ty2.
+
+
+
Arguments:
+
The ‘ptrtoint’ instruction takes a value to cast, which must be
+a value of type pointer or a vector of pointers, and a
+type to cast it to ty2, which must be an integer or
+a vector of integers type.
+
+
+
Semantics:
+
The ‘ptrtoint’ instruction converts value to integer type
+ty2 by interpreting all the pointer representation bits as an integer
+(equivalent to a bitcast) and either truncating or zero extending that value
+to the size of the integer type.
+If value is smaller than ty2 then a zero extension is done. If
+value is larger than ty2 then a truncation is done. If they are
+the same size, then nothing is done (no-op cast) other than a type
+change.
+The ptrtoint always captures address and provenance
+of the pointer argument.
+
+
+
Example:
+
%X=ptrtointptr%Ptoi8; yields truncation on 32-bit architecture
+%Y=ptrtointptr%Ptoi64; yields zero extension on 32-bit architecture
+%Z=ptrtoint<4xptr>%Pto<4xi64>; yields vector zero extension for a vector of addresses on 32-bit architecture
+
+
+
+`,
tooltip: `The ‘ptrtoint’ instruction converts the pointer or a vector ofpointers value to the integer (or vector of integers) type ty2.`,
};
- case 'INTTOPTR-TO':
+ case 'PTRTOADDR':
+ return {
+ url: `https://llvm.org/docs/LangRef.html#ptrtoaddr-to-instruction`,
+ html: `
The ‘ptrtoaddr’ instruction converts the pointer or a vector of
+pointers value to the underlying integer address (or vector of addresses) of
+type ty2. This is different from ptrtoint in that it
+only operates on the index bits of the pointer and ignores all other bits, and
+does not capture the provenance of the pointer.
+
+
+
Arguments:
+
The ‘ptrtoaddr’ instruction takes a value to cast, which must be
+a value of type pointer or a vector of pointers, and a
+type to cast it to ty2, which must be must be the integer
+type (or vector of integers) matching the pointer index width of the address
+space of ty.
+
+
+
Semantics:
+
The ‘ptrtoaddr’ instruction converts value to integer type ty2 by
+interpreting the lowest index-width pointer representation bits as an integer.
+If the address size and the pointer representation size are the same and
+value and ty2 are the same size, then nothing is done (no-op cast)
+other than a type change.
This example assumes pointers in address space 1 are 64 bits in size with an
+address width of 32 bits (p1:64:64:64:32datalayout string)
+
%X=ptrtoaddrptraddrspace(1)%Ptoi32; extracts low 32 bits of pointer
+%Y=ptrtoaddr<4xptraddrspace(1)>%Pto<4xi32>; yields vector of low 32 bits for each pointer
+
+
+
+`,
+ tooltip: `The ‘ptrtoaddr’ instruction converts the pointer or a vector ofpointers value to the underlying integer address (or vector of addresses) oftype ty2. This is different from ptrtoint in that itonly operates on the index bits of the pointer and ignores all other bits, anddoes not capture the provenance of the pointer.`,
+ };
+ case 'INTTOPTR':
return {
url: `https://llvm.org/docs/LangRef.html#inttoptr-to-instruction`,
- html: `
The ‘inttoptr’ instruction converts an integer value to apointer type, ty2.
Arguments:
The ‘inttoptr’ instruction takes an integer value tocast, and a type to cast it to, which must be a pointertype.
The optional !dereferenceable metadata must reference a single metadataname <deref_bytes_node> corresponding to a metadata node with one i64entry.See dereferenceable metadata.
The optional !dereferenceable_or_null metadata must reference a singlemetadata name <deref_bytes_node> corresponding to a metadata node with onei64 entry.See dereferenceable_or_null metadata.
Semantics:
The ‘inttoptr’ instruction converts value to type ty2 byapplying either a zero extension or a truncation depending on the sizeof the integer value. If value is larger than the size of apointer then a truncation is done. If value is smaller than the sizeof a pointer then a zero extension is done. If they are the same size,nothing is done (no-op cast).
Example:
%X=inttoptri32255toptr; yields zero extension on 64-bit architecture%Y=inttoptri32255toptr; yields no-op on 32-bit architecture%Z=inttoptri640toptr; yields truncation on 32-bit architecture%Z=inttoptr<4xi32>%Gto<4xptr>; yields truncation of vector G to four pointers
The ‘inttoptr’ instruction converts an integer value to a
+pointer type, ty2.
+
+
+
Arguments:
+
The ‘inttoptr’ instruction takes an integer value to
+cast, and a type to cast it to, which must be a pointer
+type.
+
The optional !dereferenceable metadata must reference a single metadata
+name <deref_bytes_node> corresponding to a metadata node with one i64
+entry.
+See dereferenceable metadata.
+
The optional !dereferenceable_or_null metadata must reference a single
+metadata name <deref_bytes_node> corresponding to a metadata node with one
+i64 entry.
+See dereferenceable_or_null metadata.
+
The optional !nofree metadata must reference a single metadata name
+<empty_node> corresponding to a metadata node with no entries.
+The existence of the !nofree metadata on the instruction tells the optimizer
+that the memory pointed by the pointer will not be freed after this point.
+
+
+
Semantics:
+
The ‘inttoptr’ instruction converts value to type ty2 by
+applying either a zero extension or a truncation depending on the size
+of the integer value. If value is larger than the size of a
+pointer then a truncation is done. If value is smaller than the size
+of a pointer then a zero extension is done. If they are the same size,
+nothing is done (no-op cast).
+The behavior is equivalent to a bitcast, however, the resulting value is not
+guaranteed to be dereferenceable (e.g., if the result type is a
+non-integral pointers).
+
+
+
Example:
+
%X=inttoptri32255toptr; yields zero extension on 64-bit architecture
+%Y=inttoptri32255toptr; yields no-op on 32-bit architecture
+%Z=inttoptri640toptr; yields truncation on 32-bit architecture
+%Z=inttoptr<4xi32>%Gto<4xptr>; yields truncation of vector G to four pointers
+
+
+
+`,
tooltip: `The ‘inttoptr’ instruction converts an integer value to apointer type, ty2.`,
};
- case 'BITCAST-TO':
+ case 'BITCAST':
return {
url: `https://llvm.org/docs/LangRef.html#bitcast-to-instruction`,
- html: `
The ‘bitcast’ instruction converts value to type ty2 withoutchanging any bits.
Arguments:
The ‘bitcast’ instruction takes a value to cast, which must be anon-aggregate first class value, and a type to cast it to, which mustalso be a non-aggregate first class type. Thebit sizes of value and the destination type, ty2, must beidentical. If the source type is a pointer, the destination type mustalso be a pointer of the same size. This instruction supports bitwiseconversion of vectors to integers and to vectors of other types (aslong as they have the same size).
Semantics:
The ‘bitcast’ instruction converts value to type ty2. Itis always a no-op cast because no bits change with thisconversion. The conversion is done as if the value had been storedto memory and read back as type ty2. Pointer (or vector ofpointers) types may only be converted to other pointer (or vector ofpointers) types with the same address space through this instruction.To convert pointers to other types, use the inttoptror ptrtoint instructions first.
There is a caveat for bitcasts involving vector types in relation toendianness. For example bitcast<2xi8><value>toi16 puts element zeroof the vector in the least significant bits of the i16 for little-endian whileelement zero ends up in the most significant bits for big-endian.
Example:
%X = bitcast i8 255 to i8 ; yields i8 :-1%Y = bitcast i32* %x to i16* ; yields i16*:%x%Z = bitcast <2 x i32> %V to i64; ; yields i64: %V (depends on endianness)%Z = bitcast <2 x i32*> %V to <2 x i64*> ; yields <2 x i64*>
The ‘bitcast’ instruction converts value to type ty2 without
+changing any bits.
+
+
+
Arguments:
+
The ‘bitcast’ instruction takes a value to cast, which must be a
+non-aggregate first class value, and a type to cast it to, which must
+also be a non-aggregate first class type. The
+bit sizes of value and the destination type, ty2, must be
+identical. If the source type is a pointer, the destination type must
+also be a pointer of the same size. This instruction supports bitwise
+conversion of vectors to integers and to vectors of other types (as
+long as they have the same size).
+
+
+
Semantics:
+
The ‘bitcast’ instruction converts value to type ty2. It
+is always a no-op cast because no bits change with this
+conversion. The conversion is done as if the value had been stored
+to memory and read back as type ty2. Pointer (or vector of
+pointers) types may only be converted to other pointer (or vector of
+pointers) types with the same address space through this instruction.
+To convert pointers to other types, use the inttoptr
+or ptrtoint instructions first.
+
There is a caveat for bitcasts involving vector types in relation to
+endianness. For example bitcast<2xi8><value>toi16 puts element zero
+of the vector in the least significant bits of the i16 for little-endian while
+element zero ends up in the most significant bits for big-endian.
+
+
+
Example:
+
%X = bitcast i8 255 to i8 ; yields i8 :-1
+%Y = bitcast i32* %x to i16* ; yields i16*:%x
+%Z = bitcast <2 x i32> %V to i64; ; yields i64: %V (depends on endianness)
+%Z = bitcast <2 x i32*> %V to <2 x i64*> ; yields <2 x i64*>
+
+
+
+`,
tooltip: `The ‘bitcast’ instruction converts value to type ty2 withoutchanging any bits.`,
};
- case 'ADDRSPACECAST-TO':
+ case 'ADDRSPACECAST':
return {
url: `https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction`,
- html: `
The ‘addrspacecast’ instruction converts ptrval from pty inaddress space n to type pty2 in address space m.
Arguments:
The ‘addrspacecast’ instruction takes a pointer or vector of pointer valueto cast and a pointer type to cast it to, which must have a differentaddress space.
Semantics:
The ‘addrspacecast’ instruction converts the pointer valueptrval to type pty2. It can be a no-op cast or a complexvalue modification, depending on the target and the address spacepair. Pointer conversions within the same address space must beperformed with the bitcast instruction. Note that if the addressspace conversion produces a dereferenceable result then both resultand operand refer to the same memory location. The conversion musthave no side effects, and must not capture the value of the pointer.
If the source is not poison, and both source anddestination are integral pointers, and theresult pointer is dereferenceable, the cast is assumed to bereversible (i.e. casting the result back to the original address spaceshould yield the original bit pattern).
The ‘addrspacecast’ instruction converts ptrval from pty in
+address space n to type pty2 in address space m.
+
+
+
Arguments:
+
The ‘addrspacecast’ instruction takes a pointer or vector of pointer value
+to cast and a pointer type to cast it to, which must have a different
+address space.
+
+
+
Semantics:
+
The ‘addrspacecast’ instruction converts the pointer value
+ptrval to type pty2. It can be a no-op cast or a complex
+value modification, depending on the target and the address space
+pair. Pointer conversions within the same address space must be
+performed with the bitcast instruction. Note that if the address
+space conversion produces a dereferenceable result then both result
+and operand refer to the same memory location. The conversion must
+have no side effects, and must not capture the value of the pointer.
If the source is not poison, and both source and
+destination are integral pointers, and the
+result pointer is dereferenceable, the cast is assumed to be
+reversible (i.e., casting the result back to the original address space
+should yield the original bit pattern).
+
Which address space casts are supported depends on the target. Unsupported
+address space casts return poison.
+
+`,
tooltip: `The ‘addrspacecast’ instruction converts ptrval from pty inaddress space n to type pty2 in address space m.`,
};
case 'ICMP':
return {
url: `https://llvm.org/docs/LangRef.html#icmp-instruction`,
- html: `
The ‘icmp’ instruction returns a boolean value or a vector ofboolean values based on comparison of its two integer, integer vector,pointer, or pointer vector operands.
Arguments:
The ‘icmp’ instruction takes three operands. The first operand isthe condition code indicating the kind of comparison to perform. It isnot a value, just a keyword. The possible condition codes are:
eq: equal
ne: not equal
ugt: unsigned greater than
uge: unsigned greater or equal
ult: unsigned less than
ule: unsigned less or equal
sgt: signed greater than
sge: signed greater or equal
slt: signed less than
sle: signed less or equal
The remaining two arguments must be integer orpointer or integer vector typed. Theymust also be identical types.
Semantics:
The ‘icmp’ compares op1 and op2 according to the conditioncode given as cond. The comparison performed always yields either ani1 or vector of i1 result, as follows:
eq: yields true if the operands are equal, falseotherwise. No sign interpretation is necessary or performed.
ne: yields true if the operands are unequal, falseotherwise. No sign interpretation is necessary or performed.
ugt: interprets the operands as unsigned values and yieldstrue if op1 is greater than op2.
uge: interprets the operands as unsigned values and yieldstrue if op1 is greater than or equal to op2.
ult: interprets the operands as unsigned values and yieldstrue if op1 is less than op2.
ule: interprets the operands as unsigned values and yieldstrue if op1 is less than or equal to op2.
sgt: interprets the operands as signed values and yields trueif op1 is greater than op2.
sge: interprets the operands as signed values and yields trueif op1 is greater than or equal to op2.
slt: interprets the operands as signed values and yields trueif op1 is less than op2.
sle: interprets the operands as signed values and yields trueif op1 is less than or equal to op2.
If the operands are pointer typed, the pointer valuesare compared as if they were integers.
If the operands are integer vectors, then they are compared element byelement. The result is an i1 vector with the same number of elementsas the values being compared. Otherwise, the result is an i1.
The ‘icmp’ instruction returns a boolean value or a vector of
+boolean values based on comparison of its two integer, integer vector,
+pointer, or pointer vector operands.
+
+
+
Arguments:
+
The ‘icmp’ instruction takes three operands. The first operand is
+the condition code indicating the kind of comparison to perform. It is
+not a value, just a keyword. The possible condition codes are:
+
+
eq: equal
+
ne: not equal
+
ugt: unsigned greater than
+
uge: unsigned greater or equal
+
ult: unsigned less than
+
ule: unsigned less or equal
+
sgt: signed greater than
+
sge: signed greater or equal
+
slt: signed less than
+
sle: signed less or equal
+
+
The remaining two arguments must be integer or
+pointer or integer vector typed. They
+must also be identical types.
+
+
+
Semantics:
+
The ‘icmp’ compares op1 and op2 according to the condition
+code given as cond. The comparison performed always yields either an
+i1 or vector of i1 result, as follows:
+
+
eq: yields true if the operands are equal, false
+otherwise. No sign interpretation is necessary or performed.
+
ne: yields true if the operands are unequal, false
+otherwise. No sign interpretation is necessary or performed.
+
ugt: interprets the operands as unsigned values and yields
+true if op1 is greater than op2.
+
uge: interprets the operands as unsigned values and yields
+true if op1 is greater than or equal to op2.
+
ult: interprets the operands as unsigned values and yields
+true if op1 is less than op2.
+
ule: interprets the operands as unsigned values and yields
+true if op1 is less than or equal to op2.
+
sgt: interprets the operands as signed values and yields true
+if op1 is greater than op2.
+
sge: interprets the operands as signed values and yields true
+if op1 is greater than or equal to op2.
+
slt: interprets the operands as signed values and yields true
+if op1 is less than op2.
+
sle: interprets the operands as signed values and yields true
+if op1 is less than or equal to op2.
+
+
If the operands are pointer typed, the pointer values
+are compared as if they were integers.
+
If the operands are integer vectors, then they are compared element by
+element. The result is an i1 vector with the same number of elements
+as the values being compared. Otherwise, the result is an i1.
+
If the samesign keyword is present and the operands are not of the
+same sign then the result is a poison value.
+
+`,
tooltip: `The ‘icmp’ instruction returns a boolean value or a vector ofboolean values based on comparison of its two integer, integer vector,pointer, or pointer vector operands.`,
};
case 'FCMP':
return {
url: `https://llvm.org/docs/LangRef.html#fcmp-instruction`,
- html: `
The ‘fcmp’ instruction returns a boolean value or vector of booleanvalues based on comparison of its operands.
If the operands are floating-point scalars, then the result type is aboolean (i1).
If the operands are floating-point vectors, then the result type is avector of boolean with the same number of elements as the operands beingcompared.
Arguments:
The ‘fcmp’ instruction takes three operands. The first operand isthe condition code indicating the kind of comparison to perform. It isnot a value, just a keyword. The possible condition codes are:
false: no comparison, always returns false
oeq: ordered and equal
ogt: ordered and greater than
oge: ordered and greater than or equal
olt: ordered and less than
ole: ordered and less than or equal
one: ordered and not equal
ord: ordered (no nans)
ueq: unordered or equal
ugt: unordered or greater than
uge: unordered or greater than or equal
ult: unordered or less than
ule: unordered or less than or equal
une: unordered or not equal
uno: unordered (either nans)
true: no comparison, always returns true
Ordered means that neither operand is a QNAN while unordered meansthat either operand may be a QNAN.
Each of val1 and val2 arguments must be either a floating-point type or a vector of floating-point type.They must have identical types.
Semantics:
The ‘fcmp’ instruction compares op1 and op2 according to thecondition code given as cond. If the operands are vectors, then thevectors are compared element by element. Each comparison performedalways yields an i1 result, as follows:
false: always yields false, regardless of operands.
oeq: yields true if both operands are not a QNAN and op1is equal to op2.
ogt: yields true if both operands are not a QNAN and op1is greater than op2.
oge: yields true if both operands are not a QNAN and op1is greater than or equal to op2.
olt: yields true if both operands are not a QNAN and op1is less than op2.
ole: yields true if both operands are not a QNAN and op1is less than or equal to op2.
one: yields true if both operands are not a QNAN and op1is not equal to op2.
ord: yields true if both operands are not a QNAN.
ueq: yields true if either operand is a QNAN or op1 isequal to op2.
ugt: yields true if either operand is a QNAN or op1 isgreater than op2.
uge: yields true if either operand is a QNAN or op1 isgreater than or equal to op2.
ult: yields true if either operand is a QNAN or op1 isless than op2.
ule: yields true if either operand is a QNAN or op1 isless than or equal to op2.
une: yields true if either operand is a QNAN or op1 isnot equal to op2.
uno: yields true if either operand is a QNAN.
true: always yields true, regardless of operands.
The fcmp instruction can also optionally take any number offast-math flags, which are optimization hints to enableotherwise unsafe floating-point optimizations.
Any set of fast-math flags are legal on an fcmp instruction, but theonly flags that have any effect on its semantics are those that allowassumptions to be made about the values of input arguments; namelynnan, ninf, and reassoc. See Fast-Math Flags for more information.
The ‘fcmp’ instruction returns a boolean value or vector of boolean
+values based on comparison of its operands.
+
If the operands are floating-point scalars, then the result type is a
+boolean (i1).
+
If the operands are floating-point vectors, then the result type is a
+vector of boolean with the same number of elements as the operands being
+compared.
+
+
+
Arguments:
+
The ‘fcmp’ instruction takes three operands. The first operand is
+the condition code indicating the kind of comparison to perform. It is
+not a value, just a keyword. The possible condition codes are:
+
+
false: no comparison, always returns false
+
oeq: ordered and equal
+
ogt: ordered and greater than
+
oge: ordered and greater than or equal
+
olt: ordered and less than
+
ole: ordered and less than or equal
+
one: ordered and not equal
+
ord: ordered (no nans)
+
ueq: unordered or equal
+
ugt: unordered or greater than
+
uge: unordered or greater than or equal
+
ult: unordered or less than
+
ule: unordered or less than or equal
+
une: unordered or not equal
+
uno: unordered (either nans)
+
true: no comparison, always returns true
+
+
Ordered means that neither operand is a QNAN while unordered means
+that either operand may be a QNAN.
+
Each of val1 and val2 arguments must be either a floating-point type or a vector of floating-point type.
+They must have identical types.
+
+
+
Semantics:
+
The ‘fcmp’ instruction compares op1 and op2 according to the
+condition code given as cond. If the operands are vectors, then the
+vectors are compared element by element. Each comparison performed
+always yields an i1 result, as follows:
+
+
false: always yields false, regardless of operands.
+
oeq: yields true if both operands are not a QNAN and op1
+is equal to op2.
+
ogt: yields true if both operands are not a QNAN and op1
+is greater than op2.
+
oge: yields true if both operands are not a QNAN and op1
+is greater than or equal to op2.
+
olt: yields true if both operands are not a QNAN and op1
+is less than op2.
+
ole: yields true if both operands are not a QNAN and op1
+is less than or equal to op2.
+
one: yields true if both operands are not a QNAN and op1
+is not equal to op2.
+
ord: yields true if both operands are not a QNAN.
+
ueq: yields true if either operand is a QNAN or op1 is
+equal to op2.
+
ugt: yields true if either operand is a QNAN or op1 is
+greater than op2.
+
uge: yields true if either operand is a QNAN or op1 is
+greater than or equal to op2.
+
ult: yields true if either operand is a QNAN or op1 is
+less than op2.
+
ule: yields true if either operand is a QNAN or op1 is
+less than or equal to op2.
+
une: yields true if either operand is a QNAN or op1 is
+not equal to op2.
+
uno: yields true if either operand is a QNAN.
+
true: always yields true, regardless of operands.
+
+
The fcmp instruction can also optionally take any number of
+fast-math flags, which are optimization hints to enable
+otherwise unsafe floating-point optimizations.
+
Any set of fast-math flags are legal on an fcmp instruction, but the
+only flags that have any effect on its semantics are those that allow
+assumptions to be made about the values of input arguments; namely
+nnan, ninf, and reassoc. See Fast-Math Flags for more information.
+
+`,
tooltip: `The ‘fcmp’ instruction returns a boolean value or vector of booleanvalues based on comparison of its operands.If the operands are floating-point scalars, then the result type is aboolean (i1).If the operands are floating-point vectors, then the result type is avector of boolean with the same number of elements as the operands beingcompared.`,
};
case 'PHI':
return {
url: `https://llvm.org/docs/LangRef.html#phi-instruction`,
- html: `
The ‘phi’ instruction is used to implement the φ node in the SSAgraph representing the function.
Arguments:
The type of the incoming values is specified with the first type field.After this, the ‘phi’ instruction takes a list of pairs asarguments, with one pair for each predecessor basic block of the currentblock. Only values of first class type may be used asthe value arguments to the PHI node. Only labels may be used as thelabel arguments.
There must be no non-phi instructions between the start of a basic blockand the PHI instructions: i.e. PHI instructions must be first in a basicblock.
For the purposes of the SSA form, the use of each incoming value isdeemed to occur on the edge from the corresponding predecessor block tothe current block (but after any definition of an ‘invoke’instruction’s return value on the same edge).
The optional fast-math-flags marker indicates that the phi has oneor more fast-math-flags. These are optimization hintsto enable otherwise unsafe floating-point optimizations. Fast-math-flagsare only valid for phis that return supported floating-point types.
Semantics:
At runtime, the ‘phi’ instruction logically takes on the valuespecified by the pair corresponding to the predecessor basic block thatexecuted just prior to the current block.
Example:
Loop:; Infinite loop that counts from 0 on up...%indvar=phii32[0,%LoopHeader],[%nextindvar,%Loop]%nextindvar=addi32%indvar,1brlabel%Loop
The ‘phi’ instruction is used to implement the φ node in the SSA
+graph representing the function.
+
+
+
Arguments:
+
The type of the incoming values is specified with the first type field.
+After this, the ‘phi’ instruction takes a list of pairs as
+arguments, with one pair for each predecessor basic block of the current
+block. Only values of first class type may be used as
+the value arguments to the PHI node. Only labels may be used as the
+label arguments.
+
There must be no non-phi instructions between the start of a basic block
+and the PHI instructions: i.e., PHI instructions must be first in a basic
+block.
+
For the purposes of the SSA form, the use of each incoming value is
+deemed to occur on the edge from the corresponding predecessor block to
+the current block (but after any definition of an ‘invoke’
+instruction’s return value on the same edge).
+
The optional fast-math-flags marker indicates that the phi has one
+or more fast-math-flags. These are optimization hints
+to enable otherwise unsafe floating-point optimizations. Fast-math-flags
+are only valid for phis that return supported floating-point types.
+
+
+
Semantics:
+
At runtime, the ‘phi’ instruction logically takes on the value
+specified by the pair corresponding to the predecessor basic block that
+executed just prior to the current block.
+
+
+
Example:
+
Loop:; Infinite loop that counts from 0 on up...
+%indvar=phii32[0,%LoopHeader],[%nextindvar,%Loop]
+%nextindvar=addi32%indvar,1
+brlabel%Loop
+
+
+
+`,
tooltip: `The ‘phi’ instruction is used to implement the φ node in the SSAgraph representing the function.`,
};
case 'SELECT':
return {
url: `https://llvm.org/docs/LangRef.html#select-instruction`,
- html: `
The ‘select’ instruction is used to choose one value based on acondition, without IR-level branching.
Arguments:
The ‘select’ instruction requires an ‘i1’ value or a vector of ‘i1’values indicating the condition, and two values of the same firstclass type.
The optional fast-mathflags marker indicates that the select has one or morefast-math flags. These are optimization hints to enableotherwise unsafe floating-point optimizations. Fast-math flags are only validfor selects that return supported floating-point types.
Semantics:
If the condition is an i1 and it evaluates to 1, the instruction returnsthe first value argument; otherwise, it returns the second valueargument.
If the condition is a vector of i1, then the value arguments must bevectors of the same size, and the selection is done element by element.
If the condition is an i1 and the value arguments are vectors of thesame size, then an entire vector is selected.
The ‘select’ instruction is used to choose one value based on a
+condition, without IR-level branching.
+
+
+
Arguments:
+
The ‘select’ instruction requires an ‘i1’ value or a vector of ‘i1’
+values indicating the condition, and two values of the same first
+class type.
+
+
The optional fast-mathflags marker indicates that the select has one or more
+fast-math flags. These are optimization hints to enable
+otherwise unsafe floating-point optimizations. Fast-math flags are only valid
+for selects that return supported floating-point types. Note that the presence of value which would otherwise result
+in poison does not cause the result to be poison if the value is on the non-selected arm.
+If fast-math flags are present, they are only applied to the result,
+not both arms.
+
+
+
+
Semantics:
+
If the condition is an i1 and it evaluates to 1, the instruction returns
+the first value argument; otherwise, it returns the second value
+argument.
+
If the condition is a vector of i1, then the value arguments must be
+vectors of the same size, and the selection is done element by element.
+
If the condition is an i1 and the value arguments are vectors of the
+same size, then an entire vector is selected.
+
+`,
tooltip: `The ‘select’ instruction is used to choose one value based on acondition, without IR-level branching.`,
};
case 'FREEZE':
return {
url: `https://llvm.org/docs/LangRef.html#freeze-instruction`,
- html: `
The ‘freeze’ instruction is used to stop propagation ofundef and poison values.
Arguments:
The ‘freeze’ instruction takes a single argument.
Semantics:
If the argument is undef or poison, ‘freeze’ returns anarbitrary, but fixed, value of type ‘ty’.Otherwise, this instruction is a no-op and returns the input argument.All uses of a value returned by the same ‘freeze’ instruction areguaranteed to always observe the same value, while different ‘freeze’instructions may yield different values.
While undef and poison pointers can be frozen, the result is anon-dereferenceable pointer. See thePointer Aliasing Rules section for more information.If an aggregate value or vector is frozen, the operand is frozen element-wise.The padding of an aggregate isn’t considered, since it isn’t visiblewithout storing it into memory and loading it with a different type.
Example:
%w = i32 undef%x = freeze i32 %w%y = add i32 %w, %w ; undef%z = add i32 %x, %x ; even number because all uses of %x observe ; the same value%x2 = freeze i32 %w%cmp = icmp eq i32 %x, %x2 ; can be true or false; example with vectors%v = <2 x i32> <i32 undef, i32 poison>%a = extractelement <2 x i32> %v, i32 0 ; undef%b = extractelement <2 x i32> %v, i32 1 ; poison%add = add i32 %a, %a ; undef%v.fr = freeze <2 x i32> %v ; element-wise freeze%d = extractelement <2 x i32> %v.fr, i32 0 ; not undef%add.f = add i32 %d, %d ; even number; branching on frozen value%poison = add nsw i1 %k, undef ; poison%c = freeze i1 %poisonbr i1 %c, label %foo, label %bar ; non-deterministic branch to %foo or %bar
The ‘freeze’ instruction is used to stop propagation of
+undef and poison values.
+
+
+
Arguments:
+
The ‘freeze’ instruction takes a single argument.
+
+
+
Semantics:
+
If the argument is undef or poison, ‘freeze’ returns an
+arbitrary, but fixed, value of type ‘ty’.
+Otherwise, this instruction is a no-op and returns the input argument.
+All uses of a value returned by the same ‘freeze’ instruction are
+guaranteed to always observe the same value, while different ‘freeze’
+instructions may yield different values.
+
While undef and poison pointers can be frozen, the result is a
+non-dereferenceable pointer. See the
+Pointer Aliasing Rules section for more information.
+If an aggregate value or vector is frozen, the operand is frozen element-wise.
+The padding of an aggregate isn’t considered, since it isn’t visible
+without storing it into memory and loading it with a different type.
+
+
+
Example:
+
%w = i32 undef
+%x = freeze i32 %w
+%y = add i32 %w, %w ; undef
+%z = add i32 %x, %x ; even number because all uses of %x observe
+ ; the same value
+%x2 = freeze i32 %w
+%cmp = icmp eq i32 %x, %x2 ; can be true or false
+
+; example with vectors
+%v = <2 x i32> <i32 undef, i32 poison>
+%a = extractelement <2 x i32> %v, i32 0 ; undef
+%b = extractelement <2 x i32> %v, i32 1 ; poison
+%add = add i32 %a, %a ; undef
+
+%v.fr = freeze <2 x i32> %v ; element-wise freeze
+%d = extractelement <2 x i32> %v.fr, i32 0 ; not undef
+%add.f = add i32 %d, %d ; even number
+
+; branching on frozen value
+%poison = add nsw i1 %k, undef ; poison
+%c = freeze i1 %poison
+br i1 %c, label %foo, label %bar ; non-deterministic branch to %foo or %bar
+
+
+
+`,
tooltip: `The ‘freeze’ instruction is used to stop propagation ofundef and poison values.`,
};
case 'CALL':
return {
url: `https://llvm.org/docs/LangRef.html#call-instruction`,
- html: `
The ‘call’ instruction represents a simple function call.
Arguments:
This instruction requires several arguments:
The optional tail and musttail markers indicate that the optimizersshould perform tail call optimization. The tail marker is a hint thatcan be ignored. Themusttail marker means that the call must be tail call optimized in orderfor the program to be correct. This is true even in the presence ofattributes like “disable-tail-calls”. The musttail marker provides theseguarantees:
The call will not cause unbounded stack growth if it is part of arecursive cycle in the call graph.
If the musttail call appears in a function with the "thunk" attributeand the caller and callee both have varargs, then any unprototypedarguments in register or memory are forwarded to the callee. Similarly,the return value of the callee is returned to the caller’s caller, evenif a void return type is in use.
Both markers imply that the callee does not access allocas, va_args, orbyval arguments from the caller. As an exception to that, an alloca or byvalargument may be passed to the callee as a byval argument, which can bedereferenced inside the callee. For example:
declare void @take_byval(ptr byval(i64)) declare void @take_ptr(ptr) ; Invalid (assuming @take_ptr dereferences the pointer), because %local ; may be de-allocated before the call to @take_ptr. define void @invalid_alloca() { entry: %local = alloca i64 tail call void @take_ptr(ptr %local) ret void } ; Valid, the byval attribute causes the memory allocated by %local to be ; copied into @take_byval's stack frame. define void @byval_alloca() { entry: %local = alloca i64 tail call void @take_byval(ptr byval(i64) %local) ret void } ; Invalid, because @use_global_va_list uses the variadic arguments from ; @invalid_va_list. %struct.va_list = type { ptr } @va_list = external global %struct.va_list define void @use_global_va_list() { entry: %arg = va_arg ptr @va_list, i64 ret void } define void @invalid_va_list(i32 %a, ...) { entry: call void @llvm.va_start.p0(ptr @va_list) tail call void @use_global_va_list() ret void } ; Valid, byval argument forwarded to tail call as another byval argument. define void @forward_byval(ptr byval(i64) %x) { entry: tail call void @take_byval(ptr byval(i64) %x) ret void } ; Invalid (assuming @take_ptr dereferences the pointer), byval argument ; passed to tail callee as non-byval ptr. define void @invalid_byval(ptr byval(i64) %x) { entry: tail call void @take_ptr(ptr %x) ret void } Calls marked \`\`musttail\`\` must obey the following additional rules: - The call must immediately precede a :ref:\`ret <i_ret>\` instruction, or a pointer bitcast followed by a ret instruction. - The ret instruction must return the (possibly bitcasted) value produced by the call, undef, or void. - The calling conventions of the caller and callee must match. - The callee must be varargs iff the caller is varargs. Bitcasting a non-varargs function to the appropriate varargs type is legal so long as the non-varargs prefixes obey the other rules. - The return type must not undergo automatic conversion to an \`sret\` pointer.In addition, if the calling convention is not \`swifttailcc\` or \`tailcc\`: - All ABI-impacting function attributes, such as sret, byval, inreg, returned, and inalloca, must match. - The caller and callee prototypes must match. Pointer types of parameters or return types may differ in pointee type, but not in address space.On the other hand, if the calling convention is \`swifttailcc\` or \`swiftcc\`: - Only these ABI-impacting attributes attributes are allowed: sret, byval, swiftself, and swiftasync. - Prototypes are not required to match. Tail call optimization for calls marked \`\`tail\`\` is guaranteed to occur if the following conditions are met: - Caller and callee both have the calling convention \`\`fastcc\`\` or \`\`tailcc\`\`. - The call is in tail position (ret immediately follows call and ret uses value of call or is void). - Option \`\`-tailcallopt\`\` is enabled, \`\`llvm::GuaranteedTailCallOpt\`\` is \`\`true\`\`, or the calling convention is \`\`tailcc\`\` - \`Platform-specific constraints are met. <CodeGenerator.html#tail-call-optimization>\`_
The optional notail marker indicates that the optimizers should not addtail or musttail markers to the call. It is used to prevent tailcall optimization from being performed on the call.
The optional fast-mathflags marker indicates that the call has one or morefast-math flags, which are optimization hints to enableotherwise unsafe floating-point optimizations. Fast-math flags are only validfor calls that return supported floating-point types.
The optional “cconv” marker indicates which callingconvention the call should use. If none isspecified, the call defaults to using C calling conventions. Thecalling convention of the call must match the calling convention ofthe target function, or else the behavior is undefined.
The optional Parameter Attributes list for returnvalues. Only ‘zeroext’, ‘signext’, ‘noext’, and ‘inreg’attributes are valid here.
The optional addrspace attribute can be used to indicate the address spaceof the called function. If it is not specified, the program address spacefrom the datalayout string will be used.
‘ty’: the type of the call instruction itself which is also thetype of the return value. Functions that return no value are markedvoid.
‘fnty’: shall be the signature of the function being called. Theargument types must match the types implied by this signature. Thistype can be omitted if the function is not varargs.
‘fnptrval’: An LLVM value containing a pointer to a function tobe called. In most cases, this is a direct function call, butindirect call’s are just as possible, calling an arbitrary pointerto function value.
‘functionargs’: argument list whose types match the functionsignature argument types and parameter attributes. All arguments mustbe of first class type. If the function signatureindicates the function accepts a variable number of arguments, theextra arguments can be specified.
The ‘call’ instruction is used to cause control flow to transfer toa specified function, with its incoming arguments bound to the specifiedvalues. Upon a ‘ret’ instruction in the called function, controlflow continues with the instruction after the function call, and thereturn value of the function is bound to the result argument.
Example:
%retval=calli32@test(i32%argc)calli32(ptr,...)@printf(ptr%msg,i3212,i842); yields i32%X=tailcalli32@foo(); yields i32%Y=tailcallfastcci32@foo(); yields i32callvoid%foo(i8signext97)%struct.A=type{i32,i8}%r=call%struct.A@foo(); yields { i32, i8 }%gr=extractvalue%struct.A%r,0; yields i32%gr1=extractvalue%struct.A%r,1; yields i8%Z=callvoid@foo()noreturn; indicates that %foo never returns normally%ZZ=callzeroexti32@bar(); Return value is %zero extended
llvm treats calls to some functions with names and arguments that matchthe standard C99 library as being the C99 library functions, and mayperform optimizations or generate code for them under that assumption.This is something we’d like to change in the future to provide bettersupport for freestanding environments and non-C-based languages.
The ‘call’ instruction represents a simple function call.
+
+
+
Arguments:
+
This instruction requires several arguments:
+
+
The optional tail and musttail markers indicate that the optimizers
+should perform tail call optimization. The tail marker is a hint that
+can be ignored. The
+musttail marker means that the call must be tail call optimized in order
+for the program to be correct. This is true even in the presence of
+attributes like “disable-tail-calls”. The musttail marker provides these
+guarantees:
+
+
The call will not cause unbounded stack growth if it is part of a
+recursive cycle in the call graph.
If the musttail call appears in a function with the "thunk" attribute
+and the caller and callee both have varargs, then any unprototyped
+arguments in register or memory are forwarded to the callee. Similarly,
+the return value of the callee is returned to the caller’s caller, even
+if a void return type is in use.
+
+
Both markers imply that the callee does not access allocas, va_args, or
+byval arguments from the caller. As an exception to that, an alloca or byval
+argument may be passed to the callee as a byval argument, which can be
+dereferenced inside the callee. For example:
+
declarevoid@take_byval(ptrbyval(i64))
+declarevoid@take_ptr(ptr)
+
+; Invalid (assuming @take_ptr dereferences the pointer), because %local
+; may be de-allocated before the call to @take_ptr.
+definevoid@invalid_alloca(){
+entry:
+%local=allocai64
+tailcallvoid@take_ptr(ptr%local)
+retvoid
+}
+
+; Valid, the byval attribute causes the memory allocated by %local to be
+; copied into @take_byval's stack frame.
+definevoid@byval_alloca(){
+entry:
+%local=allocai64
+tailcallvoid@take_byval(ptrbyval(i64)%local)
+retvoid
+}
+
+; Invalid, because @use_global_va_list uses the variadic arguments from
+; @invalid_va_list.
+%struct.va_list=type{ptr}
+@va_list=externalglobal%struct.va_list
+definevoid@use_global_va_list(){
+entry:
+%arg=va_argptr@va_list,i64
+retvoid
+}
+definevoid@invalid_va_list(i32%a,...){
+entry:
+callvoid@llvm.va_start.p0(ptr@va_list)
+tailcallvoid@use_global_va_list()
+retvoid
+}
+
+; Valid, byval argument forwarded to tail call as another byval argument.
+definevoid@forward_byval(ptrbyval(i64)%x){
+entry:
+tailcallvoid@take_byval(ptrbyval(i64)%x)
+retvoid
+}
+
+; Invalid (assuming @take_ptr dereferences the pointer), byval argument
+; passed to tail callee as non-byval ptr.
+definevoid@invalid_byval(ptrbyval(i64)%x){
+entry:
+tailcallvoid@take_ptr(ptr%x)
+retvoid
+}
+
+
+
Calls marked musttail must obey the following additional rules:
+
+
The call must immediately precede a ret instruction,
+or a pointer bitcast followed by a ret instruction.
+
The ret instruction must return the (possibly bitcasted) value
+produced by the call, undef, or void.
+
The calling conventions of the caller and callee must match.
+
The callee must be varargs iff the caller is varargs. Bitcasting a
+non-varargs function to the appropriate varargs type is legal so
+long as the non-varargs prefixes obey the other rules.
+
The return type must not undergo automatic conversion to an sret pointer.
+
+
In addition, if the calling convention is not swifttailcc or tailcc:
+
+
All ABI-impacting function attributes, such as sret, byval, inreg,
+returned, and inalloca, must match.
+
The caller and callee prototypes must match. Pointer types of parameters
+or return types do not differ in address space.
+
+
On the other hand, if the calling convention is swifttailcc or tailcc:
+
+
Only these ABI-impacting attributes attributes are allowed: sret, byval,
+swiftself, and swiftasync.
+
Prototypes are not required to match.
+
+
Tail call optimization for calls marked tail is guaranteed to occur if
+the following conditions are met:
+
+
Caller and callee both have the calling convention fastcc or tailcc.
+
The call is in tail position (ret immediately follows call and ret
+uses value of call or is void).
+
Option -tailcallopt is enabled, llvm::GuaranteedTailCallOpt is
+true, or the calling convention is tailcc.
The optional notail marker indicates that the optimizers should not add
+tail or musttail markers to the call. It is used to prevent tail
+call optimization from being performed on the call.
+
The optional fast-mathflags marker indicates that the call has one or more
+fast-math flags, which are optimization hints to enable
+otherwise unsafe floating-point optimizations. Fast-math flags are only valid
+for calls that return supported floating-point types.
+
The optional “cconv” marker indicates which calling
+convention the call should use. If none is
+specified, the call defaults to using C calling conventions. The
+calling convention of the call must match the calling convention of
+the target function, or else the behavior is undefined.
+
The optional Parameter Attributes list for return
+values. Only ‘zeroext’, ‘signext’, ‘noext’, and ‘inreg’
+attributes are valid here.
+
The optional addrspace attribute can be used to indicate the address space
+of the called function. If it is not specified, the program address space
+from the datalayout string will be used.
+
‘ty’: the type of the call instruction itself which is also the
+type of the return value. Functions that return no value are marked
+void. The signature is computed based on the return type and argument
+types.
+
‘fnty’: shall be the signature of the function being called. The
+argument types must match the types implied by this signature. This
+is only required if the signature specifies a varargs type.
+
‘fnptrval’: An LLVM value containing a pointer to a function to
+be called. In most cases, this is a direct function call, but
+indirect call’s are just as possible, calling an arbitrary pointer
+to function value.
+
‘functionargs’: argument list whose types match the function
+signature argument types and parameter attributes. All arguments must
+be of first class type. If the function signature
+indicates the function accepts a variable number of arguments, the
+extra arguments can be specified.
The ‘call’ instruction is used to cause control flow to transfer to
+a specified function, with its incoming arguments bound to the specified
+values. Upon a ‘ret’ instruction in the called function, control
+flow continues with the instruction after the function call, and the
+return value of the function is bound to the result argument.
+
If the callee refers to an intrinsic function, the signature of the call must
+match the signature of the callee. Otherwise, if the signature of the call
+does not match the signature of the called function, the behavior is
+target-specific. For a significant mismatch, this likely results in undefined
+behavior. LLVM interprocedural optimizations generally only optimize calls
+where the signature of the caller matches the signature of the callee.
+
Note that it is possible for the signatures to mismatch even if a call appears
+to be a “direct” call, like callvoid@f().
+
+
+
Example:
+
%retval=calli32@test(i32%argc)
+calli32(ptr,...)@printf(ptr%msg,i3212,i842); yields i32
+%X=tailcalli32@foo(); yields i32
+%Y=tailcallfastcci32@foo(); yields i32
+callvoid%foo(i8signext97)
+
+%struct.A=type{i32,i8}
+%r=call%struct.A@foo(); yields { i32, i8 }
+%gr=extractvalue%struct.A%r,0; yields i32
+%gr1=extractvalue%struct.A%r,1; yields i8
+%Z=callvoid@foo()noreturn; indicates that %foo never returns normally
+%ZZ=callzeroexti32@bar(); Return value is %zero extended
+
+
+
llvm treats calls to some functions with names and arguments that match
+the standard C99 library as being the C99 library functions, and may
+perform optimizations or generate code for them under that assumption.
+This is something we’d like to change in the future to provide better
+support for freestanding environments and non-C-based languages.
+
+`,
tooltip: `The ‘call’ instruction represents a simple function call.`,
};
case 'VA-ARG':
return {
url: `https://llvm.org/docs/LangRef.html#va-arg-instruction`,
- html: `
The ‘va_arg’ instruction is used to access arguments passed throughthe “variable argument” area of a function call. It is used to implementthe va_arg macro in C.
Arguments:
This instruction takes a va_list* value and the type of theargument. It returns a value of the specified argument type andincrements the va_list to point to the next argument. The actualtype of va_list is target specific.
Semantics:
The ‘va_arg’ instruction loads an argument of the specified typefrom the specified va_list and causes the va_list to point tothe next argument. For more information, see the variable argumenthandling Intrinsic Functions.
It is legal for this instruction to be called in a function which doesnot take a variable number of arguments, for example, the vfprintffunction.
va_arg is an LLVM instruction instead of an intrinsicfunction because it takes a type as an argument.
Note that the code generator does not yet fully support va_arg on manytargets. Also, it does not currently support va_arg with aggregatetypes on any target.
The ‘va_arg’ instruction is used to access arguments passed through
+the “variable argument” area of a function call. It is used to implement
+the va_arg macro in C.
+
+
+
Arguments:
+
This instruction takes a va_list* value and the type of the
+argument. It returns a value of the specified argument type and
+increments the va_list to point to the next argument. The actual
+type of va_list is target specific.
+
+
+
Semantics:
+
The ‘va_arg’ instruction loads an argument of the specified type
+from the specified va_list and causes the va_list to point to
+the next argument. For more information, see the variable argument
+handling Intrinsic Functions.
+
It is legal for this instruction to be called in a function which does
+not take a variable number of arguments, for example, the vfprintf
+function.
+
va_arg is an LLVM instruction instead of an intrinsic
+function because it takes a type as an argument.
Note that the code generator does not yet fully support va_arg on many
+targets. Also, it does not currently support va_arg with aggregate
+types on any target.
+
+`,
tooltip: `The ‘va_arg’ instruction is used to access arguments passed throughthe “variable argument” area of a function call. It is used to implementthe va_arg macro in C.`,
};
case 'LANDINGPAD':
return {
url: `https://llvm.org/docs/LangRef.html#landingpad-instruction`,
- html: `
The ‘landingpad’ instruction is used by LLVM’s exception handlingsystem to specify that a basic blockis a landing pad — one where the exception lands, and corresponds to thecode found in the catch portion of a try/catch sequence. Itdefines values supplied by the personality function uponre-entry to the function. The resultval has the type resultty.
Arguments:
The optionalcleanup flag indicates that the landing pad block is a cleanup.
A clause begins with the clause type — catch or filter — andcontains the global variable representing the “type” that may be caughtor filtered respectively. Unlike the catch clause, the filterclause takes an array constant as its argument. Use“[0xptr]undef” for a filter which cannot throw. The‘landingpad’ instruction must contain at least one clause orthe cleanup flag.
Semantics:
The ‘landingpad’ instruction defines the values which are set by thepersonality function upon re-entry to the function, andtherefore the “result type” of the landingpad instruction. As withcalling conventions, how the personality function results arerepresented in LLVM IR is target specific.
The clauses are applied in order from top to bottom. If twolandingpad instructions are merged together through inlining, theclauses from the calling function are appended to the list of clauses.When the call stack is being unwound due to an exception being thrown,the exception is compared against each clause in turn. If it doesn’tmatch any of the clauses, and the cleanup flag is not set, thenunwinding continues further up the call stack.
The landingpad instruction has several restrictions:
A landing pad block is a basic block which is the unwind destinationof an ‘invoke’ instruction.
A landing pad block must have a ‘landingpad’ instruction as itsfirst non-PHI instruction.
There can be only one ‘landingpad’ instruction within the landingpad block.
A basic block that is not a landing pad block may not include a‘landingpad’ instruction.
Example:
;; A landing pad which can catch an integer.%res=landingpad{ptr,i32}catchptr@_ZTIi;; A landing pad that is a cleanup.%res=landingpad{ptr,i32}cleanup;; A landing pad which can catch an integer and can only throw a double.%res=landingpad{ptr,i32}catchptr@_ZTIifilter[1xptr][ptr@_ZTId]
The ‘landingpad’ instruction is used by LLVM’s exception handling
+system to specify that a basic block
+is a landing pad — one where the exception lands, and corresponds to the
+code found in the catch portion of a try/catch sequence. It
+defines values supplied by the personality function upon
+re-entry to the function. The resultval has the type resultty.
+
+
+
Arguments:
+
The optional
+cleanup flag indicates that the landing pad block is a cleanup.
+
A clause begins with the clause type — catch or filter — and
+contains the global variable representing the “type” that may be caught
+or filtered respectively. Unlike the catch clause, the filter
+clause takes an array constant as its argument. Use
+“[0xptr]undef” for a filter which cannot throw. The
+‘landingpad’ instruction must contain at least one clause or
+the cleanup flag.
+
+
+
Semantics:
+
The ‘landingpad’ instruction defines the values which are set by the
+personality function upon re-entry to the function, and
+therefore the “result type” of the landingpad instruction. As with
+calling conventions, how the personality function results are
+represented in LLVM IR is target specific.
+
The clauses are applied in order from top to bottom. If two
+landingpad instructions are merged together through inlining, the
+clauses from the calling function are appended to the list of clauses.
+When the call stack is being unwound due to an exception being thrown,
+the exception is compared against each clause in turn. If it doesn’t
+match any of the clauses, and the cleanup flag is not set, then
+unwinding continues further up the call stack.
+
The landingpad instruction has several restrictions:
+
+
A landing pad block is a basic block which is the unwind destination
+of an ‘invoke’ instruction.
+
A landing pad block must have a ‘landingpad’ instruction as its
+first non-PHI instruction.
+
There can be only one ‘landingpad’ instruction within the landing
+pad block.
+
A basic block that is not a landing pad block may not include a
+‘landingpad’ instruction.
+
+
+
+
Example:
+
;; A landing pad which can catch an integer.
+%res=landingpad{ptr,i32}
+catchptr@_ZTIi
+;; A landing pad that is a cleanup.
+%res=landingpad{ptr,i32}
+cleanup
+;; A landing pad which can catch an integer and can only throw a double.
+%res=landingpad{ptr,i32}
+catchptr@_ZTIi
+filter[1xptr][ptr@_ZTId]
+
+
+
+`,
tooltip: `The ‘landingpad’ instruction is used by LLVM’s exception handlingsystem to specify that a basic blockis a landing pad — one where the exception lands, and corresponds to thecode found in the catch portion of a try/catch sequence. Itdefines values supplied by the personality function uponre-entry to the function. The resultval has the type resultty.`,
};
case 'CATCHPAD':
return {
url: `https://llvm.org/docs/LangRef.html#catchpad-instruction`,
- html: `
The ‘catchpad’ instruction is used by LLVM’s exception handlingsystem to specify that a basic blockbegins a catch handler — one where a personality routine attempts to transfercontrol to catch an exception.
Arguments:
The catchswitch operand must always be a token produced by acatchswitch instruction in a predecessor block. Thisensures that each catchpad has exactly one predecessor block, and it alwaysterminates in a catchswitch.
The args correspond to whatever information the personality routinerequires to know if this is an appropriate handler for the exception. Controlwill transfer to the catchpad if this is the first appropriate handler forthe exception.
The resultval has the type token and is used to match thecatchpad to corresponding catchrets and other nested EHpads.
Semantics:
When the call stack is being unwound due to an exception being thrown, theexception is compared against the args. If it doesn’t match, control willnot reach the catchpad instruction. The representation of args isentirely target and personality function-specific.
Like the landingpad instruction, the catchpadinstruction must be the first non-phi of its parent basic block.
When a catchpad has been “entered” but not yet “exited” (asdescribed in the EH documentation),it is undefined behavior to execute a call or invokethat does not carry an appropriate “funclet” bundle.
Example:
dispatch: %cs = catchswitch within none [label %handler0] unwind to caller ;; A catch block which can catch an integer.handler0: %tok = catchpad within %cs [ptr @_ZTIi]
The ‘catchpad’ instruction is used by LLVM’s exception handling
+system to specify that a basic block
+begins a catch handler — one where a personality routine attempts to transfer
+control to catch an exception.
+
+
+
Arguments:
+
The catchswitch operand must always be a token produced by a
+catchswitch instruction in a predecessor block. This
+ensures that each catchpad has exactly one predecessor block, and it always
+terminates in a catchswitch.
+
The args correspond to whatever information the personality routine
+requires to determine if this is an appropriate handler for the exception. Control
+will transfer to the catchpad if this is the first appropriate handler for
+the exception.
+
The resultval has the type token and is used to match the
+catchpad to corresponding catchrets and other nested EH
+pads.
+
+
+
Semantics:
+
When the call stack is being unwound due to an exception being thrown, the
+exception is compared against the args. If it doesn’t match, control will
+not reach the catchpad instruction. The representation of args is
+entirely target and personality function-specific.
+
Like the landingpad instruction, the catchpad
+instruction must be the first non-phi of its parent basic block.
When a catchpad has been “entered” but not yet “exited” (as
+described in the EH documentation),
+it is undefined behavior to execute a call or invoke
+that does not carry an appropriate “funclet” bundle.
+
+
+
Example:
+
dispatch:
+ %cs = catchswitch within none [label %handler0] unwind to caller
+ ;; A catch block which can catch an integer.
+handler0:
+ %tok = catchpad within %cs [ptr @_ZTIi]
+
+
+
+`,
tooltip: `The ‘catchpad’ instruction is used by LLVM’s exception handlingsystem to specify that a basic blockbegins a catch handler — one where a personality routine attempts to transfercontrol to catch an exception.`,
};
case 'CLEANUPPAD':
return {
url: `https://llvm.org/docs/LangRef.html#cleanuppad-instruction`,
- html: `
The ‘cleanuppad’ instruction is used by LLVM’s exception handlingsystem to specify that a basic blockis a cleanup block — one where a personality routine attempts totransfer control to run cleanup actions.The args correspond to whatever additionalinformation the personality function requires toexecute the cleanup.The resultval has the type token and is used tomatch the cleanuppad to corresponding cleanuprets.The parent argument is the token of the funclet that contains thecleanuppad instruction. If the cleanuppad is not inside a funclet,this operand may be the token none.
Arguments:
The instruction takes a list of arbitrary values which are interpretedby the personality function.
Semantics:
When the call stack is being unwound due to an exception being thrown,the personality function transfers control to thecleanuppad with the aid of the personality-specific arguments.As with calling conventions, how the personality function results arerepresented in LLVM IR is target specific.
The cleanuppad instruction has several restrictions:
A cleanup block is a basic block which is the unwind destination ofan exceptional instruction.
A cleanup block must have a ‘cleanuppad’ instruction as itsfirst non-PHI instruction.
There can be only one ‘cleanuppad’ instruction within thecleanup block.
A basic block that is not a cleanup block may not include a‘cleanuppad’ instruction.
When a cleanuppad has been “entered” but not yet “exited” (asdescribed in the EH documentation),it is undefined behavior to execute a call or invokethat does not carry an appropriate “funclet” bundle.
The ‘cleanuppad’ instruction is used by LLVM’s exception handling
+system to specify that a basic block
+is a cleanup block — one where a personality routine attempts to
+transfer control to run cleanup actions.
+The args correspond to whatever additional
+information the personality function requires to
+execute the cleanup.
+The resultval has the type token and is used to
+match the cleanuppad to corresponding cleanuprets.
+The parent argument is the token of the funclet that contains the
+cleanuppad instruction. If the cleanuppad is not inside a funclet,
+this operand may be the token none.
+
+
+
Arguments:
+
The instruction takes a list of arbitrary values which are interpreted
+by the personality function.
+
+
+
Semantics:
+
When the call stack is being unwound due to an exception being thrown,
+the personality function transfers control to the
+cleanuppad with the aid of the personality-specific arguments.
+As with calling conventions, how the personality function results are
+represented in LLVM IR is target specific.
+
The cleanuppad instruction has several restrictions:
+
+
A cleanup block is a basic block which is the unwind destination of
+an exceptional instruction.
+
A cleanup block must have a ‘cleanuppad’ instruction as its
+first non-PHI instruction.
+
There can be only one ‘cleanuppad’ instruction within the
+cleanup block.
+
A basic block that is not a cleanup block may not include a
+‘cleanuppad’ instruction.
+
+
When a cleanuppad has been “entered” but not yet “exited” (as
+described in the EH documentation),
+it is undefined behavior to execute a call or invoke
+that does not carry an appropriate “funclet” bundle.
+
+
+
Example:
+
%tok = cleanuppad within %cs []
+
+
+
+`,
tooltip: `The ‘cleanuppad’ instruction is used by LLVM’s exception handlingsystem to specify that a basic blockis a cleanup block — one where a personality routine attempts totransfer control to run cleanup actions.The args correspond to whatever additionalinformation the personality function requires toexecute the cleanup.The resultval has the type token and is used tomatch the cleanuppad to corresponding cleanuprets.The parent argument is the token of the funclet that contains thecleanuppad instruction. If the cleanuppad is not inside a funclet,this operand may be the token none.`,
};
}
diff --git a/lib/asm-docs/generated/asm-docs-ptx.ts b/lib/asm-docs/generated/asm-docs-ptx.ts
index f319848cdbf..be2f0f26978 100644
--- a/lib/asm-docs/generated/asm-docs-ptx.ts
+++ b/lib/asm-docs/generated/asm-docs-ptx.ts
@@ -3,1334 +3,851 @@ import type {AssemblyInstructionInfo} from '../../../types/assembly-docs.interfa
export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInfo | undefined {
if (!opcode) return;
switch (opcode) {
- case "abs":
+ case "@":
return {
- "html": "For more information, visit abs(fp) , abs(fp16) , abs(int) .
Floating Point Instructions: abs
\n\n\n
Absolute value.
\n
Syntax
\n
\n
abs{.ftz}.f32 d, a;\nabs.f64 d, a;\n
\n
\n
Description
\n
Take the absolute value of a and store the result in d.
\n
Semantics
\n
\n
d = |a|;\n
\n
\n
Notes
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
abs.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
abs.f64 supports subnormal numbers.
\n
abs.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
For abs.f32, NaN input yields unspecified NaN. For abs.f64, NaN input is passed\nthrough unchanged. Future implementations may comply with the IEEE 754 standard by preserving\npayload and modifying only the sign bit.
Take absolute value of a and store the result in d.
\n
For .f16x2 and .bf16x2 instruction type, forms input vector by extracting half word values\nfrom the source operand. Absolute values of half-word operands are then computed in parallel to\nproduce .f16x2 or .bf16x2 result in destination.
\n
For .f16 instruction type, operands d and a have .f16 or .b16 type. For\n.f16x2 instruction type, operands d and a have .f16x2 or .b32 type. For\n.bf16 instruction type, operands d and a have .b16 type. For .bf16x2 instruction\ntype, operands d and a have .b32 type.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n d = |a|;\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = |fA[i]|;\n }\n}\n
\n
\n
Notes
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nabs.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
NaN inputs yield an unspecified NaN. Future implementations may comply with the IEEE 754\nstandard by preserving payload and modifying only the sign bit.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.5.
\n
abs.bf16 and abs.bf16x2 introduced in PTX ISA 7.0.
\n
Target ISA Notes
\n
Requires sm_53 or higher.
\n
abs.bf16 and abs.bf16x2 requires architecture sm_80 or higher.
\n",
- "tooltip": "=====Floating Point Instructions: abs\n\n\n\nAbsolute value.\n\nSyntax\n\nabs{.ftz}.f32 d, a;\n\nabs.f64 d, a;\n\nDescription\n\nTake the absolute value of a and store the result in d.\n\nSemantics\n\nd = |a|;\n\nNotes\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, subnormal numbers are supported.\n\nabs.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.\n\nsm_1x\n\nabs.f64 supports subnormal numbers.\n\nabs.f32 flushes subnormal inputs and results to sign-pr...\n\n=====Half Precision Floating Point Instructions: abs\n\n\n\nAbsolute value\n\nSyntax\n\nabs{.ftz}.f16 d, a;\n\nabs{.ftz}.f16x2 d, a;\n\nabs.bf16 d, a;\n\nabs.bf16x2 d, a;\n\nDescription\n\nTake absolute value of a and store the result in d.\n\nFor .f16x2 and .bf16x2 instruction type, forms input vector by extracting half word values\n\nfrom the source operand. Absolute values of half-word operands are then computed in parallel to\n\nproduce .f16x2 or .bf16x2 result in...\n\n=====Integer Arithmetic Instructions: abs\n\n\n\nAbsolute value.\n\nSyntax\n\nabs.type d, a;\n\n.type = { .s16, .s32, .s64 };\n\nDescription\n\nTake the absolute value of a and store it in d.\n\nSemantics\n\nd = |a|;\n\nNotes\n\nOnly for signed integers.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nabs.s32 r0,a;\n\n... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-abs"
+ "html": "
Execute an instruction or instruction block for threads that have the guard predicate\nTrue. Threads with a False guard predicate do nothing.
\nFor more information, visit abs(int) .",
+ "tooltip": "Absolute value.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-abs"
};
case "activemask":
return {
- "html": "For more information, visit activemask .
Parallel Synchronization and Communication Instructions: activemask
\n\n\n
Queries the active threads within a warp.
\n
Syntax
\n
\n
activemask.b32 d;\n
\n
\n
Description
\n
activemask queries predicated-on active threads from the executing warp and sets the destination\nd with 32-bit integer mask where bit position in the mask corresponds to the thread\u2019s\nlaneid.
\n
Destination d is a 32-bit destination register.
\n
An active thread will contribute 1 for its entry in the result and exited or inactive or\npredicated-off thread will contribute 0 for its entry in the result.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.2.
\n
Target ISA Notes
\n
Requires sm_30 or higher.
\n
Examples
\n
\n
activemask.b32 %r1;\n
\n
\n",
- "tooltip": "Queries the active threads within a warp.\n\nSyntax\n\nactivemask.b32 d;\n\nDescription\n\nactivemask queries predicated-on active threads from the executing warp and sets the destination\n\nd with 32-bit integer mask where bit position in the mask corresponds to the thread\u2019s\n\nlaneid.\n\nDestination d is a 32-bit destination register.\n\nAn active thread will contribute 1 for its entry in the result and exited or inactive or\n\npredicated-off thread will contribute 0 for its entry in the result.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 6.2.\n\nTarget ISA Notes\n\nRequires sm_30 or higher.\n\nExamples\n\nactivemask.b32 %r1;\n\n ...",
+ "html": "
activemask queries predicated-on active threads from the executing warp and sets the destination\nd with 32-bit integer mask where bit position in the mask corresponds to the thread\u2019s\nlaneid.
\nFor more information, visit activemask .",
+ "tooltip": "Queries the active threads within a warp.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-activemask"
};
case "add":
return {
- "html": "For more information, visit add(fp) , add(fp16) , add(int) , add.cc .
Floating Point Instructions: add
\n\n\n
Add two values.
\n
Syntax
\n
\n
add{.rnd}{.ftz}{.sat}.f32 d, a, b;\nadd{.rnd}.f64 d, a, b;\n\n.rnd = { .rn, .rz, .rm, .rp };\n
\n
\n
Description
\n
Performs addition and writes the resulting value into a destination register.
\n
Semantics
\n
\n
d = a + b;\n
\n
\n
Notes
\n
Rounding modifiers:
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
The default value of rounding modifier is .rn. Note that an add instruction with an explicit\nrounding modifier is treated conservatively by the code optimizer. An add instruction with no\nrounding modifier defaults to round-to-nearest-even and may be optimized aggressively by the code\noptimizer. In particular, mul/add sequences with no rounding modifiers may be optimized to\nuse fused-multiply-add instructions on the target device.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
add.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
\n
sm_1x
\n
\n
add.f64 supports subnormal numbers.
\n
add.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
Saturation modifier:
\n
add.sat.f32 clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
add.f32 supported on all target architectures.
\n
add.f64 requires sm_13 or higher.
\n
Rounding modifiers have the following target requirements:
\n
\n
\n.rn, .rz\n
\n
\n
available for all targets
\n
\n
\n.rm, .rp\n
\n
\n
for add.f64, requires sm_13 or higher.
\n
for add.f32, requires sm_20 or higher.
\n
\n
\n
Examples
\n
\n
@p add.rz.ftz.f32 f1,f2,f3;\n
\n
\n\n
Half Precision Floating Point Instructions: add
\n\n\n
Add two values.
\n
Syntax
\n
\n
add{.rnd}{.ftz}{.sat}.f16 d, a, b;\nadd{.rnd}{.ftz}{.sat}.f16x2 d, a, b;\n\nadd{.rnd}.bf16 d, a, b;\nadd{.rnd}.bf16x2 d, a, b;\n\n.rnd = { .rn };\n
\n
\n
Description
\n
Performs addition and writes the resulting value into a destination register.
\n
For .f16x2 and .bf16x2 instruction type, forms input vectors by half word values from source\noperands. Half-word operands are then added in parallel to produce .f16x2 or .bf16x2 result\nin destination.
\n
For .f16 instruction type, operands d, a and b have .f16 or .b16 type. For\n.f16x2 instruction type, operands d, a and b have .b32 type. For .bf16\ninstruction type, operands d, a, b have .b16 type. For .bf16x2 instruction type,\noperands d, a, b have .b32 type.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n d = a + b;\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = fA[i] + fB[i];\n }\n}\n
\n
\n
Notes
\n
Rounding modifiers:
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
\n
The default value of rounding modifier is .rn. Note that an add instruction with an explicit\nrounding modifier is treated conservatively by the code optimizer. An add instruction with no\nrounding modifier defaults to round-to-nearest-even and may be optimized aggressively by the code\noptimizer. In particular, mul/add sequences with no rounding modifiers may be optimized to\nuse fused-multiply-add instructions on the target device.
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nadd.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
Saturation modifier:
\n
\n
add.sat.{f16,f16x2} clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.2.
\n
add{.rnd}.bf16 and add{.rnd}.bf16x2 introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_53 or higher.
\n
add{.rnd}.bf16 and add{.rnd}.bf16x2 requires sm_90 or higher.
\n
Examples
\n
\n
// scalar f16 additions\nadd.f16 d0, a0, b0;\nadd.rn.f16 d1, a1, b1;\nadd.bf16 bd0, ba0, bb0;\nadd.rn.bf16 bd1, ba1, bb1;\n\n// SIMD f16 addition\ncvt.rn.f16.f32 h0, f0;\ncvt.rn.f16.f32 h1, f1;\ncvt.rn.f16.f32 h2, f2;\ncvt.rn.f16.f32 h3, f3;\nmov.b32 p1, {h0, h1}; // pack two f16 to 32bit f16x2\nmov.b32 p2, {h2, h3}; // pack two f16 to 32bit f16x2\nadd.f16x2 p3, p1, p2; // SIMD f16x2 addition\n\n// SIMD bf16 addition\ncvt.rn.bf16x2.f32 p4, f4, f5; // Convert two f32 into packed bf16x2\ncvt.rn.bf16x2.f32 p5, f6, f7; // Convert two f32 into packed bf16x2\nadd.bf16x2 p6, p4, p5; // SIMD bf16x2 addition\n\n// SIMD fp16 addition\nld.global.b32 f0, [addr]; // load 32 bit which hold packed f16x2\nld.global.b32 f1, [addr + 4]; // load 32 bit which hold packed f16x2\nadd.f16x2 f2, f0, f1; // SIMD f16x2 addition\n\nld.global.b32 f3, [addr + 8]; // load 32 bit which hold packed bf16x2\nld.global.b32 f4, [addr + 12]; // load 32 bit which hold packed bf16x2\nadd.bf16x2 f5, f3, f4; // SIMD bf16x2 addition\n
\n
\n\n
Integer Arithmetic Instructions: add
\n\n\n
Add two values.
\n
Syntax
\n
\n
add.type d, a, b;\nadd{.sat}.s32 d, a, b; // .sat applies only to .s32\n\n.type = { .u16, .u32, .u64,\n .s16, .s32, .s64,\n .u16x2, .s16x2 };\n
\n
\n
Description
\n
Performs addition and writes the resulting value into a destination register.
\n
For .u16x2, .s16x2 instruction types, forms input vectors by half word values from source\noperands. Half-word operands are then added in parallel to produce .u16x2, .s16x2 result in\ndestination.
\n
Operands d, a and b have type .type. For instruction types .u16x2, .s16x2,\noperands d, a and b have type .b32.
\n
Semantics
\n
\n
if (type == u16x2 || type == s16x2) {\n iA[0] = a[0:15];\n iA[1] = a[16:31];\n iB[0] = b[0:15];\n iB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = iA[i] + iB[i];\n }\n} else {\n d = a + b;\n}\n
\n
\n
Notes
\n
Saturation modifier:
\n
\n
.sat
\n
\n
limits result to MININT..MAXINT (no overflow) for the size of the operation. Applies only to\n.s32 type.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
add.u16x2 and add.s16x2 introduced in PTX ISA version 8.0.
\n",
- "tooltip": "=====Floating Point Instructions: add\n\n\n\nAdd two values.\n\nSyntax\n\nadd{.rnd}{.ftz}{.sat}.f32 d, a, b;\n\nadd{.rnd}.f64 d, a, b;\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nPerforms addition and writes the resulting value into a destination register.\n\nSemantics\n\nd = a + b;\n\nNotes\n\nRounding modifiers:\n\n.rn\n\nmantissa LSB rounds to nearest even\n\n.rz\n\nmantissa LSB rounds towards zero\n\n.rm\n\nmantissa LSB rounds towards negative infinity\n\n.rp\n\nmantis...\n\n=====Half Precision Floating Point Instructions: add\n\n\n\nAdd two values.\n\nSyntax\n\nadd{.rnd}{.ftz}{.sat}.f16 d, a, b;\n\nadd{.rnd}{.ftz}{.sat}.f16x2 d, a, b;\n\nadd{.rnd}.bf16 d, a, b;\n\nadd{.rnd}.bf16x2 d, a, b;\n\n.rnd = { .rn };\n\nDescription\n\nPerforms addition and writes the resulting value into a destination register.\n\nFor .f16x2 and .bf16x2 instruction type, forms input vectors by half word values from source\n\noperands. Half-word operands are then added in paral...\n\n=====Integer Arithmetic Instructions: add\n\n\n\nAdd two values.\n\nSyntax\n\nadd.type d, a, b;\n\nadd{.sat}.s32 d, a, b; // .sat applies only to .s32\n\n.type = { .u16, .u32, .u64,\n\n .s16, .s32, .s64,\n\n .u16x2, .s16x2 };\n\nDescription\n\nPerforms addition and writes the resulting value into a destination register.\n\nFor .u16x2, .s16x2 instruction types, forms input vectors by half word values from source\n\noperands. Half-word operands are...\n\n=====Extended-Precision Arithmetic Instructions: add.cc\n\n\n\nAdd two values with carry-out.\n\nSyntax\n\nadd.cc.type d, a, b;\n\n.type = { .u32, .s32, .u64, .s64 };\n\nDescription\n\nPerforms integer addition and writes the carry-out value into the condition code register.\n\nSemantics\n\nd = a + b;\n\ncarry-out written to CC.CF\n\nNotes\n\nNo integer rounding modifiers.\n\nNo saturation.\n\nBehavior is the same for unsigned and signed integers.\n\nPTX ISA Notes\n\n32-bit add.cc introduced in PTX ... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-add"
+ "html": "
Performs addition and writes the resulting value into a destination register.
\nFor more information, visit add(int) .",
+ "tooltip": "Add two values.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-add"
};
case "addc":
return {
- "html": "For more information, visit addc .
Extended-Precision Arithmetic Instructions: addc
\n\n\n
Add two values with carry-in and optional carry-out.
\n",
- "tooltip": "Add two values with carry-in and optional carry-out.\n\nSyntax\n\naddc{.cc}.type d, a, b;\n\n.type = { .u32, .s32, .u64, .s64 };\n\nDescription\n\nPerforms integer addition with carry-in and optionally writes the carry-out value into the condition\n\ncode register.\n\nSemantics\n\nd = a + b + CC.CF;\n\nif .cc specified, carry-out written to CC.CF\n\nNotes\n\nNo integer rounding modifiers.\n\nNo saturation.\n\nBehavior is the same for unsigned and signed integers.\n\nPTX ISA Notes\n\n32-bit addc introduced in PTX ISA version 1.2.\n\n64-bit addc introduced in PTX ISA version 4.3.\n\nTarget ISA Notes\n\n32-bit addc is supported on all target architectures.\n\n64-bit addc requires sm_20 or higher.\n\nExamples\n\n@p add.cc.u32 x1,y1,z1; // extended-precision addition of\n\n@p addc.cc.u32 x2,y2,z2; // two 128-bit values\n\n@p addc.cc.u32 x3,y3,z3;\n\n@p addc.u32 x4,y4,z4;\n\n ...",
+ "html": "
Performs integer addition with carry-in and optionally writes the carry-out value into the condition\ncode register.
\nFor more information, visit addc .",
+ "tooltip": "Add two values with carry-in and optional carry-out.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#extended-precision-arithmetic-instructions-addc"
};
- case "address_size":
- return {
- "html": "For more information, visit address_size .
Specifies the address size assumed throughout the module by the PTX code and the binary DWARF\ninformation in PTX.
\n
Redefinition of this directive within a module is not allowed. In the presence of separate\ncompilation all modules must specify (or default to) the same address size.
\n
The .address_size directive is optional, but it must immediately follow the .targetdirective if present within a module.
\n
Semantics
\n
If the .address_size directive is omitted, the address size defaults to 32.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
// example directives\n .address_size 32 // addresses are 32 bit\n .address_size 64 // addresses are 64 bit\n\n// example of directive placement within a module\n .version 2.3\n .target sm_20\n .address_size 64\n...\n.entry foo () {\n...\n}\n
\n
\n",
- "tooltip": "Address size used throughout PTX module.\n\nSyntax\n\n.address_size address-size\n\naddress-size = { 32, 64 };\n\nDescription\n\nSpecifies the address size assumed throughout the module by the PTX code and the binary DWARF\n\ninformation in PTX.\n\nRedefinition of this directive within a module is not allowed. In the presence of separate\n\ncompilation all modules must specify (or default to) the same address size.\n\nThe .address_size directive is optional, but it must immediately follow the .targetdirective if present within a module.\n\nSemantics\n\nIf the .address_size directive is omitted, the address size defaults to 32.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.3.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n// example directives\n\n .address_size 32 // addresses are 32 bit\n\n .address_size 64 // addresses are 64 bit\n\n// example of directive placement within a module\n\n .version 2.3\n\n .target sm_20\n\n .address_size 64\n\n...\n\n.entry foo () {\n\n...\n\n}\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#ptx-module-directives-address-size"
- };
-
- case "aggr_smem_size":
- return {
- "html": "For more information, visit aggr_smem_size .
Special Registers: %aggr_smem_size
\n\n\n
Total size of shared memory used by a CTA of a kernel.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %aggr_smem_size;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with total aggregated size of shared memory\nconsisting of the size of user shared memory allocated (statically and dynamically) at launch time\nand the size of shared memory region which is reserved for the NVIDIA system software use.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.1.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
mov.u32 %r, %aggr_smem_size;\n
\n
\n",
- "tooltip": "Total size of shared memory used by a CTA of a kernel.\n\nSyntax (predefined)\n\n.sreg .u32 %aggr_smem_size;\n\nDescription\n\nA predefined, read-only special register initialized with total aggregated size of shared memory\n\nconsisting of the size of user shared memory allocated (statically and dynamically) at launch time\n\nand the size of shared memory region which is reserved for the NVIDIA system software use.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 8.1.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\nmov.u32 %r, %aggr_smem_size;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-aggr-smem-size"
- };
-
- case "alias":
- return {
- "html": "For more information, visit alias .
Kernel and Function Directives: .alias
\n\n\n
Define an alias to existing function symbol.
\n
Syntax
\n
\n
.alias fAlias, fAliasee;\n
\n
\n
Description
\n
.alias is a module scope directive that defines identifier fAlias to be an alias to function\nspecified by fAliasee.
\n
Both fAlias and fAliasee are non-entry function symbols.
\n
Identifier fAlias is a function declaration without body.
\n
Identifier fAliasee is a function symbol which must be defined in the same module as .alias\ndeclaration. Function fAliasee cannot have .weak linkage.
\n
Prototype of fAlias and fAliasee must match.
\n
Program can use either fAlias or fAlisee identifiers to reference function defined with\nfAliasee.
\n",
- "tooltip": "Define an alias to existing function symbol.\n\nSyntax\n\n.alias fAlias, fAliasee;\n\nDescription\n\n.alias is a module scope directive that defines identifier fAlias to be an alias to function\n\nspecified by fAliasee.\n\nBoth fAlias and fAliasee are non-entry function symbols.\n\nIdentifier fAlias is a function declaration without body.\n\nIdentifier fAliasee is a function symbol which must be defined in the same module as .alias\n\ndeclaration. Function fAliasee cannot have .weak linkage.\n\nPrototype of fAlias and fAliasee must match.\n\nProgram can use either fAlias or fAlisee identifiers to reference function defined with\n\nfAliasee.\n\nPTX ISA Notes\n\n.alias directive introduced in PTX ISA 6.3.\n\nTarget ISA Notes\n\n.alias directive requires sm_30 or higher.\n\nExamples\n\n.visible .func foo(.param .u32 p) {\n\n ...\n\n}\n\n.visible .func bar(.param .u32 p);\n\n.alias bar, foo;\n\n.entry test()\n\n{\n\n .param .u32 p;\n\n ...\n\n call foo, (p); // call foo directly\n\n ...\n\n .param .u32 p;\n\n call bar, (p); // call foo through alias\n\n}\n\n.entry filter ( .param .b32 x, .param .b32 y, .param .b32 z )\n\n{\n\n .reg .b32 %r1, %r2, %r3;\n\n ld.param.b32 %r1, [x];\n\n ld.param.b32 %r2, [y];\n\n ld.param.b32 %r3, [z];\n\n ...\n\n}\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#kernel-and-function-directives-alias"
- };
-
case "alloca":
return {
- "html": "For more information, visit alloca .
The alloca instruction dynamically allocates memory on the stack frame of the current function\nand updates the stack pointer accordingly. The returned pointer ptr points to local memory and\ncan be used in the address operand of ld.local and st.local instructions.
\n
If sufficient memory is unavailable for allocation on the stack, then execution of alloca may\nresult in stack overflow. In such cases, attempting to access the allocated memory with ptr will\nresult in undefined program behavior.
\n
The memory allocated by alloca is deallocated in the following ways:
\n
\n
It is automatically deallocated when the function exits.
\n
It can be explicitly deallocated using stacksave and stackrestore instructions:\nstacksave can be used to save the value of stack pointer before executing alloca, and\nstackrestore can be used after alloca to restore stack pointer to the original value which\nwas previously saved with stacksave. Note that accessing deallocated memory after executing\nstackrestore results in undefined behavior.
\n
\n
size is an unsigned value which specifies the amount of memory in number of bytes to be\nallocated on stack. size=0 may not lead to a valid memory allocation.
\n
Both ptr and size have the same type as the instruction type.
\n
immAlign is a 32-bit value which specifies the alignment requirement in number of bytes for the\nmemory allocated by alloca. It is an integer constant, must be a power of 2 and must not exceed\n2^23. immAlign is an optional argument with default value being 8 which is the minimum\nguaranteed alignment.
\n
Semantics
\n
\n
alloca.type ptr, size, immAlign:\n\na = max(immAlign, frame_align); // frame_align is the minimum guaranteed alignment\n\n// Allocate size bytes of stack memory with alignment a and update the stack pointer.\n// Since the stack grows down, the updated stack pointer contains a lower address.\nstackptr = alloc_stack_mem(size, a);\n\n// Return the new value of stack pointer as ptr. Since ptr is the lowest address of the memory\n// allocated by alloca, the memory can be accessed using ptr up to (ptr + size of allocated memory).\nstacksave ptr;\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.3.
\n
\n
Preview Feature:
\n
\n
alloca is a preview feature in PTX ISA version 7.3. All details are subject to change with no\nguarantees of backward compatibility on future PTX ISA versions or SM architectures.
\n
\n
\n
Target ISA Notes
\n
alloca requires sm_52 or higher.
\n
Examples
\n
\n
.reg .u32 ra, stackptr, ptr, size;\n\nstacksave.u32 stackptr; // Save the current stack pointer\nalloca ptr, size, 8; // Allocate stack memory\nst.local.u32 [ptr], ra; // Use the allocated stack memory\nstackrestore.u32 stackptr; // Deallocate memory by restoring the stack pointer\n
\n
\n",
- "tooltip": "Dynamically allocate memory on stack.\n\nSyntax\n\nalloca.type ptr, size{, immAlign};\n\n.type = { .u32, .u64 };\n\nDescription\n\nThe alloca instruction dynamically allocates memory on the stack frame of the current function\n\nand updates the stack pointer accordingly. The returned pointer ptr points to local memory and\n\ncan be used in the address operand of ld.local and st.local instructions.\n\nIf sufficient memory is unavailable for allocation on the stack, then execution of alloca may\n\nresult in stack overflow. In such cases, attempting to access the allocated memory with ptr will\n\nresult in undefined program behavior.\n\nThe memory allocated by alloca is deallocated in the following ways:\n\nIt is automatically deallocated when the function exits.\n\nIt can be explicitly deallocated using stacksave and stackrestore instructions:\n\nstacksave can be used to save the value of stack pointer before executing alloca, and\n\nstackrestore can be used after alloca to restore stack pointer to the original value which\n\nwas previously saved with stacksave. Note that accessing deallocated memory after executing\n\nstackrestore results in undefined behavior.\n\nsize is an unsigned value which specifies the amount of memory in number of bytes to be\n\nallocated on stack. size = 0 may not lead to a valid memory allocation.\n\nBoth ptr and size have the same type as the instruction type.\n\nimmAlign is a 32-bit value which specifies the alignment requirement in number of bytes for the\n\nmemory allocated by alloca. It is an integer constant, must be a power of 2 and must not exceed\n\n2^23. immAlign is an optional argument with default value being 8 which is the minimum\n\nguaranteed alignment.\n\nSemantics\n\nalloca.type ptr, size, immAlign:\n\na = max(immAlign, frame_align); // frame_align is the minimum guaranteed alignment\n\n// Allocate size bytes of stack memory with alignment a and update the stack pointer.\n\n// Since the stack grows down, the updated stack pointer contains a lower address.\n\nstackptr = alloc_stack_mem(size, a);\n\n// Return the new value of stack pointer as ptr. Since ptr is the lowest address of the memory\n\n// allocated by alloca, the memory can be accessed using ptr up to (ptr + size of allocated memory).\n\nstacksave ptr;\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.3.\n\nPreview Feature:\n\nalloca is a preview feature in PTX ISA version 7.3. All details are subject to change with no\n\nguarantees of backward compatibility on future PTX ISA versions or SM architectures.\n\nTarget ISA Notes\n\nalloca requires sm_52 or higher.\n\nExamples\n\n.reg .u32 ra, stackptr, ptr, size;\n\nstacksave.u32 stackptr; // Save the current stack pointer\n\nalloca ptr, size, 8; // Allocate stack memory\n\nst.local.u32 [ptr], ra; // Use the allocated stack memory\n\nstackrestore.u32 stackptr; // Deallocate memory by restoring the stack pointer\n\n ...",
+ "html": "
The alloca instruction dynamically allocates memory on the stack frame of the current function\nand updates the stack pointer accordingly. The returned pointer ptr points to local memory and\ncan be used in the address operand of ld.local and st.local instructions.
\nFor more information, visit alloca .",
+ "tooltip": "Dynamically allocate memory on stack.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#stack-manipulation-instructions-alloca"
};
case "and":
return {
- "html": "For more information, visit and .
\n",
- "tooltip": "Bitwise AND.\n\nSyntax\n\nand.type d, a, b;\n\n.type = { .pred, .b16, .b32, .b64 };\n\nDescription\n\nCompute the bit-wise and operation for the bits in a and b.\n\nSemantics\n\nd = a & b;\n\nNotes\n\nThe size of the operands must match, but not necessarily the type.\n\nAllowed types include predicate registers.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nand.b32 x,q,r;\n\nand.b32 sign,fpvalue,0x80000000;\n\n ...",
+ "html": "
Compute the bit-wise and operation for the bits in a and b.
\nFor more information, visit and .",
+ "tooltip": "Bitwise AND.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-and"
};
case "applypriority":
return {
- "html": "For more information, visit applypriority .
Data Movement and Conversion Instructions: applypriority
\n\n\n
Apply the cache eviction priority to the specified address in the specified cache level.
The applypriority instruction applies the cache eviction priority specified by the\n.level::eviction_priority qualifier to the address range [a..a+size) in the specified cache\nlevel.
\n
If no state space is specified then Generic Addressing is\nused. If the specified address does not fall within the address window of .global state space\nthen the behavior is undefined.
\n
The operand size is an integer constant that specifies the amount of data, in bytes, in the\nspecified cache level on which the priority is to be applied. The only supported value for the\nsize operand is 128.
\n
Supported addressing modes for operand a are described in Addresses as Operands. a must be aligned to 128 bytes.
\n
If the data pointed to by address a is not already present in the specified cache level, then\nthe data will be prefetched before applying the specified priority.
\n",
- "tooltip": "Apply the cache eviction priority to the specified address in the specified cache level.\n\nSyntax\n\napplypriority{.global}.level::eviction_priority [a], size;\n\n.level::eviction_priority = { .L2::evict_normal };\n\nDescription\n\nThe applypriority instruction applies the cache eviction priority specified by the\n\n.level::eviction_priority qualifier to the address range [a..a+size) in the specified cache\n\nlevel.\n\nIf no state space is specified then Generic Addressing is\n\nused. If the specified address does not fall within the address window of .global state space\n\nthen the behavior is undefined.\n\nThe operand size is an integer constant that specifies the amount of data, in bytes, in the\n\nspecified cache level on which the priority is to be applied. The only supported value for the\n\nsize operand is 128.\n\nSupported addressing modes for operand a are described in Addresses as Operands. a must be aligned to 128 bytes.\n\nIf the data pointed to by address a is not already present in the specified cache level, then\n\nthe data will be prefetched before applying the specified priority.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.4.\n\nTarget ISA Notes\n\nRequires sm_80 or higher.\n\nExamples\n\napplypriority.global.L2::evict_normal [ptr], 128;\n\n ...",
+ "html": "
The applypriority instruction applies the cache eviction priority specified by the\n.level::eviction_priority qualifier to the address range [a..a+size) in the specified cache\nlevel.
\nFor more information, visit applypriority .",
+ "tooltip": "Apply the cache eviction priority to the specified address in the specified cache level.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-applypriority"
};
case "atom":
return {
- "html": "For more information, visit atom .
Parallel Synchronization and Communication Instructions: atom
\n\n\n
Atomic reduction operations for thread-to-thread communication.
Atomically loads the original value at location a into destination register d, performs a\nreduction operation with operand b and the value in location a, and stores the result of the\nspecified operation at location a, overwriting the original value. Operand a specifies a\nlocation in the specified state space. If no state space is given, perform the memory accesses using\nGeneric Addressing. atom with scalar type may be used only\nwith .global and .shared spaces and with generic addressing, where the address points to\n.global or .shared space. atom with vector type may be used only with .global space\nand with generic addressing where the address points to .global space.
\n
For atom with vector type, operands d and b are brace-enclosed vector expressions, size\nof which is equal to the size of vector qualifier.
\n
If no sub-qualifier is specified with .shared state space, then ::cta is assumed by default.
\n
The optional .sem qualifier specifies a memory synchronizing effect as described in the Memory\nConsistency Model. If the .sem qualifier is absent,\n.relaxed is assumed by default.
\n
The optional .scope qualifier specifies the set of threads that can directly observe the memory\nsynchronizing effect of this operation, as described in the Memory Consistency Model. If the .scope qualifier is absent, .gpu scope is\nassumed by default.
\n
For atom with vector type, the supported combinations of vector qualifier and types, and atomic\noperations supported on these combinations are depicted in the following table:
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
Vector qualifier
\n
Types
\n
\n
\n
.f16/ bf16
\n
.f16x2/ bf16x2
\n
.f32
\n
\n\n\n
\n
.v2
\n
.add, .min, .max
\n
.add, .min, .max
\n
.add
\n
\n
\n
.v4
\n
.add, .min, .max
\n
.add, .min, .max
\n
.add
\n
\n
\n
.v8
\n
.add, .min, .max
\n
Not supported
\n
Not Supported
\n
\n\n
\n
Two atomic operations {atom or red} are performed atomically with respect to each other only\nif each operation specifies a scope that includes the other. When this condition is not met, each\noperation observes the other operation being performed as if it were split into a read followed by a\ndependent write.
\n
atom instruction on packed type or vector type, accesses adjacent scalar elements in memory. In\nsuch cases, the atomicity is guaranteed separately for each of the individual scalar elements; the\nentire atom is not guaranteed to be atomic as a single access.
\n
For sm_6x and earlier architectures, atom operations on .shared state space do not\nguarantee atomicity with respect to normal store instructions to the same address. It is the\nprogrammer\u2019s responsibility to guarantee correctness of programs that use shared memory atomic\ninstructions, e.g., by inserting barriers between normal stores and atomic operations to a common\naddress, or by using atom.exch to store to locations accessed by other atomic operations.
\n
Supported addressing modes for operand a and alignment requirements are described in Addresses\nas Operands
\n
The bit-size operations are .and, .or, .xor, .cas (compare-and-swap), and .exch\n(exchange).
\n
The integer operations are .add, .inc, .dec, .min, .max. The .inc and\n.dec operations return a result in the range [0..b].
\n
The floating-point operation .add operation rounds to nearest even. Current implementation of\natom.add.f32 on global memory flushes subnormal inputs and results to sign-preserving zero;\nwhereas atom.add.f32 on shared memory supports subnormal inputs and results and doesn\u2019t flush\nthem to zero.
\n
atom.add.f16, atom.add.f16x2, atom.add.bf16 and atom.add.bf16x2 operation requires\nthe .noftz qualifier; it preserves subnormal inputs and results, and does not flush them to\nzero.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
The qualifier .level::cache_hint is only supported for .global state space and for generic\naddressing where the address points to the .global state space.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
\n",
- "tooltip": "Atomic reduction operations for thread-to-thread communication.\n\nSyntax\n\nAtomic operation with scalar type:\n\natom{.sem}{.scope}{.space}.op{.level::cache_hint}.type d, [a], b{, cache-policy};\n\natom{.sem}{.scope}{.space}.op.type d, [a], b, c;\n\natom{.sem}{.scope}{.space}.cas.b16 d, [a], b, c;\n\natom{.sem}{.scope}{.space}.cas.b128 d, [a], b, c {, cache-policy};\n\natom{.sem}{.scope}{.space}.exch{.level::cache_hint}.b128 d, [a], b {, cache-policy};\n\natom{.sem}{.scope}{.space}.add.noftz{.level::cache_hint}.f16 d, [a], b{, cache-policy};\n\natom{.sem}{.scope}{.space}.add.noftz{.level::cache_hint}.f16x2 d, [a], b{, cache-policy};\n\natom{.sem}{.scope}{.space}.add.noftz{.level::cache_hint}.bf16 d, [a], b{, cache-policy};\n\natom{.sem}{.scope}{.space}.add.noftz{.level::cache_hint}.bf16x2 d, [a], b{, cache-policy};\n\n.space = { .global, .shared{::cta, ::cluster} };\n\n.sem = { .relaxed, .acquire, .release, .acq_rel };\n\n.scope = { .cta, .cluster, .gpu, .sys };\n\n.op = { .and, .or, .xor,\n\n .cas, .exch,\n\n .add, .inc, .dec,\n\n .min, .max };\n\n.level::cache_hint = { .L2::cache_hint };\n\n.type = { .b32, .b64, .u32, .u64, .s32, .s64, .f32, .f64 };\n\nAtomic operation with vector type:\n\natom{.sem}{.scope}{.global}.add{.level::cache_hint}.vec_32_bit.f32 d, [a], b{, cache-policy};\n\natom{.sem}{.scope}{.global}.op.noftz{.level::cache_hint}.vec_16_bit.half_word_type d, [a], b{, cache-policy};\n\natom{.sem}{.scope}{.global}.op.noftz{.level::cache_hint}.vec_32_bit.packed_type d, [a], b{, cache-policy};\n\n.sem = { .relaxed, .acquire, .release, .acq_rel };\n\n.scope = { .cta, .cluster, .gpu, .sys };\n\n.op = { .add, .min, .max };\n\n.half_word_type = { .f16, .bf16 };\n\n.packed_type = { .f16x2, .bf16x2 };\n\n.vec_16_bit = { .v2, .v4, .v8 }\n\n.vec_32_bit = { .v2, .v4 };\n\n.level::cache_hint = { .L2::cache_hint }\n\nDescription\n\nAtomically loads the original value at location a into destination register d, performs a\n\nreduction operation with operand b and the value in location a, and stores the result of the\n\nspecified operation at location a, overwriting the original value. Operand a specifies a\n\nlocation in the specified state space. If no state space is given, perform the memory accesses using\n\nGeneric Addressing. atom with scalar type may be used only\n\nwith .global and .shared spaces and with generic addressing, where the address points to\n\n.global or .shared space. atom with vector type may be used only with .global space\n\nand with generic addressing where the address points to .global space.\n\nFor atom with vector type, operands d and b are brace-enclosed vector expressions, size\n\nof which is equal to the size of vector qualifier.\n\nIf no sub-qualifier is specified with .shared state space, then ::cta is assumed by default.\n\nThe optional .sem qualifier specifies a memory synchronizing effect as described in the Memory\n\nConsistency Model. If the .sem qualifier is absent,\n\n.relaxed is assumed by default.\n\nThe optional .scope qualifier specifies the set of threads that can directly observe the memory\n\nsynchronizing effect of this operation, as described in the Memory Consistency Model. If the .scope qualifier is absent, .gpu scope is\n\nassumed by default.\n\nFor atom with vector type, the supported combinations of vector qualifier and types, and atomic\n\noperations supported on these combinations are depicted in the following table:\n\n\n\n\n\nVector qualifier\n\nTypes\n\n.f16/ bf16\n\n.f16x2/ bf16x2\n\n.f32\n\n\n\n.v2\n\n.add, .min, .max\n\n.add, .min, .max\n\n.add\n\n.v4\n\n.add, .min, .max\n\n.add, .min, .max\n\n.add\n\n.v8\n\n.add, .min, .max\n\nNot supported\n\nNot Supported\n\nTwo atomic operations {atom or red} are performed atomically with respect to each other only\n\nif each operation specifies a scope that includes the other. When this condition is not met, each\n\noperation observes the other operation being performed as if it were split into a read followed by a\n\ndep ...",
+ "html": "
Atomically loads the original value at location a into destination register d, performs a\nreduction operation with operand b and the value in location a, and stores the result of the\nspecified operation at location a, overwriting the original value. Operand a specifies a\nlocation in the specified state space. If no state space is given, perform the memory accesses using\nGeneric Addressing. atom with scalar type may be used only\nwith .global and .shared spaces and with generic addressing, where the address points to\n.global or .shared space. atom with vector type may be used only with .global space\nand with generic addressing where the address points to .global space.
\nFor more information, visit atom .",
+ "tooltip": "Atomic reduction operations for thread-to-thread communication.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-atom"
};
+ case "b4x16":
+ return {
+ "html": "
cp.async.bulk.tensor is a non-blocking instruction which initiates an asynchronous copy\noperation of tensor data from the location in .src state space to the location in the .dst\nstate space.
\nFor more information, visit b4x16 .",
+ "tooltip": "Initiates an asynchronous copy operation on the tensor data from one state space to another.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-tensor-copy"
+ };
+
case "bar":
return {
- "html": "For more information, visit bar , bar.warp.sync .
Parallel Synchronization and Communication Instructions: bar, barrier
Performs barrier synchronization and communication within a CTA. Each CTA instance has sixteen\nbarriers numbered 0..15.
\n
barrier{.cta} instructions can be used by the threads within the CTA for synchronization and\ncommunication.
\n
Operands a, b, and d have type .u32; operands p and c are predicates. Source\noperand a specifies a logical barrier resource as an immediate constant or register with value\n0 through 15. Operand b specifies the number of threads participating in the barrier. If\nno thread count is specified, all threads in the CTA participate in the barrier. When specifying a\nthread count, the value must be a multiple of the warp size. Note that a non-zero thread count is\nrequired for barrier{.cta}.arrive.
\n
Depending on operand b, either specified number of threads (in multiple of warp size) or all\nthreads in the CTA participate in barrier{.cta} instruction. The barrier{.cta} instructions\nsignal the arrival of the executing threads at the named barrier.
\n
barrier{.cta} instruction causes executing thread to wait for all non-exited threads from its\nwarp and marks warps\u2019 arrival at barrier. In addition to signaling its arrival at the barrier, the\nbarrier{.cta}.red and barrier{.cta}.sync instructions causes executing thread to wait for\nnon-exited threads of all other warps participating in the barrier to\narrive. barrier{.cta}.arrive does not cause executing thread to wait for threads of other\nparticipating warps.
\n
When a barrier completes, the waiting threads are restarted without delay, and the barrier is\nreinitialized so that it can be immediately reused.
\n
The barrier{.cta}.sync or barrier{.cta}.red or barrier{.cta}.arrive instruction\nguarantees that when the barrier completes, prior memory accesses requested by this thread are\nperformed relative to all threads participating in the barrier. The barrier{.cta}.sync and\nbarrier{.cta}.red instruction further guarantees that no new memory access is requested by this\nthread before the barrier completes.
\n
A memory read (e.g., by ld or atom) has been performed when the value read has been\ntransmitted from memory and cannot be modified by another thread participating in the barrier. A\nmemory write (e.g., by st, red or atom) has been performed when the value written has\nbecome visible to other threads participating in the barrier, that is, when the previous value can\nno longer be read.
\n
barrier{.cta}.red performs a reduction operation across threads. The c predicate (or its\ncomplement) from all threads in the CTA are combined using the specified reduction operator. Once\nthe barrier count is reached, the final value is written to the destination register in all threads\nwaiting at the barrier.
\n
The reduction operations for barrier{.cta}.red are population-count (.popc),\nall-threads-True (.and), and any-thread-True (.or). The result of .popc is the number of\nthreads with a True predicate, while .and and .or indicate if all the threads had a\nTrue predicate or if any of the threads had a True predicate.
\n
Instruction barrier{.cta} has optional .aligned modifier. When specified, it indicates that\nall threads in CTA will execute the same barrier{.cta} instruction. In conditionally executed\ncode, an aligned barrier{.cta} instruction should only be used if it is known that all threads\nin CTA evaluate the condition identically, otherwise behavior is undefined.
\n
Different warps may execute different forms of the barrier{.cta} instruction using the same\nbarrier name and thread count. One example mixes barrier{.cta}.sync and barrier{.cta}.arrive\nto implement producer/consumer models. The producer threads execute barrier{.cta}.arrive to\nannounce their arrival at the barrier and continue execution without delay to produce the next\nvalue, while the consumer threads execute the barrier{.cta}.sync to wait for a resource to be\nproduced. The roles are then reversed, using a different barrier, where the producer threads execute\na barrier{.cta}.sync to wait for a resource to consumed, while the consumer threads announce\nthat the resource has been consumed with barrier{.cta}.arrive. Care must be taken to keep a warp\nfrom executing more barrier{.cta} instructions than intended (barrier{.cta}.arrive followed\nby any other barrier{.cta} instruction to the same barrier) prior to the reset of the\nbarrier. barrier{.cta}.red should not be intermixed with barrier{.cta}.sync or\nbarrier{.cta}.arrive using the same active barrier. Execution in this case is unpredictable.
\n
The optional .cta qualifier simply indicates CTA-level applicability of the barrier and it\ndoesn\u2019t change the semantics of the instruction.
\n
bar{.cta}.sync is equivalent to barrier{.cta}.sync.aligned. bar{.cta}.arrive is\nequivalent to barrier{.cta}.arrive.aligned. bar{.cta}.red is equivalent to\nbarrier{.cta}.red.aligned.
\n
\n
Note
\n
For .target sm_6x or below,
\n\n
barrier{.cta} instruction without .aligned modifier is equivalent to .aligned\nvariant and has the same restrictions as of .aligned variant.
\n
All threads in warp (except for those have exited) must execute barrier{.cta} instruction\nin convergence.
\n\n
\n
PTX ISA Notes
\n
bar.sync without a thread count introduced in PTX ISA version 1.0.
\n
Register operands, thread count, and bar.{arrive,red} introduced in PTX ISA version 2.0.
\n
barrier instruction introduced in PTX ISA version 6.0.
\n
.cta qualifier introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Register operands, thread count, and bar{.cta}.{arrive,red} require sm_20 or higher.
\n
Only bar{.cta}.sync with an immediate barrier number is supported for sm_1x targets.
\n
barrier{.cta} instruction requires sm_30 or higher.
\n
Examples
\n
\n
// Use bar.sync to arrive at a pre-computed barrier number and\n// wait for all threads in CTA to also arrive:\n st.shared [r0],r1; // write my result to shared memory\n bar.cta.sync 1; // arrive, wait for others to arrive\n ld.shared r2,[r3]; // use shared results from other threads\n\n// Use bar.sync to arrive at a pre-computed barrier number and\n// wait for fixed number of cooperating threads to arrive:\n #define CNT1 (8*12) // Number of cooperating threads\n\n st.shared [r0],r1; // write my result to shared memory\n bar.cta.sync 1, CNT1; // arrive, wait for others to arrive\n ld.shared r2,[r3]; // use shared results from other threads\n\n// Use bar.red.and to compare results across the entire CTA:\n setp.eq.u32 p,r1,r2; // p is True if r1==r2\n bar.cta.red.and.pred r3,1,p; // r3=AND(p) forall threads in CTA\n\n// Use bar.red.popc to compute the size of a group of threads\n// that have a specific condition True:\n setp.eq.u32 p,r1,r2; // p is True if r1==r2\n bar.cta.red.popc.u32 r3,1,p; // r3=SUM(p) forall threads in CTA\n\n/* Producer/consumer model. The producer deposits a value in\n * shared memory, signals that it is complete but does not wait\n * using bar.arrive, and begins fetching more data from memory.\n * Once the data returns from memory, the producer must wait\n * until the consumer signals that it has read the value from\n * the shared memory location. In the meantime, a consumer\n * thread waits until the data is stored by the producer, reads\n * it, and then signals that it is done (without waiting).\n */\n // Producer code places produced value in shared memory.\n st.shared [r0],r1;\n bar.arrive 0,64;\n ld.global r1,[r2];\n bar.sync 1,64;\n ...\n\n // Consumer code, reads value from shared memory\n bar.sync 0,64;\n ld.shared r1,[r0];\n bar.arrive 1,64;\n ...\n\n // Examples of barrier.cta.sync\n st.shared [r0],r1;\n barrier.cta.sync 0;\n ld.shared r1, [r0];\n
\n
\n\n
Parallel Synchronization and Communication Instructions: bar.warp.sync
\n\n\n
Barrier synchronization for threads in a warp.
\n
Syntax
\n
\n
bar.warp.sync membermask;\n
\n
\n
Description
\n
bar.warp.sync will cause executing thread to wait until all threads corresponding to\nmembermask have executed a bar.warp.sync with the same membermask value before resuming\nexecution.
\n
Operand membermask specifies a 32-bit integer which is a mask indicating threads participating\nin barrier where the bit position corresponds to thread\u2019s laneid.
\n
The behavior of bar.warp.sync is undefined if the executing thread is not in the membermask.
\n
bar.warp.sync also guarantee memory ordering among threads participating in barrier. Thus,\nthreads within warp that wish to communicate via memory can store to memory, execute\nbar.warp.sync, and then safely read values stored by other threads in warp.
\n
\n
Note
\n
For .target sm_6x or below, all threads in membermask must execute the same\nbar.warp.sync instruction in convergence, and only threads belonging to some membermask\ncan be active when the bar.warp.sync instruction is executed. Otherwise, the behavior is\nundefined.
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.0.
\n
Target ISA Notes
\n
Requires sm_30 or higher.
\n
Examples
\n
\n
st.shared.u32 [r0],r1; // write my result to shared memory\nbar.warp.sync 0xffffffff; // arrive, wait for others to arrive\nld.shared.u32 r2,[r3]; // read results written by other threads\n
\n
\n",
- "tooltip": "=====Parallel Synchronization and Communication Instructions: bar, barrier\n\n\n\nBarrier synchronization.\n\nSyntax\n\nbarrier{.cta}.sync{.aligned} a{, b};\n\nbarrier{.cta}.arrive{.aligned} a, b;\n\nbarrier{.cta}.red.popc{.aligned}.u32 d, a{, b}, {!}c;\n\nbarrier{.cta}.red.op{.aligned}.pred p, a{, b}, {!}c;\n\nbar{.cta}.sync a{, b};\n\nbar{.cta}.arrive a, b;\n\nbar{.cta}.red.popc.u32 d, a{, b}, {!}c;\n\nbar{.cta}.red.op.pred p, a{, b}, {!}c;\n\n.op = { .and, .or };\n\nDescription\n\nPerform...\n\n=====Parallel Synchronization and Communication Instructions: bar.warp.sync\n\n\n\nBarrier synchronization for threads in a warp.\n\nSyntax\n\nbar.warp.sync membermask;\n\nDescription\n\nbar.warp.sync will cause executing thread to wait until all threads corresponding to\n\nmembermask have executed a bar.warp.sync with the same membermask value before resuming\n\nexecution.\n\nOperand membermask specifies a 32-bit integer which is a mask indicating threads participating\n\nin barrier where the bit... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-bar-barrier"
+ "html": "
Performs barrier synchronization and communication within a CTA. Each CTA instance has sixteen\nbarriers numbered 0..15.
\nFor more information, visit bar .",
+ "tooltip": "Barrier synchronization.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-bar"
};
case "barrier":
return {
- "html": "For more information, visit barrier , barrier.cluster .
Parallel Synchronization and Communication Instructions: bar, barrier
Performs barrier synchronization and communication within a CTA. Each CTA instance has sixteen\nbarriers numbered 0..15.
\n
barrier{.cta} instructions can be used by the threads within the CTA for synchronization and\ncommunication.
\n
Operands a, b, and d have type .u32; operands p and c are predicates. Source\noperand a specifies a logical barrier resource as an immediate constant or register with value\n0 through 15. Operand b specifies the number of threads participating in the barrier. If\nno thread count is specified, all threads in the CTA participate in the barrier. When specifying a\nthread count, the value must be a multiple of the warp size. Note that a non-zero thread count is\nrequired for barrier{.cta}.arrive.
\n
Depending on operand b, either specified number of threads (in multiple of warp size) or all\nthreads in the CTA participate in barrier{.cta} instruction. The barrier{.cta} instructions\nsignal the arrival of the executing threads at the named barrier.
\n
barrier{.cta} instruction causes executing thread to wait for all non-exited threads from its\nwarp and marks warps\u2019 arrival at barrier. In addition to signaling its arrival at the barrier, the\nbarrier{.cta}.red and barrier{.cta}.sync instructions causes executing thread to wait for\nnon-exited threads of all other warps participating in the barrier to\narrive. barrier{.cta}.arrive does not cause executing thread to wait for threads of other\nparticipating warps.
\n
When a barrier completes, the waiting threads are restarted without delay, and the barrier is\nreinitialized so that it can be immediately reused.
\n
The barrier{.cta}.sync or barrier{.cta}.red or barrier{.cta}.arrive instruction\nguarantees that when the barrier completes, prior memory accesses requested by this thread are\nperformed relative to all threads participating in the barrier. The barrier{.cta}.sync and\nbarrier{.cta}.red instruction further guarantees that no new memory access is requested by this\nthread before the barrier completes.
\n
A memory read (e.g., by ld or atom) has been performed when the value read has been\ntransmitted from memory and cannot be modified by another thread participating in the barrier. A\nmemory write (e.g., by st, red or atom) has been performed when the value written has\nbecome visible to other threads participating in the barrier, that is, when the previous value can\nno longer be read.
\n
barrier{.cta}.red performs a reduction operation across threads. The c predicate (or its\ncomplement) from all threads in the CTA are combined using the specified reduction operator. Once\nthe barrier count is reached, the final value is written to the destination register in all threads\nwaiting at the barrier.
\n
The reduction operations for barrier{.cta}.red are population-count (.popc),\nall-threads-True (.and), and any-thread-True (.or). The result of .popc is the number of\nthreads with a True predicate, while .and and .or indicate if all the threads had a\nTrue predicate or if any of the threads had a True predicate.
\n
Instruction barrier{.cta} has optional .aligned modifier. When specified, it indicates that\nall threads in CTA will execute the same barrier{.cta} instruction. In conditionally executed\ncode, an aligned barrier{.cta} instruction should only be used if it is known that all threads\nin CTA evaluate the condition identically, otherwise behavior is undefined.
\n
Different warps may execute different forms of the barrier{.cta} instruction using the same\nbarrier name and thread count. One example mixes barrier{.cta}.sync and barrier{.cta}.arrive\nto implement producer/consumer models. The producer threads execute barrier{.cta}.arrive to\nannounce their arrival at the barrier and continue execution without delay to produce the next\nvalue, while the consumer threads execute the barrier{.cta}.sync to wait for a resource to be\nproduced. The roles are then reversed, using a different barrier, where the producer threads execute\na barrier{.cta}.sync to wait for a resource to consumed, while the consumer threads announce\nthat the resource has been consumed with barrier{.cta}.arrive. Care must be taken to keep a warp\nfrom executing more barrier{.cta} instructions than intended (barrier{.cta}.arrive followed\nby any other barrier{.cta} instruction to the same barrier) prior to the reset of the\nbarrier. barrier{.cta}.red should not be intermixed with barrier{.cta}.sync or\nbarrier{.cta}.arrive using the same active barrier. Execution in this case is unpredictable.
\n
The optional .cta qualifier simply indicates CTA-level applicability of the barrier and it\ndoesn\u2019t change the semantics of the instruction.
\n
bar{.cta}.sync is equivalent to barrier{.cta}.sync.aligned. bar{.cta}.arrive is\nequivalent to barrier{.cta}.arrive.aligned. bar{.cta}.red is equivalent to\nbarrier{.cta}.red.aligned.
\n
\n
Note
\n
For .target sm_6x or below,
\n\n
barrier{.cta} instruction without .aligned modifier is equivalent to .aligned\nvariant and has the same restrictions as of .aligned variant.
\n
All threads in warp (except for those have exited) must execute barrier{.cta} instruction\nin convergence.
\n\n
\n
PTX ISA Notes
\n
bar.sync without a thread count introduced in PTX ISA version 1.0.
\n
Register operands, thread count, and bar.{arrive,red} introduced in PTX ISA version 2.0.
\n
barrier instruction introduced in PTX ISA version 6.0.
\n
.cta qualifier introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Register operands, thread count, and bar{.cta}.{arrive,red} require sm_20 or higher.
\n
Only bar{.cta}.sync with an immediate barrier number is supported for sm_1x targets.
\n
barrier{.cta} instruction requires sm_30 or higher.
\n
Examples
\n
\n
// Use bar.sync to arrive at a pre-computed barrier number and\n// wait for all threads in CTA to also arrive:\n st.shared [r0],r1; // write my result to shared memory\n bar.cta.sync 1; // arrive, wait for others to arrive\n ld.shared r2,[r3]; // use shared results from other threads\n\n// Use bar.sync to arrive at a pre-computed barrier number and\n// wait for fixed number of cooperating threads to arrive:\n #define CNT1 (8*12) // Number of cooperating threads\n\n st.shared [r0],r1; // write my result to shared memory\n bar.cta.sync 1, CNT1; // arrive, wait for others to arrive\n ld.shared r2,[r3]; // use shared results from other threads\n\n// Use bar.red.and to compare results across the entire CTA:\n setp.eq.u32 p,r1,r2; // p is True if r1==r2\n bar.cta.red.and.pred r3,1,p; // r3=AND(p) forall threads in CTA\n\n// Use bar.red.popc to compute the size of a group of threads\n// that have a specific condition True:\n setp.eq.u32 p,r1,r2; // p is True if r1==r2\n bar.cta.red.popc.u32 r3,1,p; // r3=SUM(p) forall threads in CTA\n\n/* Producer/consumer model. The producer deposits a value in\n * shared memory, signals that it is complete but does not wait\n * using bar.arrive, and begins fetching more data from memory.\n * Once the data returns from memory, the producer must wait\n * until the consumer signals that it has read the value from\n * the shared memory location. In the meantime, a consumer\n * thread waits until the data is stored by the producer, reads\n * it, and then signals that it is done (without waiting).\n */\n // Producer code places produced value in shared memory.\n st.shared [r0],r1;\n bar.arrive 0,64;\n ld.global r1,[r2];\n bar.sync 1,64;\n ...\n\n // Consumer code, reads value from shared memory\n bar.sync 0,64;\n ld.shared r1,[r0];\n bar.arrive 1,64;\n ...\n\n // Examples of barrier.cta.sync\n st.shared [r0],r1;\n barrier.cta.sync 0;\n ld.shared r1, [r0];\n
\n
\n\n
Parallel Synchronization and Communication Instructions: barrier.cluster
Performs barrier synchronization and communication within a cluster.
\n
barrier.cluster instructions can be used by the threads within the cluster for synchronization\nand communication.
\n
barrier.cluster.arrive instruction marks warps\u2019 arrival at barrier without causing executing\nthread to wait for threads of other participating warps.
\n
barrier.cluster.wait instruction causes the executing thread to wait for all non-exited threads\nof the cluster to perform barrier.cluster.arrive.
\n
In addition, barrier.cluster instructions cause the executing thread to wait for all non-exited\nthreads from its warp.
\n
When all non-exited threads that executed barrier.cluster.arrive have executed\nbarrier.cluster.wait, the barrier completes and is reinitialized so it can be reused\nimmediately. Each thread must arrive at the barrier only once before the barrier completes.
\n
The barrier.cluster.wait instruction guarantees that when it completes the execution, memory\naccesses (except asynchronous operations) requested, in program order, prior to the preceding\nbarrier.cluster.arrive by all threads in the cluster are complete and visible to the executing\nthread.
\n
There is no memory ordering and visibility guarantee for memory accesses requested by the executing\nthread, in program order, after barrier.cluster.arrive and prior to barrier.cluster.wait.
\n
The optional .relaxed qualifier on barrier.cluster.arrive specifies that there are no memory\nordering and visibility guarantees provided for the memory accesses performed prior to\nbarrier.cluster.arrive.
\n
The optional .sem and .acquire qualifiers on instructions barrier.cluster.arrive and\nbarrier.cluster.wait specify the memory synchronization as described in the Memory Consistency\nModel. If the optional .sem qualifier is absent for\nbarrier.cluster.arrive, .release is assumed by default. If the optional .acquire\nqualifier is absent for barrier.cluster.wait, .acquire is assumed by default.
\n
The optional .aligned qualifier indicates that all threads in the warp must execute the same\nbarrier.cluster instruction. In conditionally executed code, an aligned barrier.cluster\ninstruction should only be used if it is known that all threads in the warp evaluate the condition\nidentically, otherwise behavior is undefined.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.8.
\n
Support for .acquire, .relaxed, .release qualifiers introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
// use of arrive followed by wait\nld.shared::cluster.u32 r0, [addr];\nbarrier.cluster.arrive.aligned;\n...\nbarrier.cluster.wait.aligned;\nst.shared::cluster.u32 [addr], r1;\n\n// use memory fence prior to arrive for relaxed barrier\n@cta0 ld.shared::cluster.u32 r0, [addr];\nfence.cluster.acq_rel;\nbarrier.cluster.arrive.relaxed.aligned;\n...\nbarrier.cluster.wait.aligned;\n@cta1 st.shared::cluster.u32 [addr], r1;\n
\n
\n",
- "tooltip": "=====Parallel Synchronization and Communication Instructions: bar, barrier\n\n\n\nBarrier synchronization.\n\nSyntax\n\nbarrier{.cta}.sync{.aligned} a{, b};\n\nbarrier{.cta}.arrive{.aligned} a, b;\n\nbarrier{.cta}.red.popc{.aligned}.u32 d, a{, b}, {!}c;\n\nbarrier{.cta}.red.op{.aligned}.pred p, a{, b}, {!}c;\n\nbar{.cta}.sync a{, b};\n\nbar{.cta}.arrive a, b;\n\nbar{.cta}.red.popc.u32 d, a{, b}, {!}c;\n\nbar{.cta}.red.op.pred p, a{, b}, {!}c;\n\n.op = { .and, .or };\n\nDescription\n\nPerform...\n\n=====Parallel Synchronization and Communication Instructions: barrier.cluster\n\n\n\nBarrier synchronization within a cluster.\n\nSyntax\n\nbarrier.cluster.arrive{.sem}{.aligned};\n\nbarrier.cluster.wait{.acquire}{.aligned};\n\n.sem = {.release, .relaxed}\n\nDescription\n\nPerforms barrier synchronization and communication within a cluster.\n\nbarrier.cluster instructions can be used by the threads within the cluster for synchronization\n\nand communication.\n\nbarrier.cluster.arrive instruction marks warps... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-bar-barrier"
+ "html": "
Performs barrier synchronization and communication within a cluster.
\nFor more information, visit barrier.cluster .",
+ "tooltip": "Barrier synchronization within a cluster.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-barrier-cluster"
};
case "bfe":
return {
- "html": "For more information, visit bfe(int) .
Extract bit field from a and place the zero or sign-extended result in d. Source b gives\nthe bit field starting bit position, and source c gives the bit field length in bits.
\n
Operands a and d have the same type as the instruction type. Operands b and c are\ntype .u32, but are restricted to the 8-bit value range 0..255.
\n
The sign bit of the extracted field is defined as:
\n
\n
\n.u32, .u64:
\n
\n
zero
\n
\n
\n.s32, .s64:
\n
\n
msb of input a if the extracted field extends beyond the msb of a msb of extracted\nfield, otherwise
\n
\n
\n
If the bit field length is zero, the result is zero.
\n
The destination d is padded with the sign bit of the extracted field. If the start position is\nbeyond the msb of the input, the destination d is filled with the replicated sign bit of the\nextracted field.
\n",
- "tooltip": "Bit Field Extract.\n\nSyntax\n\nbfe.type d, a, b, c;\n\n.type = { .u32, .u64,\n\n .s32, .s64 };\n\nDescription\n\nExtract bit field from a and place the zero or sign-extended result in d. Source b gives\n\nthe bit field starting bit position, and source c gives the bit field length in bits.\n\nOperands a and d have the same type as the instruction type. Operands b and c are\n\ntype .u32, but are restricted to the 8-bit value range 0..255.\n\nThe sign bit of the extracted field is defined as:\n\n.u32, .u64:\n\nzero\n\n.s32, .s64:\n\nmsb of input a if the extracted field extends beyond the msb of a msb of extracted\n\nfield, otherwise\n\nIf the bit field length is zero, the result is zero.\n\nThe destination d is padded with the sign bit of the extracted field. If the start position is\n\nbeyond the msb of the input, the destination d is filled with the replicated sign bit of the\n\nextracted field.\n\nSemantics\n\nmsb = (.type==.u32 || .type==.s32) ? 31 : 63;\n\npos = b & 0xff; // pos restricted to 0..255 range\n\nlen = c & 0xff; // len restricted to 0..255 range\n\nif (.type==.u32 || .type==.u64 || len==0)\n\n sbit = 0;\n\nelse\n\n sbit = a[min(pos+len-1,msb)];\n\nd = 0;\n\nfor (i=0; i<=msb; i++) {\n\n d[i] = (iExtract bit field from a and place the zero or sign-extended result in d. Source b gives\nthe bit field starting bit position, and source c gives the bit field length in bits.
\nFor more information, visit bfe(int) .",
+ "tooltip": "Bit Field Extract.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-bfe"
};
case "bfi":
return {
- "html": "For more information, visit bfi(int) .
Align and insert a bit field from a into b, and place the result in f. Source c\ngives the starting bit position for the insertion, and source d gives the bit field length in\nbits.
\n
Operands a, b, and f have the same type as the instruction type. Operands c and\nd are type .u32, but are restricted to the 8-bit value range 0..255.
\n
If the bit field length is zero, the result is b.
\n
If the start position is beyond the msb of the input, the result is b.
\n
Semantics
\n
\n
msb = (.type==.b32) ? 31 : 63;\npos = c & 0xff; // pos restricted to 0..255 range\nlen = d & 0xff; // len restricted to 0..255 range\n\nf = b;\nfor (i=0; i<len && pos+i<=msb; i++) {\n f[pos+i] = a[i];\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
bfi requires sm_20 or higher.
\n
Examples
\n
\n
bfi.b32 d,a,b,start,len;\n
\n
\n",
- "tooltip": "Bit Field Insert.\n\nSyntax\n\nbfi.type f, a, b, c, d;\n\n.type = { .b32, .b64 };\n\nDescription\n\nAlign and insert a bit field from a into b, and place the result in f. Source c\n\ngives the starting bit position for the insertion, and source d gives the bit field length in\n\nbits.\n\nOperands a, b, and f have the same type as the instruction type. Operands c and\n\nd are type .u32, but are restricted to the 8-bit value range 0..255.\n\nIf the bit field length is zero, the result is b.\n\nIf the start position is beyond the msb of the input, the result is b.\n\nSemantics\n\nmsb = (.type==.b32) ? 31 : 63;\n\npos = c & 0xff; // pos restricted to 0..255 range\n\nlen = d & 0xff; // len restricted to 0..255 range\n\nf = b;\n\nfor (i=0; iAlign and insert a bit field from a into b, and place the result in f. Source c\ngives the starting bit position for the insertion, and source d gives the bit field length in\nbits.\nFor more information, visit bfi(int) .",
+ "tooltip": "Bit Field Insert.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-bfi"
};
case "bfind":
return {
- "html": "For more information, visit bfind(int) .
Find the bit position of the most significant non-sign bit in a and place the result in\nd. Operand a has the instruction type, and destination d has type .u32. For unsigned\nintegers, bfind returns the bit position of the most significant 1. For signed integers,\nbfind returns the bit position of the most significant 0 for negative inputs and the most\nsignificant 1 for non-negative inputs.
\n
If .shiftamt is specified, bfind returns the shift amount needed to left-shift the found bit\ninto the most-significant bit position.
\n
bfind returns 0xffffffff if no non-sign bit is found.
\n
Semantics
\n
\n
msb = (.type==.u32 || .type==.s32) ? 31 : 63;\n// negate negative signed inputs\nif ( (.type==.s32 || .type==.s64) && (a & (1<<msb)) ) {\n a = ~a;\n}\n.u32 d = 0xffffffff;\nfor (.s32 i=msb; i>=0; i--) {\n if (a & (1<<i)) { d = i; break; }\n}\nif (.shiftamt && d != 0xffffffff) { d = msb - d; }\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
bfind requires sm_20 or higher.
\n
Examples
\n
\n
bfind.u32 d, a;\nbfind.shiftamt.s64 cnt, X; // cnt is .u32\n
\n
\n",
- "tooltip": "Find most significant non-sign bit.\n\nSyntax\n\nbfind.type d, a;\n\nbfind.shiftamt.type d, a;\n\n.type = { .u32, .u64,\n\n .s32, .s64 };\n\nDescription\n\nFind the bit position of the most significant non-sign bit in a and place the result in\n\nd. Operand a has the instruction type, and destination d has type .u32. For unsigned\n\nintegers, bfind returns the bit position of the most significant 1. For signed integers,\n\nbfind returns the bit position of the most significant 0 for negative inputs and the most\n\nsignificant 1 for non-negative inputs.\n\nIf .shiftamt is specified, bfind returns the shift amount needed to left-shift the found bit\n\ninto the most-significant bit position.\n\nbfind returns 0xffffffff if no non-sign bit is found.\n\nSemantics\n\nmsb = (.type==.u32 || .type==.s32) ? 31 : 63;\n\n// negate negative signed inputs\n\nif ( (.type==.s32 || .type==.s64) && (a & (1<=0; i--) {\n\n if (a & (1<Find the bit position of the most significant non-sign bit in a and place the result in\nd. Operand a has the instruction type, and destination d has type .u32. For unsigned\nintegers, bfind returns the bit position of the most significant 1. For signed integers,\nbfind returns the bit position of the most significant 0 for negative inputs and the most\nsignificant 1 for non-negative inputs.\nFor more information, visit bfind(int) .",
+ "tooltip": "Find most significant non-sign bit.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-bfind"
};
case "bmsk":
return {
- "html": "For more information, visit bmsk(int) .
Integer Arithmetic Instructions: bmsk
\n\n\n
Bit Field Mask.
\n
Syntax
\n
\n
bmsk.mode.b32 d, a, b;\n\n.mode = { .clamp, .wrap };\n
\n
\n
Description
\n
Generates a 32-bit mask starting from the bit position specified in operand a, and of the width\nspecified in operand b. The generated bitmask is stored in the destination operand d.
\n
The resulting bitmask is 0 in the following cases:
\n
\n
When the value of a is 32 or higher and .mode is .clamp.
\n
When either the specified value of b or the wrapped value of b (when .mode is\nspecified as .wrap) is 0.
The bitmask width specified by operand b is limited to range 0..32 in .clamp mode and to\nrange 0..31 in .wrap mode.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.6.
\n
Target ISA Notes
\n
bmsk requires sm_70 or higher.
\n
Examples
\n
\n
bmsk.clamp.b32 rd, ra, rb;\nbmsk.wrap.b32 rd, 1, 2; // Creates a bitmask of 0x00000006.\n
\n
\n",
- "tooltip": "Bit Field Mask.\n\nSyntax\n\nbmsk.mode.b32 d, a, b;\n\n.mode = { .clamp, .wrap };\n\nDescription\n\nGenerates a 32-bit mask starting from the bit position specified in operand a, and of the width\n\nspecified in operand b. The generated bitmask is stored in the destination operand d.\n\nThe resulting bitmask is 0 in the following cases:\n\nWhen the value of a is 32 or higher and .mode is .clamp.\n\nWhen either the specified value of b or the wrapped value of b (when .mode is\n\nspecified as .wrap) is 0.\n\nSemantics\n\na1 = a & 0x1f;\n\nmask0 = (~0) << a1;\n\nb1 = b & 0x1f;\n\nsum = a1 + b1;\n\nmask1 = (~0) << sum;\n\nsum-overflow = sum >= 32 ? true : false;\n\nbit-position-overflow = false;\n\nbit-width-overflow = false;\n\nif (.mode == .clamp) {\n\n if (a >= 32) {\n\n bit-position-overflow = true;\n\n mask0 = 0;\n\n }\n\n if (b >= 32) {\n\n bit-width-overflow = true;\n\n }\n\n}\n\nif (sum-overflow || bit-position-overflow || bit-width-overflow) {\n\n mask1 = 0;\n\n} else if (b1 == 0) {\n\n mask1 = ~0;\n\n}\n\nd = mask0 & ~mask1;\n\nNotes\n\nThe bitmask width specified by operand b is limited to range 0..32 in .clamp mode and to\n\nrange 0..31 in .wrap mode.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.6.\n\nTarget ISA Notes\n\nbmsk requires sm_70 or higher.\n\nExamples\n\nbmsk.clamp.b32 rd, ra, rb;\n\nbmsk.wrap.b32 rd, 1, 2; // Creates a bitmask of 0x00000006.\n\n ...",
+ "html": "
Generates a 32-bit mask starting from the bit position specified in operand a, and of the width\nspecified in operand b. The generated bitmask is stored in the destination operand d.
\nFor more information, visit bmsk(int) .",
+ "tooltip": "Bit Field Mask.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-bmsk"
};
case "bra":
return {
- "html": "For more information, visit bra .
Control Flow Instructions: bra
\n\n\n
Branch to a target and continue execution there.
\n
Syntax
\n
\n
@p bra{.uni} tgt; // tgt is a label\n bra{.uni} tgt; // unconditional branch\n
\n
\n
Description
\n
Continue execution at the target. Conditional branches are specified by using a guard predicate. The\nbranch target must be a label.
\n
bra.uni is guaranteed to be non-divergent, i.e. all active threads in a warp that are currently\nexecuting this instruction have identical values for the guard predicate and branch target.
\n
Semantics
\n
\n
if (p) {\n pc = tgt;\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Unimplemented indirect branch introduced in PTX ISA version 2.1 has been removed from the spec.
\n",
- "tooltip": "Branch to a target and continue execution there.\n\nSyntax\n\n@p bra{.uni} tgt; // tgt is a label\n\n bra{.uni} tgt; // unconditional branch\n\nDescription\n\nContinue execution at the target. Conditional branches are specified by using a guard predicate. The\n\nbranch target must be a label.\n\nbra.uni is guaranteed to be non-divergent, i.e. all active threads in a warp that are currently\n\nexecuting this instruction have identical values for the guard predicate and branch target.\n\nSemantics\n\nif (p) {\n\n pc = tgt;\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nUnimplemented indirect branch introduced in PTX ISA version 2.1 has been removed from the spec.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nbra.uni L_exit; // uniform unconditional jump\n\n@q bra L23; // conditional branch\n\n ...",
+ "html": "
Continue execution at the target. Conditional branches are specified by using a guard predicate. The\nbranch target must be a label.
\nFor more information, visit bra .",
+ "tooltip": "Branch to a target and continue execution there.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-instructions-bra"
};
- case "branchtargets":
- return {
- "html": "For more information, visit branchtargets .
Control Flow Directives: .branchtargets
\n\n\n
Declare a list of potential branch targets.
\n
Syntax
\n
\n
Label: .branchtargets list-of-labels ;\n
\n
\n
Description
\n
Declares a list of potential branch targets for a subsequent brx.idx, and associates the list\nwith the label at the start of the line.
\n
All control flow labels in the list must occur within the same function as the declaration.
\n
The list of labels may use the compact, shorthand syntax for enumerating a range of labels having a\ncommon prefix, similar to the syntax described in Parameterized Variable Names.
\n",
- "tooltip": "Declare a list of potential branch targets.\n\nSyntax\n\nLabel: .branchtargets list-of-labels ;\n\nDescription\n\nDeclares a list of potential branch targets for a subsequent brx.idx, and associates the list\n\nwith the label at the start of the line.\n\nAll control flow labels in the list must occur within the same function as the declaration.\n\nThe list of labels may use the compact, shorthand syntax for enumerating a range of labels having a\n\ncommon prefix, similar to the syntax described in Parameterized Variable Names.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.1.\n\nTarget ISA Notes\n\nRequires sm_20 or higher.\n\nExamples\n\n .function foo () {\n\n .reg .u32 %r0;\n\n ...\n\n L1:\n\n ...\n\n L2:\n\n ...\n\n L3:\n\n ...\n\n ts: .branchtargets L1, L2, L3;\n\n @p brx.idx %r0, ts;\n\n ...\n\n.function bar() {\n\n .reg .u32 %r0;\n\n ...\n\n N0:\n\n ...\n\n N1:\n\n ...\n\n N2:\n\n ...\n\n N3:\n\n ...\n\n N4:\n\n ...\n\n ts: .branchtargets N<5>;\n\n @p brx.idx %r0, ts;\n\n ...\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-directives-branchtargets"
- };
-
case "brev":
return {
- "html": "For more information, visit brev(int) .
\n",
- "tooltip": "Bit reverse.\n\nSyntax\n\nbrev.type d, a;\n\n.type = { .b32, .b64 };\n\nDescription\n\nPerform bitwise reversal of input.\n\nSemantics\n\nmsb = (.type==.b32) ? 31 : 63;\n\nfor (i=0; i<=msb; i++) {\n\n d[i] = a[msb-i];\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nbrev requires sm_20 or higher.\n\nExamples\n\nbrev.b32 d, a;\n\n ...",
+ "html": "
Perform bitwise reversal of input.
\nFor more information, visit brev(int) .",
+ "tooltip": "Bit reverse.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-brev"
};
case "brkpt":
return {
- "html": "For more information, visit brkpt .
Miscellaneous Instructions: brkpt
\n\n\n
Breakpoint.
\n
Syntax
\n
\n
brkpt;\n
\n
\n
Description
\n
Suspends execution.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
brkpt requires sm_11 or higher.
\n
Examples
\n
\n
brkpt;\n@p brkpt;\n
\n
\n",
- "tooltip": "Breakpoint.\n\nSyntax\n\nbrkpt;\n\nDescription\n\nSuspends execution.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nbrkpt requires sm_11 or higher.\n\nExamples\n\n brkpt;\n\n@p brkpt;\n\n ...",
+ "html": "
Suspends execution.
\nFor more information, visit brkpt .",
+ "tooltip": "Breakpoint.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#miscellaneous-instructions-brkpt"
};
case "brx":
return {
- "html": "For more information, visit brx.idx .
Control Flow Instructions: brx.idx
\n\n\n
Branch to a label indexed from a list of potential branch targets.
Index into a list of possible destination labels, and continue execution from the chosen\nlabel. Conditional branches are specified by using a guard predicate.
\n
brx.idx.uni guarantees that the branch is non-divergent, i.e. all active threads in a warp that\nare currently executing this instruction have identical values for the guard predicate and the\nindex argument.
\n
The index operand is a .u32 register. The tlist operand must be the label of a\n.branchtargets directive. It is accessed as a zero-based sequence using index. Behaviour is\nundefined if the value of index is greater than or equal to the length of tlist.
\n
The .branchtargets directive must be defined in the local function scope before it is used. It\nmust refer to labels within the current function.
\n
Semantics
\n
\n
if (p) {\n if (index < length(tlist)) {\n pc = tlist[index];\n } else {\n pc = undefined;\n }\n}\n
\n",
- "tooltip": "Branch to a label indexed from a list of potential branch targets.\n\nSyntax\n\n@p brx.idx{.uni} index, tlist;\n\n brx.idx{.uni} index, tlist;\n\nDescription\n\nIndex into a list of possible destination labels, and continue execution from the chosen\n\nlabel. Conditional branches are specified by using a guard predicate.\n\nbrx.idx.uni guarantees that the branch is non-divergent, i.e. all active threads in a warp that\n\nare currently executing this instruction have identical values for the guard predicate and the\n\nindex argument.\n\nThe index operand is a .u32 register. The tlist operand must be the label of a\n\n.branchtargets directive. It is accessed as a zero-based sequence using index. Behaviour is\n\nundefined if the value of index is greater than or equal to the length of tlist.\n\nThe .branchtargets directive must be defined in the local function scope before it is used. It\n\nmust refer to labels within the current function.\n\nSemantics\n\nif (p) {\n\n if (index < length(tlist)) {\n\n pc = tlist[index];\n\n } else {\n\n pc = undefined;\n\n }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 6.0.\n\nTarget ISA Notes\n\nRequires sm_30 or higher.\n\nExamples\n\n.function foo () {\n\n .reg .u32 %r0;\n\n ...\n\n L1:\n\n ...\n\n L2:\n\n ...\n\n L3:\n\n ...\n\n ts: .branchtargets L1, L2, L3;\n\n @p brx.idx %r0, ts;\n\n ...\n\n}\n\n ...",
+ "html": "
Index into a list of possible destination labels, and continue execution from the chosen\nlabel. Conditional branches are specified by using a guard predicate.
\nFor more information, visit brx.idx .",
+ "tooltip": "Branch to a label indexed from a list of potential branch targets.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-instructions-brx-idx"
};
case "call":
return {
- "html": "For more information, visit call .
Control Flow Instructions: call
\n\n\n
Call a function, recording the return location.
\n
Syntax
\n
\n
// direct call to named function, func is a symbol\ncall{.uni} (ret-param), func, (param-list);\ncall{.uni} func, (param-list);\ncall{.uni} func;\n\n// indirect call via pointer, with full list of call targets\ncall{.uni} (ret-param), fptr, (param-list), flist;\ncall{.uni} fptr, (param-list), flist;\ncall{.uni} fptr, flist;\n\n// indirect call via pointer, with no knowledge of call targets\ncall{.uni} (ret-param), fptr, (param-list), fproto;\ncall{.uni} fptr, (param-list), fproto;\ncall{.uni} fptr, fproto;\n
\n
\n
Description
\n
The call instruction stores the address of the next instruction, so execution can resume at that\npoint after executing a ret instruction. A call is assumed to be divergent unless the\n.uni suffix is present. The .uni suffix indicates that the call is guaranteed to be\nnon-divergent, i.e. all active threads in a warp that are currently executing this instruction have\nidentical values for the guard predicate and call target.
\n
For direct calls, the called location func must be a symbolic function name; for indirect calls,\nthe called location fptr must be an address of a function held in a register. Input arguments\nand return values are optional.\u00a0Arguments may be registers, immediate constants, or variables in\n.param space. Arguments are pass-by-value.
\n
Indirect calls require an additional operand, flist or fproto, to communicate the list of\npotential call targets or the common function prototype of all call targets,\nrespectively. In the first case, flist gives a complete list of potential call targets and\nthe optimizing backend is free to optimize the calling convention. In the second case, where the\ncomplete list of potential call targets may not be known, the common function prototype is given\nand the call must obey the ABI\u2019s calling convention.
\n
The flist operand is either the name of an array (call table) initialized to a list of function\nnames; or a label associated with a .calltargets directive, which declares a list of potential\ncall targets. In both cases the fptr register holds the address of a function listed in the call\ntable or .calltargets list, and the call operands are type-checked against the type\nsignature of the functions indicated by flist.
\n
The fproto operand is the name of a label associated with a .callprototype directive. This\noperand is used when a complete list of potential targets is not known. The call operands are\ntype-checked against the prototype, and code generation will follow the ABI calling convention. If a\nfunction that doesn\u2019t match the prototype is called, the behavior is undefined.
\n
Call tables may be declared at module scope or local scope, in either the constant or global state\nspace. The .calltargets and .callprototype directives must be declared within a function\nbody. All functions must be declared prior to being referenced in a call table initializer or\n.calltargets directive.
\n
PTX ISA Notes
\n
Direct call introduced in PTX ISA version 1.0. Indirect call introduced in PTX ISA version 2.1.
\n
Target ISA Notes
\n
Direct call supported on all target architectures. Indirect call requires sm_20 or higher.
\n
Examples
\n
\n
// examples of direct call\n call init; // call function 'init'\n call.uni g, (a); // call function 'g' with parameter 'a'\n@p call (d), h, (a, b); // return value into register d\n\n// call-via-pointer using jump table\n.func (.reg .u32 rv) foo (.reg .u32 a, .reg .u32 b) ...\n.func (.reg .u32 rv) bar (.reg .u32 a, .reg .u32 b) ...\n.func (.reg .u32 rv) baz (.reg .u32 a, .reg .u32 b) ...\n\n.global .u32 jmptbl[5] = { foo, bar, baz };\n ...\n@p ld.global.u32 %r0, [jmptbl+4];\n@p ld.global.u32 %r0, [jmptbl+8];\n call (retval), %r0, (x, y), jmptbl;\n\n// call-via-pointer using .calltargets directive\n.func (.reg .u32 rv) foo (.reg .u32 a, .reg .u32 b) ...\n.func (.reg .u32 rv) bar (.reg .u32 a, .reg .u32 b) ...\n.func (.reg .u32 rv) baz (.reg .u32 a, .reg .u32 b) ...\n ...\n@p mov.u32 %r0, foo;\n@q mov.u32 %r0, baz;\nFtgt: .calltargets foo, bar, baz;\n call (retval), %r0, (x, y), Ftgt;\n\n// call-via-pointer using .callprototype directive\n.func dispatch (.reg .u32 fptr, .reg .u32 idx)\n{\n...\nFproto: .callprototype _ (.param .u32 _, .param .u32 _);\n call %fptr, (x, y), Fproto;\n...\n
\n
\n",
- "tooltip": "Call a function, recording the return location.\n\nSyntax\n\n// direct call to named function, func is a symbol\n\ncall{.uni} (ret-param), func, (param-list);\n\ncall{.uni} func, (param-list);\n\ncall{.uni} func;\n\n// indirect call via pointer, with full list of call targets\n\ncall{.uni} (ret-param), fptr, (param-list), flist;\n\ncall{.uni} fptr, (param-list), flist;\n\ncall{.uni} fptr, flist;\n\n// indirect call via pointer, with no knowledge of call targets\n\ncall{.uni} (ret-param), fptr, (param-list), fproto;\n\ncall{.uni} fptr, (param-list), fproto;\n\ncall{.uni} fptr, fproto;\n\nDescription\n\nThe call instruction stores the address of the next instruction, so execution can resume at that\n\npoint after executing a ret instruction. A call is assumed to be divergent unless the\n\n.uni suffix is present. The .uni suffix indicates that the call is guaranteed to be\n\nnon-divergent, i.e. all active threads in a warp that are currently executing this instruction have\n\nidentical values for the guard predicate and call target.\n\nFor direct calls, the called location func must be a symbolic function name; for indirect calls,\n\nthe called location fptr must be an address of a function held in a register. Input arguments\n\nand return values are optional.\u00a0Arguments may be registers, immediate constants, or variables in\n\n.param space. Arguments are pass-by-value.\n\nIndirect calls require an additional operand, flist or fproto, to communicate the list of\n\npotential call targets or the common function prototype of all call targets,\n\nrespectively. In the first case, flist gives a complete list of potential call targets and\n\nthe optimizing backend is free to optimize the calling convention. In the second case, where the\n\ncomplete list of potential call targets may not be known, the common function prototype is given\n\nand the call must obey the ABI\u2019s calling convention.\n\nThe flist operand is either the name of an array (call table) initialized to a list of function\n\nnames; or a label associated with a .calltargets directive, which declares a list of potential\n\ncall targets. In both cases the fptr register holds the address of a function listed in the call\n\ntable or .calltargets list, and the call operands are type-checked against the type\n\nsignature of the functions indicated by flist.\n\nThe fproto operand is the name of a label associated with a .callprototype directive. This\n\noperand is used when a complete list of potential targets is not known. The call operands are\n\ntype-checked against the prototype, and code generation will follow the ABI calling convention. If a\n\nfunction that doesn\u2019t match the prototype is called, the behavior is undefined.\n\nCall tables may be declared at module scope or local scope, in either the constant or global state\n\nspace. The .calltargets and .callprototype directives must be declared within a function\n\nbody. All functions must be declared prior to being referenced in a call table initializer or\n\n.calltargets directive.\n\nPTX ISA Notes\n\nDirect call introduced in PTX ISA version 1.0. Indirect call introduced in PTX ISA version 2.1.\n\nTarget ISA Notes\n\nDirect call supported on all target architectures. Indirect call requires sm_20 or higher.\n\nExamples\n\n// examples of direct call\n\n call init; // call function 'init'\n\n call.uni g, (a); // call function 'g' with parameter 'a'\n\n@p call (d), h, (a, b); // return value into register d\n\n// call-via-pointer using jump table\n\n.func (.reg .u32 rv) foo (.reg .u32 a, .reg .u32 b) ...\n\n.func (.reg .u32 rv) bar (.reg .u32 a, .reg .u32 b) ...\n\n.func (.reg .u32 rv) baz (.reg .u32 a, .reg .u32 b) ...\n\n.global .u32 jmptbl[5] = { foo, bar, baz };\n\n ...\n\n@p ld.global.u32 %r0, [jmptbl+4];\n\n@p ld.global.u32 %r0, [jmptbl+8];\n\n call (retval), %r0, (x, y), jmptbl;\n\n// call-via-pointer using .calltargets directive\n\n.func (.reg .u32 rv) foo (.reg .u32 a, .reg .u32 b) ...\n\n.func (.reg .u32 rv) bar (.reg .u32 a, .reg .u32 b) ...\n\n.func (.reg .u32 rv) baz (.reg .u32 a, .reg .u32 b) ...\n\n ...\n\n@p mov.u32 %r0, foo;\n\n@q mov.u32 %r0, baz;\n\nFtgt: ...",
+ "html": "
The call instruction stores the address of the next instruction, so execution can resume at that\npoint after executing a ret instruction. A call is assumed to be divergent unless the\n.uni suffix is present. The .uni suffix indicates that the call is guaranteed to be\nnon-divergent, i.e. all active threads in a warp that are currently executing this instruction have\nidentical values for the guard predicate and call target.
\nFor more information, visit call .",
+ "tooltip": "Call a function, recording the return location.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-instructions-call"
};
- case "callprototype":
- return {
- "html": "For more information, visit callprototype .
Control Flow Directives: .callprototype
\n\n\n
Declare a prototype for use in an indirect call.
\n
Syntax
\n
\n
// no input or return parameters\nlabel: .callprototype _ .noreturn;\n// input params, no return params\nlabel: .callprototype _ (param-list) .noreturn;\n// no input params, // return params\nlabel: .callprototype (ret-param) _ ;\n// input, return parameters\nlabel: .callprototype (ret-param) _ (param-list);\n
\n
\n
Description
\n
Defines a prototype with no specific function name, and associates the prototype with a label. The\nprototype may then be used in indirect call instructions where there is incomplete knowledge of the\npossible call targets.
\n
Parameters may have either base types in the register or parameter state spaces, or array types in\nparameter state space. The sink symbol '_' may be used to avoid dummy parameter names.
\n
An optional .noreturn directive indicates that the function does not return to the caller\nfunction. .noreturn directive cannot be specified on functions which have return parameters. See\nthe description of .noreturn directive in Performance-Tuning Directives: .noreturn.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.1.
\n
Support for .noreturn directive introduced in PTX ISA version 6.4.
\n",
- "tooltip": "Declare a prototype for use in an indirect call.\n\nSyntax\n\n // no input or return parameters\n\nlabel: .callprototype _ .noreturn;\n\n// input params, no return params\n\nlabel: .callprototype _ (param-list) .noreturn;\n\n// no input params, // return params\n\nlabel: .callprototype (ret-param) _ ;\n\n// input, return parameters\n\nlabel: .callprototype (ret-param) _ (param-list);\n\nDescription\n\nDefines a prototype with no specific function name, and associates the prototype with a label. The\n\nprototype may then be used in indirect call instructions where there is incomplete knowledge of the\n\npossible call targets.\n\nParameters may have either base types in the register or parameter state spaces, or array types in\n\nparameter state space. The sink symbol '_' may be used to avoid dummy parameter names.\n\nAn optional .noreturn directive indicates that the function does not return to the caller\n\nfunction. .noreturn directive cannot be specified on functions which have return parameters. See\n\nthe description of .noreturn directive in Performance-Tuning Directives: .noreturn.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.1.\n\nSupport for .noreturn directive introduced in PTX ISA version 6.4.\n\nTarget ISA Notes\n\nRequires sm_20 or higher.\n\n.noreturn directive requires sm_30 or higher.\n\nExamples\n\nFproto1: .callprototype _ ;\n\nFproto2: .callprototype _ (.param .f32 _);\n\nFproto3: .callprototype (.param .u32 _) _ ;\n\nFproto4: .callprototype (.param .u32 _) _ (.param .f32 _);\n\n...\n\n@p call (%val), %r0, (%f1), Fproto4;\n\n...\n\n// example of array parameter\n\nFproto5: .callprototype _ (.param .b8 _[12]);\n\nFproto6: .callprototype _ (.param .f32 _) .noreturn;\n\n...\n\n@p call %r0, (%f1), Fproto6;\n\n...\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-directives-callprototype"
- };
-
- case "calltargets":
- return {
- "html": "For more information, visit calltargets .
Control Flow Directives: .calltargets
\n\n\n
Declare a list of potential call targets.
\n
Syntax
\n
\n
Label: .calltargets list-of-functions ;\n
\n
\n
Description
\n
Declares a list of potential call targets for a subsequent indirect call, and associates the list\nwith the label at the start of the line.
\n
All functions named in the list must be declared prior to the .calltargets directive, and all\nfunctions must have the same type signature.
\n",
- "tooltip": "Declare a list of potential call targets.\n\nSyntax\n\nLabel: .calltargets list-of-functions ;\n\nDescription\n\nDeclares a list of potential call targets for a subsequent indirect call, and associates the list\n\nwith the label at the start of the line.\n\nAll functions named in the list must be declared prior to the .calltargets directive, and all\n\nfunctions must have the same type signature.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.1.\n\nTarget ISA Notes\n\nRequires sm_20 or higher.\n\nExamples\n\ncalltgt: .calltargets fastsin, fastcos;\n\n...\n\n@p call (%f1), %r0, (%x), calltgt;\n\n...\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-directives-calltargets"
- };
-
- case "clock":
- return {
- "html": "For more information, visit clock .
Special Registers: %clock, %clock_hi
\n\n\n
\n
%clock
\n
\n
A predefined, read-only 32-bit unsigned cycle counter.
\n
\n
%clock_hi
\n
\n
The upper 32-bits of %clock64 special register.
\n
\n
\n
Syntax (predefined)
\n
\n
.sreg .u32 %clock;\n.sreg .u32 %clock_hi;\n
\n
\n
Description
\n
Special register %clock and %clock_hi are unsigned 32-bit read-only cycle counters that wrap\nsilently.
\n
PTX ISA Notes
\n
%clock introduced in PTX ISA version 1.0.
\n
%clock_hi introduced in PTX ISA version 5.0.
\n
Target ISA Notes
\n
%clock supported on all target architectures.
\n
%clock_hi requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 r1,%clock;\nmov.u32 r2, %clock_hi;\n
\n
\n",
- "tooltip": "%clock\n\nA predefined, read-only 32-bit unsigned cycle counter.\n\n%clock_hi\n\nThe upper 32-bits of %clock64 special register.\n\nSyntax (predefined)\n\n.sreg .u32 %clock;\n\n.sreg .u32 %clock_hi;\n\nDescription\n\nSpecial register %clock and %clock_hi are unsigned 32-bit read-only cycle counters that wrap\n\nsilently.\n\nPTX ISA Notes\n\n%clock introduced in PTX ISA version 1.0.\n\n%clock_hi introduced in PTX ISA version 5.0.\n\nTarget ISA Notes\n\n%clock supported on all target architectures.\n\n%clock_hi requires sm_20 or higher.\n\nExamples\n\nmov.u32 r1,%clock;\n\nmov.u32 r2, %clock_hi;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-clock-clock-hi"
- };
-
- case "clock64":
- return {
- "html": "For more information, visit clock64 .
Special Registers: %clock64
\n\n\n
A predefined, read-only 64-bit unsigned cycle counter.
\n
Syntax (predefined)
\n
\n
.sreg .u64 %clock64;\n
\n
\n
Description
\n
Special register %clock64 is an unsigned 64-bit read-only cycle counter that wraps silently.
\n
Notes
\n
The lower 32-bits of %clock64 are identical to %clock.
\n
The upper 32-bits of %clock64 are identical to %clock_hi.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%clock64 requires sm_20 or higher.
\n
Examples
\n
\n
mov.u64 r1,%clock64;\n
\n
\n",
- "tooltip": "A predefined, read-only 64-bit unsigned cycle counter.\n\nSyntax (predefined)\n\n.sreg .u64 %clock64;\n\nDescription\n\nSpecial register %clock64 is an unsigned 64-bit read-only cycle counter that wraps silently.\n\nNotes\n\nThe lower 32-bits of %clock64 are identical to %clock.\n\nThe upper 32-bits of %clock64 are identical to %clock_hi.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%clock64 requires sm_20 or higher.\n\nExamples\n\nmov.u64 r1,%clock64;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-clock64"
- };
-
- case "clock_hi":
- return {
- "html": "For more information, visit clock_hi .
Special Registers: %clock, %clock_hi
\n\n\n
\n
%clock
\n
\n
A predefined, read-only 32-bit unsigned cycle counter.
\n
\n
%clock_hi
\n
\n
The upper 32-bits of %clock64 special register.
\n
\n
\n
Syntax (predefined)
\n
\n
.sreg .u32 %clock;\n.sreg .u32 %clock_hi;\n
\n
\n
Description
\n
Special register %clock and %clock_hi are unsigned 32-bit read-only cycle counters that wrap\nsilently.
\n
PTX ISA Notes
\n
%clock introduced in PTX ISA version 1.0.
\n
%clock_hi introduced in PTX ISA version 5.0.
\n
Target ISA Notes
\n
%clock supported on all target architectures.
\n
%clock_hi requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 r1,%clock;\nmov.u32 r2, %clock_hi;\n
\n
\n",
- "tooltip": "%clock\n\nA predefined, read-only 32-bit unsigned cycle counter.\n\n%clock_hi\n\nThe upper 32-bits of %clock64 special register.\n\nSyntax (predefined)\n\n.sreg .u32 %clock;\n\n.sreg .u32 %clock_hi;\n\nDescription\n\nSpecial register %clock and %clock_hi are unsigned 32-bit read-only cycle counters that wrap\n\nsilently.\n\nPTX ISA Notes\n\n%clock introduced in PTX ISA version 1.0.\n\n%clock_hi introduced in PTX ISA version 5.0.\n\nTarget ISA Notes\n\n%clock supported on all target architectures.\n\n%clock_hi requires sm_20 or higher.\n\nExamples\n\nmov.u32 r1,%clock;\n\nmov.u32 r2, %clock_hi;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-clock-clock-hi"
- };
-
- case "cluster_ctaid":
- return {
- "html": "For more information, visit cluster_ctaid .
A predefined, read-only special register initialized with the CTA identifier in a cluster in each\ndimension. Each CTA in a cluster has a unique CTA identifier.
\n
The %cluster_ctaid special register contains a 1D, 2D, or 3D vector, depending upon the shape of\nthe cluster. The fourth element is unused and always returns zero.
\n",
- "tooltip": "CTA identifier within a cluster.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %cluster_ctaid;\n\n.sreg .u32 %cluster_ctaid.x, %cluster_ctaid.y, %cluster_ctaid.z;\n\nDescription\n\nA predefined, read-only special register initialized with the CTA identifier in a cluster in each\n\ndimension. Each CTA in a cluster has a unique CTA identifier.\n\nThe %cluster_ctaid special register contains a 1D, 2D, or 3D vector, depending upon the shape of\n\nthe cluster. The fourth element is unused and always returns zero.\n\nIt is guaranteed that:\n\n0 <= %cluster_ctaid.x < %cluster_nctaid.x\n\n0 <= %cluster_ctaid.y < %cluster_nctaid.y\n\n0 <= %cluster_ctaid.z < %cluster_nctaid.z\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.reg .b32 %r<2>;\n\n.reg .v4 .b32 %rx;\n\nmov.u32 %r0, %cluster_ctaid.x;\n\nmov.u32 %r1, %cluster_ctaid.z;\n\nmov.v4.u32 %rx, %cluster_ctaid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-cluster-ctaid"
- };
-
- case "cluster_ctarank":
- return {
- "html": "For more information, visit cluster_ctarank .
Special Registers: %cluster_ctarank
\n\n\n
CTA identifier in a cluster across all dimensions.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %cluster_ctarank;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with the CTA rank within a cluster across all\ndimensions.
\n
It is guaranteed that:
\n
\n
0 <= %cluster_ctarank < %cluster_nctarank\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
.reg .b32 %r;\n\nmov.u32 %r, %cluster_ctarank;\n
\n
\n",
- "tooltip": "CTA identifier in a cluster across all dimensions.\n\nSyntax (predefined)\n\n.sreg .u32 %cluster_ctarank;\n\nDescription\n\nA predefined, read-only special register initialized with the CTA rank within a cluster across all\n\ndimensions.\n\nIt is guaranteed that:\n\n0 <= %cluster_ctarank < %cluster_nctarank\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.reg .b32 %r;\n\nmov.u32 %r, %cluster_ctarank;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-cluster-ctarank"
- };
-
- case "cluster_nctaid":
- return {
- "html": "For more information, visit cluster_nctaid .
A predefined, read-only special register initialized with the number of CTAs in a cluster in each\ndimension.
\n
The %cluster_nctaid special register contains a 3D grid shape vector that holds the cluster\ndimensions in terms of CTAs. The fourth element is unused and always returns zero.
\n
Refer to the Cuda Programming Guide for details on the maximum values of\n%cluster_nctaid.{x,y,z}.
\n",
- "tooltip": "Number of CTA identifiers per cluster.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %cluster_nctaid;\n\n.sreg .u32 %cluster_nctaid.x, %cluster_nctaid.y, %cluster_nctaid.z;\n\nDescription\n\nA predefined, read-only special register initialized with the number of CTAs in a cluster in each\n\ndimension.\n\nThe %cluster_nctaid special register contains a 3D grid shape vector that holds the cluster\n\ndimensions in terms of CTAs. The fourth element is unused and always returns zero.\n\nRefer to the Cuda Programming Guide for details on the maximum values of\n\n%cluster_nctaid.{x,y,z}.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.reg .b32 %r<2>;\n\n.reg .v4 .b32 %rx;\n\nmov.u32 %r0, %cluster_nctaid.x;\n\nmov.u32 %r1, %cluster_nctaid.z;\n\nmov.v4.u32 %rx, %cluster_nctaid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-cluster-nctaid"
- };
-
- case "cluster_nctarank":
- return {
- "html": "For more information, visit cluster_nctarank .
Special Registers: %cluster_nctarank
\n\n\n
Number of CTA identifiers in a cluster across all dimensions.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %cluster_nctarank;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with the nunber of CTAs within a cluster across\nall dimensions.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
.reg .b32 %r;\n\nmov.u32 %r, %cluster_nctarank;\n
\n
\n",
- "tooltip": "Number of CTA identifiers in a cluster across all dimensions.\n\nSyntax (predefined)\n\n.sreg .u32 %cluster_nctarank;\n\nDescription\n\nA predefined, read-only special register initialized with the nunber of CTAs within a cluster across\n\nall dimensions.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.reg .b32 %r;\n\nmov.u32 %r, %cluster_nctarank;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-cluster-nctarank"
- };
-
- case "clusterid":
+ case "clusterlaunchcontrol":
return {
- "html": "For more information, visit clusterid .
A predefined, read-only special register initialized with the cluster identifier in a grid in each\ndimension. Each cluster in a grid has a unique identifier.
\n
The %clusterid special register contains a 1D, 2D, or 3D vector, depending upon the shape and\nrank of the cluster. The fourth element is unused and always returns zero.
\n",
- "tooltip": "Cluster identifier within a grid.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %clusterid;\n\n.sreg .u32 %clusterid.x, %clusterid.y, %clusterid.z;\n\nDescription\n\nA predefined, read-only special register initialized with the cluster identifier in a grid in each\n\ndimension. Each cluster in a grid has a unique identifier.\n\nThe %clusterid special register contains a 1D, 2D, or 3D vector, depending upon the shape and\n\nrank of the cluster. The fourth element is unused and always returns zero.\n\nIt is guaranteed that:\n\n0 <= %clusterid.x < %nclusterid.x\n\n0 <= %clusterid.y < %nclusterid.y\n\n0 <= %clusterid.z < %nclusterid.z\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.reg .b32 %r<2>;\n\n.reg .v4 .b32 %rx;\n\nmov.u32 %r0, %clusterid.x;\n\nmov.u32 %r1, %clusterid.z;\n\nmov.v4.u32 %rx, %clusterid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-clusterid"
+ "html": "
The clusterlaunchcontrol.try_cancel instruction requests atomically cancelling the launch of\na cluster that has not started running yet. It asynchronously writes an opaque response to shared\nmemory indicating whether the operation succeeded or failed. The completion of the asynchronous\noperation is tracked using the mbarrier completion mechanism at .cluster scope.
\nFor more information, visit clusterlaunchcontrol.try_cancel .",
+ "tooltip": "Requests cancellation of cluster which is not launched yet.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-clusterlaunchcontrol-try-cancel"
};
case "clz":
return {
- "html": "For more information, visit clz(int) .
Integer Arithmetic Instructions: clz
\n\n\n
Count leading zeros.
\n
Syntax
\n
\n
clz.type d, a;\n\n.type = { .b32, .b64 };\n
\n
\n
Description
\n
Count the number of leading zeros in a starting with the most-significant bit and place the\nresult in 32-bit destination register d.\u00a0Operand a has the instruction type, and destination\nd has type .u32. For .b32 type, the number of leading zeros is between 0 and 32,\ninclusively. For.b64 type, the number of leading zeros is between 0 and 64, inclusively.
\n
Semantics
\n
\n
.u32 d = 0;\nif (.type == .b32) { max = 32; mask = 0x80000000; }\nelse { max = 64; mask = 0x8000000000000000; }\n\nwhile (d < max && (a&mask == 0) ) {\n d++;\n a = a << 1;\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
clz requires sm_20 or higher.
\n
Examples
\n
\n
clz.b32 d, a;\nclz.b64 cnt, X; // cnt is .u32\n
\n
\n",
- "tooltip": "Count leading zeros.\n\nSyntax\n\nclz.type d, a;\n\n.type = { .b32, .b64 };\n\nDescription\n\nCount the number of leading zeros in a starting with the most-significant bit and place the\n\nresult in 32-bit destination register d.\u00a0Operand a has the instruction type, and destination\n\nd has type .u32. For .b32 type, the number of leading zeros is between 0 and 32,\n\ninclusively. For.b64 type, the number of leading zeros is between 0 and 64, inclusively.\n\nSemantics\n\n.u32 d = 0;\n\nif (.type == .b32) { max = 32; mask = 0x80000000; }\n\nelse { max = 64; mask = 0x8000000000000000; }\n\nwhile (d < max && (a&mask == 0) ) {\n\n d++;\n\n a = a << 1;\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nclz requires sm_20 or higher.\n\nExamples\n\nclz.b32 d, a;\n\nclz.b64 cnt, X; // cnt is .u32\n\n ...",
+ "html": "
Count the number of leading zeros in a starting with the most-significant bit and place the\nresult in 32-bit destination register d. Operand a has the instruction type, and destination\nd has type .u32. For .b32 type, the number of leading zeros is between 0 and 32,\ninclusively. For .b64 type, the number of leading zeros is between 0 and 64, inclusively.
\nFor more information, visit clz(int) .",
+ "tooltip": "Count leading zeros.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-clz"
};
case "cnot":
return {
- "html": "For more information, visit cnot .
Compute the logical negation using C/C++ semantics.
\n
Semantics
\n
\n
d = (a==0) ? 1 : 0;\n
\n
\n
Notes
\n
The size of the operands must match, but not necessarily the type.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
cnot.b32 d,a;\n
\n
\n",
- "tooltip": "C/C++ style logical negation.\n\nSyntax\n\ncnot.type d, a;\n\n.type = { .b16, .b32, .b64 };\n\nDescription\n\nCompute the logical negation using C/C++ semantics.\n\nSemantics\n\nd = (a==0) ? 1 : 0;\n\nNotes\n\nThe size of the operands must match, but not necessarily the type.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\ncnot.b32 d,a;\n\n ...",
+ "html": "
Compute the logical negation using C/C++ semantics.
\nFor more information, visit cnot .",
+ "tooltip": "C/C++ style logical negation.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-cnot"
};
- case "common":
- return {
- "html": "For more information, visit common .
Linking Directives: .common
\n\n\n
Visible (externally) symbol declaration.
\n
Syntax
\n
\n
.common identifier\n
\n
\n
Description
\n
Declares identifier to be globally visible but \u201ccommon\u201d.
\n
Common symbols are similar to globally visible symbols. However multiple object files may declare\nthe same common symbol and they may have different types and sizes and references to a symbol get\nresolved against a common symbol with the largest size.
\n
Only one object file can initialize a common symbol and that must have the largest size among all\nother definitions of that common symbol from different object files.
\n
.common linking directive can be used only on variables with .global storage. It cannot be\nused on function symbols or on symbols with opaque type.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 5.0.
\n
Target ISA Notes
\n
.common directive requires sm_20 or higher.
\n
Examples
\n
\n
.common .global .u32 gbl;\n
\n
\n",
- "tooltip": "Visible (externally) symbol declaration.\n\nSyntax\n\n.common identifier\n\nDescription\n\nDeclares identifier to be globally visible but \u201ccommon\u201d.\n\nCommon symbols are similar to globally visible symbols. However multiple object files may declare\n\nthe same common symbol and they may have different types and sizes and references to a symbol get\n\nresolved against a common symbol with the largest size.\n\nOnly one object file can initialize a common symbol and that must have the largest size among all\n\nother definitions of that common symbol from different object files.\n\n.common linking directive can be used only on variables with .global storage. It cannot be\n\nused on function symbols or on symbols with opaque type.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 5.0.\n\nTarget ISA Notes\n\n.common directive requires sm_20 or higher.\n\nExamples\n\n.common .global .u32 gbl;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#linking-directives-common"
- };
-
case "copysign":
return {
- "html": "For more information, visit copysign(fp) .
Floating Point Instructions: copysign
\n\n\n
Copy sign of one input to another.
\n
Syntax
\n
\n
copysign.type d, a, b;\n\n.type = { .f32, .f64 };\n
\n
\n
Description
\n
Copy sign bit of a into value of b, and return the result as d.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
Requires sm_20 or higher.
\n
Examples
\n
\n
copysign.f32 x, y, z;\ncopysign.f64 A, B, C;\n
\n
\n",
- "tooltip": "Copy sign of one input to another.\n\nSyntax\n\ncopysign.type d, a, b;\n\n.type = { .f32, .f64 };\n\nDescription\n\nCopy sign bit of a into value of b, and return the result as d.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nRequires sm_20 or higher.\n\nExamples\n\ncopysign.f32 x, y, z;\n\ncopysign.f64 A, B, C;\n\n ...",
+ "html": "
Copy sign bit of a into value of b, and return the result as d.
\nFor more information, visit copysign(fp) .",
+ "tooltip": "Copy sign of one input to another.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-copysign"
};
case "cos":
return {
- "html": "For more information, visit cos(fp) .
Floating Point Instructions: cos
\n\n\n
Find the cosine of a value.
\n
Syntax
\n
\n
cos.approx{.ftz}.f32 d, a;\n
\n
\n
Description
\n
Find the cosine of the angle a (in radians).
\n
Semantics
\n
\n
d = cos(a);\n
\n
\n
Notes
\n
cos.approx.f32 implements a fast approximation to cosine.
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
NaN
\n
\n
\n
-subnormal
\n
+1.0
\n
\n
\n
-0.0
\n
+1.0
\n
\n
\n
+0.0
\n
+1.0
\n
\n
\n
+subnormal
\n
+1.0
\n
\n
\n
+Inf
\n
NaN
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
The maximum absolute error is 2-20.9 in quadrant 00.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
cos.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
Subnormal inputs and results to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
cos.f32 introduced in PTX ISA version 1.0. Explicit modifiers .approx and .ftz\nintroduced in PTX ISA version 1.4.
\n
For PTX ISA version 1.4 and later, the .approx modifier is required.
\n
For PTX ISA versions 1.0 through 1.3, cos.f32 defaults to cos.approx.ftz.f32.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
cos.approx.ftz.f32 ca, a;\n
\n
\n",
- "tooltip": "Find the cosine of a value.\n\nSyntax\n\ncos.approx{.ftz}.f32 d, a;\n\nDescription\n\nFind the cosine of the angle a (in radians).\n\nSemantics\n\nd = cos(a);\n\nNotes\n\ncos.approx.f32 implements a fast approximation to cosine.\n\n\n\nInput\n\nResult\n\n\n\n-Inf\n\nNaN\n\n-subnormal\n\n+1.0\n\n-0.0\n\n+1.0\n\n+0.0\n\n+1.0\n\n+subnormal\n\n+1.0\n\n+Inf\n\nNaN\n\nNaN\n\nNaN\n\nThe maximum absolute error is 2-20.9 in quadrant 00.\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, subnormal numbers are supported.\n\ncos.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.\n\nsm_1x\n\nSubnormal inputs and results to sign-preserving zero.\n\nPTX ISA Notes\n\ncos.f32 introduced in PTX ISA version 1.0. Explicit modifiers .approx and .ftz\n\nintroduced in PTX ISA version 1.4.\n\nFor PTX ISA version 1.4 and later, the .approx modifier is required.\n\nFor PTX ISA versions 1.0 through 1.3, cos.f32 defaults to cos.approx.ftz.f32.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\ncos.approx.ftz.f32 ca, a;\n\n ...",
+ "html": "
cp.async is a non-blocking instruction which initiates an asynchronous copy operation of data\nfrom the location specified by source address operand src to the location specified by\ndestination address operand dst. Operand src specifies a location in the global state space\nand dst specifies a location in the shared state space.
\n
Operand cp-size is an integer constant which specifies the size of data in bytes to be copied to\nthe destination dst. cp-size can only be 4, 8 and 16.
\n
Instruction cp.async allows optionally specifying a 32-bit integer operand src-size. Operand\nsrc-size represents the size of the data in bytes to be copied from src to dst and must\nbe less than cp-size. In such case, remaining bytes in destination dst are filled with\nzeros. Specifying src-size larger than cp-size results in undefined behavior.
\n
The optional and non-immediate predicate argument ignore-src specifies whether the data from the\nsource location src should be ignored completely. If the source data is ignored then zeros will\nbe copied to destination dst. If the argument ignore-src is not specified then it defaults\nto False.
\n
Supported alignment requirements and addressing modes for operand src and dst are described\nin Addresses as Operands.
\n
The mandatory .async qualifier indicates that the cp instruction will initiate the memory\ncopy operation asynchronously and control will return to the executing thread before the copy\noperation is complete. The executing thread can then use cp.async.wait_all or\ncp.async.wait_group or mbarrier instructions to wait for\ncompletion of the asynchronous copy operation. No other synchronization mechanisms described in\nMemory Consistency Model can be used to guarantee the\ncompletion of the asynchronous copy operations.
\n
There is no ordering guarantee between two cp.async operations if they are not explicitly\nsynchronized using cp.async.wait_all or cp.async.wait_group or mbarrier instructions.
\n
As described in Cache Operators, the .cg qualifier indicates\ncaching of data only at global level cache L2 and not at L1 whereas .ca qualifier indicates\ncaching of data at all levels including L1 cache. Cache operator are treated as performance hints\nonly.
The .level::prefetch_size qualifier is a hint to fetch additional data of the specified size\ninto the respective cache level.The sub-qualifier prefetch_size can be set to either of 64B,\n128B, 256B thereby allowing the prefetch size to be 64 Bytes, 128 Bytes or 256 Bytes\nrespectively.
\n
The qualifier .level::prefetch_size may only be used with .global state space and with\ngeneric addressing where the address points to .global state space. If the generic address does\nnot fall within the address window of the global memory, then the prefetching behavior is undefined.
\n
The .level::prefetch_size qualifier is treated as a performance hint only.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
The qualifier .level::cache_hint is only supported for .global state space and for generic\naddressing where the address points to the .global state space.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Support for .level::cache_hint and .level::prefetch_size qualifiers introduced in PTX ISA\nversion 7.4.
\n
Support for ignore-src operand introduced in PTX ISA version 7.5.
\n
Support for sub-qualifier ::cta introduced in PTX ISA version 7.8.
cp.async.bulk is a non-blocking instruction which initiates an asynchronous bulk-copy operation\nfrom the location specified by source address operand srcMem to the location specified by\ndestination address operand dstMem.
\n
The direction of bulk-copy is from the state space specified by the .src modifier to the state\nspace specified by the .dst modifiers.
\n
The 32-bit operand size specifies the amount of memory to be copied, in terms of number of\nbytes. size must be a multiple of 16. If the value is not a multiple of 16, then the behavior is\nundefined. The memory range [dstMem,dstMem+size-1] must not overflow the destination memory\nspace and the memory range [srcMem,srcMem+size-1] must not overflow the source memory\nspace. Otherwise, the behavior is undefined. The addresses dstMem and srcMem must be aligned\nto 16 bytes.
\n
When the source of the copy is .shared::cta and the destination is .shared::cluster, the\ndestination has to be in the shared memory of a different CTA within the cluster.
\n
The modifier .completion_mechanism specifies the completion mechanism that is supported on the\ninstruction variant. The completion mechanisms that are supported for different variants are\nsummarized in the following table:
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
Completion mechanism
\n
.dst
\n
.src
\n
Description
\n
\n\n\n
\n
.mbarrier::...
\n
.shared::cluster
\n
.global
\n
mbarrier based completion mechanism
\n
\n
\n
.shared::cluster
\n
.shared::cta
\n
\n
\n
.bulk_group
\n
.global
\n
.shared::cta
\n
Bulk async-group based completion mechanism
\n
\n\n
\n
The modifier .mbarrier::complete_tx::bytes specifies that the cp.async.bulk variant uses\nmbarrier based completion mechanism. The complete-tx\noperation, with completeCount argument equal to amount of data copied in bytes, will be\nperformed on the mbarrier object specified by the operand mbar.
\n
The modifier .bulk_group specifies that the cp.async.bulk variant uses bulk async-group\nbased completion mechanism.
\n
The optional modifier .multicast::cluster allows copying of data from global memory to shared\nmemory of multiple CTAs in the cluster. Operand ctaMask specifies the destination CTAs in the\ncluster such that each bit position in the 16-bit ctaMask operand corresponds to the %ctaid\nof the destination CTA. The source data is multicast to the same CTA-relative offset as dstMem\nin the shared memory of each destination CTA. The mbarrier signal is also multicast to the same\nCTA-relative offset as mbar in the shared memory of the destination CTA.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program. The\nqualifier .level::cache_hint is only supported when at least one of the .src or .dst\nstatespaces is .global state space.
\n
The copy operation in cp.async.bulk is treated as a weak memory operation and the complete-tx\noperation on the mbarrier has .release semantics at the .cluster scope as described in the\nMemory Consistency Model.
\n
Notes
\n
.multicast::cluster qualifier is optimized for target architecture sm_90a and may have\nsubstantially reduced performance on other targets and hence .multicast::cluster is advised to\nbe used with .targetsm_90a.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
.multicast::cluster qualifier advised to be used with .targetsm_90a.
Data Movement and Conversion Instructions: cp.async.bulk.commit_group
\n\n\n
Commits all prior initiated but uncommitted cp.async.bulk instructions into a\ncp.async.bulk-group.
\n
Syntax
\n
\n
cp.async.bulk.commit_group;\n
\n
\n
Description
\n
cp.async.bulk.commit_group instruction creates a new per-thread bulk async-group and batches\nall prior cp{.reduce}.async.bulk.{.prefetch}{.tensor} instructions satisfying the following\nconditions into the new bulk async-group:
\n
\n
The prior cp{.reduce}.async.bulk.{.prefetch}{.tensor} instructions use bulk_group based\ncompletion mechanism, and
\n
They are initiated by the executing thread but not committed to any bulk async-group.
\n
\n
If there are no uncommitted cp{.reduce}.async.bulk.{.prefetch}{.tensor} instructions then\ncp.async.bulk.commit_group results in an empty bulk async-group.
\n
An executing thread can wait for the completion of all\ncp{.reduce}.async.bulk.{.prefetch}{.tensor} operations in a bulk async-group using\ncp.async.wait_group.
\n
There is no memory ordering guarantee provided between any two\ncp{.reduce}.async.bulk.{.prefetch}{.tensor} operations within the same bulk async-group.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
cp.async.bulk.commit_group;\n
\n
\n\n
Data Movement and Conversion Instructions: cp.async.bulk.prefetch
\n\n\n
Provides a hint to the system to initiate the asynchronous prefetch of data to the cache.
cp.async.bulk.prefetch is a non-blocking instruction which may initiate an asynchronous prefetch\nof data from the location specified by source address operand srcMem, in .src statespace, to\nthe L2 cache.
\n
The 32-bit operand size specifies the amount of memory to be prefetched in terms of number of\nbytes. size must be a multiple of 16. If the value is not a multiple of 16, then the behavior is\nundefined. The memory range [dstMem,dstMem+size-1] must not overflow the destination memory\nspace and the memory range [srcMem,srcMem+size-1] must not overflow the source memory\nspace. Otherwise, the behavior is undefined. The address srcMem must be aligned to 16 bytes.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
cp.async.bulk.prefetch.tensor is a non-blocking instruction which may initiate an asynchronous\nprefetch of tensor data from the location in .src statespace to the L2 cache.
\n
The operand tensorMap is the generic address of the opaque tensor-map object which resides\neither in .param space or .const space or .global space. The operand tensorMap specifies\nthe properties of the tensor copy operation, as described in Tensor-map.\nThe tensorMap is accessed in tensormap proxy. Refer to the CUDA programming guide for creating\nthe tensor-map objects on the host side.
\n
The dimension of the tensor data is specified by the .dim modifier.
\n
The vector operand tensorCoords specifies the starting coordinates in the tensor data in the\nglobal memory from or to which the copy operation has to be performed. The number of tensor\ncoordinates in the vector argument tensorCoords should be equal to the dimension specified by\nthe modifier .dim. The individual tensor coordinates in tensorCoords are of type .s32.
\n
The qualifier .load_mode specifies how the data in the source location is copied into the\ndestination location. If .load_mode is not specified, it defaults to .tile. In .tile\nmode, the multi-dimensional layout of the source tensor is preserved at the destination.\nIn .im2col mode, some dimensions of the source tensors are unrolled in a single dimensional column\nat the destination. Details of the im2col mode are described in Im2col mode.\nIn .im2col mode, the tensor has to be at least 3-dimensional. The vector operand im2colOffsets can\nbe specified only when .load_mode is .im2col. The length of the vector operand im2colOffsets\nis two less than the number of dimension .dim of the tensor operation.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
\n
cp.async.bulk.prefetch.tensor is treated as a weak memory operation in the Memory Consistency\nModel.
cp.async.bulk.tensor is a non-blocking instruction which initiates an asynchronous copy\noperation of tensor data from the location in .src state space to the location in the .dst\nstate space.
\n
The operand dstMem specifies the location in the .dst state space into which the tensor data\nhas to be copied and srcMem specifies the location in the .src state space from which the\ntensor data has to be copied.
\n
The operand tensorMap is the generic address of the opaque tensor-map object which resides\neither in .param space or .const space or .global space. The operand tensorMap specifies\nthe properties of the tensor copy operation, as described in Tensor-map.\nThe tensorMap is accessed in tensormap proxy. Refer to the CUDA programming guide for creating\nthe tensor-map objects on the host side.
\n
The dimension of the tensor data is specified by the .dim modifier.
\n
The vector operand tensorCoords specifies the starting coordinates in the tensor data in the\nglobal memory from or to which the copy operation has to be performed. The number of tensor\ncoordinates in the vector argument tensorCoords should be equal to the dimension specified by\nthe modifier .dim. The individual tensor coordinates in tensorCoords are of type .s32.
\n
The modifier .completion_mechanism specifies the completion mechanism that is supported on the\ninstruction variant. The completion mechanisms that are supported for different variants are\nsummarized in the following table:
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
Completion mechanism
\n
.dst
\n
.src
\n
Description
\n
\n\n\n
\n
.mbarrier::...
\n
.shared::cluster
\n
.global
\n
mbarrier based completion mechanism
\n
\n
\n
.bulk_group
\n
.global
\n
.shared::cta
\n
Bulk async-group based completion mechanism
\n
\n\n
\n
The modifier .mbarrier::complete_tx::bytes specifies that the cp.async.bulk.tensor variant\nuses mbarrier based completion mechanism. The complete-tx\noperation, with completeCount argument equal to amount of data copied in bytes, will be\nperformed on the mbarrier object specified by the operand mbar.
\n
The modifier .bulk_group specifies that the cp.async.bulk.tensor variant uses bulk\nasync-group based completion mechanism.
\n
The qualifier .load_mode specifies how the data in the source location is copied into the\ndestination location. If .load_mode is not specified, it defaults to .tile. In .tile\nmode, the multi-dimensional layout of the source tensor is preserved at the destination. In\n.im2col mode, some dimensions of the source tensors are unrolled in a single dimensional column\nat the destination. Details of the im2col mode are described in Im2col mode. In .im2col mode, the tensor has to be at least\n3-dimensional. The vector operand im2colOffsets can be specified only when .load_mode is\n.im2col. The length of the vector operand im2colOffsets is two less than the number of dimension\n.dim of the tensor operation. The modifier .im2col_no_offs is the same as .im2col mode\nexcept there is no im2colOffsets vector involved.
\n
The optional modifier .multicast::cluster allows copying of data from global memory to shared\nmemory of multiple CTAs in the cluster. Operand ctaMask specifies the destination CTAs in the\ncluster such that each bit position in the 16-bit ctaMask operand corresponds to the %ctaid\nof the destination CTA. The source data is multicast to the same offset as dstMem in the shared\nmemory of each destination CTA. The mbarrier signal is also multicast to the same offset as mbar\nin the shared memory of the destination CTA.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program. The\nqualifier .level::cache_hint is only supported when at least one of the .src or .dst\nstatespaces is .global state space.
\n
The copy operation in cp.async.bulk.tensor is treated as a weak memory operation and the\ncomplete-tx\noperation on the mbarrier has .release semantics at the .cluster scope as described in the\nMemory Consistency Model.
\n
Notes
\n
.multicast::cluster qualifier is optimized for target architecture sm_90a and may have\nsubstantially reduced performance on other targets and hence .multicast::cluster is advised to\nbe used with .targetsm_90a.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
.multicast::cluster qualifier advised to be used with .targetsm_90a.
Data Movement and Conversion Instructions: cp.async.bulk.wait_group
\n\n\n
Wait for completion of bulk async-groups.
\n
Syntax
\n
\n
cp.async.bulk.wait_group{.read} N;\n
\n
\n
Description
\n
cp.async.bulk.wait_group instruction will cause the executing thread to wait until only N or\nfewer of the most recent bulk async-groups are pending and all the prior bulk async-groups\ncommitted by the executing threads are complete. For example, when N is 0, the executing thread\nwaits on all the prior bulk async-groups to complete. Operand N is an integer constant.
\n
By default, cp.async.bulk.wait_group instruction will cause the executing thread to wait till\nall the bulk async operations in the specified bulk async-group have completed all of the\nfollowing:
\n
\n
Reading from the source locations.
\n
Writing to their respective destination locations.
\n
Writes being made visible to the executing thread.
\n
\n
The optional .read modifier indicates that the waiting has to be done until all the bulk async\noperations in the specified bulk async-group have completed reading from their source locations.
Data Movement and Conversion Instructions: cp.async.commit_group
\n\n\n
Commits all prior initiated but uncommitted cp.async instructions into a cp.async-group.
\n
Syntax
\n
\n
cp.async.commit_group ;\n
\n
\n
Description
\n
cp.async.commit_group instruction creates a new cp.async-group per thread and batches all\nprior cp.async instructions initiated by the executing thread but not committed to any\ncp.async-group into the new cp.async-group. If there are no uncommitted cp.async\ninstructions then cp.async.commit_group results in an empty cp.async-group.
\n
An executing thread can wait for the completion of all cp.async operations in a cp.async-group\nusing cp.async.wait_group.
\n
There is no memory ordering guarantee provided between any two cp.async operations within the\nsame cp.async-group. So two or more cp.async operations within a cp.async-group copying data\nto the same location results in undefined behavior.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
// Example 1:\ncp.async.ca.shared.global [shrd], [gbl], 4;\ncp.async.commit_group ; // Marks the end of a cp.async group\n\n// Example 2:\ncp.async.ca.shared.global [shrd1], [gbl1], 8;\ncp.async.ca.shared.global [shrd1+8], [gbl1+8], 8;\ncp.async.commit_group ; // Marks the end of cp.async group 1\n\ncp.async.ca.shared.global [shrd2], [gbl2], 16;\ncp.async.cg.shared.global [shrd2+16], [gbl2+16], 16;\ncp.async.commit_group ; // Marks the end of cp.async group 2\n
\n
\n\n
Parallel Synchronization and Communication Instructions: cp.async.mbarrier.arrive
\n\n\n
Makes the mbarrier object track all prior cp.async operations initiated by the\nexecuting thread.
Causes an arrive-on operation to be\ntriggered by the system on the mbarrier object upon the completion of all prior cp.async operations initiated by the\nexecuting thread. The mbarrier object is at the location specified by the operand addr. The\narrive-on operation is\nasynchronous to execution of cp.async.mbarrier.arrive.
\n
When .noinc modifier is not specified, the pending count of the mbarrier object is incremented\nby 1 prior to the asynchronous arrive-on operation. This\nresults in a zero-net change for the pending count from the asynchronous arrive-on operation\nduring the current phase. The pending count of the mbarrier object after the increment should not\nexceed the limit as mentioned in Contents of the mbarrier object. Otherwise,\nthe behavior is undefined.
\n
When the .noinc modifier is specified, the increment to the pending count of the mbarrier\nobject is not performed. Hence the decrement of the pending count done by the asynchronous\narrive-on operation must be\naccounted for in the initialization of the mbarrier object.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
// Example 1: no .noinc\nmbarrier.init.shared.b64 [shMem], threadCount;\n....\ncp.async.ca.shared.global [shard1], [gbl1], 4;\ncp.async.cg.shared.global [shard2], [gbl2], 16;\n....\n// Absence of .noinc accounts for arrive-on from completion of prior cp.async operations.\n// So mbarrier.init must only account for arrive-on from mbarrier.arrive.\ncp.async.mbarrier.arrive.shared.b64 [shMem];\n....\nmbarrier.arrive.shared.b64 state, [shMem];\n\nwaitLoop:\nmbarrier.test_wait.shared.b64 p, [shMem], state;\n@!p bra waitLoop;\n\n\n\n// Example 2: with .noinc\n\n// Tracks arrive-on from mbarrier.arrive and cp.async.mbarrier.arrive.\n\n// All threads participating in the mbarrier perform cp.async\nmov.b32 copyOperationCnt, threadCount;\n\n// 3 arrive-on operations will be triggered per-thread\nmul.lo.u32 copyArrivalCnt, copyOperationCnt, 3;\n\nadd.u32 totalCount, threadCount, copyArrivalCnt;\n\nmbarrier.init.shared.b64 [shMem], totalCount;\n....\ncp.async.ca.shared.global [shard1], [gbl1], 4;\ncp.async.cg.shared.global [shard2], [gbl2], 16;\n...\n// Presence of .noinc requires mbarrier initalization to have accounted for arrive-on from cp.async\ncp.async.mbarrier.arrive.noinc.shared.b64 [shMem]; // 1st instance\n....\ncp.async.ca.shared.global [shard3], [gbl3], 4;\ncp.async.ca.shared.global [shard4], [gbl4], 16;\ncp.async.mbarrier.arrive.noinc.shared::cta.b64 [shMem]; // 2nd instance\n....\ncp.async.ca.shared.global [shard5], [gbl5], 4;\ncp.async.cg.shared.global [shard6], [gbl6], 16;\ncp.async.mbarrier.arrive.noinc.shared.b64 [shMem]; // 3rd and last instance\n....\nmbarrier.arrive.shared.b64 state, [shMem];\n\nwaitLoop:\nmbarrier.test_wait.shared.b64 p, [shMem], state;\n@!p bra waitLoop;\n
\n
\n\n
Data Movement and Conversion Instructions: cp.async.wait_group / cp.async.wait_all
\n\n\n
Wait for completion of prior asynchronous copy operations.
\n
Syntax
\n
\n
cp.async.wait_group N;\ncp.async.wait_all ;\n
\n
\n
Description
\n
cp.async.wait_group instruction will cause executing thread to wait till only N or fewer of\nthe most recent cp.async-groups are pending and all the prior cp.async-groups committed by\nthe executing threads are complete. For example, when N is 0, the executing thread waits on all\nthe prior cp.async-groups to complete. Operand N is an integer constant.
\n
cp.async.wait_all is equivalent to :
\n
\n
cp.async.commit_group;\ncp.async.wait_group 0;\n
\n
\n
An empty cp.async-group is considered to be trivially complete.
\n
Writes performed by cp.async operations are made visible to the executing thread only after:
\n\n
The completion of cp.async.wait_all or
\n
The completion of cp.async.wait_group on the cp.async-group in which the cp.async\nbelongs to or
\n
mbarrier.test_wait\nreturns True on an mbarrier object which is tracking the completion of the cp.async\noperation.
\n\n
There is no ordering between two cp.async operations that are not synchronized with\ncp.async.wait_all or cp.async.wait_group or mbarrier objects.
\n
cp.async.wait_group and cp.async.wait_all does not provide any ordering and visibility\nguarantees for any other memory operation apart from cp.async.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
// Example of .wait_all:\ncp.async.ca.shared.global [shrd1], [gbl1], 4;\ncp.async.cg.shared.global [shrd2], [gbl2], 16;\ncp.async.wait_all; // waits for all prior cp.async to complete\n\n// Example of .wait_group :\ncp.async.ca.shared.global [shrd3], [gbl3], 8;\ncp.async.commit_group; // End of group 1\n\ncp.async.cg.shared.global [shrd4], [gbl4], 16;\ncp.async.commit_group; // End of group 2\n\ncp.async.cg.shared.global [shrd5], [gbl5], 16;\ncp.async.commit_group; // End of group 3\n\ncp.async.wait_group 1; // waits for group 1 and group 2 to complete\n
\n
\n\n
Data Movement and Conversion Instructions: cp.async.wait_group / cp.async.wait_all
\n\n\n
Wait for completion of prior asynchronous copy operations.
\n
Syntax
\n
\n
cp.async.wait_group N;\ncp.async.wait_all ;\n
\n
\n
Description
\n
cp.async.wait_group instruction will cause executing thread to wait till only N or fewer of\nthe most recent cp.async-groups are pending and all the prior cp.async-groups committed by\nthe executing threads are complete. For example, when N is 0, the executing thread waits on all\nthe prior cp.async-groups to complete. Operand N is an integer constant.
\n
cp.async.wait_all is equivalent to :
\n
\n
cp.async.commit_group;\ncp.async.wait_group 0;\n
\n
\n
An empty cp.async-group is considered to be trivially complete.
\n
Writes performed by cp.async operations are made visible to the executing thread only after:
\n\n
The completion of cp.async.wait_all or
\n
The completion of cp.async.wait_group on the cp.async-group in which the cp.async\nbelongs to or
\n
mbarrier.test_wait\nreturns True on an mbarrier object which is tracking the completion of the cp.async\noperation.
\n\n
There is no ordering between two cp.async operations that are not synchronized with\ncp.async.wait_all or cp.async.wait_group or mbarrier objects.
\n
cp.async.wait_group and cp.async.wait_all does not provide any ordering and visibility\nguarantees for any other memory operation apart from cp.async.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
// Example of .wait_all:\ncp.async.ca.shared.global [shrd1], [gbl1], 4;\ncp.async.cg.shared.global [shrd2], [gbl2], 16;\ncp.async.wait_all; // waits for all prior cp.async to complete\n\n// Example of .wait_group :\ncp.async.ca.shared.global [shrd3], [gbl3], 8;\ncp.async.commit_group; // End of group 1\n\ncp.async.cg.shared.global [shrd4], [gbl4], 16;\ncp.async.commit_group; // End of group 2\n\ncp.async.cg.shared.global [shrd5], [gbl5], 16;\ncp.async.commit_group; // End of group 3\n\ncp.async.wait_group 1; // waits for group 1 and group 2 to complete\n
\n
\n\n
Data Movement and Conversion Instructions: cp.reduce.async.bulk
cp.reduce.async.bulk is a non-blocking instruction which initiates an asynchronous reduction\noperation on an array of memory locations specified by the destination address operand dstMem\nwith the source array whose location is specified by the source address operand srcMem. The size\nof the source and the destination array must be the same and is specified by the operand size.
\n
Each data element in the destination array is reduced inline with the corresponding data element in\nthe source array with the reduction operation specified by the modifier .redOp. The type of each\ndata element in the source and the destination array is specified by the modifier .type.
\n
The source address operand srcMem is located in the state space specified by .src and the\ndestination address operand dstMem is located in the state specified by the .dst.
\n
The 32-bit operand size specifies the amount of memory to be copied from the source location and\nused in the reduction operation, in terms of number of bytes. size must be a multiple of 16. If\nthe value is not a multiple of 16, then the behavior is undefined. The memory range [dstMem,\ndstMem+size-1] must not overflow the destination memory space and the memory range [srcMem,\nsrcMem+size-1] must not overflow the source memory space. Otherwise, the behavior is\nundefined. The addresses dstMem and srcMem must be aligned to 16 bytes.
\n
The operations supported by .redOp are classified as follows:
\n
\n
The bit-size operations are .and, .or, and .xor.
\n
The integer operations are .add, .inc, .dec, .min, and .max. The .inc and\n.dec operations return a result in the range [0..x] where x is the value at the source\nstate space.
\n
The floating point operation .add rounds to the nearest even. The current implementation of\ncp.reduce.async.bulk.add.f32 flushes subnormal inputs and results to sign-preserving zero. The\ncp.reduce.async.bulk.add.f16 and cp.reduce.async.bulk.add.bf16 operations require\n.noftz qualifier. It preserves input and result subnormals, and does not flush them to zero.
\n
\n
The following table describes the valid combinations of .redOp and element type:
\n
\n
\n
\n
\n
\n
\n\n
\n
.dst
\n
.redOp
\n
Element type
\n
\n\n\n
\n
.shared::cluster
\n
.add
\n
.u32, .s32, .u64
\n
\n
\n
.min, .max
\n
.u32, .s32
\n
\n
\n
.inc, .dec
\n
.u32
\n
\n
\n
.and, .or, .xor
\n
.b32
\n
\n
\n
.global
\n
.add
\n
.u32, .s32, .u64, .f32, .f64, .f16, .bf16
\n
\n
\n
.min, .max
\n
.u32, .s32, .u64, .s64, .f16, .bf16
\n
\n
\n
.inc, .dec
\n
.u32
\n
\n
\n
.and, .or, .xor
\n
.b32, .b64
\n
\n\n
\n
The modifier .completion_mechanism specifies the completion mechanism that is supported on the\ninstruction variant. The completion mechanisms that are supported for different variants are\nsummarized in the following table:
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
Completion mechanism
\n
.dst
\n
.src
\n
Description
\n
\n\n\n
\n
.mbarrier::...
\n
.shared::cluster
\n
.global
\n
mbarrier based completion mechanism
\n
\n
\n
.shared::cluster
\n
.shared::cta
\n
\n
\n
.bulk_group
\n
.global
\n
.shared::cta
\n
Bulk async-group based completion mechanism
\n
\n\n
\n
The modifier .mbarrier::complete_tx::bytes specifies that the cp.reduce.async.bulk variant\nuses mbarrier based completion mechanism. The complete-tx\noperation, with completeCount argument equal to amount of data copied in bytes, will be\nperformed on the mbarrier object specified by the operand mbar.
\n
The modifier .bulk_group specifies that the cp.reduce.async.bulk variant uses bulk\nasync-group based completion mechanism.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program. The\nqualifier .level::cache_hint is only supported when at least one of the .src or .dst\nstatespaces is .global state space.
\n
Each reduction operation performed by the cp.reduce.async.bulk has individually .relaxed.gpu\nmemory ordering semantics. The load operations in cp.reduce.async.bulk are treated as weak\nmemory operation and the complete-tx\noperation on the mbarrier has .release semantics at the .cluster scope as described in the\nMemory Consistency Model.
cp.reduce.async.bulk.tensor is a non-blocking instruction which initiates an asynchronous\nreduction operation of tensor data in the .dst state space with tensor data in the .src\nstate space.
\n
The operand srcMem specifies the location of the tensor data in the .src state space using\nwhich the reduction operation has to be performed.
\n
The operand tensorMap is the generic address of the opaque tensor-map object which resides\neither in .param space or .const space or .global space. The operand tensorMap specifies\nthe properties of the tensor copy operation, as described in Tensor-map.\nThe tensorMap is accessed in tensormap proxy. Refer to the CUDA programming guide for creating\nthe tensor-map objects on the host side.
\n
Each element of the tensor data in the .dst state space is reduced inline with the corresponding\nelement from the tensor data in the .src state space. The modifier .redOp specifies the\nreduction operation used for the inline reduction. The type of each tensor data element in the\nsource and the destination tensor is specified in Tensor-map.
\n
The dimension of the tensor is specified by the .dim modifier.
\n
The vector operand tensorCoords specifies the starting coordinates of the tensor data in the\nglobal memory on which the reduce operation is to be performed. The number of tensor coordinates in\nthe vector argument tensorCoords should be equal to the dimension specified by the modifier\n.dim. The individual tensor coordinates are of the type .s32.
\n
The following table describes the valid combinations of .redOp and element type:
\n
\n
\n
\n
\n
\n\n
\n
.redOp
\n
Element type
\n
\n\n\n
\n
.add
\n
.u32, .s32, .u64, .f32, .f16, .bf16
\n
\n
\n
.min, .max
\n
.u32, .s32, .u64, .s64, .f16, .bf16
\n
\n
\n
.inc, .dec
\n
.u32
\n
\n
\n
.and, .or, .xor
\n
.b32, .b64
\n
\n\n
\n
The modifier .completion_mechanism specifies the completion mechanism that is supported on the\ninstruction variant. Value .bulk_group of the modifier .completion_mechanism specifies that\ncp.reduce.async.bulk.tensor instruction uses bulk async-group based completion mechanism.
\n
The qualifier .load_mode specifies how the data in the source location is copied into the\ndestination location. If .load_mode is not specified, it defaults to .tile. In .tile\nmode, the multi-dimensional layout of the source tensor is preserved at the destination. In\n.im2col_no_offs mode, some dimensions of the source tensors are unrolled in a single dimensional\ncolumn at the destination. Details of the im2col mode are described in Im2col mode. In .im2col mode, the tensor has to be at least\n3-dimensional.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program. The\nqualifier .level::cache_hint is only supported when at least one of the .src or .dst\nstatespaces is .global state space.
\n
Each reduction operation performed by cp.reduce.async.bulk.tensor has individually\n.relaxed.gpu memory ordering semantics. The load operations in cp.reduce.async.bulk.tensor\nare treated as weak memory operations and the complete-tx\noperation on the mbarrier has .release semantics at the .cluster scope as described in the\nMemory Consistency Model.
\n",
- "tooltip": "=====Data Movement and Conversion Instructions: cp.async\n\n\n\nInitiates an asynchronous copy operation from one state space to another.\n\nSyntax\n\ncp.async.ca.shared{::cta}.global{.level::cache_hint}{.level::prefetch_size}\n\n [dst], [src], cp-size{, src-size}{, cache-policy} ;\n\ncp.async.cg.shared{::cta}.global{.level::cache_hint}{.level::prefetch_size}\n\n [dst], [src], 16{, src-size}{, cache-policy} ;\n\ncp.async.ca.shared...\n\n=====Data Movement and Conversion Instructions: cp.async.bulk\n\n\n\nInitiates an asynchronous copy operation from one state space to another.\n\nSyntax\n\ncp.async.bulk.dst.src.completion_mechanism{.multicast}{.level::cache_hint}\n\n [dstMem], [srcMem], size, [mbar] {, ctaMask} {, cache-policy}\n\n.dst = { .shared::cluster }\n\n.src = { .global }\n\n.completion_mechanism = { .mbarrier::complete_tx::bytes }\n\n.level::cache_hint = ...\n\n=====Data Movement and Conversion Instructions: cp.async.bulk.commit_group\n\n\n\nCommits all prior initiated but uncommitted cp.async.bulk instructions into a\n\ncp.async.bulk-group.\n\nSyntax\n\ncp.async.bulk.commit_group;\n\nDescription\n\ncp.async.bulk.commit_group instruction creates a new per-thread bulk async-group and batches\n\nall prior cp{.reduce}.async.bulk.{.prefetch}{.tensor} instructions satisfying the following\n\nconditions into the new bulk async-group:\n\nThe prior cp{.reduce}.async...\n\n=====Data Movement and Conversion Instructions: cp.async.bulk.prefetch\n\n\n\nProvides a hint to the system to initiate the asynchronous prefetch of data to the cache.\n\nSyntax\n\ncp.async.bulk.prefetch.L2.src{.level::cache_hint} [srcMem], size {, cache-policy}\n\n.src = { .global }\n\n.level::cache_hint = { .L2::cache_hint }\n\nDescription\n\ncp.async.bulk.prefetch is a non-blocking instruction which may initiate an asynchronous prefetch\n\nof data from the location specifie...\n\n=====Data Movement and Conversion Instructions: cp.async.bulk.prefetch.tensor\n\n\n\nProvides a hint to the system to initiate the asynchronous prefetch of tensor data to the cache.\n\nSyntax\n\n// global -> shared::cluster:\n\ncp.async.bulk.prefetch.tensor.dim.L2.src{.load_mode}{.level::cache_hint} [tensorMap, tensorCoords]\n\n {, im2colOffsets } {, cache-policy}\n\n.src = { .global }\n\n.dim = { .1d, .2d, .3...\n\n=====Data Movement and Conversion Instructions: cp.async.bulk.tensor\n\n\n\nInitiates an asynchronous copy operation on the tensor data from one state space to another.\n\nSyntax\n\n// global -> shared::cluster:\n\ncp.async.bulk.tensor.dim.dst.src{.load_mode}.completion_mechanism{.multicast}{.level::cache_hint}\n\n [dstMem], [tensorMap, tensorCoords], [mbar]{, im2colOffsets}\n\n {, ctaMask} {, cache-policy}\n\n.dst = ...\n\n=====Data Movement and Conversion Instructions: cp.async.bulk.wait_group\n\n\n\nWait for completion of bulk async-groups.\n\nSyntax\n\ncp.async.bulk.wait_group{.read} N;\n\nDescription\n\ncp.async.bulk.wait_group instruction will cause the executing thread to wait until only N or\n\nfewer of the most recent bulk async-groups are pending and all the prior bulk async-groups\n\ncommitted by the executing threads are complete. For example, when N is 0, the executing thread\n\nwaits on all the prior b...\n\n=====Data Movement and Conversion Instructions: cp.async.commit_group\n\n\n\nCommits all prior initiated but uncommitted cp.async instructions into a cp.async-group.\n\nSyntax\n\ncp.async.commit_group ;\n\nDescription\n\ncp.async.commit_group instruction creates a new cp.async-group per thread and batches all\n\nprior cp.async instructions initiated by the executing thread but not committed to any\n\ncp.async-group into the new cp.async-group. If there are no uncommitted cp.async\n\ninstructio...\n\n=====Parallel Synchronization and Communication Instructions: cp.async.mbarrier.arrive\n\n\n\nMakes the mbarrier object track all prior cp.async operations initiated by the\n\nexecuting thread.\n\nSyntax\n\ncp.async.mbar ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-cp-async"
+ "html": "
cp.async is a non-blocking instruction which initiates an asynchronous copy operation of data\nfrom the location specified by source address operand src to the location specified by\ndestination address operand dst. Operand src specifies a location in the global state space\nand dst specifies a location in the shared state space.
\nFor more information, visit cp.async .",
+ "tooltip": "Initiates an asynchronous copy operation from one state space to another.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-non-bulk-copy"
};
case "createpolicy":
return {
- "html": "For more information, visit createpolicy .
Data Movement and Conversion Instructions: createpolicy
\n\n\n
Create a cache eviction policy for the specified cache level.
The createpolicy instruction creates a cache eviction policy for the specified cache level in an\nopaque 64-bit register specified by the destination operand cache-policy. The cache eviction\npolicy specifies how cache eviction priorities are applied to global memory addresses used in memory\noperations with .level::cache_hint qualifier.
\n
There are two types of cache eviction policies:
\n
\n
\n
Range-based policy
\n
The cache eviction policy created using createpolicy.range specifies the cache eviction\nbehaviors for the following three address ranges:
\n
\n
[a..a+(primary-size-1)] referred to as primary range.
\n
[a+primary-size..a+(total-size-1)] referred to as trailing secondary range.
\n
[a-(total-size-primary-size)..(a-1)] referred to as preceding secondary range.
\n
\n
When a range-based cache eviction policy is used in a memory operation with\n.level::cache_hint qualifier, the eviction priorities are applied as follows:
\n
\n
If the memory address falls in the primary range, the eviction priority specified by\n.L2::primary_priority is applied.
\n
If the memory address falls in any of the secondary ranges, the eviction priority specified by\n.L2::secondary_priority is applied.
\n
If the memory address does not fall in either of the above ranges, then the applied eviction\npriority is unspecified.
\n
\n
The 32-bit operand primary-size specifies the size, in bytes, of the primary range. The\n32-bit operand total-size specifies the combined size, in bytes, of the address range\nincluding primary and secondary ranges. The value of primary-size must be less than or equal\nto the value of total-size. Maximum allowed value of total-size is 4GB.
\n
If .L2::secondary_priority is not specified, then it defaults to .L2::evict_unchanged.
\n
If no state space is specified then Generic Addressing is\nused. If the specified address does not fall within the address window of .global state space\nthen the behavior is undefined.
\n
\n
\n
Fraction-based policy
\n
A memory operation with .level::cache_hint qualifier can use the fraction-based cache\neviction policy to request the cache eviction priority specified by .L2:primary_priority to\nbe applied to a fraction of cache accesses specified by the 32-bit floating point operand\nfraction. The remainder of the cache accesses get the eviction priority specified by\n.L2::secondary_priority. This implies that in a memory operation that uses a fraction-based\ncache policy, the memory access has a probability specified by the operand fraction of\ngetting the cache eviction priority specified by .L2::primary_priority.
\n
The valid range of values for the operand fraction is (0.0,..,1.0]. If the operand\nfraction is not specified, it defaults to 1.0.
\n
If .L2::secondary_priority is not specified, then it defaults to .L2::evict_unchanged.
\n
\n
\n
The access property created using the CUDA APIs can be converted into cache eviction policy by the\ninstruction createpolicy.cvt. The source operand access-property is a 64-bit opaque\nregister. Refer to CUDA programming guide for more details.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.4.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
createpolicy.fractional.L2::evict_last.b64 policy, 1.0;\ncreatepolicy.fractional.L2::evict_last.L2::evict_unchanged.b64 policy, 0.5;\n\ncreatepolicy.range.L2::evict_last.L2::evict_first.b64\n policy, [ptr], 0x100000, 0x200000;\n\n// access-prop is created by CUDA APIs.\ncreatepolicy.cvt.L2.b64 policy, access-prop;\n
\n
\n",
- "tooltip": "Create a cache eviction policy for the specified cache level.\n\nSyntax\n\n// Range-based policy\n\ncreatepolicy.range{.global}.level::primary_priority{.level::secondary_priority}.b64\n\n cache-policy, [a], primary-size, total-size;\n\n// Fraction-based policy\n\ncreatepolicy.fractional.level::primary_priority{.level::secondary_priority}.b64\n\n cache-policy{, fraction};\n\n// Converting the access property from CUDA APIs\n\ncreatepolicy.cvt.L2.b64 cache-policy, access-property;\n\n.level::primary_priority = { .L2::evict_last, .L2::evict_normal,\n\n .L2::evict_first, .L2::evict_unchanged };\n\n.level::secondary_priority = { .L2::evict_first, .L2::evict_unchanged };\n\nDescription\n\nThe createpolicy instruction creates a cache eviction policy for the specified cache level in an\n\nopaque 64-bit register specified by the destination operand cache-policy. The cache eviction\n\npolicy specifies how cache eviction priorities are applied to global memory addresses used in memory\n\noperations with .level::cache_hint qualifier.\n\nThere are two types of cache eviction policies:\n\nRange-based policy\n\nThe cache eviction policy created using createpolicy.range specifies the cache eviction\n\nbehaviors for the following three address ranges:\n\n[a .. a + (primary-size - 1)] referred to as primary range.\n\n[a + primary-size .. a + (total-size - 1)] referred to as trailing secondary range.\n\n[a - (total-size - primary-size) .. (a - 1)] referred to as preceding secondary range.\n\nWhen a range-based cache eviction policy is used in a memory operation with\n\n.level::cache_hint qualifier, the eviction priorities are applied as follows:\n\nIf the memory address falls in the primary range, the eviction priority specified by\n\n.L2::primary_priority is applied.\n\nIf the memory address falls in any of the secondary ranges, the eviction priority specified by\n\n.L2::secondary_priority is applied.\n\nIf the memory address does not fall in either of the above ranges, then the applied eviction\n\npriority is unspecified.\n\nThe 32-bit operand primary-size specifies the size, in bytes, of the primary range. The\n\n32-bit operand total-size specifies the combined size, in bytes, of the address range\n\nincluding primary and secondary ranges. The value of primary-size must be less than or equal\n\nto the value of total-size. Maximum allowed value of total-size is 4GB.\n\nIf .L2::secondary_priority is not specified, then it defaults to .L2::evict_unchanged.\n\nIf no state space is specified then Generic Addressing is\n\nused. If the specified address does not fall within the address window of .global state space\n\nthen the behavior is undefined.\n\nFraction-based policy\n\nA memory operation with .level::cache_hint qualifier can use the fraction-based cache\n\neviction policy to request the cache eviction priority specified by .L2:primary_priority to\n\nbe applied to a fraction of cache accesses specified by the 32-bit floating point operand\n\nfraction. The remainder of the cache accesses get the eviction priority specified by\n\n.L2::secondary_priority. This implies that in a memory operation that uses a fraction-based\n\ncache policy, the memory access has a probability specified by the operand fraction of\n\ngetting the cache eviction priority specified by .L2::primary_priority.\n\nThe valid range of values for the operand fraction is (0.0,.., 1.0]. If the operand\n\nfraction is not specified, it defaults to 1.0.\n\nIf .L2::secondary_priority is not specified, then it defaults to .L2::evict_unchanged.\n\nThe access property created using the CUDA APIs can be converted into cache eviction policy by the\n\ninstruction createpolicy.cvt. The source operand access-property is a 64-bit opaque\n\nregister. Refer to CUDA programming guide for more details.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.4.\n\nTarget ISA Notes\n\nRequires sm_80 or higher.\n\nExamples\n\ncreatepolicy.fractional.L2::evict_last.b64 policy, 1.0;\n\ncreatepolicy.fractional.L2::evict_last.L2::evict_unchanged.b64 polic ...",
+ "html": "
The createpolicy instruction creates a cache eviction policy for the specified cache level in an\nopaque 64-bit register specified by the destination operand cache-policy. The cache eviction\npolicy specifies how cache eviction priorities are applied to global memory addresses used in memory\noperations with .level::cache_hint qualifier.
\nFor more information, visit createpolicy .",
+ "tooltip": "Create a cache eviction policy for the specified cache level.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-createpolicy"
};
- case "ctaid":
- return {
- "html": "For more information, visit ctaid .
Special Registers: %ctaid
\n\n\n
CTA identifier within a grid.
\n
Syntax (predefined)
\n
\n
.sreg .v4 .u32 %ctaid; // CTA id vector\n.sreg .u32 %ctaid.x, %ctaid.y, %ctaid.z; // CTA id components\n
\n
\n
Description
\n
A predefined, read-only special register initialized with the CTA identifier within the CTA\ngrid. The %ctaid special register contains a 1D, 2D, or 3D vector, depending on the shape and\nrank of the CTA grid. The fourth element is unused and always returns zero.
Introduced in PTX ISA version 1.0 with type .v4.u16.
\n
Redefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n%ctaid.
\n",
- "tooltip": "CTA identifier within a grid.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %ctaid; // CTA id vector\n\n.sreg .u32 %ctaid.x, %ctaid.y, %ctaid.z; // CTA id components\n\nDescription\n\nA predefined, read-only special register initialized with the CTA identifier within the CTA\n\ngrid. The %ctaid special register contains a 1D, 2D, or 3D vector, depending on the shape and\n\nrank of the CTA grid. The fourth element is unused and always returns zero.\n\nIt is guaranteed that:\n\n0 <= %ctaid.x < %nctaid.x\n\n0 <= %ctaid.y < %nctaid.y\n\n0 <= %ctaid.z < %nctaid.z\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0 with type .v4.u16.\n\nRedefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\n\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n\n%ctaid.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.u32 %r0,%ctaid.x;\n\nmov.u16 %rh,%ctaid.y; // legacy code\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-ctaid"
- };
-
- case "current_graph_exec":
- return {
- "html": "For more information, visit current_graph_exec .
Special Registers: %current_graph_exec
\n\n\n
An Identifier for currently executing CUDA device graph.
\n
Syntax (predefined)
\n
\n
.sreg .u64 %current_graph_exec;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with the identifier referring to the CUDA\ndevice graph being currently executed. This register is 0 if the executing kernel is not part of a\nCUDA device graph.
\n
Refer to the CUDA Programming Guide for more details on CUDA device graphs.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Requires sm_50 or higher.
\n
Examples
\n
\n
mov.u64 r1, %current_graph_exec;\n
\n
\n",
- "tooltip": "An Identifier for currently executing CUDA device graph.\n\nSyntax (predefined)\n\n.sreg .u64 %current_graph_exec;\n\nDescription\n\nA predefined, read-only special register initialized with the identifier referring to the CUDA\n\ndevice graph being currently executed. This register is 0 if the executing kernel is not part of a\n\nCUDA device graph.\n\nRefer to the CUDA Programming Guide for more details on CUDA device graphs.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 8.0.\n\nTarget ISA Notes\n\nRequires sm_50 or higher.\n\nExamples\n\nmov.u64 r1, %current_graph_exec;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-current-graph-exec"
- };
-
case "cvt":
return {
- "html": "For more information, visit cvt , cvt.pack .
For .f16x2 and .bf16x2 instruction type, two inputs a and b of .f32 type are\nconverted into .f16 or .bf16 type and the converted values are packed in the destination\nregister d, such that the value converted from input a is stored in the upper half of d\nand the value converted from input b is stored in the lower half of d
\n
For .f16x2 instruction type, destination operand d has .f16x2 or .b32 type. For\n.bf16 instruction type, operand d has .b16 type. For .bf16x2 instruction type,\noperand d has .b32 type. For .tf32 instruction type, operand d has .b32 type.
\n
When converting to .e4m3x2/.e5m2x2 data formats, the destination operand d has .b16\ntype. When converting two .f32 inputs to .e4m3x2/.e5m2x2, each input is converted to the\nspecified format, and the converted values are packed in the destination operand d such that the\nvalue converted from input a is stored in the upper 8 bits of d and the value converted from\ninput b is stored in the lower 8 bits of d. When converting an .f16x2 input to\n.e4m3x2/ .e5m2x2, each .f16 input from operand a is converted to the specified\nformat. The converted values are packed in the destination operand d such that the value\nconverted from the upper 16 bits of input a is stored in the upper 8 bits of d and the value\nconverted from the lower 16 bits of input a is stored in the lower 8 bits of d.
\n
When converting from .e4m3x2/.e5m2x2 to .f16x2, source operand a has .b16\ntype. Each 8-bit input value in operand a is converted to .f16 type. The converted values\nare packed in the destination operand d such that the value converted from the upper 8 bits of\na is stored in the upper 16 bits of d and the value converted from the lower 8 bits of a\nis stored in the lower 16 bits of d.
\n
Rounding modifier is mandatory in all of the following cases:
\n
\n
float-to-float conversions, when destination type is smaller than source type
\n
All float-to-int conversions
\n
All int-to-float conversions
\n
All conversions involving .f16x2, .e4m3x2,.e5m2x2,, .bf16x2 and .tf32 instruction\ntypes.
\n
\n
.satfinite modifier is only supported for conversions involving the following types:
\n
\n
.e4m3x2 and .e5m2x2 destination types. .satfinite modifier is mandatory for such\nconversions.
\n
.f16, .bf16, .f16x2, .bf16x2 as destination types.
\n
.tf32 as destination type with rounding mode specified as round to nearest, ties away from\nzero.
\n
\n
Semantics
\n
\n
if (/* inst type is .f16x2 or .bf16x2 */) {\n d[31:16] = convert(a);\n d[15:0] = convert(b);\n} else {\n d = convert(a);\n}\n
\n
\n
Integer Notes
\n
Integer rounding is required for float-to-integer conversions, and for same-size float-to-float\nconversions where the value is rounded to an integer. Integer rounding is illegal in all other\ninstances.
\n
Integer rounding modifiers:
\n
\n
.rni
\n
\n
round to nearest integer, choosing even integer if source is equidistant between two integers
\n
\n
.rzi
\n
\n
round to nearest integer in the direction of zero
\n
\n
.rmi
\n
\n
round to nearest integer in direction of negative infinity
\n
\n
.rpi
\n
\n
round to nearest integer in direction of positive infinity
\n
\n
\n
In float-to-integer conversion, NaN inputs are converted to 0.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
For cvt.ftz.dtype.f32 float-to-integer conversions and cvt.ftz.f32.f32 float-to-float\nconversions with integer rounding, subnormal inputs are flushed to sign-preserving zero. Modifier\n.ftz can only be specified when either .dtype or .atype is .f32 and applies only\nto single precision (.f32) inputs and results.
\n
\n
sm_1x
\n
\n
For cvt.ftz.dtype.f32 float-to-integer conversions and cvt.ftz.f32.f32\nfloat-to-float conversions with integer rounding, subnormal inputs are flushed to sign-preserving\nzero. The optional .ftz modifier may be specified in these cases for clarity.
\n
Note: In PTX ISA versions 1.4 and earlier, the cvt instruction did not flush single-precision\nsubnormal inputs or results to zero if the destination type size was 64-bits. The compiler will\npreserve this behavior for legacy PTX code.
\n
\n
\n
Saturation modifier:
\n
\n
.sat
\n
\n
For integer destination types, .sat limits the result to MININT..MAXINT for the size of\nthe operation. Note that saturation applies to both signed and unsigned integer types.
\n
The saturation modifier is allowed only in cases where the destination type\u2019s value range is not\na superset of the source type\u2019s value range; i.e., the .sat modifier is illegal in cases\nwhere saturation is not possible based on the source and destination types.
\n
For float-to-integer conversions, the result is clamped to the destination range by default; i.e,\n.sat is redundant.
\n
\n
\n
Floating Point Notes
\n
Floating-point rounding is required for float-to-float conversions that result in loss of precision,\nand for integer-to-float conversions. Floating-point rounding is illegal in all other instances.
\n
Floating-point rounding modifiers:
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rna
\n
\n
mantissa LSB rounds to nearest, ties away from zero
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
A floating-point value may be rounded to an integral value using the integer rounding modifiers (see\nInteger Notes). The operands must be of the same size. The result is an integral value, stored in\nfloating-point format.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported. Modifier .ftz may be specified to flush\nsingle-precision subnormal inputs and results to sign-preserving zero. Modifier .ftz can only\nbe specified when either .dtype or .atype is .f32 and applies only to single\nprecision (.f32) inputs and results.
\n
\n
sm_1x
\n
\n
Single-precision subnormal inputs and results are flushed to sign-preserving zero. The optional\n.ftz modifier may be specified in these cases for clarity.
\n
\n
\n
Note: In PTX ISA versions 1.4 and earlier, the cvt instruction did not flush\nsingle-precision subnormal inputs or results to zero if either source or destination type was\n.f64. The compiler will preserve this behavior for legacy PTX code. Specifically, if the PTX\nISA version is 1.4 or earlier, single-precision subnormal inputs and results are flushed to\nsign-preserving zero only for cvt.f32.f16, cvt.f16.f32, and cvt.f32.f32 instructions.
\n
Saturation modifier:
\n
\n
\n.sat:
\n
\n
For floating-point destination types, .sat limits the result to the range [0.0, 1.0]. NaN\nresults are flushed to positive zero. Applies to .f16, .f32, and .f64 types.
\n
\n
\n.relu:
\n
\n
For .f16, .f16x2, .bf16, .bf16x2, .e4m3x2, .e5m2x2 and .tf32\ndestination types, .relu clamps the result to 0 if negative. NaN results are converted to\ncanonical NaN.
\n
\n
\n.satfinite:
\n
\n
For .f16, .f16x2, .bf16, .bf16x2, .e4m3x2, .e5m2x2 and .tf32\ndestination formats, if the input value is NaN, then the result is NaN in the specified\ndestination format. If the absolute value of input (ignoring sign) is greater than MAX_NORM of\nthe specified destination format, then the result is sign-preserved MAX_NORM of the destination\nformat.
\n
\n
\n
Notes
\n
A source register wider than the specified type may be used, except when the source operand has\n.bf16 or .bf16x2 format. The lower n bits corresponding to the instruction-type width\nare used in the conversion. See Operand Size Exceeding Instruction-Type Size for a description of these relaxed\ntype-checking rules.
\n
A destination register wider than the specified type may be used, except when the destination\noperand has .bf16, .bf16x2 or .tf32 format. The result of conversion is sign-extended to\nthe destination register width for signed integers, and is zero-extended to the destination register\nwidth for unsigned, bit-size, and floating-point types. See Operand Size Exceeding Instruction-Type\nSize for a description of these relaxed\ntype-checking rules.
\n
For cvt.f32.bf16, NaN input yields unspecified NaN.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
.relu modifier and {.f16x2, .bf16, .bf16x2, .tf32} destination formats\nintroduced in PTX ISA version 7.0.
\n
cvt.bf16.{u8/s8/u16/s16/u32/s32/u64/s64/f16/f64/bf16},\ncvt.{u8/s8/u16/s16/u32/s32/u64/s64/f16/f64}.bf16, and cvt.tf32.f32.{relu}.{rn/rz} introduced\nin PTX ISA 7.8.
\n
cvt with .e4m3x2/.e5m2x2 for sm_90 or higher introduced in PTX ISA version 7.8.
\n
cvt.satfinite.{e4m3x2,e5m2x2}.{f32,f16x2} for sm_90 or higher introduced in PTX ISA version 7.8.
\n
cvt with .e4m3x2/.e5m2x2 for sm_89 introduced in PTX ISA version 8.1.
\n
cvt.satfinite.{e4m3x2,e5m2x2}.{f32,f16x2} for sm_89 introduced in PTX ISA version 8.1.
\n
cvt.satfinite.{f16,bf16,f16x2,bf16x2,tf32}.f32 introduced in PTX ISA version 8.1.
\n
Target ISA Notes
\n
cvt to or from .f64 requires sm_13 or higher.
\n
.relu modifier and {.f16x2, .bf16, .bf16x2, .tf32} destination formats require\nsm_80 or higher.
\n
cvt.bf16.{u8/s8/u16/s16/u32/s32/u64/s64/f16/f64/bf16},\ncvt.{u8/s8/u16/s16/u32/s32/u64/s64/f16/f64}.bf16, and cvt.tf32.f32.{relu}.{rn/rz} require\nsm_90 or higher.
\n
cvt with .e4m3x2/.e5m2x2 requires sm89 or higher.
\n
cvt.satfinite.{e4m3x2,e5m2x2}.{f32,f16x2} requires sm_89 or higher.
\n
Examples
\n
\n
cvt.f32.s32 f,i;\ncvt.s32.f64 j,r; // float-to-int saturates by default\ncvt.rni.f32.f32 x,y; // round to nearest int, result is fp\ncvt.f32.f32 x,y; // note .ftz behavior for sm_1x targets\ncvt.rn.relu.f16.f32 b, f; // result is saturated with .relu saturation mode\ncvt.rz.f16x2.f32 b1, f, f1; // convert two fp32 values to packed fp16 outputs\ncvt.rn.relu.satfinite.f16x2.f32 b1, f, f1; // convert two fp32 values to packed fp16 outputs with .relu saturation on each output\ncvt.rn.bf16.f32 b, f; // convert fp32 to bf16\ncvt.rz.relu.satfinite.bf16.f3 2 b, f; // convert fp32 to bf16 with .relu and .satfinite saturation\ncvt.rz.satfinite.bf16x2.f32 b1, f, f1; // convert two fp32 values to packed bf16 outputs\ncvt.rn.relu.bf16x2.f32 b1, f, f1; // convert two fp32 values to packed bf16 outputs with .relu saturation on each output\ncvt.rna.satfinite.tf32.f32 b1, f; // convert fp32 to tf32 format\ncvt.rn.relu.tf32.f32 d, a; // convert fp32 to tf32 format\ncvt.f64.bf16.rp f, b; // convert bf16 to f64 format\ncvt.bf16.f16.rz b, f // convert f16 to bf16 format\ncvt.bf16.u64.rz b, u // convert u64 to bf16 format\ncvt.s8.bf16.rpi s, b // convert bf16 to s8 format\ncvt.bf16.bf16.rpi b1, b2 // convert bf16 to corresponding int represented in bf16 format\ncvt.rn.satfinite.e4m3x2.f32 d, a, b; // convert a, b to .e4m3 and pack as .e4m3x2 output\ncvt.rn.relu.satfinite.e5m2x2.f16x2 d, a; // unpack a and convert the values to .e5m2 outputs with .relu\n // saturation on each output and pack as .e5m2x2\ncvt.rn.f16x2.e4m3x2 d, a; // unpack a, convert two .e4m3 values to packed f16x2 output\n
\n
\n\n
Data Movement and Conversion Instructions: cvt.pack
\n\n\n
Convert two integer values from one integer type to another and pack the results.
Convert two 32-bit integers a and b into specified type and pack the results into d.
\n
Destination d is an unsigned 32-bit integer. Source operands a and b are integers of\ntype .abType and the source operand c is an integer of type .cType.
\n
The inputs a and b are converted to values of type specified by .convertType with\nsaturation and the results after conversion are packed into lower bits of d.
\n
If operand c is specified then remaining bits of d are copied from lower bits of c.
\n
Semantics
\n
\n
ta = a < MIN(convertType) ? MIN(convertType) : a;\nta = a > MAX(convertType) ? MAX(convertType) : a;\ntb = b < MIN(convertType) ? MIN(convertType) : b;\ntb = b > MAX(convertType) ? MAX(convertType) : b;\n\nsize = sizeInBits(convertType);\ntd = tb ;\nfor (i = size; i <= 2 * size - 1; i++) {\n td[i] = ta[i - size];\n}\n\nif (isU16(convertType) || isS16(convertType)) {\n d = td;\n} else {\n for (i = 0; i < 2 * size; i++) {\n d[i] = td[i];\n }\n for (i = 2 * size; i <= 31; i++) {\n d[i] = c[i - 2 * size];\n }\n}\n
\n
\n
.sat modifier limits the converted values to MIN(convertType)..MAX(convertedType) (no\noverflow) if the corresponding inputs are not in the range of datatype specified as\n.convertType.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.5.
\n
Target ISA Notes
\n
Requires sm_72 or higher.
\n
Sub byte types (.u4/.s4 and .u2/.s2) requires sm_75 or higher.
\n",
- "tooltip": "=====Data Movement and Conversion Instructions: cvt\n\n\n\nConvert a value from one type to another.\n\nSyntax\n\ncvt{.irnd}{.ftz}{.sat}.dtype.atype d, a; // integer rounding\n\ncvt{.frnd}{.ftz}{.sat}.dtype.atype d, a; // fp rounding\n\ncvt.frnd2{.relu}{.satfinite}.f16.f32 d, a;\n\ncvt.frnd2{.relu}{.satfinite}.f16x2.f32 d, a, b;\n\ncvt.frnd2{.relu}{.satfinite}.bf16.f32 d, a;\n\ncvt.frnd2{.relu}{.satfinite}.bf16x2.f32 d, a, b;\n\ncvt.rna{.satfi...\n\n=====Data Movement and Conversion Instructions: cvt.pack\n\n\n\nConvert two integer values from one integer type to another and pack the results.\n\nSyntax\n\ncvt.pack.sat.convertType.abType d, a, b;\n\n .convertType = { .u16, .s16 }\n\n .abType = { .s32 }\n\ncvt.pack.sat.convertType.abType.cType d, a, b, c;\n\n .convertType = { .u2, .s2, .u4, .s4, .u8, .s8 }\n\n .abType = { .s32 }\n\n .cType = { .b32 }\n\nDescription\n\nConvert two 32-bit integers a a... ...",
+ "html": "
Convert between different types and sizes.
\nFor more information, visit cvt .",
+ "tooltip": "Convert a value from one type to another.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-cvt"
};
case "cvta":
return {
- "html": "For more information, visit cvta .
Data Movement and Conversion Instructions: cvta
\n\n\n
Convert address from .const, Kernel Function Parameters (.param), .global, .local, or .shared\nstate space to generic, or vice-versa. Take the generic address of a variable declared in\n.const, Kernel Function Parameters (.param),\n.global, .local, or .shared state space.
\n
Syntax
\n
\n
// convert const, global, local, or shared address to generic address\ncvta.space.size p, a; // source address in register a\ncvta.space.size p, var; // get generic address of var\ncvta.space.size p, var+imm; // generic address of var+offset\n\n// convert generic address to const, global, local, or shared address\ncvta.to.space.size p, a;\n\n.space = { .const, .global, .local, .shared{::cta, ::cluster}, .param{::entry} };\n.size = { .u32, .u64 };\n
\n
\n
Description
\n
Convert a const, Kernel Function Parameters\n(.param), global, local, or shared address to a generic address, or vice-versa. The\nsource and destination addresses must be the same size. Use cvt.u32.u64 or cvt.u64.u32 to\ntruncate or zero-extend addresses.
\n
For variables declared in .const, Kernel Function Parameters (.param), .global, .local, or .shared\nstate space, the generic address of the variable may be taken using cvta. The source is either a\nregister or a variable defined in const, Kernel Function Parameters (.param), global, local, or shared memory\nwith an optional offset.
\n
When converting a generic address into a const, Kernel Function Parameters (.param), global, local, or shared\naddress, the resulting address is undefined in cases where the generic address does not fall within\nthe address window of the specified state space. A program may use isspacep to guard against\nsuch incorrect behavior.
\n
For cvta with .shared state space, the address must belong to the space specified by\n::cta or ::cluster sub-qualifier, otherwise the behavior is undefined. If no sub-qualifier\nis specified with .shared state space, then ::cta is assumed by default.
\n
If .param is specified without any sub-qualifiers then it defaults to .param::entry.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
cvta.const and cvta.to.const introduced in PTX ISA version 3.1.
\n
cvta.param and cvta.to.param introduced in PTX ISA version 7.7.
\n
Note: The current implementation does not allow generic pointers to const space variables in\nprograms that contain pointers to constant buffers passed as kernel parameters.
\n
Support for ::cta and ::cluster sub-qualifiers introduced in PTX ISA version 7.8.
\n
Support for sub-qualifier ::entry on .param space introduced in PTX ISA version 8.3.
\n
Target ISA Notes
\n
cvta requires sm_20 or higher.
\n
cvta.param{::entry} and cvta.to.param{::entry} requires sm_70 or higher.
\n",
- "tooltip": "Convert address from .const, Kernel Function Parameters (.param), .global, .local, or .shared\n\nstate space to generic, or vice-versa. Take the generic address of a variable declared in\n\n.const, Kernel Function Parameters (.param),\n\n.global, .local, or .shared state space.\n\nSyntax\n\n// convert const, global, local, or shared address to generic address\n\ncvta.space.size p, a; // source address in register a\n\ncvta.space.size p, var; // get generic address of var\n\ncvta.space.size p, var+imm; // generic address of var+offset\n\n// convert generic address to const, global, local, or shared address\n\ncvta.to.space.size p, a;\n\n.space = { .const, .global, .local, .shared{::cta, ::cluster}, .param{::entry} };\n\n.size = { .u32, .u64 };\n\nDescription\n\nConvert a const, Kernel Function Parameters\n\n(.param), global, local, or shared address to a generic address, or vice-versa. The\n\nsource and destination addresses must be the same size. Use cvt.u32.u64 or cvt.u64.u32 to\n\ntruncate or zero-extend addresses.\n\nFor variables declared in .const, Kernel Function Parameters (.param), .global, .local, or .shared\n\nstate space, the generic address of the variable may be taken using cvta. The source is either a\n\nregister or a variable defined in const, Kernel Function Parameters (.param), global, local, or shared memory\n\nwith an optional offset.\n\nWhen converting a generic address into a const, Kernel Function Parameters (.param), global, local, or shared\n\naddress, the resulting address is undefined in cases where the generic address does not fall within\n\nthe address window of the specified state space. A program may use isspacep to guard against\n\nsuch incorrect behavior.\n\nFor cvta with .shared state space, the address must belong to the space specified by\n\n::cta or ::cluster sub-qualifier, otherwise the behavior is undefined. If no sub-qualifier\n\nis specified with .shared state space, then ::cta is assumed by default.\n\nIf .param is specified without any sub-qualifiers then it defaults to .param::entry.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\ncvta.const and cvta.to.const introduced in PTX ISA version 3.1.\n\ncvta.param and cvta.to.param introduced in PTX ISA version 7.7.\n\nNote: The current implementation does not allow generic pointers to const space variables in\n\nprograms that contain pointers to constant buffers passed as kernel parameters.\n\nSupport for ::cta and ::cluster sub-qualifiers introduced in PTX ISA version 7.8.\n\nSupport for sub-qualifier ::entry on .param space introduced in PTX ISA version 8.3.\n\nTarget ISA Notes\n\ncvta requires sm_20 or higher.\n\ncvta.param{::entry} and cvta.to.param{::entry} requires sm_70 or higher.\n\nSub-qualifier ::cta requires sm_30 or higher.\n\nSub-qualifier ::cluster requires sm_90 or higher.\n\nExamples\n\ncvta.const.u32 ptr,cvar;\n\ncvta.local.u32 ptr,lptr;\n\ncvta.shared::cta.u32 p,As+4;\n\ncvta.shared::cluster.u32 ptr, As;\n\ncvta.to.global.u32 p,gptr;\n\ncvta.param.u64 ptr,pvar;\n\ncvta.to.param::entry.u64 epptr, ptr;\n\n ...",
+ "html": "
Convert a const, Kernel Function Parameters\n(.param), global, local, or shared address to a generic address, or vice-versa. The\nsource and destination addresses must be the same size. Use cvt.u32.u64 or cvt.u64.u32 to\ntruncate or zero-extend addresses.
\nFor more information, visit cvta .",
+ "tooltip": "Convert aconst,Kernel Function Parameters(.param),global,local, orsharedaddress to a generic address, or vice-versa. The\n\nsource and destination addresses must be the same size. Usecvt.u32.u64orcvt.u64...",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-cvta"
};
case "discard":
return {
- "html": "For more information, visit discard .
Data Movement and Conversion Instructions: discard
\n\n\n
Invalidate the data in cache at the specified address and cache level.
The discard instruction invalidates the data at the address range [a..a+(size-1)] in\nthe cache level specified by the .level qualifier without writing back the data in the cache to\nthe memory. Therefore after the discard operation, the data at the address range [a..a+(size-\n1)] has undetermined value.
\n
The operand size is an integer constant that specifies the amount of data, in bytes, in the\ncache level specified by the .level qualifier to be discarded. The only supported value for the\nsize operand is 128.
\n
If no state space is specified then Generic Addressing is\nused. If the specified address does not fall within the address window of .global state space\nthen the behavior is undefined.
\n
Supported addressing modes for address operand a are described in Addresses as Operands. a must be aligned to 128 bytes.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.4.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
discard.global.L2 [ptr], 128;\n
\n
\n",
- "tooltip": "Invalidate the data in cache at the specified address and cache level.\n\nSyntax\n\ndiscard{.global}.level [a], size;\n\n.level = { .L2 };\n\nDescription\n\nThe discard instruction invalidates the data at the address range [a .. a + (size - 1)] in\n\nthe cache level specified by the .level qualifier without writing back the data in the cache to\n\nthe memory. Therefore after the discard operation, the data at the address range [a .. a+ (size -\n\n1)] has undetermined value.\n\nThe operand size is an integer constant that specifies the amount of data, in bytes, in the\n\ncache level specified by the .level qualifier to be discarded. The only supported value for the\n\nsize operand is 128.\n\nIf no state space is specified then Generic Addressing is\n\nused. If the specified address does not fall within the address window of .global state space\n\nthen the behavior is undefined.\n\nSupported addressing modes for address operand a are described in Addresses as Operands. a must be aligned to 128 bytes.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.4.\n\nTarget ISA Notes\n\nRequires sm_80 or higher.\n\nExamples\n\ndiscard.global.L2 [ptr], 128;\n\n ...",
+ "html": "
Semantically, this behaves like a weak write of an unstable indeterminate value:\nreads of memory locations with unstable indeterminate values may return different\nbit patterns each time until the memory is overwritten.\nThis operation hints to the implementation that data in the specified cache .level\ncan be destructively discarded without writing it back to memory.
\nFor more information, visit discard .",
+ "tooltip": "Discard the data at the specified address range and cache level.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-discard"
};
case "div":
return {
- "html": "For more information, visit div(fp) , div(int) .
Floating Point Instructions: div
\n\n\n
Divide one value by another.
\n
Syntax
\n
\n
div.approx{.ftz}.f32 d, a, b; // fast, approximate divide\ndiv.full{.ftz}.f32 d, a, b; // full-range approximate divide\ndiv.rnd{.ftz}.f32 d, a, b; // IEEE 754 compliant rounding\ndiv.rnd.f64 d, a, b; // IEEE 754 compliant rounding\n\n.rnd = { .rn, .rz, .rm, .rp };\n
\n
\n
Description
\n
Divides a by b, stores result in d.
\n
Semantics
\n
\n
d = a / b;\n
\n
\n
Notes
\n
Fast, approximate single-precision divides:
\n
\n
div.approx.f32 implements a fast approximation to divide, computed as d=a*(1/b). For\n|b| in [2-126, 2126], the maximum ulp error is 2. For 2126 <\n|b| < 2128, if a is infinity, div.approx.f32 returns NaN, otherwise it\nreturns 0.
\n
div.full.f32 implements a relatively fast, full-range approximation that scales operands to\nachieve better accuracy, but is not fully IEEE 754 compliant and does not support rounding\nmodifiers. The maximum ulp error is 2 across the full range of inputs.
\n
Subnormal inputs and results are flushed to sign-preserving zero. Fast, approximate division by\nzero creates a value of infinity (with same sign as a).
\n
\n
Divide with IEEE 754 compliant rounding:
\n
Rounding modifiers (no default):
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
div.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
div.f64 supports subnormal numbers.
\n
div.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
div.f32 and div.f64 introduced in PTX ISA version 1.0.
\n
Explicit modifiers .approx, .full, .ftz, and rounding introduced in PTX ISA version 1.4.
\n
For PTX ISA version 1.4 and later, one of .approx, .full, or .rnd is required.
\n
For PTX ISA versions 1.0 through 1.3, div.f32 defaults to div.approx.ftz.f32, and\ndiv.f64 defaults to div.rn.f64.
\n
Target ISA Notes
\n
div.approx.f32 and div.full.f32 supported on all target architectures.
\n
div.rnd.f32 requires sm_20 or higher.
\n
div.rn.f64 requires sm_13 or higher, or .targetmap_f64_to_f32.
\n
div.{rz,rm,rp}.f64 requires sm_20 or higher.
\n
Examples
\n
\n
div.approx.ftz.f32 diam,circum,3.14159;\ndiv.full.ftz.f32 x, y, z;\ndiv.rn.f64 xd, yd, zd;\n
Division by zero yields an unspecified, machine-specific value.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
div.s32 b,n,i;\n
\n
\n",
- "tooltip": "=====Floating Point Instructions: div\n\n\n\nDivide one value by another.\n\nSyntax\n\ndiv.approx{.ftz}.f32 d, a, b; // fast, approximate divide\n\ndiv.full{.ftz}.f32 d, a, b; // full-range approximate divide\n\ndiv.rnd{.ftz}.f32 d, a, b; // IEEE 754 compliant rounding\n\ndiv.rnd.f64 d, a, b; // IEEE 754 compliant rounding\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nDivides a by b, stores result in d.\n\nSemantics\n\nd = a / b;\n\nNotes\n\nFast, a...\n\n=====Integer Arithmetic Instructions: div\n\n\n\nDivide one value by another.\n\nSyntax\n\ndiv.type d, a, b;\n\n.type = { .u16, .u32, .u64,\n\n .s16, .s32, .s64 };\n\nDescription\n\nDivides a by b, stores result in d.\n\nSemantics\n\nd = a / b;\n\nNotes\n\nDivision by zero yields an unspecified, machine-specific value.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\ndiv.s32 b,n,i;\n\n... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-div"
+ "html": "
Divides a by b, stores result in d.
\nFor more information, visit div(int) .",
+ "tooltip": "Divide one value by another.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-div"
};
case "dp2a":
return {
- "html": "For more information, visit dp2a(int) .
Two-way 16-bit to 8-bit dot product which is accumulated in 32-bit result.
\n
Operand a and b are 32-bit inputs. Operand a holds two 16-bits inputs in packed form and\noperand b holds 4 byte inputs in packed form for dot product.
\n
Depending on the .mode specified, either lower half or upper half of operand b will be used\nfor dot product.
\n
Operand c has type .u32 if both .atype and .btype are .u32 else operand c\nhas type .s32.
\n
Semantics
\n
\n
d = c;\n// Extract two 16-bit values from a 32-bit input and sign or zero extend\n// based on input type.\nVa = extractAndSignOrZeroExt_2(a, .atype);\n\n// Extract four 8-bit values from a 32-bit input and sign or zer extend\n// based on input type.\nVb = extractAndSignOrZeroExt_4(b, .btype);\n\nb_select = (.mode == .lo) ? 0 : 2;\n\nfor (i = 0; i < 2; ++i) {\n d += Va[i] * Vb[b_select + i];\n}\n
\n",
- "tooltip": "Two-way dot product-accumulate.\n\nSyntax\n\ndp2a.mode.atype.btype d, a, b, c;\n\n.atype = .btype = { .u32, .s32 };\n\n.mode = { .lo, .hi };\n\nDescription\n\nTwo-way 16-bit to 8-bit dot product which is accumulated in 32-bit result.\n\nOperand a and b are 32-bit inputs. Operand a holds two 16-bits inputs in packed form and\n\noperand b holds 4 byte inputs in packed form for dot product.\n\nDepending on the .mode specified, either lower half or upper half of operand b will be used\n\nfor dot product.\n\nOperand c has type .u32 if both .atype and .btype are .u32 else operand c\n\nhas type .s32.\n\nSemantics\n\nd = c;\n\n// Extract two 16-bit values from a 32-bit input and sign or zero extend\n\n// based on input type.\n\nVa = extractAndSignOrZeroExt_2(a, .atype);\n\n// Extract four 8-bit values from a 32-bit input and sign or zer extend\n\n// based on input type.\n\nVb = extractAndSignOrZeroExt_4(b, .btype);\n\nb_select = (.mode == .lo) ? 0 : 2;\n\nfor (i = 0; i < 2; ++i) {\n\n d += Va[i] * Vb[b_select + i];\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 5.0.\n\nTarget ISA Notes\n\nRequires sm_61 or higher.\n\nExamples\n\ndp2a.lo.u32.u32 d0, a0, b0, c0;\n\ndp2a.hi.u32.s32 d1, a1, b1, c1;\n\n ...",
+ "html": "
Two-way 16-bit to 8-bit dot product which is accumulated in 32-bit result.
\nFor more information, visit dp2a(int) .",
+ "tooltip": "Two-way dot product-accumulate.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-dp2a"
};
case "dp4a":
return {
- "html": "For more information, visit dp4a(int) .
Four-way byte dot product which is accumulated in 32-bit result.
\n
Operand a and b are 32-bit inputs which hold 4 byte inputs in packed form for dot product.
\n
Operand c has type .u32 if both .atype and .btype are .u32 else operand c\nhas type .s32.
\n
Semantics
\n
\n
d = c;\n\n// Extract 4 bytes from a 32bit input and sign or zero extend\n// based on input type.\nVa = extractAndSignOrZeroExt_4(a, .atype);\nVb = extractAndSignOrZeroExt_4(b, .btype);\n\nfor (i = 0; i < 4; ++i) {\n d += Va[i] * Vb[i];\n}\n
\n",
- "tooltip": "Four-way byte dot product-accumulate.\n\nSyntax\n\ndp4a.atype.btype d, a, b, c;\n\n.atype = .btype = { .u32, .s32 };\n\nDescription\n\nFour-way byte dot product which is accumulated in 32-bit result.\n\nOperand a and b are 32-bit inputs which hold 4 byte inputs in packed form for dot product.\n\nOperand c has type .u32 if both .atype and .btype are .u32 else operand c\n\nhas type .s32.\n\nSemantics\n\nd = c;\n\n// Extract 4 bytes from a 32bit input and sign or zero extend\n\n// based on input type.\n\nVa = extractAndSignOrZeroExt_4(a, .atype);\n\nVb = extractAndSignOrZeroExt_4(b, .btype);\n\nfor (i = 0; i < 4; ++i) {\n\n d += Va[i] * Vb[i];\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 5.0.\n\nTarget ISA Notes\n\nRequires sm_61 or higher.\n\nExamples\n\ndp4a.u32.u32 d0, a0, b0, c0;\n\ndp4a.u32.s32 d1, a1, b1, c1;\n\n ...",
+ "html": "
Four-way byte dot product which is accumulated in 32-bit result.
\nFor more information, visit dp4a(int) .",
+ "tooltip": "Four-way byte dot product-accumulate.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-dp4a"
};
- case "dynamic_smem_size":
- return {
- "html": "For more information, visit dynamic_smem_size .
Special Registers: %dynamic_smem_size
\n\n\n
Size of shared memory allocated dynamically at kernel launch.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %dynamic_smem_size;\n
\n
\n
Description
\n
Size of shared memory allocated dynamically at kernel launch.
\n
A predefined, read-only special register initialized with size of shared memory allocated dynamically for the CTA of a kernel at launch time.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.1.
\n
Target ISA Notes
\n
Requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %dynamic_smem_size;\n
\n
\n",
- "tooltip": "Size of shared memory allocated dynamically at kernel launch.\n\nSyntax (predefined)\n\n.sreg .u32 %dynamic_smem_size;\n\nDescription\n\nSize of shared memory allocated dynamically at kernel launch.\n\nA predefined, read-only special register initialized with size of shared memory allocated dynamically for the CTA of a kernel at launch time.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 4.1.\n\nTarget ISA Notes\n\nRequires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %dynamic_smem_size;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-dynamic-smem-size"
- };
-
case "elect":
return {
- "html": "For more information, visit elect.sync .
Parallel Synchronization and Communication Instructions: elect.sync
\n\n\n
Elect a leader thread from a set of threads.
\n
Syntax
\n
\n
elect.sync d|p, membermask;\n
\n
\n
Description
\n
elect.sync elects one predicated active leader thread from among a set of threads specified by\nmembermask. laneid of the elected thread is returned in the 32-bit destination operand\nd. The sink symbol \u2018_\u2019 can be used for destination operand d. The predicate destination\np is set to True for the leader thread, and False for all other threads.
\n
Operand membermask specifies a 32-bit integer indicating the set of threads from which a leader\nis to be elected. The behavior is undefined if the executing thread is not in membermask.
\n
Election of a leader thread happens deterministically, i.e. the same leader thread is elected for\nthe same membermask every time.
\n
The mandatory .sync qualifier indicates that elect causes the executing thread to wait until\nall threads in the membermask execute the elect instruction before resuming execution.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
elect.sync %r0|%p0, 0xffffffff;\n
\n
\n",
- "tooltip": "Elect a leader thread from a set of threads.\n\nSyntax\n\nelect.sync d|p, membermask;\n\nDescription\n\nelect.sync elects one predicated active leader thread from among a set of threads specified by\n\nmembermask. laneid of the elected thread is returned in the 32-bit destination operand\n\nd. The sink symbol \u2018_\u2019 can be used for destination operand d. The predicate destination\n\np is set to True for the leader thread, and False for all other threads.\n\nOperand membermask specifies a 32-bit integer indicating the set of threads from which a leader\n\nis to be elected. The behavior is undefined if the executing thread is not in membermask.\n\nElection of a leader thread happens deterministically, i.e. the same leader thread is elected for\n\nthe same membermask every time.\n\nThe mandatory .sync qualifier indicates that elect causes the executing thread to wait until\n\nall threads in the membermask execute the elect instruction before resuming execution.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 8.0.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\nelect.sync %r0|%p0, 0xffffffff;\n\n ...",
+ "html": "
elect.sync elects one predicated active leader thread from among a set of threads specified by\nmembermask. laneid of the elected thread is returned in the 32-bit destination operand\nd. The sink symbol \u2018_\u2019 can be used for destination operand d. The predicate destination\np is set to True for the leader thread, and False for all other threads.
\nFor more information, visit elect.sync .",
+ "tooltip": "Elect a leader thread from a set of threads.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-elect-sync"
};
- case "entry":
- return {
- "html": "For more information, visit entry .
Kernel and Function Directives: .entry
\n\n\n
Kernel entry point and body, with optional parameters.
Defines a kernel entry point name, parameters, and body for the kernel function.
\n
Parameters are passed via .param space memory and are listed within an optional parenthesized\nparameter list. Parameters may be referenced by name within the kernel body and loaded into\nregisters using ld.param{::entry} instructions.
\n
In addition to normal parameters, opaque .texref, .samplerref, and .surfref variables\nmay be passed as parameters. These parameters can only be referenced by name within texture and\nsurface load, store, and query instructions and cannot be accessed via ld.param instructions.
\n
The shape and size of the CTA executing the kernel are available in special registers.
\n
Semantics
\n
Specify the entry point for a kernel program.
\n
At kernel launch, the kernel dimensions and properties are established and made available via\nspecial registers, e.g., %ntid, %nctaid, etc.
\n
PTX ISA Notes
\n
For PTX ISA version 1.4 and later, parameter variables are declared in the kernel parameter\nlist. For PTX ISA versions 1.0 through 1.3, parameter variables are declared in the kernel body.
\n
The maximum memory size supported by PTX for normal (non-opaque type) parameters is 32764\nbytes. Depending upon the PTX ISA version, the parameter size limit varies. The following table\nshows the allowed parameter size for a PTX ISA version:
\n
\n
\n
\n
\n
\n\n
\n
PTX ISA Version
\n
Maximum parameter size (In bytes)
\n
\n\n\n
\n
PTX ISA version 8.1 and above
\n
32764
\n
\n
\n
PTX ISA version 1.5 and above
\n
4352
\n
\n
\n
PTX ISA version 1.4 and above
\n
256
\n
\n\n
\n
The CUDA and OpenCL drivers support the following limits for parameter memory:
\n
\n
\n
\n
\n
\n\n
\n
Driver
\n
Parameter memory size
\n
\n\n\n
\n
CUDA
\n
256 bytes for sm_1x, 4096 bytes for sm_2xandhigher,\n32764 bytes fo sm_70 and higher
\n
\n
\n
OpenCL
\n
32764 bytes for sm_70 and higher, 4352 bytes on sm_6x\nand lower
\n",
- "tooltip": "Kernel entry point and body, with optional parameters.\n\nSyntax\n\n.entry kernel-name ( param-list ) kernel-body\n\n.entry kernel-name kernel-body\n\nDescription\n\nDefines a kernel entry point name, parameters, and body for the kernel function.\n\nParameters are passed via .param space memory and are listed within an optional parenthesized\n\nparameter list. Parameters may be referenced by name within the kernel body and loaded into\n\nregisters using ld.param{::entry} instructions.\n\nIn addition to normal parameters, opaque .texref, .samplerref, and .surfref variables\n\nmay be passed as parameters. These parameters can only be referenced by name within texture and\n\nsurface load, store, and query instructions and cannot be accessed via ld.param instructions.\n\nThe shape and size of the CTA executing the kernel are available in special registers.\n\nSemantics\n\nSpecify the entry point for a kernel program.\n\nAt kernel launch, the kernel dimensions and properties are established and made available via\n\nspecial registers, e.g., %ntid, %nctaid, etc.\n\nPTX ISA Notes\n\nFor PTX ISA version 1.4 and later, parameter variables are declared in the kernel parameter\n\nlist. For PTX ISA versions 1.0 through 1.3, parameter variables are declared in the kernel body.\n\nThe maximum memory size supported by PTX for normal (non-opaque type) parameters is 32764\n\nbytes. Depending upon the PTX ISA version, the parameter size limit varies. The following table\n\nshows the allowed parameter size for a PTX ISA version:\n\n\n\nPTX ISA Version\n\nMaximum parameter size (In bytes)\n\n\n\nPTX ISA version 8.1 and above\n\n32764\n\nPTX ISA version 1.5 and above\n\n4352\n\nPTX ISA version 1.4 and above\n\n256\n\nThe CUDA and OpenCL drivers support the following limits for parameter memory:\n\n\n\nDriver\n\nParameter memory size\n\n\n\nCUDA\n\n256 bytes for sm_1x, 4096 bytes for sm_2x and higher,\n\n32764 bytes fo sm_70 and higher\n\nOpenCL\n\n32764 bytes for sm_70 and higher, 4352 bytes on sm_6x\n\nand lower\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.entry cta_fft\n\n.entry filter ( .param .b32 x, .param .b32 y, .param .b32 z )\n\n{\n\n .reg .b32 %r<99>;\n\n ld.param.b32 %r1, [x];\n\n ld.param.b32 %r2, [y];\n\n ld.param.b32 %r3, [z];\n\n ...\n\n}\n\n.entry prefix_sum ( .param .align 4 .s32 pitch[8000] )\n\n{\n\n .reg .s32 %t;\n\n ld.param::entry.s32 %t, [pitch];\n\n ...\n\n}\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#kernel-and-function-directives-entry"
- };
-
- case "envreg<32>":
- return {
- "html": "For more information, visit envreg<32> .
Special Registers: %envreg<32>
\n\n\n
Driver-defined read-only registers.
\n
Syntax (predefined)
\n
\n
.sreg .b32 %envreg<32>;\n
\n
\n
Description
\n
A set of 32 pre-defined read-only registers used to capture execution environment of PTX program\noutside of PTX virtual machine. These registers are initialized by the driver prior to kernel launch\nand can contain cta-wide or grid-wide values.
\n
Precise semantics of these registers is defined in the driver documentation.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.1.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mov.b32 %r1,%envreg0; // move envreg0 to %r1\n
\n
\n",
- "tooltip": "Driver-defined read-only registers.\n\nSyntax (predefined)\n\n.sreg .b32 %envreg<32>;\n\nDescription\n\nA set of 32 pre-defined read-only registers used to capture execution environment of PTX program\n\noutside of PTX virtual machine. These registers are initialized by the driver prior to kernel launch\n\nand can contain cta-wide or grid-wide values.\n\nPrecise semantics of these registers is defined in the driver documentation.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.1.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.b32 %r1,%envreg0; // move envreg0 to %r1\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-envreg-32"
- };
-
case "ex2":
return {
- "html": "For more information, visit ex2(fp) , ex2(fp16) .
Floating Point Instructions: ex2
\n\n\n
Find the base-2 exponential of a value.
\n
Syntax
\n
\n
ex2.approx{.ftz}.f32 d, a;\n
\n
\n
Description
\n
Raise 2 to the power a.
\n
Semantics
\n
\n
d = 2 ^ a;\n
\n
\n
Notes
\n
ex2.approx.f32 implements a fast approximation to 2a.
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
+0.0
\n
\n
\n
-subnormal
\n
+1.0
\n
\n
\n
-0.0
\n
+1.0
\n
\n
\n
+0.0
\n
+1.0
\n
\n
\n
+subnormal
\n
+1.0
\n
\n
\n
+Inf
\n
+Inf
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
The maximum absolute error is 2-22.5 for fraction in the primary range.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
ex2.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
Subnormal inputs and results to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
ex2.f32 introduced in PTX ISA version 1.0. Explicit modifiers .approx and .ftz\nintroduced in PTX ISA version 1.4.
\n
For PTX ISA version 1.4 and later, the .approx modifier is required.
\n
For PTX ISA versions 1.0 through 1.3, ex2.f32 defaults to ex2.approx.ftz.f32.
The type of operands d and a are as specified by .type.
\n
For .f16x2 or .bf16x2 instruction type, each of the half-word operands are operated in\nparallel and the results are packed appropriately into a .f16x2 or .bf16x2.
\n",
- "tooltip": "=====Floating Point Instructions: ex2\n\n\n\nFind the base-2 exponential of a value.\n\nSyntax\n\nex2.approx{.ftz}.f32 d, a;\n\nDescription\n\nRaise 2 to the power a.\n\nSemantics\n\nd = 2 ^ a;\n\nNotes\n\nex2.approx.f32 implements a fast approximation to 2a.\n\n\n\nInput\n\nResult\n\n\n\n-Inf\n\n+0.0\n\n-subnormal\n\n+1.0\n\n-0.0\n\n+1.0\n\n+0.0\n\n+1.0\n\n+subnormal\n\n+1.0\n\n+Inf\n\n+Inf\n\nNaN\n\nNaN\n\nThe maximum absolute error is 2-22.5 for fraction in the primary range.\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, sub...\n\n=====Half Precision Floating Point Instructions: ex2\n\n\n\nFind the base-2 exponent of input.\n\nSyntax\n\nex2.approx.atype d, a;\n\nex2.approx.ftz.btype d, a;\n\n.atype = { .f16, .f16x2}\n\n.btype = { .bf16, .bf16x2}\n\nDescription\n\nRaise 2 to the power a.\n\nThe type of operands d and a are as specified by .type.\n\nFor .f16x2 or .bf16x2 instruction type, each of the half-word operands are operated in\n\nparallel and the results are packed appropriately into a .f16x2 or .bf16... ...",
+ "html": "
Raise 2 to the power a.
\nFor more information, visit ex2(fp) .",
+ "tooltip": "Find the base-2 exponential of a value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-ex2"
};
case "exit":
return {
- "html": "For more information, visit exit .
Control Flow Instructions: exit
\n\n\n
Terminate a thread.
\n
Syntax
\n
\n
exit;\n
\n
\n
Description
\n
Ends execution of a thread.
\n
As threads exit, barriers waiting on all threads are checked to see if the exiting threads are the\nonly threads that have not yet made it to a barrier{.cta} for all threads in the CTA or to a\nbarrier.cluster for all threads in the cluster. If the exiting threads are holding up the\nbarrier, the barrier is released.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
exit;\n@p exit;\n
\n
\n",
- "tooltip": "Terminate a thread.\n\nSyntax\n\nexit;\n\nDescription\n\nEnds execution of a thread.\n\nAs threads exit, barriers waiting on all threads are checked to see if the exiting threads are the\n\nonly threads that have not yet made it to a barrier{.cta} for all threads in the CTA or to a\n\nbarrier.cluster for all threads in the cluster. If the exiting threads are holding up the\n\nbarrier, the barrier is released.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n exit;\n\n@p exit;\n\n ...",
+ "html": "
Ends execution of a thread.
\nFor more information, visit exit .",
+ "tooltip": "Terminate a thread.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-instructions-exit"
};
- case "explicitcluster":
- return {
- "html": "For more information, visit explicitcluster .
Cluster Dimension Directives: .explicitcluster
\n\n\n
Declare that Kernel must be launched with cluster dimensions explicitly specified.
\n
Syntax
\n
\n
.explicitcluster\n
\n
\n
Description
\n
Declares that this Kernel should be launched with cluster dimension explicitly specified.
\n
Semantics
\n
Kernels with .explicitcluster directive must be launched with cluster dimension explicitly\nspecified (either at launch time or via .reqnctapercluster), otherwise program will fail with\nruntime error or kernel launch failure.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
.entry foo .explicitcluster { . . . }\n
\n
\n",
- "tooltip": "Declare that Kernel must be launched with cluster dimensions explicitly specified.\n\nSyntax\n\n.explicitcluster\n\nDescription\n\nDeclares that this Kernel should be launched with cluster dimension explicitly specified.\n\nSemantics\n\nKernels with .explicitcluster directive must be launched with cluster dimension explicitly\n\nspecified (either at launch time or via .reqnctapercluster), otherwise program will fail with\n\nruntime error or kernel launch failure.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.entry foo .explicitcluster { . . . }\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#cluster-dimension-directives-explicitcluster"
- };
-
- case "extern":
- return {
- "html": "For more information, visit extern .
Linking Directives: .extern
\n\n\n
External symbol declaration.
\n
Syntax
\n
\n
.extern identifier\n
\n
\n
Description
\n
Declares identifier to be defined external to the current module. The module defining such\nidentifier must define it as .weak or .visible only once in a single object file. Extern\ndeclaration of symbol may appear multiple times and references to that get resolved against the\nsingle definition of that symbol.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.extern .global .b32 foo; // foo is defined in another module\n
\n
\n",
- "tooltip": "External symbol declaration.\n\nSyntax\n\n.extern identifier\n\nDescription\n\nDeclares identifier to be defined external to the current module. The module defining such\n\nidentifier must define it as .weak or .visible only once in a single object file. Extern\n\ndeclaration of symbol may appear multiple times and references to that get resolved against the\n\nsingle definition of that symbol.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.extern .global .b32 foo; // foo is defined in another module\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#linking-directives-extern"
- };
-
- case "file":
- return {
- "html": "For more information, visit file .
Associates a source filename with an integer index. .loc directives reference source files by\nindex.
\n
.file directive allows optionally specifying an unsigned number representing time of last\nmodification and an unsigned integer representing size in bytes of source file. timestamp and\nfile_size value can be 0 to indicate this information is not available.
\n
timestamp value is in format of C and C++ data type time_t.
\n
file_size is an unsigned 64-bit integer.
\n
The .file directive is allowed only in the outermost scope, i.e., at the same level as kernel\nand device function declarations.
\n
Semantics
\n
If timestamp and file size are not specified, they default to 0.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Timestamp and file size introduced in PTX ISA version 3.2.
\n",
- "tooltip": "Source file name.\n\nSyntax\n\n.file file_index \"filename\" {, timestamp, file_size}\n\nDescription\n\nAssociates a source filename with an integer index. .loc directives reference source files by\n\nindex.\n\n.file directive allows optionally specifying an unsigned number representing time of last\n\nmodification and an unsigned integer representing size in bytes of source file. timestamp and\n\nfile_size value can be 0 to indicate this information is not available.\n\ntimestamp value is in format of C and C++ data type time_t.\n\nfile_size is an unsigned 64-bit integer.\n\nThe .file directive is allowed only in the outermost scope, i.e., at the same level as kernel\n\nand device function declarations.\n\nSemantics\n\nIf timestamp and file size are not specified, they default to 0.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTimestamp and file size introduced in PTX ISA version 3.2.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.file 1 \"example.cu\"\n\n.file 2 \"kernel.cu\"\n\n.file 1 \u201ckernel.cu\u201d, 1339013327, 64118\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#debugging-directives-file"
- };
-
case "fma":
return {
- "html": "For more information, visit fma(fp) , fma(fp16) .
Floating Point Instructions: fma
\n\n\n
Fused multiply-add.
\n
Syntax
\n
\n
fma.rnd{.ftz}{.sat}.f32 d, a, b, c;\nfma.rnd.f64 d, a, b, c;\n\n.rnd = { .rn, .rz, .rm, .rp };\n
\n
\n
Description
\n
Performs a fused multiply-add with no loss of precision in the intermediate product and addition.
\n
Semantics
\n
\n
d = a*b + c;\n
\n
\n
Notes
\n
fma.f32 computes the product of a and b to infinite precision and then adds c to\nthis product, again in infinite precision. The resulting value is then rounded to single precision\nusing the rounding mode specified by .rnd.
\n
fma.f64 computes the product of a and b to infinite precision and then adds c to\nthis product, again in infinite precision. The resulting value is then rounded to double precision\nusing the rounding mode specified by .rnd.
\n
fma.f64 is the same as mad.f64.
\n
Rounding modifiers (no default):
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
fma.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
\n
sm_1x
\n
\n
fma.f64 supports subnormal numbers.
\n
fma.f32 is unimplemented for sm_1x targets.
\n
\n
\n
Saturation:
\n
fma.sat.f32 clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
PTX ISA Notes
\n
fma.f64 introduced in PTX ISA version 1.4.
\n
fma.f32 introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
fma.f32 requires sm_20 or higher.
\n
fma.f64 requires sm_13 or higher.
\n
Examples
\n
\n
fma.rn.ftz.f32 w,x,y,z;\n@p fma.rn.f64 d,a,b,c;\n
\n
\n\n
Half Precision Floating Point Instructions: fma
\n\n\n
Fused multiply-add
\n
Syntax
\n
\n
fma.rnd{.ftz}{.sat}.f16 d, a, b, c;\nfma.rnd{.ftz}{.sat}.f16x2 d, a, b, c;\nfma.rnd{.ftz}.relu.f16 d, a, b, c;\nfma.rnd{.ftz}.relu.f16x2 d, a, b, c;\nfma.rnd{.relu}.bf16 d, a, b, c;\nfma.rnd{.relu}.bf16x2 d, a, b, c;\nfma.rnd.oob.{relu}.type d, a, b, c;\n\n.rnd = { .rn };\n
\n
\n
Description
\n
Performs a fused multiply-add with no loss of precision in the intermediate product and addition.
\n
For .f16x2 and .bf16x2 instruction type, forms input vectors by half word values from source\noperands. Half-word operands are then operated in parallel to produce .f16x2 or .bf16x2\nresult in destination.
\n
For .f16 instruction type, operands d, a, b and c have .f16 or .b16\ntype. For .f16x2 instruction type, operands d, a, b and c have .b32\ntype. For .bf16 instruction type, operands d, a, b and c have .b16 type. For\n.bf16x2 instruction type, operands d, a, b and c have .b32 type.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n d = a * b + c;\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n fC[0] = c[0:15];\n fC[1] = c[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = fA[i] * fB[i] + fC[i];\n }\n}\n
\n
\n
Notes
\n
Rounding modifiers (default is .rn):
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nfma.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
Saturation modifier:
\n
\n
fma.sat.{f16,f16x2} clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.\nfma.relu.{f16,f16x2,bf16,bf16x2} clamps the result to 0 if negative. NaN result is\nconverted to canonical NaN.
\n
\n
Out Of Bounds modifier:
\n
\n
fma.oob.{f16,f16x2,bf16,bf16x2} clamps the result to 0 if either of the operands\nis OOBNaN (defined under Tensors) value. The test for the special NaN value\nand resultant forcing of the result to +0.0 is performed independently for each of the\ntwo SIMD operations.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.2.
\n
fma.relu.{f16,f16x2} and fma{.relu}.{bf16,bf16x2} introduced in PTX ISA version 7.0.
\n
Support for modifier .oob introduced in PTX ISA version 8.1.
\n
Target ISA Notes
\n
Requires sm_53 or higher.
\n
fma.relu.{f16,f16x2} and fma{.relu}.{bf16,bf16x2} require sm_80 or higher.
\n
fma{.oob}.{f16,f16x2,bf16,bf16x2} requires sm_90 or higher.
\n",
- "tooltip": "=====Floating Point Instructions: fma\n\n\n\nFused multiply-add.\n\nSyntax\n\nfma.rnd{.ftz}{.sat}.f32 d, a, b, c;\n\nfma.rnd.f64 d, a, b, c;\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nPerforms a fused multiply-add with no loss of precision in the intermediate product and addition.\n\nSemantics\n\nd = a*b + c;\n\nNotes\n\nfma.f32 computes the product of a and b to infinite precision and then adds c to\n\nthis product, again in infinite precision. The r...\n\n=====Half Precision Floating Point Instructions: fma\n\n\n\nFused multiply-add\n\nSyntax\n\nfma.rnd{.ftz}{.sat}.f16 d, a, b, c;\n\nfma.rnd{.ftz}{.sat}.f16x2 d, a, b, c;\n\nfma.rnd{.ftz}.relu.f16 d, a, b, c;\n\nfma.rnd{.ftz}.relu.f16x2 d, a, b, c;\n\nfma.rnd{.relu}.bf16 d, a, b, c;\n\nfma.rnd{.relu}.bf16x2 d, a, b, c;\n\nfma.rnd.oob.{relu}.type d, a, b, c;\n\n.rnd = { .rn };\n\nDescription\n\nPerforms a fused multiply-add with no loss of precision in the int... ...",
+ "html": "
Performs a fused multiply-add with no loss of precision in the intermediate product and addition.
\nFor more information, visit fma(fp) .",
+ "tooltip": "Fused multiply-add.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-fma"
};
case "fns":
return {
- "html": "For more information, visit fns(int) .
Integer Arithmetic Instructions: fns
\n\n\n
Find the n-th set bit
\n
Syntax
\n
\n
fns.b32 d, mask, base, offset;\n
\n
\n
Description
\n
Given a 32-bit value mask and an integer value base (between 0 and 31), find the n-th (given\nby offset) set bit in mask from the base bit, and store the bit position in d. If not\nfound, store 0xffffffff in d.
\n
Operand mask has a 32-bit type. Operand base has .b32, .u32 or .s32\ntype. Operand offset has .s32 type. Destination d has type .b32.
\n
Operand base must be <= 31, otherwise behavior is undefined.
fns.b32 d, 0xaaaaaaaa, 3, 1; // d = 3\nfns.b32 d, 0xaaaaaaaa, 3, -1; // d = 3\nfns.b32 d, 0xaaaaaaaa, 2, 1; // d = 3\nfns.b32 d, 0xaaaaaaaa, 2, -1; // d = 1\n
\n
\n",
- "tooltip": "Find the n-th set bit\n\nSyntax\n\nfns.b32 d, mask, base, offset;\n\nDescription\n\nGiven a 32-bit value mask and an integer value base (between 0 and 31), find the n-th (given\n\nby offset) set bit in mask from the base bit, and store the bit position in d. If not\n\nfound, store 0xffffffff in d.\n\nOperand mask has a 32-bit type. Operand base has .b32, .u32 or .s32\n\ntype. Operand offset has .s32 type. Destination d has type .b32.\n\nOperand base must be <= 31, otherwise behavior is undefined.\n\nSemantics\n\nd = 0xffffffff;\n\nif (offset == 0) {\n\n if (mask[base] == 1) {\n\n d = base;\n\n }\n\n} else {\n\n pos = base;\n\n count = |offset| - 1;\n\n inc = (offset > 0) ? 1 : -1;\n\n while ((pos >= 0) && (pos < 32)) {\n\n if (mask[pos] == 1) {\n\n if (count == 0) {\n\n d = pos;\n\n break;\n\n } else {\n\n count = count \u2013 1;\n\n }\n\n }\n\n pos = pos + inc;\n\n }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 6.0.\n\nTarget ISA Notes\n\nfns requires sm_30 or higher.\n\nExamples\n\nfns.b32 d, 0xaaaaaaaa, 3, 1; // d = 3\n\nfns.b32 d, 0xaaaaaaaa, 3, -1; // d = 3\n\nfns.b32 d, 0xaaaaaaaa, 2, 1; // d = 3\n\nfns.b32 d, 0xaaaaaaaa, 2, -1; // d = 1\n\n ...",
+ "html": "
Given a 32-bit value mask and an integer value base (between 0 and 31), find the n-th (given\nby offset) set bit in mask from the base bit, and store the bit position in d. If not\nfound, store 0xffffffff in d.
\nFor more information, visit fns(int) .",
+ "tooltip": "Find the n-th set bit",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-fns"
};
- case "func":
- return {
- "html": "For more information, visit func .
Defines a function, including input and return parameters and optional function body.
\n
An optional .noreturn directive indicates that the function does not return to the caller\nfunction. .noreturn directive cannot be specified on functions which have return parameters. See\nthe description of .noreturn directive in Performance-Tuning Directives: .noreturn.
A .func definition with no body provides a function prototype.
\n
The parameter lists define locally-scoped variables in the function body. Parameters must be base\ntypes in either the register or parameter state space. Parameters in register state space may be\nreferenced directly within instructions in the function body. Parameters in .param space are\naccessed using ld.param{::func} and st.param{::func} instructions in the body. Parameter\npassing is call-by-value.
\n
The last parameter in the parameter list may be a .param array of type .b8 with no size\nspecified. It is used to pass an arbitrary number of parameters to the function packed into a single\narray object.
\n
When calling a function with such an unsized last argument, the last argument may be omitted from\nthe call instruction if no parameter is passed through it. Accesses to this array parameter must\nbe within the bounds of the array. The result of an access is undefined if no array was passed, or\nif the access was outside the bounds of the actual array being passed.
\n
Semantics
\n
The PTX syntax hides all details of the underlying calling convention and ABI.
\n
The implementation of parameter passing is left to the optimizing translator, which may use a\ncombination of registers and stack locations to pass parameters.
\n
Release Notes
\n
For PTX ISA version 1.x code, parameters must be in the register state space, there is no stack, and\nrecursion is illegal.
\n
PTX ISA versions 2.0 and later with target sm_20 or higher allow parameters in the .param\nstate space, implements an ABI with stack, and supports recursion.
\n
PTX ISA versions 2.0 and later with target sm_20 or higher support at most one return value.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Support for unsized array parameter introduced in PTX ISA version 6.0.
\n
Support for .noreturn directive introduced in PTX ISA version 6.4.
\n
Support for .attribute directive introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Functions without unsized array parameter supported on all target architectures.
\n
Unsized array parameter requires sm_30 or higher.
\n
.noreturn directive requires sm_30 or higher.
\n
.attribute directive requires sm_90 or higher.
\n
Examples
\n
\n
.func (.reg .b32 rval) foo (.reg .b32 N, .reg .f64 dbl)\n{\n.reg .b32 localVar;\n\n... use N, dbl;\nother code;\n\nmov.b32 rval,result;\nret;\n}\n\n...\ncall (fooval), foo, (val0, val1); // return value in fooval\n...\n\n.func foo (.reg .b32 N, .reg .f64 dbl) .noreturn\n{\n.reg .b32 localVar;\n... use N, dbl;\nother code;\nmov.b32 rval, result;\nret;\n}\n...\ncall foo, (val0, val1);\n...\n\n.func (.param .u32 rval) bar(.param .u32 N, .param .align 4 .b8 numbers[])\n{\n .reg .b32 input0, input1;\n ld.param.b32 input0, [numbers + 0];\n ld.param.b32 input1, [numbers + 4];\n ...\n other code;\n ret;\n}\n...\n\n.param .u32 N;\n.param .align 4 .b8 numbers[8];\nst.param.u32 [N], 2;\nst.param.b32 [numbers + 0], 5;\nst.param.b32 [numbers + 4], 10;\ncall (rval), bar, (N, numbers);\n...\n
\n
\n",
- "tooltip": "Function definition.\n\nSyntax\n\n.func {.attribute(attr-list)} fname {.noreturn} function-body\n\n.func {.attribute(attr-list)} fname (param-list) {.noreturn} function-body\n\n.func {.attribute(attr-list)} (ret-param) fname (param-list) function-body\n\nDescription\n\nDefines a function, including input and return parameters and optional function body.\n\nAn optional .noreturn directive indicates that the function does not return to the caller\n\nfunction. .noreturn directive cannot be specified on functions which have return parameters. See\n\nthe description of .noreturn directive in Performance-Tuning Directives: .noreturn.\n\nAn optional .attribute directive specifies additional information associated with the\n\nfunction. See the description of Variable and Function Attribute Directive: .attribute for allowed attributes.\n\nA .func definition with no body provides a function prototype.\n\nThe parameter lists define locally-scoped variables in the function body. Parameters must be base\n\ntypes in either the register or parameter state space. Parameters in register state space may be\n\nreferenced directly within instructions in the function body. Parameters in .param space are\n\naccessed using ld.param{::func} and st.param{::func} instructions in the body. Parameter\n\npassing is call-by-value.\n\nThe last parameter in the parameter list may be a .param array of type .b8 with no size\n\nspecified. It is used to pass an arbitrary number of parameters to the function packed into a single\n\narray object.\n\nWhen calling a function with such an unsized last argument, the last argument may be omitted from\n\nthe call instruction if no parameter is passed through it. Accesses to this array parameter must\n\nbe within the bounds of the array. The result of an access is undefined if no array was passed, or\n\nif the access was outside the bounds of the actual array being passed.\n\nSemantics\n\nThe PTX syntax hides all details of the underlying calling convention and ABI.\n\nThe implementation of parameter passing is left to the optimizing translator, which may use a\n\ncombination of registers and stack locations to pass parameters.\n\nRelease Notes\n\nFor PTX ISA version 1.x code, parameters must be in the register state space, there is no stack, and\n\nrecursion is illegal.\n\nPTX ISA versions 2.0 and later with target sm_20 or higher allow parameters in the .param\n\nstate space, implements an ABI with stack, and supports recursion.\n\nPTX ISA versions 2.0 and later with target sm_20 or higher support at most one return value.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nSupport for unsized array parameter introduced in PTX ISA version 6.0.\n\nSupport for .noreturn directive introduced in PTX ISA version 6.4.\n\nSupport for .attribute directive introduced in PTX ISA version 8.0.\n\nTarget ISA Notes\n\nFunctions without unsized array parameter supported on all target architectures.\n\nUnsized array parameter requires sm_30 or higher.\n\n.noreturn directive requires sm_30 or higher.\n\n.attribute directive requires sm_90 or higher.\n\nExamples\n\n.func (.reg .b32 rval) foo (.reg .b32 N, .reg .f64 dbl)\n\n{\n\n.reg .b32 localVar;\n\n... use N, dbl;\n\nother code;\n\nmov.b32 rval,result;\n\nret;\n\n}\n\n...\n\ncall (fooval), foo, (val0, val1); // return value in fooval\n\n...\n\n.func foo (.reg .b32 N, .reg .f64 dbl) .noreturn\n\n{\n\n.reg .b32 localVar;\n\n... use N, dbl;\n\nother code;\n\nmov.b32 rval, result;\n\nret;\n\n}\n\n...\n\ncall foo, (val0, val1);\n\n...\n\n.func (.param .u32 rval) bar(.param .u32 N, .param .align 4 .b8 numbers[])\n\n{\n\n .reg .b32 input0, input1;\n\n ld.param.b32 input0, [numbers + 0];\n\n ld.param.b32 input1, [numbers + 4];\n\n ...\n\n other code;\n\n ret;\n\n}\n\n...\n\n.param .u32 N;\n\n.param .align 4 .b8 numbers[8];\n\nst.param.u32 [N], 2;\n\nst.param.b32 [numbers + 0], 5;\n\nst.param.b32 [numbers + 4], 10;\n\ncall (rval), bar, (N, numbers);\n\n...\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#kernel-and-function-directives-func"
- };
-
case "getctarank":
return {
- "html": "For more information, visit getctarank .
Data Movement and Conversion Instructions: getctarank
\n\n\n
Generate the CTA rank of the address.
\n
Syntax
\n
\n
getctarank{.space}.type d, a;\n\n// Get cta rank from source shared memory address in register a.\ngetctarank.shared::cluster.type d, a;\n\n// Get cta rank from shared memory variable.\ngetctarank.shared::cluster.type d, var;\n\n// Get cta rank from shared memory variable+offset.\ngetctarank.shared::cluster.type d, var + imm;\n\n// Get cta rank from generic address of shared memory variable in register a.\ngetctarank.type d, a;\n\n.space = { .shared::cluster }\n.type = { .u32, .u64 }\n
\n
\n
Description
\n
Write the destination register d with the rank of the CTA which contains the address specified\nin operand a.
\n
Instruction type .type indicates the type of source operand a.
\n
When space is .shared::cluster, source a is either a shared memory variable or a register\ncontaining a valid shared memory address. When the optional qualifier .space is not specified,\na is a register containing a generic addresses pointing to shared memory. Destination d is\nalways a 32-bit register which holds the rank of the CTA.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
getctarank.shared::cluster.u32 d1, addr;\ngetctarank.shared::cluster.u64 d2, sh + 4;\ngetctarank.u64 d3, src;\n
\n
\n",
- "tooltip": "Generate the CTA rank of the address.\n\nSyntax\n\ngetctarank{.space}.type d, a;\n\n// Get cta rank from source shared memory address in register a.\n\ngetctarank.shared::cluster.type d, a;\n\n// Get cta rank from shared memory variable.\n\ngetctarank.shared::cluster.type d, var;\n\n// Get cta rank from shared memory variable+offset.\n\ngetctarank.shared::cluster.type d, var + imm;\n\n// Get cta rank from generic address of shared memory variable in register a.\n\ngetctarank.type d, a;\n\n.space = { .shared::cluster }\n\n.type = { .u32, .u64 }\n\nDescription\n\nWrite the destination register d with the rank of the CTA which contains the address specified\n\nin operand a.\n\nInstruction type .type indicates the type of source operand a.\n\nWhen space is .shared::cluster, source a is either a shared memory variable or a register\n\ncontaining a valid shared memory address. When the optional qualifier .space is not specified,\n\na is a register containing a generic addresses pointing to shared memory. Destination d is\n\nalways a 32-bit register which holds the rank of the CTA.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\ngetctarank.shared::cluster.u32 d1, addr;\n\ngetctarank.shared::cluster.u64 d2, sh + 4;\n\ngetctarank.u64 d3, src;\n\n ...",
+ "html": "
Write the destination register d with the rank of the CTA which contains the address specified\nin operand a.
\nFor more information, visit getctarank .",
+ "tooltip": "Generate the CTA rank of the address.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-getctarank"
};
- case "globaltimer":
- return {
- "html": "For more information, visit globaltimer .
Special Registers: %globaltimer, %globaltimer_lo, %globaltimer_hi
Special registers intended for use by NVIDIA tools. The behavior is target-specific and may change\nor be removed in future GPUs. When JIT-compiled to other targets, the value of these registers is\nunspecified.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.1.
\n
Target ISA Notes
\n
Requires target sm_30 or higher.
\n
Examples
\n
\n
mov.u64 r1,%globaltimer;\n
\n
\n",
- "tooltip": "%globaltimer\n\nA predefined, 64-bit global nanosecond timer.\n\n%globaltimer_lo\n\nThe lower 32-bits of %globaltimer.\n\n%globaltimer_hi\n\nThe upper 32-bits of %globaltimer.\n\nSyntax (predefined)\n\n.sreg .u64 %globaltimer;\n\n.sreg .u32 %globaltimer_lo, %globaltimer_hi;\n\nDescription\n\nSpecial registers intended for use by NVIDIA tools. The behavior is target-specific and may change\n\nor be removed in future GPUs. When JIT-compiled to other targets, the value of these registers is\n\nunspecified.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.1.\n\nTarget ISA Notes\n\nRequires target sm_30 or higher.\n\nExamples\n\nmov.u64 r1,%globaltimer;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-globaltimer-globaltimer-lo-globaltimer-hi"
- };
-
- case "globaltimer_hi":
- return {
- "html": "For more information, visit globaltimer_hi .
Special Registers: %globaltimer, %globaltimer_lo, %globaltimer_hi
Special registers intended for use by NVIDIA tools. The behavior is target-specific and may change\nor be removed in future GPUs. When JIT-compiled to other targets, the value of these registers is\nunspecified.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.1.
\n
Target ISA Notes
\n
Requires target sm_30 or higher.
\n
Examples
\n
\n
mov.u64 r1,%globaltimer;\n
\n
\n",
- "tooltip": "%globaltimer\n\nA predefined, 64-bit global nanosecond timer.\n\n%globaltimer_lo\n\nThe lower 32-bits of %globaltimer.\n\n%globaltimer_hi\n\nThe upper 32-bits of %globaltimer.\n\nSyntax (predefined)\n\n.sreg .u64 %globaltimer;\n\n.sreg .u32 %globaltimer_lo, %globaltimer_hi;\n\nDescription\n\nSpecial registers intended for use by NVIDIA tools. The behavior is target-specific and may change\n\nor be removed in future GPUs. When JIT-compiled to other targets, the value of these registers is\n\nunspecified.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.1.\n\nTarget ISA Notes\n\nRequires target sm_30 or higher.\n\nExamples\n\nmov.u64 r1,%globaltimer;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-globaltimer-globaltimer-lo-globaltimer-hi"
- };
-
- case "globaltimer_lo":
- return {
- "html": "For more information, visit globaltimer_lo .
Special Registers: %globaltimer, %globaltimer_lo, %globaltimer_hi
Special registers intended for use by NVIDIA tools. The behavior is target-specific and may change\nor be removed in future GPUs. When JIT-compiled to other targets, the value of these registers is\nunspecified.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.1.
\n
Target ISA Notes
\n
Requires target sm_30 or higher.
\n
Examples
\n
\n
mov.u64 r1,%globaltimer;\n
\n
\n",
- "tooltip": "%globaltimer\n\nA predefined, 64-bit global nanosecond timer.\n\n%globaltimer_lo\n\nThe lower 32-bits of %globaltimer.\n\n%globaltimer_hi\n\nThe upper 32-bits of %globaltimer.\n\nSyntax (predefined)\n\n.sreg .u64 %globaltimer;\n\n.sreg .u32 %globaltimer_lo, %globaltimer_hi;\n\nDescription\n\nSpecial registers intended for use by NVIDIA tools. The behavior is target-specific and may change\n\nor be removed in future GPUs. When JIT-compiled to other targets, the value of these registers is\n\nunspecified.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.1.\n\nTarget ISA Notes\n\nRequires target sm_30 or higher.\n\nExamples\n\nmov.u64 r1,%globaltimer;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-globaltimer-globaltimer-lo-globaltimer-hi"
- };
-
case "griddepcontrol":
return {
- "html": "For more information, visit griddepcontrol .
Parallel Synchronization and Communication Instructions: griddepcontrol
The griddepcontrol instruction allows the dependent grids and prerequisite grids as defined by\nthe runtime, to control execution in the following way:
\n
.launch_dependents modifier signals that specific dependents the runtime system designated to\nreact to this instruction can be scheduled as soon as all other CTAs in the grid issue the same\ninstruction or have completed. The dependent may launch before the completion of the current\ngrid. There is no guarantee that the dependent will launch before the completion of the current\ngrid. Repeated invocations of this instruction by threads in the current CTA will have no additional\nside effects past that of the first invocation.
\n
.wait modifier causes the executing thread to wait until all prerequisite grids in flight have\ncompleted and all the memory operations from the prerequisite grids are performed and made visible\nto the current grid.
\n
\n
Note
\n
If the prerequisite grid is using griddepcontrol.launch_dependents, then the dependent grid\nmust use griddepcontrol.wait to ensure correct functional execution.
\n",
- "tooltip": "Control execution of dependent grids.\n\nSyntax\n\ngriddepcontrol.action;\n\n.action = { .launch_dependents, .wait }\n\nDescription\n\nThe griddepcontrol instruction allows the dependent grids and prerequisite grids as defined by\n\nthe runtime, to control execution in the following way:\n\n.launch_dependents modifier signals that specific dependents the runtime system designated to\n\nreact to this instruction can be scheduled as soon as all other CTAs in the grid issue the same\n\ninstruction or have completed. The dependent may launch before the completion of the current\n\ngrid. There is no guarantee that the dependent will launch before the completion of the current\n\ngrid. Repeated invocations of this instruction by threads in the current CTA will have no additional\n\nside effects past that of the first invocation.\n\n.wait modifier causes the executing thread to wait until all prerequisite grids in flight have\n\ncompleted and all the memory operations from the prerequisite grids are performed and made visible\n\nto the current grid.\n\nNote\n\nIf the prerequisite grid is using griddepcontrol.launch_dependents, then the dependent grid\n\nmust use griddepcontrol.wait to ensure correct functional execution.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\ngriddepcontrol.launch_dependents;\n\ngriddepcontrol.wait;\n\n ...",
+ "html": "
The griddepcontrol instruction allows the dependent grids and prerequisite grids as defined by\nthe runtime, to control execution in the following way:
\nFor more information, visit griddepcontrol .",
+ "tooltip": "Control execution of dependent grids.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-griddepcontrol"
};
- case "gridid":
- return {
- "html": "For more information, visit gridid .
Special Registers: %gridid
\n\n\n
Grid identifier.
\n
Syntax (predefined)
\n
\n
.sreg .u64 %gridid;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with the per-grid temporal grid identifier. The\n%gridid is used by debuggers to distinguish CTAs and clusters within concurrent (small) grids.
\n
During execution, repeated launches of programs may occur, where each launch starts a\ngrid-of-CTAs. This variable provides the temporal grid launch number for this context.
\n
For sm_1x targets, %gridid is limited to the range [0..216-1]. For sm_20,\n%gridid is limited to the range [0..232-1]. sm_30 supports the entire 64-bit range.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0 as type .u16.
\n
Redefined as type .u32 in PTX ISA version 1.3.
\n
Redefined as type .u64 in PTX ISA version 3.0.
\n
For compatibility with legacy PTX code, 16-bit and 32-bit mov and cvt instructions may be\nused to read the lower 16-bits or 32-bits of each component of %gridid.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mov.u64 %s, %gridid; // 64-bit read of %gridid\nmov.u32 %r, %gridid; // legacy code with 32-bit %gridid\n
\n
\n",
- "tooltip": "Grid identifier.\n\nSyntax (predefined)\n\n.sreg .u64 %gridid;\n\nDescription\n\nA predefined, read-only special register initialized with the per-grid temporal grid identifier. The\n\n%gridid is used by debuggers to distinguish CTAs and clusters within concurrent (small) grids.\n\nDuring execution, repeated launches of programs may occur, where each launch starts a\n\ngrid-of-CTAs. This variable provides the temporal grid launch number for this context.\n\nFor sm_1x targets, %gridid is limited to the range [0..216-1]. For sm_20,\n\n%gridid is limited to the range [0..232-1]. sm_30 supports the entire 64-bit range.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0 as type .u16.\n\nRedefined as type .u32 in PTX ISA version 1.3.\n\nRedefined as type .u64 in PTX ISA version 3.0.\n\nFor compatibility with legacy PTX code, 16-bit and 32-bit mov and cvt instructions may be\n\nused to read the lower 16-bits or 32-bits of each component of %gridid.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.u64 %s, %gridid; // 64-bit read of %gridid\n\nmov.u32 %r, %gridid; // legacy code with 32-bit %gridid\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-gridid"
- };
-
- case "is_explicit_cluster":
- return {
- "html": "For more information, visit is_explicit_cluster .
Special Registers: %is_explicit_cluster
\n\n\n
Checks if user has explicitly specified cluster launch.
\n
Syntax (predefined)
\n
\n
.sreg .pred %is_explicit_cluster;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with the predicate value of whether the cluster\nlaunch is explicitly specified by user.
\n",
- "tooltip": "Checks if user has explicitly specified cluster launch.\n\nSyntax (predefined)\n\n.sreg .pred %is_explicit_cluster;\n\nDescription\n\nA predefined, read-only special register initialized with the predicate value of whether the cluster\n\nlaunch is explicitly specified by user.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.reg .pred p;\n\nmov.pred p, %is_explicit_cluster;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-is-explicit-cluster"
- };
-
case "isspacep":
return {
- "html": "For more information, visit isspacep .
Data Movement and Conversion Instructions: isspacep
\n\n\n
Query whether a generic address falls within a specified state space window.
\n
Syntax
\n
\n
isspacep.space p, a; // result is .pred\n\n.space = { const, .global, .local, .shared{::cta, ::cluster}, .param{::entry} };\n
\n
\n
Description
\n
Write predicate register p with 1 if generic address a falls within the specified state\nspace window and with 0 otherwise. Destination p has type .pred; the source address\noperand must be of type .u32 or .u64.
\n
isspacep.param{::entry} returns 1 if the generic address falls within the window of\nKernel Function Parameters, otherwise returns 0. If .param\nis specified without any sub-qualifiers then it defaults to .param::entry.
\n
isspacep.global returns 1 for Kernel Function Parameters as .param window is contained within the .global\nwindow.
\n
If no sub-qualifier is specified with .shared state space, then ::cta is assumed by default.
\n
\n
Note
\n
ispacep.shared::cluster will return 1 for every shared memory address that is accessible to\nthe threads in the cluster, whereas ispacep.shared::cta will return 1 only if the address is\nof a variable declared in the executing CTA.
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
isspacep.const introduced in PTX ISA version 3.1.
\n
isspacep.param introduced in PTX ISA version 7.7.
\n
Support for ::cta and ::cluster sub-qualifiers introduced in PTX ISA version 7.8.
\n
Support for sub-qualifier ::entry on .param space introduced in PTX ISA version 8.3.
\n",
- "tooltip": "Query whether a generic address falls within a specified state space window.\n\nSyntax\n\nisspacep.space p, a; // result is .pred\n\n.space = { const, .global, .local, .shared{::cta, ::cluster}, .param{::entry} };\n\nDescription\n\nWrite predicate register p with 1 if generic address a falls within the specified state\n\nspace window and with 0 otherwise. Destination p has type .pred; the source address\n\noperand must be of type .u32 or .u64.\n\nisspacep.param{::entry} returns 1 if the generic address falls within the window of\n\nKernel Function Parameters, otherwise returns 0. If .param\n\nis specified without any sub-qualifiers then it defaults to .param::entry.\n\nisspacep.global returns 1 for Kernel Function Parameters as .param window is contained within the .global\n\nwindow.\n\nIf no sub-qualifier is specified with .shared state space, then ::cta is assumed by default.\n\nNote\n\nispacep.shared::cluster will return 1 for every shared memory address that is accessible to\n\nthe threads in the cluster, whereas ispacep.shared::cta will return 1 only if the address is\n\nof a variable declared in the executing CTA.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nisspacep.const introduced in PTX ISA version 3.1.\n\nisspacep.param introduced in PTX ISA version 7.7.\n\nSupport for ::cta and ::cluster sub-qualifiers introduced in PTX ISA version 7.8.\n\nSupport for sub-qualifier ::entry on .param space introduced in PTX ISA version 8.3.\n\nTarget ISA Notes\n\nisspacep requires sm_20 or higher.\n\nisspacep.param{::entry} requires sm_70 or higher.\n\nSub-qualifier ::cta requires sm_30 or higher.\n\nSub-qualifier ::cluster requires sm_90 or higher.\n\nExamples\n\nisspacep.const iscnst, cptr;\n\nisspacep.global isglbl, gptr;\n\nisspacep.local islcl, lptr;\n\nisspacep.shared isshrd, sptr;\n\nisspacep.param::entry isparam, pptr;\n\nisspacep.shared::cta isshrdcta, sptr;\n\nisspacep.shared::cluster ishrdany sptr;\n\n ...",
+ "html": "
Write predicate register p with 1 if generic address a falls within the specified state\nspace window and with 0 otherwise. Destination p has type .pred; the source address\noperand must be of type .u32 or .u64.
\nFor more information, visit isspacep .",
+ "tooltip": "Query whether a generic address falls within a specified state space window.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-isspacep"
};
case "istypep":
return {
- "html": "For more information, visit istypep .
Texture Instructions: istypep
\n\n\n
Query whether a register points to an opaque variable of a specified type.
\n
Syntax
\n
\n
istypep.type p, a; // result is .pred\n\n.type = { .texref, .samplerref, .surfref };\n
\n
\n
Description
\n
Write predicate register p with 1 if register a points to an opaque variable of the\nspecified type, and with 0 otherwise. Destination p has type .pred; the source address\noperand must be of type .u64.
\n",
- "tooltip": "Query whether a register points to an opaque variable of a specified type.\n\nSyntax\n\nistypep.type p, a; // result is .pred\n\n.type = { .texref, .samplerref, .surfref };\n\nDescription\n\nWrite predicate register p with 1 if register a points to an opaque variable of the\n\nspecified type, and with 0 otherwise. Destination p has type .pred; the source address\n\noperand must be of type .u64.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 4.0.\n\nTarget ISA Notes\n\nistypep requires sm_30 or higher.\n\nExamples\n\nistypep.texref istex, tptr;\n\nistypep.samplerref issampler, sptr;\n\nistypep.surfref issurface, surfptr;\n\n ...",
+ "html": "
Write predicate register p with 1 if register a points to an opaque variable of the\nspecified type, and with 0 otherwise. Destination p has type .pred; the source address\noperand must be of type .u64.
\nFor more information, visit istypep .",
+ "tooltip": "Query whether a register points to an opaque variable of a specified type.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#texture-instructions-istypep"
};
- case "laneid":
- return {
- "html": "For more information, visit laneid .
Special Registers: %laneid
\n\n\n
Lane Identifier.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %laneid;\n
\n
\n
Description
\n
A predefined, read-only special register that returns the thread\u2019s lane within the warp. The lane\nidentifier ranges from zero to WARP_SZ-1.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mov.u32 %r, %laneid;\n
\n
\n",
- "tooltip": "Lane Identifier.\n\nSyntax (predefined)\n\n.sreg .u32 %laneid;\n\nDescription\n\nA predefined, read-only special register that returns the thread\u2019s lane within the warp. The lane\n\nidentifier ranges from zero to WARP_SZ-1.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.3.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.u32 %r, %laneid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-laneid"
- };
-
- case "lanemask_eq":
- return {
- "html": "For more information, visit lanemask_eq .
Special Registers: %lanemask_eq
\n\n\n
32-bit mask with bit set in position equal to the thread\u2019s lane number in the warp.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %lanemask_eq;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with a 32-bit mask with a bit set in the\nposition equal to the thread\u2019s lane number in the warp.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%lanemask_eq requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %lanemask_eq;\n
\n
\n",
- "tooltip": "32-bit mask with bit set in position equal to the thread\u2019s lane number in the warp.\n\nSyntax (predefined)\n\n.sreg .u32 %lanemask_eq;\n\nDescription\n\nA predefined, read-only special register initialized with a 32-bit mask with a bit set in the\n\nposition equal to the thread\u2019s lane number in the warp.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%lanemask_eq requires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %lanemask_eq;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-lanemask-eq"
- };
-
- case "lanemask_ge":
- return {
- "html": "For more information, visit lanemask_ge .
Special Registers: %lanemask_ge
\n\n\n
32-bit mask with bits set in positions greater than or equal to the thread\u2019s lane number in the warp.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %lanemask_ge;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with a 32-bit mask with bits set in positions\ngreater than or equal to the thread\u2019s lane number in the warp.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%lanemask_ge requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %lanemask_ge;\n
\n
\n",
- "tooltip": "32-bit mask with bits set in positions greater than or equal to the thread\u2019s lane number in the warp.\n\nSyntax (predefined)\n\n.sreg .u32 %lanemask_ge;\n\nDescription\n\nA predefined, read-only special register initialized with a 32-bit mask with bits set in positions\n\ngreater than or equal to the thread\u2019s lane number in the warp.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%lanemask_ge requires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %lanemask_ge;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-lanemask-ge"
- };
-
- case "lanemask_gt":
- return {
- "html": "For more information, visit lanemask_gt .
Special Registers: %lanemask_gt
\n\n\n
32-bit mask with bits set in positions greater than the thread\u2019s lane number in the warp.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %lanemask_gt;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with a 32-bit mask with bits set in positions\ngreater than the thread\u2019s lane number in the warp.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%lanemask_gt requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %lanemask_gt;\n
\n
\n",
- "tooltip": "32-bit mask with bits set in positions greater than the thread\u2019s lane number in the warp.\n\nSyntax (predefined)\n\n.sreg .u32 %lanemask_gt;\n\nDescription\n\nA predefined, read-only special register initialized with a 32-bit mask with bits set in positions\n\ngreater than the thread\u2019s lane number in the warp.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%lanemask_gt requires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %lanemask_gt;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-lanemask-gt"
- };
-
- case "lanemask_le":
- return {
- "html": "For more information, visit lanemask_le .
Special Registers: %lanemask_le
\n\n\n
32-bit mask with bits set in positions less than or equal to the thread\u2019s lane number in the warp.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %lanemask_le;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with a 32-bit mask with bits set in positions\nless than or equal to the thread\u2019s lane number in the warp.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%lanemask_le requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %lanemask_le\n
\n
\n",
- "tooltip": "32-bit mask with bits set in positions less than or equal to the thread\u2019s lane number in the warp.\n\nSyntax (predefined)\n\n.sreg .u32 %lanemask_le;\n\nDescription\n\nA predefined, read-only special register initialized with a 32-bit mask with bits set in positions\n\nless than or equal to the thread\u2019s lane number in the warp.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%lanemask_le requires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %lanemask_le\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-lanemask-le"
- };
-
- case "lanemask_lt":
+ case "ld":
return {
- "html": "For more information, visit lanemask_lt .
Special Registers: %lanemask_lt
\n\n\n
32-bit mask with bits set in positions less than the thread\u2019s lane number in the warp.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %lanemask_lt;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with a 32-bit mask with bits set in positions\nless than the thread\u2019s lane number in the warp.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%lanemask_lt requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %lanemask_lt;\n
\n
\n",
- "tooltip": "32-bit mask with bits set in positions less than the thread\u2019s lane number in the warp.\n\nSyntax (predefined)\n\n.sreg .u32 %lanemask_lt;\n\nDescription\n\nA predefined, read-only special register initialized with a 32-bit mask with bits set in positions\n\nless than the thread\u2019s lane number in the warp.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%lanemask_lt requires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %lanemask_lt;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-lanemask-lt"
+ "html": "
Load register variable d from the location specified by the source address operand a in\nspecified state space. If no state space is given, perform the load using Generic Addressing.
\nFor more information, visit ld .",
+ "tooltip": "Load a register variable from an addressable state space variable.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-ld"
};
- case "ld":
+ case "ldmatrix":
return {
- "html": "For more information, visit ld , ld.global.nc .
Data Movement and Conversion Instructions: ld
\n\n\n
Load a register variable from an addressable state space variable.
Load register variable d from the location specified by the source address operand a in\nspecified state space. If no state space is given, perform the load using Generic Addressing.
\n
If no sub-qualifier is specified with .shared state space, then ::cta is assumed by default.
\n
Supported addressing modes for operand a and alignment requirements are described in Addresses\nas Operands
\n
If no sub-qualifier is specified with .param state space, then\u202f:
\n
\n
::func is assumed when access is inside a device function.
\n
::entry is assumed when accessing kernel function parameters from entry function. Otherwise, when\naccessing device function parameters or any other .param variables from entry function ::func\nis assumed by default.
\n
\n
For ld.param::entry instruction, operand a must be a kernel parameter address, otherwise behavior\nis undefined. For ld.param::func instruction, operand a must be a device function parameter address,\notherwise behavior is undefined.
The .relaxed and .acquire qualifiers indicate memory synchronization as described in the\nMemory Consistency Model. The .scope qualifier\nindicates the set of threads with which an ld.relaxed or ld.acquire instruction can directly\nsynchronize1. The .weak qualifier indicates a memory instruction with no synchronization.\nThe effects of this instruction become visible to other threads only when synchronization is established\nby other means.
\n
The semantic details of .mmio qualifier are described in the Memory Consistency Model. Only .sys thread scope is valid for ld.mmio operation. The\nqualifiers .mmio and .relaxed must be specified together.
\n
The .weak, .volatile, .relaxed and .acquire qualifiers are mutually exclusive. When\nnone of these is specified, the .weak qualifier is assumed by default.
\n
An ld.volatile operation is always performed and it will not be reordered with respect to other\nvolatile operations to the same memory location. volatile and non-volatile load operations\nto the same memory location may be reordered. ld.volatile has the same memory synchronization\nsemantics as ld.relaxed.sys.
\n
The qualifiers .volatile, .relaxed and .acquire may be used only with .global and\n.shared spaces and with generic addressing, where the address points to .global or\n.shared space. Cache operations are not permitted with these qualifiers. The qualifier .mmio\nmay be used only with .global space and with generic addressing, where the address points to\n.global space.
The qualifier .level::eviction_priority specifies the eviction policy that will be used during\nmemory access.
\n
The .level::prefetch_size qualifier is a hint to fetch additional data of the specified size\ninto the respective cache level.The sub-qualifier prefetch_size can be set to either of 64B,\n128B, 256B thereby allowing the prefetch size to be 64 Bytes, 128 Bytes or 256 Bytes\nrespectively.
\n
The qualifier .level::prefetch_size may only be used with .global state space and with\ngeneric addressing where the address points to .global state space. If the generic address does\nnot fall within the address window of the global memory, then the prefetching behavior is undefined.
\n
The .level::prefetch_size qualifier is treated as a performance hint only.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
The qualifiers .unified and .level::cache_hint are only supported for .global state\nspace and for generic addressing where the address points to the .global state space.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
\n
1 This synchronization is further extended to other threads through the transitive nature of\ncausality order, as described in the memory consistency model.
A destination register wider than the specified type may be used. The value loaded is sign-extended\nto the destination register width for signed integers, and is zero-extended to the destination\nregister width for unsigned and bit-size types. See\nTable 27\nfor a description of these relaxed type-checking rules.
\n
.f16 data may be loaded using ld.b16, and then converted to .f32 or .f64 using\ncvt or can be used in half precision floating point instructions.
\n
.f16x2 data may be loaded using ld.b32 and then used in half precision floating point\ninstructions.
\n
PTX ISA Notes
\n
ld introduced in PTX ISA version 1.0. ld.volatile introduced in PTX ISA version 1.1.
\n
Generic addressing and cache operations introduced in PTX ISA version 2.0.
\n
Support for scope qualifier, .relaxed, .acquire, .weak qualifiers introduced in PTX ISA\nversion 6.0.
\n
Support for generic addressing of .const space added in PTX ISA version 3.1.
\n
Support for .level::eviction_priority, .level::prefetch_size and .level::cache_hint\nqualifiers introduced in PTX ISA version 7.4.
\n
Support for .cluster scope qualifier introduced in PTX ISA version 7.8.
\n
Support for ::cta and ::cluster sub-qualifiers introduced in PTX ISA version 7.8.
\n
Support for .unified qualifier introduced in PTX ISA version 8.0.
\n
Support for .mmio qualifier introduced in PTX ISA version 8.2.
\n
Support for ::entry and ::func sub-qualifiers on .param space introduced in PTX ISA\nversion 8.3.
\n
Support for .b128 type introduced in PTX ISA version 8.3.
\n
Support for .sys scope with .b128 type introduced in PTX ISA version 8.4.
\n
Target ISA Notes
\n
ld.f64 requires sm_13 or higher.
\n
Support for scope qualifier, .relaxed, .acquire, .weak qualifiers require sm_70 or\nhigher.
\n
Generic addressing requires sm_20 or higher.
\n
Cache operations require sm_20 or higher.
\n
Support for .level::eviction_priority qualifier requires sm_70 or higher.
\n
Support for .level::prefetch_size qualifier requires sm_75 or higher.
\n
Support for .L2::256B and .L2::cache_hint qualifiers requires sm_80 or higher.
\n
Support for .cluster scope qualifier requires sm_90 or higher.
\n
Sub-qualifier ::cta requires sm_30 or higher.
\n
Sub-qualifier ::cluster requires sm_90 or higher.
\n
Support for .unified qualifier requires sm_90 or higher.
\n
Support for .mmio qualifier requires sm_70 or higher.
\n
Support for .b128 type requires sm_70 or higher.
\n
Examples
\n
\n
ld.global.f32 d,[a];\nld.shared.v4.b32 Q,[p];\nld.const.s32 d,[p+4];\nld.local.b32 x,[p+-8]; // negative offset\nld.local.b64 x,[240]; // immediate address\n\nld.global.b16 %r,[fs]; // load .f16 data into 32-bit reg\ncvt.f32.f16 %r,%r; // up-convert f16 data to f32\n\nld.global.b32 %r0, [fs]; // load .f16x2 data in 32-bit reg\nld.global.b32 %r1, [fs + 4]; // load .f16x2 data in 32-bit reg\nadd.rn.f16x2 %d0, %r0, %r1; // addition of f16x2 data\nld.global.relaxed.gpu.u32 %r0, [gbl];\nld.shared.acquire.gpu.u32 %r1, [sh];\nld.global.relaxed.cluster.u32 %r2, [gbl];\nld.shared::cta.acquire.gpu.u32 %r2, [sh + 4];\nld.shared::cluster.u32 %r3, [sh + 8];\nld.global.mmio.relaxed.sys.u32 %r3, [gbl];\n\nld.global.f32 d,[ugbl].unified;\nld.b32 %r0, [%r1].unified;\n\nld.global.L1::evict_last.u32 d, [p];\n\nld.global.L2::64B.b32 %r0, [gbl]; // Prefetch 64B to L2\nld.L2::128B.f64 %r1, [gbl]; // Prefetch 128B to L2\nld.global.L2::256B.f64 %r2, [gbl]; // Prefetch 256B to L2\n\ncreatepolicy.fractional.L2::evict_last.L2::evict_unchanged.b64 cache-policy, 1;\nld.global.L2::cache_hint.b64 x, [p], cache-policy;\nld.param::entry.b32 %rp1, [kparam1];\n\nld.global.b128 %r0, [gbl]; // 128-bit load\n
\n
\n\n
Data Movement and Conversion Instructions: ld.global.nc
\n\n\n
Load a register variable from global state space via non-coherent cache.
Load register variable d from the location specified by the source address operand a in the\nglobal state space, and optionally cache in non-coherent read-only cache.
\n
\n
Note
\n
On some architectures, the texture cache is larger, has higher bandwidth, and longer latency than\nthe global memory cache. For applications with sufficient parallelism to cover the longer\nlatency, ld.global.nc should offer better performance than ld.global on such\narchitectures.
\n
\n
The address operand a may contain a generic address pointing to the\n.global state space. Supported addressing modes for operand a and alignment requirements are\ndescribed in Addresses as Operands
\n
The qualifier .level::eviction_priority specifies the eviction policy that will be used during\nmemory access.
\n
The .level::prefetch_size qualifier is a hint to fetch additional data of the specified size\ninto the respective cache level.The sub-qualifier prefetch_size can be set to either of 64B,\n128B, 256B thereby allowing the prefetch size to be 64 Bytes, 128 Bytes or 256 Bytes\nrespectively.
\n
The .level::prefetch_size qualifier is treated as a performance hint only.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
A destination register wider than the specified type may be used. The value loaded is sign-extended\nto the destination register width for signed integers, and is zero-extended to the destination\nregister width for unsigned and bit-size types.
\n
.f16 data may be loaded using ld.b16, and then converted to .f32 or .f64 using cvt.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.1.
\n
Support for .level::eviction_priority, .level::prefetch_size and .level::cache_hint\nqualifiers introduced in PTX ISA version 7.4.
\n
Support for .b128 type introduced in PTX ISA version 8.3.
\n
Target ISA Notes
\n
Requires sm_32 or higher.
\n
Support for .level::eviction_priority qualifier requires sm_70 or higher.
\n
Support for .level::prefetch_size qualifier requires sm_75 or higher.
\n
Support for .level::cache_hint qualifier requires sm_80 or higher.
\n",
- "tooltip": "=====Data Movement and Conversion Instructions: ld\n\n\n\nLoad a register variable from an addressable state space variable.\n\nSyntax\n\nld{.weak}{.ss}{.cop}{.level::cache_hint}{.level::prefetch_size}{.vec}.type d, [a]{.unified}{, cache-policy};\n\nld{.weak}{.ss}{.level::eviction_priority}{.level::cache_hint}{.level::prefetch_size}{.vec}.type d, [a]{.unified}{, cache-policy};\n\nld.volatile{.ss}{.level::prefetch_size}{.vec}.type d, [a];\n\nld.relaxed.scope{.ss}{.le...\n\n=====Data Movement and Conversion Instructions: ld.global.nc\n\n\n\nLoad a register variable from global state space via non-coherent cache.\n\nSyntax\n\nld.global{.cop}.nc{.level::cache_hint}{.level::prefetch_size}.type d, [a]{, cache-policy};\n\nld.global{.cop}.nc{.level::cache_hint}{.level::prefetch_size}.vec.type d, [a]{, cache-policy};\n\nld.global.nc{.level::eviction_priority}{.level::cache_hint}{.level::prefetch_size}.type d, [a]{, cach... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-ld"
+ "html": "
Collectively load one or more matrices across all threads in a warp from the location indicated by\nthe address operand p, from .shared state space into destination register r. If no state\nspace is provided, generic addressing is used, such that the address in p points into\n.shared space. If the generic address doesn\u2019t fall in .shared state space, then the behavior\nis undefined.
\nFor more information, visit ldmatrix .",
+ "tooltip": "Collectively load one or more matrices from shared memory formmainstruction",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-ldmatrix"
};
case "ldu":
return {
- "html": "For more information, visit ldu .
Data Movement and Conversion Instructions: ldu
\n\n\n
Load read-only data from an address that is common across threads in the warp.
Load read-only data into register variable d from the location specified by the source address\noperand a in the global state space, where the address is guaranteed to be the same across all\nthreads in the warp. If no state space is given, perform the load using Generic Addressing.
\n
Supported addressing modes for operand a and alignment requirements are described in Addresses\nas Operands
A destination register wider than the specified type may be used. The value loaded is sign-extended\nto the destination register width for signed integers, and is zero-extended to the destination\nregister width for unsigned and bit-size types. See\nTable 27\nfor a description of these relaxed type-checking rules.
\n
.f16 data may be loaded using ldu.b16, and then converted to .f32 or .f64 using\ncvtor can be used in half precision floating point instructions.
\n
.f16x2 data may be loaded using ldu.b32 and then used in half precision floating point\ninstructions.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Support for .b128 type introduced in PTX ISA version 8.3.
\n",
- "tooltip": "Load read-only data from an address that is common across threads in the warp.\n\nSyntax\n\nldu{.ss}.type d, [a]; // load from address\n\nldu{.ss}.vec.type d, [a]; // vec load from address\n\n.ss = { .global }; // state space\n\n.vec = { .v2, .v4 };\n\n.type = { .b8, .b16, .b32, .b64, .b128,\n\n .u8, .u16, .u32, .u64,\n\n .s8, .s16, .s32, .s64,\n\n .f32, .f64 };\n\nDescription\n\nLoad read-only data into register variable d from the location specified by the source address\n\noperand a in the global state space, where the address is guaranteed to be the same across all\n\nthreads in the warp. If no state space is given, perform the load using Generic Addressing.\n\nSupported addressing modes for operand a and alignment requirements are described in Addresses\n\nas Operands\n\nSemantics\n\nd = a; // named variable a\n\nd = *(&a+immOff) // variable-plus-offset\n\nd = *a; // register\n\nd = *(a+immOff); // register-plus-offset\n\nd = *(immAddr); // immediate address\n\nNotes\n\nDestination d must be in the .reg state space.\n\nA destination register wider than the specified type may be used. The value loaded is sign-extended\n\nto the destination register width for signed integers, and is zero-extended to the destination\n\nregister width for unsigned and bit-size types. See\n\nTable 27\n\nfor a description of these relaxed type-checking rules.\n\n.f16 data may be loaded using ldu.b16, and then converted to .f32 or .f64 using\n\ncvtor can be used in half precision floating point instructions.\n\n.f16x2 data may be loaded using ldu.b32 and then used in half precision floating point\n\ninstructions.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nSupport for .b128 type introduced in PTX ISA version 8.3.\n\nTarget ISA Notes\n\nldu.f64 requires sm_13 or higher.\n\nSupport for .b128 type requires sm_70 or higher.\n\nExamples\n\nldu.global.f32 d,[a];\n\nldu.global.b32 d,[p+4];\n\nldu.global.v4.f32 Q,[p];\n\nldu.global.b128 d,[a];\n\n ...",
+ "html": "
Load read-only data into register variable d from the location specified by the source address\noperand a in the global state space, where the address is guaranteed to be the same across all\nthreads in the warp. If no state space is given, perform the load using Generic Addressing.
\nFor more information, visit ldu .",
+ "tooltip": "Load read-only data from an address that is common across threads in the warp.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-ldu"
};
case "lg2":
return {
- "html": "For more information, visit lg2(fp) .
Floating Point Instructions: lg2
\n\n\n
Find the base-2 logarithm of a value.
\n
Syntax
\n
\n
lg2.approx{.ftz}.f32 d, a;\n
\n
\n
Description
\n
Determine the log2 of a.
\n
Semantics
\n
\n
d = log(a) / log(2);\n
\n
\n
Notes
\n
lg2.approx.f32 implements a fast approximation to log2(a).
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
NaN
\n
\n
\n
-subnormal
\n
-Inf
\n
\n
\n
-0.0
\n
-Inf
\n
\n
\n
+0.0
\n
-Inf
\n
\n
\n
+subnormal
\n
-Inf
\n
\n
\n
+Inf
\n
+Inf
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
The maximum absolute error is 2-22.6 for mantissa.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
lg2.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
Subnormal inputs and results to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
lg2.f32 introduced in PTX ISA version 1.0. Explicit modifiers .approx and .ftz\nintroduced in PTX ISA version 1.4.
\n
For PTX ISA version 1.4 and later, the .approx modifier is required.
\n
For PTX ISA versions 1.0 through 1.3, lg2.f32 defaults to lg2.approx.ftz.f32.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
lg2.approx.ftz.f32 la, a;\n
\n
\n",
- "tooltip": "Find the base-2 logarithm of a value.\n\nSyntax\n\nlg2.approx{.ftz}.f32 d, a;\n\nDescription\n\nDetermine the log2 of a.\n\nSemantics\n\nd = log(a) / log(2);\n\nNotes\n\nlg2.approx.f32 implements a fast approximation to log2(a).\n\n\n\nInput\n\nResult\n\n\n\n-Inf\n\nNaN\n\n-subnormal\n\n-Inf\n\n-0.0\n\n-Inf\n\n+0.0\n\n-Inf\n\n+subnormal\n\n-Inf\n\n+Inf\n\n+Inf\n\nNaN\n\nNaN\n\nThe maximum absolute error is 2-22.6 for mantissa.\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, subnormal numbers are supported.\n\nlg2.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.\n\nsm_1x\n\nSubnormal inputs and results to sign-preserving zero.\n\nPTX ISA Notes\n\nlg2.f32 introduced in PTX ISA version 1.0. Explicit modifiers .approx and .ftz\n\nintroduced in PTX ISA version 1.4.\n\nFor PTX ISA version 1.4 and later, the .approx modifier is required.\n\nFor PTX ISA versions 1.0 through 1.3, lg2.f32 defaults to lg2.approx.ftz.f32.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nlg2.approx.ftz.f32 la, a;\n\n ...",
+ "html": "
Determine the log2 of a.
\nFor more information, visit lg2(fp) .",
+ "tooltip": "Find the base-2 logarithm of a value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-lg2"
};
- case "loc":
- return {
- "html": "For more information, visit loc .
Declares the source file location (source file, line number, and column position) to be associated\nwith lexically subsequent PTX instructions. .loc refers to file_index which is defined by a\n.file directive.
\n
To indicate PTX instructions that are generated from a function that got inlined, additional\nattribute .inlined_at can be specified as part of the .loc directive. .inlined_at\nattribute specifies source location at which the specified function is inlined. file_index2,\nline_number2, and column_position2 specify the location at which function is inlined. Source\nlocation specified as part of .inlined_at directive must lexically precede as source location in\n.loc directive.
\n
The function_name attribute specifies an offset in the DWARF section named\n.debug_str. Offset is specified as label expression or label+immediate expression\nwhere label is defined in .debug_str section. DWARF section .debug_str contains ASCII\nnull-terminated strings that specify the name of the function that is inlined.
\n
Note that a PTX instruction may have a single associated source location, determined by the nearest\nlexically preceding .loc directive, or no associated source location if there is no preceding .loc\ndirective. Labels in PTX inherit the location of the closest lexically following instruction. A\nlabel with no following PTX instruction has no associated source location.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
function_name and inlined_at attributes are introduced in PTX ISA version 7.2.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.loc 2 4237 0\nL1: // line 4237, col 0 of file #2,\n // inherited from mov\n mov.u32 %r1,%r2; // line 4237, col 0 of file #2\n add.u32 %r2,%r1,%r3; // line 4237, col 0 of file #2\n...\nL2: // line 4239, col 5 of file #2,\n // inherited from sub\n .loc 2 4239 5\n sub.u32 %r2,%r1,%r3; // line 4239, col 5 of file #2\n .loc 1 21 3\n .loc 1 9 3, function_name info_string0, inlined_at 1 21 3\n ld.global.u32 %r1, [gg]; // Function at line 9\n setp.lt.s32 %p1, %r1, 8; // inlined at line 21\n .loc 1 27 3\n .loc 1 10 5, function_name info_string1, inlined_at 1 27 3\n .loc 1 15 3, function_name .debug_str+16, inlined_at 1 10 5\n setp.ne.s32 %p2, %r1, 18;\n @%p2 bra BB2_3;\n\n .section .debug_str {\n info_string0:\n .b8 95 // _\n .b8 90 // z\n .b8 51 // 3\n .b8 102 // f\n .b8 111 // o\n .b8 111 // o\n .b8 118 // v\n .b8 0\n\n info_string1:\n .b8 95 // _\n .b8 90 // z\n .b8 51 // 3\n .b8 98 // b\n .b8 97 // a\n .b8 114 // r\n .b8 118 // v\n .b8 0\n .b8 95 // _\n .b8 90 // z\n .b8 51 // 3\n .b8 99 // c\n .b8 97 // a\n .b8 114 // r\n .b8 118 // v\n .b8 0\n }\n
\n
\n",
- "tooltip": "Source file location.\n\nSyntax\n\n.loc file_index line_number column_position\n\n.loc file_index line_number column_position,function_name label {+ immediate }, inlined_at file_index2 line_number2 column_position2\n\nDescription\n\nDeclares the source file location (source file, line number, and column position) to be associated\n\nwith lexically subsequent PTX instructions. .loc refers to file_index which is defined by a\n\n.file directive.\n\nTo indicate PTX instructions that are generated from a function that got inlined, additional\n\nattribute .inlined_at can be specified as part of the .loc directive. .inlined_at\n\nattribute specifies source location at which the specified function is inlined. file_index2,\n\nline_number2, and column_position2 specify the location at which function is inlined. Source\n\nlocation specified as part of .inlined_at directive must lexically precede as source location in\n\n.loc directive.\n\nThe function_name attribute specifies an offset in the DWARF section named\n\n.debug_str. Offset is specified as label expression or label + immediate expression\n\nwhere label is defined in .debug_str section. DWARF section .debug_str contains ASCII\n\nnull-terminated strings that specify the name of the function that is inlined.\n\nNote that a PTX instruction may have a single associated source location, determined by the nearest\n\nlexically preceding .loc directive, or no associated source location if there is no preceding .loc\n\ndirective. Labels in PTX inherit the location of the closest lexically following instruction. A\n\nlabel with no following PTX instruction has no associated source location.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nfunction_name and inlined_at attributes are introduced in PTX ISA version 7.2.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n .loc 2 4237 0\n\nL1: // line 4237, col 0 of file #2,\n\n // inherited from mov\n\n mov.u32 %r1,%r2; // line 4237, col 0 of file #2\n\n add.u32 %r2,%r1,%r3; // line 4237, col 0 of file #2\n\n...\n\nL2: // line 4239, col 5 of file #2,\n\n // inherited from sub\n\n .loc 2 4239 5\n\n sub.u32 %r2,%r1,%r3; // line 4239, col 5 of file #2\n\n .loc 1 21 3\n\n .loc 1 9 3, function_name info_string0, inlined_at 1 21 3\n\n ld.global.u32 %r1, [gg]; // Function at line 9\n\n setp.lt.s32 %p1, %r1, 8; // inlined at line 21\n\n .loc 1 27 3\n\n .loc 1 10 5, function_name info_string1, inlined_at 1 27 3\n\n .loc 1 15 3, function_name .debug_str+16, inlined_at 1 10 5\n\n setp.ne.s32 %p2, %r1, 18;\n\n @%p2 bra BB2_3;\n\n .section .debug_str {\n\n info_string0:\n\n .b8 95 // _\n\n .b8 90 // z\n\n .b8 51 // 3\n\n .b8 102 // f\n\n .b8 111 // o\n\n .b8 111 // o\n\n .b8 118 // v\n\n .b8 0\n\n info_string1:\n\n .b8 95 // _\n\n .b8 90 // z\n\n .b8 51 // 3\n\n .b8 98 // b\n\n .b8 97 // a\n\n .b8 114 // r\n\n .b8 118 // v\n\n .b8 0\n\n .b8 95 // _\n\n .b8 90 // z\n\n .b8 51 // 3\n\n .b8 99 // c\n\n .b8 97 // a\n\n .b8 114 // r\n\n .b8 118 // v\n\n .b8 0\n\n }\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#debugging-directives-loc"
- };
-
case "lop3":
return {
- "html": "For more information, visit lop3 .
Logic and Shift Instructions: lop3
\n\n\n
Arbitrary logical operation on 3 inputs.
\n
Syntax
\n
\n
lop3.b32 d, a, b, c, immLut;\nlop3.BoolOp.b32 d|p, a, b, c, immLut, q;\n\n.BoolOp = { .or , .and };\n
\n
\n
Description
\n
Compute bitwise logical operation on inputs a, b, c and store the result in destination\nd.
\n
Optionally, .BoolOp can be specified to compute the predicate result p by performing a\nBoolean operation on the destination operand d with the predicate q in the following manner:
\n
\n
p = (d != 0) BoolOp q;\n
\n
\n
The sink symbol \u2018_\u2019 may be used in place of the destination operand d when .BoolOp qualifier\nis specified.
\n
The logical operation is defined by a look-up table which, for 3 inputs, can be represented as an\n8-bit value specified by operand immLut as described below. immLut is an integer constant\nthat can take values from 0 to 255, thereby allowing up to 256 distinct logical operations on inputs\na, b, c.
\n
For a logical operation F(a,b,c) the value of immLut can be computed by applying the same\noperation to three predefined constant values as follows:
If F = (a & b & c);\nimmLut = 0xF0 & 0xCC & 0xAA = 0x80\n\nIf F = (a | b | c);\nimmLut = 0xF0 | 0xCC | 0xAA = 0xFE\n\nIf F = (a & b & ~c);\nimmLut = 0xF0 & 0xCC & (~0xAA) = 0x40\n\nIf F = ((a & b | c) ^ a);\nimmLut = (0xF0 & 0xCC | 0xAA) ^ 0xF0 = 0x1A\n
\n
\n
The following table illustrates computation of immLut for various logical operations:
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
ta
\n
tb
\n
tc
\n
Oper 0 (False)
\n
Oper 1 (ta & tb & tc)
\n
Oper 2 (ta & tb & ~tc)
\n
\u2026
\n
Oper 254 (ta | tb | tc)
\n
Oper 255 (True)
\n
\n\n\n
\n
0
\n
0
\n
0
\n
0
\n
0
\n
0
\n
\u2026
\n
0
\n
1
\n
\n
\n
0
\n
0
\n
1
\n
0
\n
0
\n
0
\n
1
\n
1
\n
\n
\n
0
\n
1
\n
0
\n
0
\n
0
\n
0
\n
1
\n
1
\n
\n
\n
0
\n
1
\n
1
\n
0
\n
0
\n
0
\n
1
\n
1
\n
\n
\n
1
\n
0
\n
0
\n
0
\n
0
\n
0
\n
1
\n
1
\n
\n
\n
1
\n
0
\n
1
\n
0
\n
0
\n
0
\n
1
\n
1
\n
\n
\n
1
\n
1
\n
0
\n
0
\n
0
\n
1
\n
1
\n
1
\n
\n
\n
1
\n
1
\n
1
\n
0
\n
1
\n
0
\n
1
\n
1
\n
\n
\n
immLut
\n
0x0
\n
0x80
\n
0x40
\n
\u2026
\n
0xFE
\n
0xFF
\n
\n\n
\n
Semantics
\n
\n
F = GetFunctionFromTable(immLut); // returns the function corresponding to immLut value\nd = F(a, b, c);\nif (BoolOp specified) {\n p = (d != 0) BoolOp q;\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.3.
\n
Support for .BoolOp qualifier introduced in PTX ISA version 8.2.
\n
Target ISA Notes
\n
Requires sm_50 or higher.
\n
Qualifier .BoolOp requires sm_70 or higher.
\n
Examples
\n
\n
lop3.b32 d, a, b, c, 0x40;\nlop3.or.b32 d|p, a, b, c, 0x3f, q;\nlop3.and.b32 _|p, a, b, c, 0x3f, q;\n
\n
\n",
- "tooltip": "Arbitrary logical operation on 3 inputs.\n\nSyntax\n\nlop3.b32 d, a, b, c, immLut;\n\nlop3.BoolOp.b32 d|p, a, b, c, immLut, q;\n\n.BoolOp = { .or , .and };\n\nDescription\n\nCompute bitwise logical operation on inputs a, b, c and store the result in destination\n\nd.\n\nOptionally, .BoolOp can be specified to compute the predicate result p by performing a\n\nBoolean operation on the destination operand d with the predicate q in the following manner:\n\np = (d != 0) BoolOp q;\n\nThe sink symbol \u2018_\u2019 may be used in place of the destination operand d when .BoolOp qualifier\n\nis specified.\n\nThe logical operation is defined by a look-up table which, for 3 inputs, can be represented as an\n\n8-bit value specified by operand immLut as described below. immLut is an integer constant\n\nthat can take values from 0 to 255, thereby allowing up to 256 distinct logical operations on inputs\n\na, b, c.\n\nFor a logical operation F(a, b, c) the value of immLut can be computed by applying the same\n\noperation to three predefined constant values as follows:\n\nta = 0xF0;\n\ntb = 0xCC;\n\ntc = 0xAA;\n\nimmLut = F(ta, tb, tc);\n\nExamples:\n\nIf F = (a & b & c);\n\nimmLut = 0xF0 & 0xCC & 0xAA = 0x80\n\nIf F = (a | b | c);\n\nimmLut = 0xF0 | 0xCC | 0xAA = 0xFE\n\nIf F = (a & b & ~c);\n\nimmLut = 0xF0 & 0xCC & (~0xAA) = 0x40\n\nIf F = ((a & b | c) ^ a);\n\nimmLut = (0xF0 & 0xCC | 0xAA) ^ 0xF0 = 0x1A\n\nThe following table illustrates computation of immLut for various logical operations:\n\n\n\n\n\n\n\nta\n\ntb\n\ntc\n\nOper 0 (False)\n\nOper 1 (ta & tb & tc)\n\nOper 2 (ta & tb & ~tc)\n\n\u2026\n\nOper 254 (ta | tb | tc)\n\nOper 255 (True)\n\n\n\n0\n\n0\n\n0\n\n0\n\n0\n\n0\n\n\u2026\n\n0\n\n1\n\n0\n\n0\n\n1\n\n0\n\n0\n\n0\n\n1\n\n1\n\n0\n\n1\n\n0\n\n0\n\n0\n\n0\n\n1\n\n1\n\n0\n\n1\n\n1\n\n0\n\n0\n\n0\n\n1\n\n1\n\n1\n\n0\n\n0\n\n0\n\n0\n\n0\n\n1\n\n1\n\n1\n\n0\n\n1\n\n0\n\n0\n\n0\n\n1\n\n1\n\n1\n\n1\n\n0\n\n0\n\n0\n\n1\n\n1\n\n1\n\n1\n\n1\n\n1\n\n0\n\n1\n\n0\n\n1\n\n1\n\nimmLut\n\n0x0\n\n0x80\n\n0x40\n\n\u2026\n\n0xFE\n\n0xFF\n\nSemantics\n\nF = GetFunctionFromTable(immLut); // returns the function corresponding to immLut value\n\nd = F(a, b, c);\n\nif (BoolOp specified) {\n\n p = (d != 0) BoolOp q;\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 4.3.\n\nSupport for .BoolOp qualifier introduced in PTX ISA version 8.2.\n\nTarget ISA Notes\n\nRequires sm_50 or higher.\n\nQualifier .BoolOp requires sm_70 or higher.\n\nExamples\n\nlop3.b32 d, a, b, c, 0x40;\n\nlop3.or.b32 d|p, a, b, c, 0x3f, q;\n\nlop3.and.b32 _|p, a, b, c, 0x3f, q;\n\n ...",
+ "html": "
Compute bitwise logical operation on inputs a, b, c and store the result in destination\nd.
\nFor more information, visit lop3 .",
+ "tooltip": "Arbitrary logical operation on 3 inputs.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-lop3"
};
case "mad":
return {
- "html": "For more information, visit mad(fp) , mad(int) , mad.cc .
Floating Point Instructions: mad
\n\n\n
Multiply two values and add a third value.
\n
Syntax
\n
\n
mad{.ftz}{.sat}.f32 d, a, b, c; // .target sm_1x\nmad.rnd{.ftz}{.sat}.f32 d, a, b, c; // .target sm_20\nmad.rnd.f64 d, a, b, c; // .target sm_13 and higher\n\n.rnd = { .rn, .rz, .rm, .rp };\n
\n
\n
Description
\n
Multiplies two values and adds a third, and then writes the resulting value into a destination\nregister.
\n
Semantics
\n
\n
d = a*b + c;\n
\n
\n
Notes
\n
For .targetsm_20 and higher:
\n
\n
mad.f32 computes the product of a and b to infinite precision and then adds c to\nthis product, again in infinite precision. The resulting value is then rounded to single precision\nusing the rounding mode specified by .rnd.
\n
mad.f64 computes the product of a and b to infinite precision and then adds c to\nthis product, again in infinite precision. The resulting value is then rounded to double precision\nusing the rounding mode specified by .rnd.
\n
mad.{f32,f64} is the same as fma.{f32,f64}.
\n
\n
For .targetsm_1x:
\n
\n
mad.f32 computes the product of a and b at double precision, and then the mantissa is\ntruncated to 23 bits, but the exponent is preserved. Note that this is different from computing\nthe product with mul, where the mantissa can be rounded and the exponent will be clamped. The\nexception for mad.f32 is when c=+/-0.0, mad.f32 is identical to the result computed\nusing separate mul and add instructions. When JIT-compiled for SM 2.0 devices, mad.f32 is\nimplemented as a fused multiply-add (i.e., fma.rn.ftz.f32). In this case, mad.f32 can\nproduce slightly different numeric results and backward compatibility is not guaranteed in this\ncase.
\n
mad.f64 computes the product of a and b to infinite precision and then adds c to\nthis product, again in infinite precision. The resulting value is then rounded to double precision\nusing the rounding mode specified by .rnd. Unlike mad.f32, the treatment of subnormal\ninputs and output follows IEEE 754 standard.
\n
mad.f64 is the same as fma.f64.
\n
\n
Rounding modifiers (no default):
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
mad.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
mad.f64 supports subnormal numbers.
\n
mad.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
Saturation modifier:
\n
mad.sat.f32 clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
In PTX ISA versions 1.4 and later, a rounding modifier is required for mad.f64.
\n
Legacy mad.f64 instructions having no rounding modifier will map to mad.rn.f64.
\n
In PTX ISA versions 2.0 and later, a rounding modifier is required for mad.f32 for sm_20 and higher targets.
\n
Errata
\n
mad.f32 requires a rounding modifier for sm_20 and higher targets. However for PTX ISA\nversion 3.0 and earlier, ptxas does not enforce this requirement and mad.f32 silently defaults\nto mad.rn.f32. For PTX ISA version 3.1, ptxas generates a warning and defaults to\nmad.rn.f32, and in subsequent releases ptxas will enforce the requirement for PTX ISA version\n3.2 and later.
\n
Target ISA Notes
\n
mad.f32 supported on all target architectures.
\n
mad.f64 requires sm_13 or higher.
\n
Rounding modifiers have the following target requirements:
\n
\n
.rn,.rz,.rm,.rp for mad.f64, requires sm_13 or higher.
\n
.rn,.rz,.rm,.rp for mad.f32, requires sm_20 or higher.
\n
\n
Examples
\n
\n
@p mad.f32 d,a,b,c;\n
\n
\n\n
Integer Arithmetic Instructions: mad
\n\n\n
Multiply two values, optionally extract the high or low half of the intermediate result, and add a third value.
Multiplies two values, optionally extracts the high or low half of the intermediate result, and adds\na third value. Writes the result into a destination register.
\n
Semantics
\n
\n
t = a * b;\nn = bitwidth of type;\nd = t + c; // for .wide\nd = t<2n-1..n> + c; // for .hi variant\nd = t<n-1..0> + c; // for .lo variant\n
\n
\n
Notes
\n
The type of the operation represents the types of the a and b operands. If .hi or .lo is\nspecified, then d and c are the same size as a and b, and either the upper or lower\nhalf of the result is written to the destination register. If .wide is specified, then d and\nc are twice as wide as a and b to receive the result of the multiplication.
\n
The .wide suffix is supported only for 16-bit and 32-bit integer types.
\n
Saturation modifier:
\n
\n
.sat
\n
\n
limits result to MININT..MAXINT (no overflow) for the size of the operation.
Multiplies two values, extracts either the high or low part of the result, and adds a third\nvalue. Writes the result to the destination register and the carry-out from the addition into the\ncondition code register.
\n
Semantics
\n
\n
t = a * b;\nd = t<63..32> + c; // for .hi variant\nd = t<31..0> + c; // for .lo variant\n
\n
\n
carry-out from addition is written to CC.CF
\n
Notes
\n
Generally used in combination with madc and addc to implement extended-precision multi-word\nmultiplication. See madc for an example.
\n",
- "tooltip": "=====Floating Point Instructions: mad\n\n\n\nMultiply two values and add a third value.\n\nSyntax\n\nmad{.ftz}{.sat}.f32 d, a, b, c; // .target sm_1x\n\nmad.rnd{.ftz}{.sat}.f32 d, a, b, c; // .target sm_20\n\nmad.rnd.f64 d, a, b, c; // .target sm_13 and higher\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nMultiplies two values and adds a third, and then writes the resulting value into a destination\n\nregister.\n\nSemantics\n\nd = a*b + ...\n\n=====Integer Arithmetic Instructions: mad\n\n\n\nMultiply two values, optionally extract the high or low half of the intermediate result, and add a third value.\n\nSyntax\n\nmad.mode.type d, a, b, c;\n\nmad.hi.sat.s32 d, a, b, c;\n\n.mode = { .hi, .lo, .wide };\n\n.type = { .u16, .u32, .u64,\n\n .s16, .s32, .s64 };\n\nDescription\n\nMultiplies two values, optionally extracts the high or low half of the intermediate result, and adds\n\na third value. Writes the r...\n\n=====Extended-Precision Arithmetic Instructions: mad.cc\n\n\n\nMultiply two values, extract high or low half of result, and add a third value with carry-out.\n\nSyntax\n\nmad{.hi,.lo}.cc.type d, a, b, c;\n\n.type = { .u32, .s32, .u64, .s64 };\n\nDescription\n\nMultiplies two values, extracts either the high or low part of the result, and adds a third\n\nvalue. Writes the result to the destination register and the carry-out from the addition into the\n\ncondition code register.\n\nS... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-mad"
+ "html": "
Multiplies two values, optionally extracts the high or low half of the intermediate result, and adds\na third value. Writes the result into a destination register.
\nFor more information, visit mad(int) .",
+ "tooltip": "Multiplies two values, optionally extracts the high or low half of the intermediate result, and adds\n\na third value. Writes the result into a destination register.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-mad"
};
case "mad24":
return {
- "html": "For more information, visit mad24(int) .
Integer Arithmetic Instructions: mad24
\n\n\n
Multiply two 24-bit integer values and add a third value.
\n
Syntax
\n
\n
mad24.mode.type d, a, b, c;\nmad24.hi.sat.s32 d, a, b, c;\n\n.mode = { .hi, .lo };\n.type = { .u32, .s32 };\n
\n
\n
Description
\n
Compute the product of two 24-bit integer values held in 32-bit source registers, and add a third,\n32-bit value to either the high or low 32-bits of the 48-bit result. Return either the high or low\n32-bits of the 48-bit result.
\n
Semantics
\n
\n
t = a * b;\nd = t<47..16> + c; // for .hi variant\nd = t<31..0> + c; // for .lo variant\n
\n
\n
Notes
\n
Integer multiplication yields a result that is twice the size of the input operands, i.e., 48-bits.
\n
mad24.hi performs a 24x24-bit multiply and adds the high 32 bits of the 48-bit result to a third\nvalue.
\n
mad24.lo performs a 24x24-bit multiply and adds the low 32 bits of the 48-bit result to a third\nvalue.
\n
All operands are of the same type and size.
\n
Saturation modifier:
\n
\n
.sat
\n
\n
limits result of 32-bit signed addition to MININT..MAXINT (no overflow). Applies only to\n.s32 type in .hi mode.
\n
\n
\n
mad24.hi may be less efficient on machines without hardware support for 24-bit multiply.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mad24.lo.s32 d,a,b,c; // low 32-bits of 24x24-bit signed multiply.\n
\n
\n",
- "tooltip": "Multiply two 24-bit integer values and add a third value.\n\nSyntax\n\nmad24.mode.type d, a, b, c;\n\nmad24.hi.sat.s32 d, a, b, c;\n\n.mode = { .hi, .lo };\n\n.type = { .u32, .s32 };\n\nDescription\n\nCompute the product of two 24-bit integer values held in 32-bit source registers, and add a third,\n\n32-bit value to either the high or low 32-bits of the 48-bit result. Return either the high or low\n\n32-bits of the 48-bit result.\n\nSemantics\n\nt = a * b;\n\nd = t<47..16> + c; // for .hi variant\n\nd = t<31..0> + c; // for .lo variant\n\nNotes\n\nInteger multiplication yields a result that is twice the size of the input operands, i.e., 48-bits.\n\nmad24.hi performs a 24x24-bit multiply and adds the high 32 bits of the 48-bit result to a third\n\nvalue.\n\nmad24.lo performs a 24x24-bit multiply and adds the low 32 bits of the 48-bit result to a third\n\nvalue.\n\nAll operands are of the same type and size.\n\nSaturation modifier:\n\n.sat\n\nlimits result of 32-bit signed addition to MININT..MAXINT (no overflow). Applies only to\n\n.s32 type in .hi mode.\n\nmad24.hi may be less efficient on machines without hardware support for 24-bit multiply.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmad24.lo.s32 d,a,b,c; // low 32-bits of 24x24-bit signed multiply.\n\n ...",
+ "html": "
Compute the product of two 24-bit integer values held in 32-bit source registers, and add a third,\n32-bit value to either the high or low 32-bits of the 48-bit result. Return either the high or low\n32-bits of the 48-bit result.
\nFor more information, visit mad24(int) .",
+ "tooltip": "Multiply two 24-bit integer values and add a third value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-mad24"
};
case "madc":
return {
- "html": "For more information, visit madc .
Extended-Precision Arithmetic Instructions: madc
\n\n\n
Multiply two values, extract high or low half of result, and add a third value with carry-in and\noptional carry-out.
Multiplies two values, extracts either the high or low part of the result, and adds a third value\nalong with carry-in. Writes the result to the destination register and optionally writes the\ncarry-out from the addition into the condition code register.
\n
Semantics
\n
\n
t = a * b;\nd = t<63..32> + c + CC.CF; // for .hi variant\nd = t<31..0> + c + CC.CF; // for .lo variant\n
\n
\n
if .cc specified, carry-out from addition is written to CC.CF
\n
Notes
\n
Generally used in combination with mad.cc and addc to implement extended-precision\nmulti-word multiplication. See example below.
\n
PTX ISA Notes
\n
32-bit madc introduced in PTX ISA version 3.0.
\n
64-bit madc introduced in PTX ISA version 4.3.
\n
Target ISA Notes
\n
Requires target sm_20 or higher.
\n
Examples
\n
\n
// extended-precision multiply: [r3,r2,r1,r0] = [r5,r4] * [r7,r6]\nmul.lo.u32 r0,r4,r6; // r0=(r4*r6).[31:0], no carry-out\nmul.hi.u32 r1,r4,r6; // r1=(r4*r6).[63:32], no carry-out\nmad.lo.cc.u32 r1,r5,r6,r1; // r1+=(r5*r6).[31:0], may carry-out\nmadc.hi.u32 r2,r5,r6,0; // r2 =(r5*r6).[63:32]+carry-in,\n // no carry-out\nmad.lo.cc.u32 r1,r4,r7,r1; // r1+=(r4*r7).[31:0], may carry-out\nmadc.hi.cc.u32 r2,r4,r7,r2; // r2+=(r4*r7).[63:32]+carry-in,\n // may carry-out\naddc.u32 r3,0,0; // r3 = carry-in, no carry-out\nmad.lo.cc.u32 r2,r5,r7,r2; // r2+=(r5*r7).[31:0], may carry-out\nmadc.hi.u32 r3,r5,r7,r3; // r3+=(r5*r7).[63:32]+carry-in\n
\n
\n",
- "tooltip": "Multiply two values, extract high or low half of result, and add a third value with carry-in and\n\noptional carry-out.\n\nSyntax\n\nmadc{.hi,.lo}{.cc}.type d, a, b, c;\n\n.type = { .u32, .s32, .u64, .s64 };\n\nDescription\n\nMultiplies two values, extracts either the high or low part of the result, and adds a third value\n\nalong with carry-in. Writes the result to the destination register and optionally writes the\n\ncarry-out from the addition into the condition code register.\n\nSemantics\n\nt = a * b;\n\nd = t<63..32> + c + CC.CF; // for .hi variant\n\nd = t<31..0> + c + CC.CF; // for .lo variant\n\nif .cc specified, carry-out from addition is written to CC.CF\n\nNotes\n\nGenerally used in combination with mad.cc and addc to implement extended-precision\n\nmulti-word multiplication. See example below.\n\nPTX ISA Notes\n\n32-bit madc introduced in PTX ISA version 3.0.\n\n64-bit madc introduced in PTX ISA version 4.3.\n\nTarget ISA Notes\n\nRequires target sm_20 or higher.\n\nExamples\n\n// extended-precision multiply: [r3,r2,r1,r0] = [r5,r4] * [r7,r6]\n\nmul.lo.u32 r0,r4,r6; // r0=(r4*r6).[31:0], no carry-out\n\nmul.hi.u32 r1,r4,r6; // r1=(r4*r6).[63:32], no carry-out\n\nmad.lo.cc.u32 r1,r5,r6,r1; // r1+=(r5*r6).[31:0], may carry-out\n\nmadc.hi.u32 r2,r5,r6,0; // r2 =(r5*r6).[63:32]+carry-in,\n\n // no carry-out\n\nmad.lo.cc.u32 r1,r4,r7,r1; // r1+=(r4*r7).[31:0], may carry-out\n\nmadc.hi.cc.u32 r2,r4,r7,r2; // r2+=(r4*r7).[63:32]+carry-in,\n\n // may carry-out\n\naddc.u32 r3,0,0; // r3 = carry-in, no carry-out\n\nmad.lo.cc.u32 r2,r5,r7,r2; // r2+=(r5*r7).[31:0], may carry-out\n\nmadc.hi.u32 r3,r5,r7,r3; // r3+=(r5*r7).[63:32]+carry-in\n\n ...",
+ "html": "
Multiplies two values, extracts either the high or low part of the result, and adds a third value\nalong with carry-in. Writes the result to the destination register and optionally writes the\ncarry-out from the addition into the condition code register.
\nFor more information, visit madc .",
+ "tooltip": "Multiplies two values, extracts either the high or low part of the result, and adds a third value\n\nalong with carry-in. Writes the result to the destination register and optionally writes the\n\ncarry-out...",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#extended-precision-arithmetic-instructions-madc"
};
case "mapa":
return {
- "html": "For more information, visit mapa .
Data Movement and Conversion Instructions: mapa
\n\n\n
Map the address of the shared variable in the target CTA.
\n
Syntax
\n
\n
mapa{.space}.type d, a, b;\n\n// Maps shared memory address in register a into CTA b.\nmapa.shared::cluster.type d, a, b;\n\n// Maps shared memory variable into CTA b.\nmapa.shared::cluster.type d, sh, b;\n\n// Maps shared memory variable into CTA b.\nmapa.shared::cluster.type d, sh + imm, b;\n\n// Maps generic address in register a into CTA b.\nmapa.type d, a, b;\n\n.space = { .shared::cluster }\n.type = { .u32, .u64 }\n
\n
\n
Description
\n
Get address in the CTA specified by operand b which corresponds to the address specified by\noperand a.
\n
Instruction type .type indicates the type of the destination operand d and the source\noperand a.
\n
When space is .shared::cluster, source a is either a shared memory variable or a register\ncontaining a valid shared memory address and register d contains a shared memory address. When\nthe optional qualifier .space is not specified, both a and d are registers containing\ngeneric addresses pointing to shared memory.
\n
b is a 32-bit integer operand representing the rank of the target CTA.
\n
Destination register d will hold an address in CTA b corresponding to operand a.
\n",
- "tooltip": "Map the address of the shared variable in the target CTA.\n\nSyntax\n\nmapa{.space}.type d, a, b;\n\n// Maps shared memory address in register a into CTA b.\n\nmapa.shared::cluster.type d, a, b;\n\n// Maps shared memory variable into CTA b.\n\nmapa.shared::cluster.type d, sh, b;\n\n// Maps shared memory variable into CTA b.\n\nmapa.shared::cluster.type d, sh + imm, b;\n\n// Maps generic address in register a into CTA b.\n\nmapa.type d, a, b;\n\n.space = { .shared::cluster }\n\n.type = { .u32, .u64 }\n\nDescription\n\nGet address in the CTA specified by operand b which corresponds to the address specified by\n\noperand a.\n\nInstruction type .type indicates the type of the destination operand d and the source\n\noperand a.\n\nWhen space is .shared::cluster, source a is either a shared memory variable or a register\n\ncontaining a valid shared memory address and register d contains a shared memory address. When\n\nthe optional qualifier .space is not specified, both a and d are registers containing\n\ngeneric addresses pointing to shared memory.\n\nb is a 32-bit integer operand representing the rank of the target CTA.\n\nDestination register d will hold an address in CTA b corresponding to operand a.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\nmapa.shared::cluster.u64 d1, %reg1, cta;\n\nmapa.shared::cluster.u32 d2, sh, 3;\n\nmapa.u64 d3, %reg2, cta;\n\n ...",
+ "html": "
Get address in the CTA specified by operand b which corresponds to the address specified by\noperand a.
\nFor more information, visit mapa .",
+ "tooltip": "Map the address of the shared variable in the target CTA.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-mapa"
};
case "match":
return {
- "html": "For more information, visit match.sync .
Parallel Synchronization and Communication Instructions: match.sync
\n\n\n
Broadcast and compare a value across threads in warp.
\n
Syntax
\n
\n
match.any.sync.type d, a, membermask;\nmatch.all.sync.type d[|p], a, membermask;\n\n.type = { .b32, .b64 };\n
\n
\n
Description
\n
match.sync will cause executing thread to wait until all non-exited threads from membermask\nhave executed match.sync with the same qualifiers and same membermask value before resuming\nexecution.
\n
Operand membermask specifies a 32-bit integer which is a mask indicating threads participating\nin this instruction where the bit position corresponds to thread\u2019s laneid.
\n
match.sync performs broadcast and compare of operand a across all non-exited threads in\nmembermask and sets destination d and optional predicate p based on mode.
\n
Operand a has instruction type and d has .b32 type.
\n
Destination d is a 32-bit mask where bit position in mask corresponds to thread\u2019s laneid.
\n
The matching operation modes are:
\n
\n
.all
\n
\n
d is set to mask corresponding to non-exited threads in membermask if all non-exited\nthreads in membermask have same value of operand a; otherwise d is set\nto 0. Optionally predicate p is set to true if all non-exited threads in membermask have\nsame value of operand a; otherwise p is set to false. The sink symbol \u2018_\u2019 may be used in\nplace of any one of the destination operands.
\n
\n
.any
\n
\n
d is set to mask of non-exited threads in membermask that have same value of operand\na.
\n
\n
\n
The behavior of match.sync is undefined if the executing thread is not in the membermask.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.0.
\n
Target ISA Notes
\n
Requires sm_70 or higher.
\n
Release Notes
\n
Note that match.sync applies to threads in a single warp, not across an entire CTA.
\n
Examples
\n
\n
match.any.sync.b32 d, a, 0xffffffff;\nmatch.all.sync.b64 d|p, a, mask;\n
\n
\n",
- "tooltip": "Broadcast and compare a value across threads in warp.\n\nSyntax\n\nmatch.any.sync.type d, a, membermask;\n\nmatch.all.sync.type d[|p], a, membermask;\n\n.type = { .b32, .b64 };\n\nDescription\n\nmatch.sync will cause executing thread to wait until all non-exited threads from membermask\n\nhave executed match.sync with the same qualifiers and same membermask value before resuming\n\nexecution.\n\nOperand membermask specifies a 32-bit integer which is a mask indicating threads participating\n\nin this instruction where the bit position corresponds to thread\u2019s laneid.\n\nmatch.sync performs broadcast and compare of operand a across all non-exited threads in\n\nmembermask and sets destination d and optional predicate p based on mode.\n\nOperand a has instruction type and d has .b32 type.\n\nDestination d is a 32-bit mask where bit position in mask corresponds to thread\u2019s laneid.\n\nThe matching operation modes are:\n\n.all\n\nd is set to mask corresponding to non-exited threads in membermask if all non-exited\n\nthreads in membermask have same value of operand a; otherwise d is set\n\nto 0. Optionally predicate p is set to true if all non-exited threads in membermask have\n\nsame value of operand a; otherwise p is set to false. The sink symbol \u2018_\u2019 may be used in\n\nplace of any one of the destination operands.\n\n.any\n\nd is set to mask of non-exited threads in membermask that have same value of operand\n\na.\n\nThe behavior of match.sync is undefined if the executing thread is not in the membermask.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 6.0.\n\nTarget ISA Notes\n\nRequires sm_70 or higher.\n\nRelease Notes\n\nNote that match.sync applies to threads in a single warp, not across an entire CTA.\n\nExamples\n\nmatch.any.sync.b32 d, a, 0xffffffff;\n\nmatch.all.sync.b64 d|p, a, mask;\n\n ...",
+ "html": "
match.sync will cause executing thread to wait until all non-exited threads from membermask\nhave executed match.sync with the same qualifiers and same membermask value before resuming\nexecution.
\nFor more information, visit match.sync .",
+ "tooltip": "Broadcast and compare a value across threads in warp.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-match-sync"
};
case "max":
return {
- "html": "For more information, visit max(fp) , max(fp16) , max(int) .
Floating Point Instructions: max
\n\n\n
Find the maximum of two values.
\n
Syntax
\n
\n
max{.ftz}{.NaN}{.xorsign.abs}.f32 d, a, b;\nmax.f64 d, a, b;\n
\n
\n
Description
\n
Store the maximum of a and b in d.
\n
If .NaN modifier is specified, the result is canonical NaN if either of the inputs is\nNaN.
\n
If .abs modifier is specified, the magnitude of destination operand d is the maximum of\nabsolute values of both the input arguments.
\n
If .xorsign modifier is specified, the sign bit of destination d is equal to the XOR of the\nsign bits of both the inputs.
\n
Modifiers .abs and .xorsign must be specified together and .xorsign considers the sign\nbit of both inputs before applying .abs operation.
\n
If the result of max is NaN then the .xorsign and .abs modifiers will be ignored.
\n
Semantics
\n
\n
if (.xorsign) {\n xorsign = getSignBit(a) ^ getSignBit(b);\n if (.abs) {\n a = |a|;\n b = |b|;\n }\n}\nif (isNaN(a) && isNaN(b)) d = NaN;\nelse if (.NaN && (isNaN(a) || isNaN(b))) d = NaN;\nelse if (isNaN(a)) d = b;\nelse if (isNaN(b)) d = a;\nelse d = (a > b) ? a : b;\nif (.xorsign && !isNaN(d)) {\n setSignBit(d, xorsign);\n}\n
\n
\n
Notes
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
max.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
max.f64 supports subnormal numbers.
\n
max.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
If values of both inputs are 0.0, then +0.0 > -0.0.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
max.NaNintroduced in PTX ISA version 7.0.
\n
max.xorsign.abs introduced in PTX ISA version 7.2.
\n
Target ISA Notes
\n
max.f32 supported on all target architectures.
\n
max.f64 requires sm_13 or higher.
\n
max.NaNrequires sm_80 or higher.
\n
max.xorsign.abs requires sm_86 or higher.
\n
Examples
\n
\n
max.ftz.f32 f0,f1,f2;\nmax.f64 a,b,c;\n// fp32 max with .NaN\nmax.NaN.f32 f0,f1,f2;\n// fp32 max with .xorsign.abs\nmax.xorsign.abs.f32 Rd, Ra, Rb;\n
\n
\n\n
Half Precision Floating Point Instructions: max
\n\n\n
Find the maximum of two values.
\n
Syntax
\n
\n
max{.ftz}{.NaN}{.xorsign.abs}.f16 d, a, b;\nmax{.ftz}{.NaN}{.xorsign.abs}.f16x2 d, a, b;\nmax{.NaN}{.xorsign.abs}.bf16 d, a, b;\nmax{.NaN}{.xorsign.abs}.bf16x2 d, a, b;\n
\n
\n
Description
\n
Store the maximum of a and b in d.
\n
For .f16x2 and .bf16x2 instruction types, input vectors are formed with half-word values\nfrom source operands. Half-word operands are then processed in parallel to store .f16x2 or\n.bf16x2 result in destination.
\n
For .f16 instruction type, operands d and a have .f16 or .b16 type. For\n.f16x2 instruction type, operands d and a have .f16x2 or .b32 type. For\n.bf16 instruction type, operands d and a have .b16 type. For .bf16x2 instruction\ntype, operands d and a have .b32 type.
\n
If .NaN modifier is specified, the result is canonical NaN if either of the inputs is\nNaN.
\n
If .abs modifier is specified, the magnitude of destination operand d is the maximum of\nabsolute values of both the input arguments.
\n
If .xorsign modifier is specified, the sign bit of destination d is equal to the XOR of the\nsign bits of both the inputs.
\n
Modifiers .abs and .xorsign must be specified together and .xorsign considers the sign\nbit of both inputs before applying .abs operation.
\n
If the result of max is NaN then the .xorsign and .abs modifiers will be ignored.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n if (.xorsign) {\n xorsign = getSignBit(a) ^ getSignBit(b);\n if (.abs) {\n a = |a|;\n b = |b|;\n }\n }\n if (isNaN(a) && isNaN(b)) d = NaN;\n if (.NaN && (isNaN(a) || isNaN(b))) d = NaN;\n else if (isNaN(a)) d = b;\n else if (isNaN(b)) d = a;\n else d = (a > b) ? a : b;\n if (.xorsign && !isNaN(d)) {\n setSignBit(d, xorsign);\n }\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n if (.xorsign) {\n xorsign = getSignBit(fA[i]) ^ getSignBit(fB[i]);\n if (.abs) {\n fA[i] = |fA[i]|;\n fB[i] = |fB[i]|;\n }\n }\n if (isNaN(fA[i]) && isNaN(fB[i])) d[i] = NaN;\n if (.NaN && (isNaN(fA[i]) || isNaN(fB[i]))) d[i] = NaN;\n else if (isNaN(fA[i])) d[i] = fB[i];\n else if (isNaN(fB[i])) d[i] = fA[i];\n else d[i] = (fA[i] > fB[i]) ? fA[i] : fB[i];\n if (.xorsign && !isNaN(fA[i])) {\n setSignBit(d[i], xorsign);\n }\n }\n}\n
\n
\n
Notes
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nmax.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
If values of both inputs are 0.0, then +0.0 > -0.0.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
max.xorsign.abs introduced in PTX ISA version 7.2.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
max.xorsign.abs support requires sm_86 or higher.
\n
Examples
\n
\n
max.ftz.f16 h0,h1,h2;\nmax.f16x2 b0,b1,b2;\n// SIMD fp16 max with NaN\nmax.NaN.f16x2 b0,b1,b2;\n// scalar f16 max with xorsign.abs\nmax.xorsign.abs.f16 Rd, Ra, Rb;\nmax.bf16 h0, h1, h2;\n// scalar bf16 max and NaN\nmax.NaN.bf16x2 b0, b1, b2;\n// SIMD bf16 max with xorsign.abs\nmax.xorsign.abs.bf16x2 Rd, Ra, Rb;\n
For .u16x2, .s16x2 instruction types, forms input vectors by half word values from source\noperands. Half-word operands are then processed in parallel to produce .u16x2, .s16x2 result\nin destination.
\n
Operands d, a and b have the same type as the instruction type. For instruction types\n.u16x2, .s16x2, operands d, a and b have type .b32.
\n
Semantics
\n
\n
if (type == u16x2 || type == s16x2) {\n iA[0] = a[0:15];\n iA[1] = a[16:31];\n iB[0] = b[0:15];\n iB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = (iA[i] > iB[i]) ? iA[i] : iB[i];\n }\n} else {\n d = (a > b) ? a : b; // Integer (signed and unsigned)\n}\n
\n
\n
Notes
\n
Signed and unsigned differ.
\n
\n
Saturation modifier:
\n
\n
max.relu.{s16x2,s32} clamps the result to 0 if negative.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
max.u16x2, max{.relu}.s16x2 and max.relu.s32 introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
max.u16x2, max{.relu}.s16x2 and max.relu.s32 require sm_90 or higher.
\n",
- "tooltip": "=====Floating Point Instructions: max\n\n\n\nFind the maximum of two values.\n\nSyntax\n\nmax{.ftz}{.NaN}{.xorsign.abs}.f32 d, a, b;\n\nmax.f64 d, a, b;\n\nDescription\n\nStore the maximum of a and b in d.\n\nIf .NaN modifier is specified, the result is canonical NaN if either of the inputs is\n\nNaN.\n\nIf .abs modifier is specified, the magnitude of destination operand d is the maximum of\n\nabsolute values of both the input arguments.\n\nIf...\n\n=====Half Precision Floating Point Instructions: max\n\n\n\nFind the maximum of two values.\n\nSyntax\n\nmax{.ftz}{.NaN}{.xorsign.abs}.f16 d, a, b;\n\nmax{.ftz}{.NaN}{.xorsign.abs}.f16x2 d, a, b;\n\nmax{.NaN}{.xorsign.abs}.bf16 d, a, b;\n\nmax{.NaN}{.xorsign.abs}.bf16x2 d, a, b;\n\nDescription\n\nStore the maximum of a and b in d.\n\nFor .f16x2 and .bf16x2 instruction types, input vectors are formed with half-word values\n\nfrom source operands. Half-word o...\n\n=====Integer Arithmetic Instructions: max\n\n\n\nFind the maximum of two values.\n\nSyntax\n\nmax.atype d, a, b;\n\nmax{.relu}.btype d, a, b;\n\n.atype = { .u16, .u32, .u64,\n\n .u16x2, .s16, .s64 };\n\n.btype = { .s16x2, .s32 };\n\nDescription\n\nStore the maximum of a and b in d.\n\nFor .u16x2, .s16x2 instruction types, forms input vectors by half word values from source\n\noperands. Half-word operands are then processed in parallel to produce .u16x2, .s... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-max"
- };
-
- case "maxclusterrank":
- return {
- "html": "For more information, visit maxclusterrank .
Cluster Dimension Directives: .maxclusterrank
\n\n\n
Declare the maximum number of CTAs that can be part of the cluster.
\n
Syntax
\n
\n
.maxclusterrank n\n
\n
\n
Description
\n
Declare the maximum number of thread blocks (CTAs) allowed to be part of the cluster.
\n
Semantics
\n
Product of the number of CTAs in each cluster dimension specified in any invocation of the kernel is\nrequired to be less or equal to that specified in this directive. Otherwise invocation will result\nin a runtime error or kernel launch failure.
\n
The .maxclusterrank directive cannot be used in conjunction with the .reqnctapercluster directive.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
.entry foo ..maxclusterrank 8 { . . . }\n
\n
\n",
- "tooltip": "Declare the maximum number of CTAs that can be part of the cluster.\n\nSyntax\n\n.maxclusterrank n\n\nDescription\n\nDeclare the maximum number of thread blocks (CTAs) allowed to be part of the cluster.\n\nSemantics\n\nProduct of the number of CTAs in each cluster dimension specified in any invocation of the kernel is\n\nrequired to be less or equal to that specified in this directive. Otherwise invocation will result\n\nin a runtime error or kernel launch failure.\n\nThe .maxclusterrank directive cannot be used in conjunction with the .reqnctapercluster directive.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.entry foo ..maxclusterrank 8 { . . . }\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#cluster-dimension-directives-maxclusterrank"
- };
-
- case "maxnreg":
- return {
- "html": "For more information, visit maxnreg .
Performance-Tuning Directives: .maxnreg
\n\n\n
Maximum number of registers that can be allocated per thread.
\n
Syntax
\n
\n
.maxnreg n\n
\n
\n
Description
\n
Declare the maximum number of registers per thread in a CTA.
\n
Semantics
\n
The compiler guarantees that this limit will not be exceeded. The actual number of registers used\nmay be less; for example, the backend may be able to compile to fewer registers, or the maximum\nnumber of registers may be further constrained by .maxntid and .maxctapersm.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.entry foo .maxnreg 16 { ... } // max regs per thread = 16\n
\n
\n",
- "tooltip": "Maximum number of registers that can be allocated per thread.\n\nSyntax\n\n.maxnreg n\n\nDescription\n\nDeclare the maximum number of registers per thread in a CTA.\n\nSemantics\n\nThe compiler guarantees that this limit will not be exceeded. The actual number of registers used\n\nmay be less; for example, the backend may be able to compile to fewer registers, or the maximum\n\nnumber of registers may be further constrained by .maxntid and .maxctapersm.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.3.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.entry foo .maxnreg 16 { ... } // max regs per thread = 16\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#performance-tuning-directives-maxnreg"
- };
-
- case "maxntid":
- return {
- "html": "For more information, visit maxntid .
Performance-Tuning Directives: .maxntid
\n\n\n
Maximum number of threads in the thread block (CTA).
Declare the maximum number of threads in the thread block (CTA). This maximum is specified by giving\nthe maximum extent of each dimension of the 1D, 2D, or 3D CTA.\u00a0 The maximum number of threads is the\nproduct of the maximum extent in each dimension.
\n
Semantics
\n
The maximum number of threads in the thread block, computed as the product of the maximum extent\nspecified for each dimension, is guaranteed not to be exceeded in any invocation of the kernel in\nwhich this directive appears. Exceeding the maximum number of threads results in a runtime error or\nkernel launch failure.
\n
Note that this directive guarantees that the total number of threads does not exceed the maximum,\nbut does not guarantee that the limit in any particular dimension is not exceeded.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.entry foo .maxntid 256 { ... } // max threads = 256\n.entry bar .maxntid 16,16,4 { ... } // max threads = 1024\n
\n
\n",
- "tooltip": "Maximum number of threads in the thread block (CTA).\n\nSyntax\n\n.maxntid nx\n\n.maxntid nx, ny\n\n.maxntid nx, ny, nz\n\nDescription\n\nDeclare the maximum number of threads in the thread block (CTA). This maximum is specified by giving\n\nthe maximum extent of each dimension of the 1D, 2D, or 3D CTA.\u00a0 The maximum number of threads is the\n\nproduct of the maximum extent in each dimension.\n\nSemantics\n\nThe maximum number of threads in the thread block, computed as the product of the maximum extent\n\nspecified for each dimension, is guaranteed not to be exceeded in any invocation of the kernel in\n\nwhich this directive appears. Exceeding the maximum number of threads results in a runtime error or\n\nkernel launch failure.\n\nNote that this directive guarantees that the total number of threads does not exceed the maximum,\n\nbut does not guarantee that the limit in any particular dimension is not exceeded.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.3.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.entry foo .maxntid 256 { ... } // max threads = 256\n\n.entry bar .maxntid 16,16,4 { ... } // max threads = 1024\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#performance-tuning-directives-maxntid"
+ "html": "
Parallel Synchronization and Communication Instructions: mbarrier
\n\n\n
\n
Synchronizing any subset of threads within a CTA
\n
One-way synchronization of threads across CTAs of a cluster. As noted in mbarrier support with\nshared memory, threads can\nperform only arrive operations but not *_wait on an mbarrier located in shared::cluster\nspace.
\n
Waiting for completion of asynchronous memory operations initiated by a thread and making them\nvisible to other threads.
\n
\n
An mbarrier object is an opaque object in memory which can be initialized and invalidated using :
\n
\n
mbarrier.init
\n
mbarrier.inval
\n
\n
Operations supported on mbarrier objects are :
\n
\n
mbarrier.expect_tx
\n
mbarrier.complete_tx
\n
mbarrier.arrive
\n
mbarrier.arrive_drop
\n
mbarrier.test_wait
\n
mbarrier.try_wait
\n
mbarrier.pending_count
\n
cp.async.mbarrier.arrive
\n
\n
Performing any mbarrier operation except mbarrier.init on an uninitialized mbarrier object\nresults in undefined behavior.
\n
Unlike bar{.cta}/barrier{.cta} instructions which can access a limited number of barriers\nper CTA, mbarrier objects are used defined and are only limited by the total shared memory size\navailable.
\n
mbarrier operations enable threads to perform useful work after the arrival at the mbarrier and\nbefore waiting for the mbarrier to complete.
An opaque mbarrier object keeps track of the following information :
\n
\n
Current phase of the mbarrier object
\n
Count of pending arrivals for the current phase of the mbarrier object
\n
Count of expected arrivals for the next phase of the mbarrier object
\n
Count of pending asynchronous memory operations (or transactions) tracked by the current phase of\nthe mbarrier object. This is also referred to as tx-count.
\n
\n
An mbarrier object progresses through a sequence of phases where each phase is defined by threads\nperforming an expected number of arrive-on\noperations.
\n
The valid range of each of the counts is as shown below:
The phase of an mbarrier object is the number of times the mbarrier object has been used to\nsynchronize threads and cp.async\noperations. In each phase {0, 1, 2, \u2026}, threads perform in program order :
\n
\n
arrive-on\noperations to complete the current phase and
\n
test_wait / try_wait operations to check for the completion of the current phase.
\n
\n
An mbarrier object is automatically reinitialized upon completion of the current phase for\nimmediate use in the next phase. The current phase is incomplete and all prior phases are complete.
\n
For each phase of the mbarrier object, at least one test_wait or try_wait operation must be\nperformed which returns True for waitComplete before an arrive-on operation\nin the subsequent phase.
Starting with the Hopper architecture (sm_9x), mbarrier object supports a new count, called\ntx-count, which is used for tracking the completion of asynchronous memory operations or\ntransactions. tx-count tracks the number of asynchronous transactions, in units specified by the\nasynchronous memory operation, that are outstanding and yet to be complete.
\n
The tx-count of an mbarrier object must be set to the total amount of asynchronous memory\noperations, in units as specified by the asynchronous operations, to be tracked by the current\nphase. Upon completion of each of the asynchronous operations, the complete-tx\noperation will be performed on the mbarrier object and thus progress the mbarrier towards the\ncompletion of the current phase.
The expect-tx operation, with an expectCount argument, increases the tx-count of an\nmbarrier object by the value specified by expectCount. This makes the current phase of the\nmbarrier object to expect and track the completion of additional asynchronous transactions.
The complete-tx operation, with an completeCount argument, on an mbarrier object consists of the following:
\n
\n
mbarrier signaling
\n
\n
Signals the completion of asynchronous transactions that were tracked by the current phase. As a\nresult of this, tx-count is decremented by completeCount.
\n
\n
mbarrier potentially completing the current phase
\n
\n
If the current phase has been completed then the mbarrier transitions to the next phase. Refer to\nPhase Completion of the mbarrier object\nfor details on phase completion requirements and phase transition process.
The requirements for completion of the current phase are described below. Upon completion of the\ncurrent phase, the phase transitions to the subsequent phase as described below.
\n
\n
Current phase completion requirements
\n
\n
An mbarrier object completes the current phase when all of the following conditions are met:
\n
\n
The count of the pending arrivals has reached zero.
\n
The tx-count has reached zero.
\n
\n
\n
Phase transition
\n
\n
When an mbarrier object completes the current phase, the following actions are performed\natomically:
\n
\n
The mbarrier object transitions to the next phase.
\n
The pending arrival count is reinitialized to the expected arrival count.
An arrive-on operation, with an optional count argument, on an mbarrier object consists of the\nfollowing 2 steps :
\n
\n
\n
mbarrier signalling:
\n
Signals the arrival of the executing thread OR completion of the cp.async instruction which\nsignals the arrive-on operation initiated by the executing thread on the mbarrier object. As a\nresult of this, the pending arrival count is decremented by count. If the count argument is\nnot specified, then it defaults to 1.
\n
\n
\n
mbarrier potentially completing the current phase:
\n
If the current phase has been completed then the mbarrier transitions to the next phase. Refer to\nPhase Completion of the mbarrier object\nfor details on phase completion requirements and phase transition process.
mbarrier.init initializes the mbarrier object at the location specified by the address operand\naddr with the unsigned 32-bit integer count. The value of operand count must be in the range\nas specified in Contents of the mbarrier object.
\n
Initialization of the mbarrier object involves :
\n
\n
Initializing the current phase to 0.
\n
Initializing the expected arrival count to count.
\n
Initializing the pending arrival count to count.
\n
Initializing the tx-count to 0.
\n
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
mbarrier.inval invalidates the mbarrier object at the location specified by the address\noperand addr.
\n
An mbarrier object must be invalidated before using its memory location for any other purpose.
\n
Performing any mbarrier operation except mbarrier.init on an invalidated mbarrier object\nresults in undefined behaviour.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
.shared .b64 shmem;\n.reg .b64 addr;\n.reg .b32 %r1;\n.reg .pred t0;\n\n// Example 1 :\nbar.sync 0;\n@t0 mbarrier.init.b64 [addr], %r1;\n// ... other mbarrier operations on addr\nbar.sync 0;\n@t0 mbarrier.inval.b64 [addr];\n\n\n// Example 2 :\nbar.cta.sync 0;\nmbarrier.init.shared.b64 [shmem], 12;\n// ... other mbarrier operations on shmem\nbar.cta.sync 0;\n@t0 mbarrier.inval.shared.b64 [shmem];\n\n// shmem can be reused here for unrelated use :\nbar.cta.sync 0;\nst.shared.b64 [shmem], ...;\n\n// shmem can be re-initialized as mbarrier object :\nbar.cta.sync 0;\n@t0 mbarrier.init.shared.b64 [shmem], 24;\n// ... other mbarrier operations on shmem\nbar.cta.sync 0;\n@t0 mbarrier.inval.shared::cta.b64 [shmem];\n
A thread executing mbarrier.expect_tx performs an expect-tx\noperation on the mbarrier object at the location specified by the address operand addr. The\n32-bit unsigned integer operand txCount specifies the expectCount argument to the\nexpect-tx operation.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta or .shared::cluster state space then the behavior is undefined.
A thread executing mbarrier.complete_tx performs a complete-tx\noperation on the mbarrier object at the location specified by the address operand addr. The\n32-bit unsigned integer operand txCount specifies the completeCount argument to the\ncomplete-tx operation.
\n
mbarrier.complete_tx does not involve any asynchronous memory operations and only simulates the\ncompletion of an asynchronous memory operation and its side effect of signaling to the mbarrier\nobject.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta or .shared::cluster state space then the behavior is undefined.
A thread executing mbarrier.arrive performs an arrive-on operation\non the mbarrier object at the location specified by the address operand addr. The 32-bit\nunsigned integer operand count specifies the count argument to the arrive-on\noperation.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
The optional qualifier .expect_tx specifies that an expect-tx\noperation is performed prior to the arrive-on\noperation. The 32-bit unsigned integer operand txCount specifies the expectCount argument to\nthe expect-tx operation. When both qualifiers .arrive and .expect_tx are specified, then\nthe count argument of the arrive-on operation is assumed to be 1.
\n
A mbarrier.arrive operation with .noComplete qualifier must not cause the mbarrier to\ncomplete its current phase, otherwise the behavior is undefined.
Note: for sm_8x, when the argument count is specified, the modifier .noComplete is\nrequired.
\n
mbarrier.arrive operation on an mbarrier object located in .shared::cta returns an opaque\n64-bit register capturing the phase of the mbarrier object prior to the arrive-on operation in the\ndestination operand state. Contents of the state operand are implementation\nspecific. Optionally, sink symbol '_' can be used for the state argument.
\n
mbarrier.arrive operation on an mbarrier object located in .shared::cluster but not in\n.shared::cta cannot return a value. Sink symbol \u2018_\u2019 is mandatory for the destination operand for\nsuch cases.
\n
The optional .sem qualifier specifies a memory synchronizing effect as described in the Memory\nConsistency Model. If the .sem qualifier is absent,\n.release is assumed by default.
\n
The optional .scope qualifier indicates the set of threads that directly observe the memory\nsynchronizing effect of this operation, as described in the Memory Consistency Model. If the .scope qualifier is not specified then it\ndefaults to .cta. In contrast, the .shared::<scope> indicates the state space where the\nmbarrier resides.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Support for sink symbol \u2018_\u2019 as the destination operand is introduced in PTX ISA version 7.1.
\n
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Support for count argument without the modifier .noComplete introduced in PTX ISA version\n7.8.
\n
Support for sub-qualifier ::cluster introduced in PTX ISA version 8.0.
\n
Support for qualifier .expect_tx is introduced in PTX ISA version 8.0.
\n
Support for .scope and .sem qualifiers introduced in PTX ISA version 8.0
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Support for count argument without the modifier .noComplete requires sm_90 or higher.
\n
Qualifier .expect_tx requires sm_90 or higher.
\n
Sub-qualifier ::cluster requires sm_90 or higher.
\n
Support for .cluster scope requires sm_90 or higher.
A thread executing mbarrier.arrive_drop on the mbarrier object at the location specified by\nthe address operand addr performs the following steps:
\n
\n
Decrements the expected arrival count of the mbarrier object by the value specified by the\n32-bit integer operand count. If count operand is not specified, it defaults to 1.
The decrement done in the expected arrivals count of the mbarrier object will be for all the\nsubsequent phases of the mbarrier object.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta or .shared::cluster state space then the behavior is undefined.
The optional qualifier .expect_tx specifies that an expect-tx\noperation is performed prior to the arrive-on\noperation. The 32-bit unsigned integer operand txCount specifies the expectCount argument to\nthe expect-tx operation. When both qualifiers .arrive and .expect_tx are specified, then\nthe count argument of the arrive-on operation is assumed to be 1.
\n
mbarrier.arrive_drop operation forms the release pattern as described in the Memory\nConsistency Model and synchronizes with the acquire patterns.
\n
The optional .scope qualifier indicates the set of threads that an mbarrier.arrive_drop\ninstruction can directly synchronize. If the .scope qualifier is not specified then it defaults\nto .cta. In contrast, the .shared::<scope> indicates the state space where the mbarrier\nresides.
\n
A mbarrier.arrive_drop with .noComplete qualifier must not complete the mbarrier,\notherwise the behavior is undefined.
Note: for sm_8x, when the argument count is specified, the modifier .noComplete is\nrequired.
\n
A thread that wants to either exit or opt out of participating in the arrive-on operation can use\nmbarrier.arrive_drop to drop itself from the mbarrier.
\n
mbarrier.arrive_drop operation on an mbarrier object located in .shared::cta returns an\nopaque 64-bit register capturing the phase of the mbarrier object prior to the arrive-on\noperation\nin the destination operand state. Contents of the returned state are implementation\nspecific. Optionally, sink symbol '_' can be used for the state argument.
\n
mbarrier.arrive_drop operation on an mbarrier object located in .shared::cluster but not\nin .shared::cta cannot return a value. Sink symbol \u2018_\u2019 is mandatory for the destination operand\nfor such cases.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Support for count argument without the modifier .noComplete introduced in PTX ISA version\n7.8.
\n
Support for qualifier .expect_tx is introduced in PTX ISA version 8.0.
\n
Support for sub-qualifier ::cluster introduced in PTX ISA version 8.0.
\n
Support for .scope and .sem qualifiers introduced in PTX ISA version 8.0
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Support for count argument without the modifier .noComplete requires sm_90 or higher.
\n
Qualifier .expect_tx requires sm_90 or higher.
\n
Sub-qualifier ::cluster requires sm_90 or higher.
\n
Support for .cluster scope requires sm_90 or higher.
\n
Examples
\n
\n
.reg .b32 cnt;\n.reg .b64 %r1;\n.shared .b64 shMem;\n\n// Example 1\n@p mbarrier.arrive_drop.shared.b64 _, [shMem];\n@p exit;\n@p2 mbarrier.arrive_drop.noComplete.shared.b64 _, [shMem], %a;\n@p2 exit;\n..\n@!p mbarrier.arrive.shared.b64 %r1, [shMem];\n@!p mbarrier.test_wait.shared.b64 q, [shMem], %r1;\n\n// Example 2\nmbarrier.arrive_drop.shared::cluster.b64 _, [addr];\nmbarrier.arrive_drop.shared::cta.release.cluster.b64 _, [addr], cnt;\n\n// Example 3\nmbarrier.arrive_drop.expect_tx.shared::cta.release.cta.b64 state, [addr], tx_count;\n
Causes an arrive-on operation to be\ntriggered by the system on the mbarrier object upon the completion of all prior cp.async operations initiated by the\nexecuting thread. The mbarrier object is at the location specified by the operand addr. The\narrive-on operation is\nasynchronous to execution of cp.async.mbarrier.arrive.
\n
When .noinc modifier is not specified, the pending count of the mbarrier object is incremented\nby 1 prior to the asynchronous arrive-on operation. This\nresults in a zero-net change for the pending count from the asynchronous arrive-on operation\nduring the current phase. The pending count of the mbarrier object after the increment should not\nexceed the limit as mentioned in Contents of the mbarrier object. Otherwise,\nthe behavior is undefined.
\n
When the .noinc modifier is specified, the increment to the pending count of the mbarrier\nobject is not performed. Hence the decrement of the pending count done by the asynchronous\narrive-on operation must be\naccounted for in the initialization of the mbarrier object.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
// Example 1: no .noinc\nmbarrier.init.shared.b64 [shMem], threadCount;\n....\ncp.async.ca.shared.global [shard1], [gbl1], 4;\ncp.async.cg.shared.global [shard2], [gbl2], 16;\n....\n// Absence of .noinc accounts for arrive-on from completion of prior cp.async operations.\n// So mbarrier.init must only account for arrive-on from mbarrier.arrive.\ncp.async.mbarrier.arrive.shared.b64 [shMem];\n....\nmbarrier.arrive.shared.b64 state, [shMem];\n\nwaitLoop:\nmbarrier.test_wait.shared.b64 p, [shMem], state;\n@!p bra waitLoop;\n\n\n\n// Example 2: with .noinc\n\n// Tracks arrive-on from mbarrier.arrive and cp.async.mbarrier.arrive.\n\n// All threads participating in the mbarrier perform cp.async\nmov.b32 copyOperationCnt, threadCount;\n\n// 3 arrive-on operations will be triggered per-thread\nmul.lo.u32 copyArrivalCnt, copyOperationCnt, 3;\n\nadd.u32 totalCount, threadCount, copyArrivalCnt;\n\nmbarrier.init.shared.b64 [shMem], totalCount;\n....\ncp.async.ca.shared.global [shard1], [gbl1], 4;\ncp.async.cg.shared.global [shard2], [gbl2], 16;\n...\n// Presence of .noinc requires mbarrier initalization to have accounted for arrive-on from cp.async\ncp.async.mbarrier.arrive.noinc.shared.b64 [shMem]; // 1st instance\n....\ncp.async.ca.shared.global [shard3], [gbl3], 4;\ncp.async.ca.shared.global [shard4], [gbl4], 16;\ncp.async.mbarrier.arrive.noinc.shared::cta.b64 [shMem]; // 2nd instance\n....\ncp.async.ca.shared.global [shard5], [gbl5], 4;\ncp.async.cg.shared.global [shard6], [gbl6], 16;\ncp.async.mbarrier.arrive.noinc.shared.b64 [shMem]; // 3rd and last instance\n....\nmbarrier.arrive.shared.b64 state, [shMem];\n\nwaitLoop:\nmbarrier.test_wait.shared.b64 p, [shMem], state;\n@!p bra waitLoop;\n
The test_wait and try_wait operations test for the completion of the current or the immediately\npreceding phase of an mbarrier object at the location specified by the operand addr.
\n
mbarrier.test_wait is a non-blocking instruction which tests for the completion of the phase.
\n
mbarrier.try_wait is a potentially blocking instruction which tests for the completion of the\nphase. If the phase is not complete, the executing thread may be suspended. Suspended thread resumes\nexecution when the specified phase completes OR before the phase completes following a\nsystem-dependent time limit. The optional 32-bit unsigned integer operand suspendTimeHint\nspecifies the time limit, in nanoseconds, that may be used for the time limit instead of the\nsystem-dependent limit.
\n
mbarrier.test_wait and mbarrier.try_wait test for completion of the phase :
\n
\n
Specified by the operand state, which was returned by an mbarrier.arrive instruction on\nthe same mbarrier object during the current or the immediately preceding phase. Or
\n
Indicated by the operand phaseParity, which is the integer parity of either the current phase\nor the immediately preceding phase of the mbarrier object.
\n
\n
The .parity variant of the instructions test for the completion of the phase indicated by the\noperand phaseParity, which is the integer parity of either the current phase or the immediately\npreceding phase of the mbarrier object. An even phase has integer parity 0 and an odd phase has\ninteger parity of 1. So the valid values of phaseParity operand are 0 and 1.
\n
Note: the use of the .parity variants of the instructions requires tracking the phase of an\nmbarrier object throughout its lifetime.
\n
The test_wait and try_wait operations are valid only for :
\n
\n
the current incomplete phase, for which waitComplete returns False.
\n
the immediately preceding phase, for which waitComplete returns True.
\n
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
When mbarrier.test_wait and mbarrier.try_wait operations return True, they form the\nacquire pattern as described in the Memory Consistency Model.
\n
The optional .scope qualifier indicates the set of threads that the mbarrier.test_wait and\nmbarrier.try_wait instructions can directly synchronize. If the .scope qualifier is not\nspecified then it defaults to .cta. In contrast, the .shared::<scope> indicates the state\nspace where the mbarrier resides.
\n
The following ordering of memory operations hold for the executing thread when\nmbarrier.test_wait or mbarrier.try_wait returns True :
\n\n
All memory accesses (except async operations ) requested prior, in program\norder, to mbarrier.arrive during the completed phase by the participating threads of the CTA\nare performed and are visible to the executing thread.
\n
All cp.async operations\nrequested prior, in program order, to cp.async.mbarrier.arrive during the completed phase by\nthe participating threads of the CTA are performed and made visible to the executing thread.
\n
All cp.async.bulk asynchronous operations using the same mbarrier object requested prior,\nin program order, to mbarrier.arrive during the completed phase by the participating threads\nof the CTA are performed and made visible to the executing thread.
\n
All memory accesses requested after the mbarrier.test_wait or mbarrier.try_wait, in\nprogram order, are not performed and not visible to memory accesses performed prior to\nmbarrier.arrive, in program order, by other threads participating in the mbarrier.
\n
There is no ordering and visibility guarantee for memory accesses requested by the thread after\nmbarrier.arrive and prior to mbarrier.test_wait, in program order.
\n\n
PTX ISA Notes
\n
mbarrier.test_wait introduced in PTX ISA version 7.0.
\n
Modifier .parity is introduced in PTX ISA version 7.1.
\n
mbarrier.try_wait introduced in PTX ISA version 7.8.
\n
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Support for .scope and .sem qualifiers introduced in PTX ISA version 8.0
\n
Target ISA Notes
\n
mbarrier.test_wait requires sm_80 or higher.
\n
mbarrier.try_wait requires sm_90 or higher.
\n
Support for .cluster scope requires sm_90 or higher.
\n
Examples
\n
\n
// Example 1a, thread synchronization with test_wait:\n\n.reg .b64 %r1;\n.shared .b64 shMem;\n\nmbarrier.init.shared.b64 [shMem], N; // N threads participating in the mbarrier.\n...\nmbarrier.arrive.shared.b64 %r1, [shMem]; // N threads executing mbarrier.arrive\n\n// computation not requiring mbarrier synchronization...\n\nwaitLoop:\nmbarrier.test_wait.shared.b64 complete, [shMem], %r1;\n@!complete nanosleep.u32 20;\n@!complete bra waitLoop;\n\n// Example 1b, thread synchronization with try_wait :\n\n.reg .b64 %r1;\n.shared .b64 shMem;\n\nmbarrier.init.shared.b64 [shMem], N; // N threads participating in the mbarrier.\n...\nmbarrier.arrive.shared.b64 %r1, [shMem]; // N threads executing mbarrier.arrive\n\n// computation not requiring mbarrier synchronization...\n\nwaitLoop:\nmbarrier.try_wait.shared.b64 complete, [shMem], %r1;\n@!complete bra waitLoop;\n\n\n// Example 2, thread synchronization using phase parity :\n\n.reg .b32 i, parArg;\n.reg .b64 %r1;\n.shared .b64 shMem;\n\nmov.b32 i, 0;\nmbarrier.init.shared.b64 [shMem], N; // N threads participating in the mbarrier.\n...\nloopStart : // One phase per loop iteration\n ...\n mbarrier.arrive.shared.b64 %r1, [shMem]; // N threads\n ...\n and.b32 parArg, i, 1;\n waitLoop:\n mbarrier.test_wait.parity.shared.b64 complete, [shMem], parArg;\n @!complete nanosleep.u32 20;\n @!complete bra waitLoop;\n ...\n add.u32 i, i, 1;\n setp.lt.u32 p, i, IterMax;\n@p bra loopStart;\n\n\n// Example 3, Asynchronous copy completion waiting :\n\n.reg .b64 state;\n.shared .b64 shMem2;\n.shared .b64 shard1, shard2;\n.global .b64 gbl1, gbl2;\n\nmbarrier.init.shared.b64 [shMem2], threadCount;\n...\ncp.async.ca.shared.global [shard1], [gbl1], 4;\ncp.async.cg.shared.global [shard2], [gbl2], 16;\n\n// Absence of .noinc accounts for arrive-on from prior cp.async operation\ncp.async.mbarrier.arrive.shared.b64 [shMem2];\n...\nmbarrier.arrive.shared.b64 state, [shMem2];\n\nwaitLoop:\nmbarrier.test_wait.shared::cta.b64 p, [shMem2], state;\n@!p bra waitLoop;\n\n// Example 4, Synchronizing the CTA0 threads with cluster threads\n.reg .b64 %r1, addr, remAddr;\n.shared .b64 shMem;\n\ncvta.shared.u64 addr, shMem;\nmapa.u64 remAddr, addr, 0; // CTA0\u2019s shMem instance\n\n// One thread from CTA0 executing the below initialization operation\n@p0 mbarrier.init.shared::cta.b64 [shMem], N; // N = no of cluster threads\n\nbarrier.cluster.arrive;\nbarrier.cluster.wait;\n\n// Entire cluster executing the below arrive operation\nmbarrier.arrive.release.cluster.b64 _, [remAddr];\n\n// computation not requiring mbarrier synchronization ...\n\n// Only CTA0 threads executing the below wait operation\nwaitLoop:\nmbarrier.try_wait.parity.acquire.cluser.shared::cta.b64 complete, [shMem], 0;\n@!complete bra waitLoop;\n
Query the pending arrival count from the opaque mbarrier state.
\n
Syntax
\n
\n
mbarrier.pending_count.b64 count, state;\n
\n
\n
Description
\n
The pending count can be queried from the opaque mbarrier state using mbarrier.pending_count.
\n
The state operand is a 64-bit register that must be the result of a prior\nmbarrier.arrive.noComplete or mbarrier.arrive_drop.noComplete instruction. Otherwise, the\nbehavior is undefined.
\n
The destination register count is a 32-bit unsigned integer representing the pending count of\nthe mbarrier object prior to the arrive-on operation from\nwhich the state register was obtained.
A thread executing mbarrier.arrive performs an arrive-on operation\non the mbarrier object at the location specified by the address operand addr. The 32-bit\nunsigned integer operand count specifies the count argument to the arrive-on\noperation.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
The optional qualifier .expect_tx specifies that an expect-tx\noperation is performed prior to the arrive-on\noperation. The 32-bit unsigned integer operand txCount specifies the expectCount argument to\nthe expect-tx operation. When both qualifiers .arrive and .expect_tx are specified, then\nthe count argument of the arrive-on operation is assumed to be 1.
\n
A mbarrier.arrive operation with .noComplete qualifier must not cause the mbarrier to\ncomplete its current phase, otherwise the behavior is undefined.
Note: for sm_8x, when the argument count is specified, the modifier .noComplete is\nrequired.
\n
mbarrier.arrive operation on an mbarrier object located in .shared::cta returns an opaque\n64-bit register capturing the phase of the mbarrier object prior to the arrive-on operation in the\ndestination operand state. Contents of the state operand are implementation\nspecific. Optionally, sink symbol '_' can be used for the state argument.
\n
mbarrier.arrive operation on an mbarrier object located in .shared::cluster but not in\n.shared::cta cannot return a value. Sink symbol \u2018_\u2019 is mandatory for the destination operand for\nsuch cases.
\n
The optional .sem qualifier specifies a memory synchronizing effect as described in the Memory\nConsistency Model. If the .sem qualifier is absent,\n.release is assumed by default.
\n
The optional .scope qualifier indicates the set of threads that directly observe the memory\nsynchronizing effect of this operation, as described in the Memory Consistency Model. If the .scope qualifier is not specified then it\ndefaults to .cta. In contrast, the .shared::<scope> indicates the state space where the\nmbarrier resides.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Support for sink symbol \u2018_\u2019 as the destination operand is introduced in PTX ISA version 7.1.
\n
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Support for count argument without the modifier .noComplete introduced in PTX ISA version\n7.8.
\n
Support for sub-qualifier ::cluster introduced in PTX ISA version 8.0.
\n
Support for qualifier .expect_tx is introduced in PTX ISA version 8.0.
\n
Support for .scope and .sem qualifiers introduced in PTX ISA version 8.0
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Support for count argument without the modifier .noComplete requires sm_90 or higher.
\n
Qualifier .expect_tx requires sm_90 or higher.
\n
Sub-qualifier ::cluster requires sm_90 or higher.
\n
Support for .cluster scope requires sm_90 or higher.
A thread executing mbarrier.arrive_drop on the mbarrier object at the location specified by\nthe address operand addr performs the following steps:
\n
\n
Decrements the expected arrival count of the mbarrier object by the value specified by the\n32-bit integer operand count. If count operand is not specified, it defaults to 1.
The decrement done in the expected arrivals count of the mbarrier object will be for all the\nsubsequent phases of the mbarrier object.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta or .shared::cluster state space then the behavior is undefined.
The optional qualifier .expect_tx specifies that an expect-tx\noperation is performed prior to the arrive-on\noperation. The 32-bit unsigned integer operand txCount specifies the expectCount argument to\nthe expect-tx operation. When both qualifiers .arrive and .expect_tx are specified, then\nthe count argument of the arrive-on operation is assumed to be 1.
\n
mbarrier.arrive_drop operation forms the release pattern as described in the Memory\nConsistency Model and synchronizes with the acquire patterns.
\n
The optional .scope qualifier indicates the set of threads that an mbarrier.arrive_drop\ninstruction can directly synchronize. If the .scope qualifier is not specified then it defaults\nto .cta. In contrast, the .shared::<scope> indicates the state space where the mbarrier\nresides.
\n
A mbarrier.arrive_drop with .noComplete qualifier must not complete the mbarrier,\notherwise the behavior is undefined.
Note: for sm_8x, when the argument count is specified, the modifier .noComplete is\nrequired.
\n
A thread that wants to either exit or opt out of participating in the arrive-on operation can use\nmbarrier.arrive_drop to drop itself from the mbarrier.
\n
mbarrier.arrive_drop operation on an mbarrier object located in .shared::cta returns an\nopaque 64-bit register capturing the phase of the mbarrier object prior to the arrive-on\noperation\nin the destination operand state. Contents of the returned state are implementation\nspecific. Optionally, sink symbol '_' can be used for the state argument.
\n
mbarrier.arrive_drop operation on an mbarrier object located in .shared::cluster but not\nin .shared::cta cannot return a value. Sink symbol \u2018_\u2019 is mandatory for the destination operand\nfor such cases.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Support for count argument without the modifier .noComplete introduced in PTX ISA version\n7.8.
\n
Support for qualifier .expect_tx is introduced in PTX ISA version 8.0.
\n
Support for sub-qualifier ::cluster introduced in PTX ISA version 8.0.
\n
Support for .scope and .sem qualifiers introduced in PTX ISA version 8.0
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Support for count argument without the modifier .noComplete requires sm_90 or higher.
\n
Qualifier .expect_tx requires sm_90 or higher.
\n
Sub-qualifier ::cluster requires sm_90 or higher.
\n
Support for .cluster scope requires sm_90 or higher.
\n
Examples
\n
\n
.reg .b32 cnt;\n.reg .b64 %r1;\n.shared .b64 shMem;\n\n// Example 1\n@p mbarrier.arrive_drop.shared.b64 _, [shMem];\n@p exit;\n@p2 mbarrier.arrive_drop.noComplete.shared.b64 _, [shMem], %a;\n@p2 exit;\n..\n@!p mbarrier.arrive.shared.b64 %r1, [shMem];\n@!p mbarrier.test_wait.shared.b64 q, [shMem], %r1;\n\n// Example 2\nmbarrier.arrive_drop.shared::cluster.b64 _, [addr];\nmbarrier.arrive_drop.shared::cta.release.cluster.b64 _, [addr], cnt;\n\n// Example 3\nmbarrier.arrive_drop.expect_tx.shared::cta.release.cta.b64 state, [addr], tx_count;\n
\n
\n\n
Parallel Synchronization and Communication Instructions: mbarrier.complete_tx
\n\n\n
Perfoms complete-tx\noperation on the mbarrier object.
A thread executing mbarrier.complete_tx performs a complete-tx\noperation on the mbarrier object at the location specified by the address operand addr. The\n32-bit unsigned integer operand txCount specifies the completeCount argument to the\ncomplete-tx operation.
\n
mbarrier.complete_tx does not involve any asynchronous memory operations and only simulates the\ncompletion of an asynchronous memory operation and its side effect of signaling to the mbarrier\nobject.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta or .shared::cluster state space then the behavior is undefined.
A thread executing mbarrier.expect_tx performs an expect-tx\noperation on the mbarrier object at the location specified by the address operand addr. The\n32-bit unsigned integer operand txCount specifies the expectCount argument to the\nexpect-tx operation.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta or .shared::cluster state space then the behavior is undefined.
mbarrier.init initializes the mbarrier object at the location specified by the address operand\naddr with the unsigned 32-bit integer count. The value of operand count must be in the range\nas specified in Contents of the mbarrier object.
\n
Initialization of the mbarrier object involves :
\n
\n
Initializing the current phase to 0.
\n
Initializing the expected arrival count to count.
\n
Initializing the pending arrival count to count.
\n
Initializing the tx-count to 0.
\n
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
.shared .b64 shMem, shMem2;\n.reg .b64 addr;\n.reg .b32 %r1;\n\ncvta.shared.u64 addr, shMem2;\nmbarrier.init.b64 [addr], %r1;\nbar.cta.sync 0;\n// ... other mbarrier operations on addr\n\nmbarrier.init.shared::cta.b64 [shMem], 12;\nbar.sync 0;\n// ... other mbarrier operations on shMem\n
\n
\n\n
Parallel Synchronization and Communication Instructions: mbarrier.inval
\n\n\n
Invalidates the mbarrier object.
\n
Syntax
\n
\n
mbarrier.inval{.shared{::cta}}.b64 [addr];\n
\n
\n
Description
\n
mbarrier.inval invalidates the mbarrier object at the location specified by the address\noperand addr.
\n
An mbarrier object must be invalidated before using its memory location for any other purpose.
\n
Performing any mbarrier operation except mbarrier.init on an invalidated mbarrier object\nresults in undefined behaviour.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Examples
\n
\n
.shared .b64 shmem;\n.reg .b64 addr;\n.reg .b32 %r1;\n.reg .pred t0;\n\n// Example 1 :\nbar.sync 0;\n@t0 mbarrier.init.b64 [addr], %r1;\n// ... other mbarrier operations on addr\nbar.sync 0;\n@t0 mbarrier.inval.b64 [addr];\n\n\n// Example 2 :\nbar.cta.sync 0;\nmbarrier.init.shared.b64 [shmem], 12;\n// ... other mbarrier operations on shmem\nbar.cta.sync 0;\n@t0 mbarrier.inval.shared.b64 [shmem];\n\n// shmem can be reused here for unrelated use :\nbar.cta.sync 0;\nst.shared.b64 [shmem], ...;\n\n// shmem can be re-initialized as mbarrier object :\nbar.cta.sync 0;\n@t0 mbarrier.init.shared.b64 [shmem], 24;\n// ... other mbarrier operations on shmem\nbar.cta.sync 0;\n@t0 mbarrier.inval.shared::cta.b64 [shmem];\n
\n
\n\n
Parallel Synchronization and Communication Instructions: mbarrier.pending_count
\n\n\n
Query the pending arrival count from the opaque mbarrier state.
\n
Syntax
\n
\n
mbarrier.pending_count.b64 count, state;\n
\n
\n
Description
\n
The pending count can be queried from the opaque mbarrier state using mbarrier.pending_count.
\n
The state operand is a 64-bit register that must be the result of a prior\nmbarrier.arrive.noComplete or mbarrier.arrive_drop.noComplete instruction. Otherwise, the\nbehavior is undefined.
\n
The destination register count is a 32-bit unsigned integer representing the pending count of\nthe mbarrier object prior to the arrive-on operation from\nwhich the state register was obtained.
The test_wait and try_wait operations test for the completion of the current or the immediately\npreceding phase of an mbarrier object at the location specified by the operand addr.
\n
mbarrier.test_wait is a non-blocking instruction which tests for the completion of the phase.
\n
mbarrier.try_wait is a potentially blocking instruction which tests for the completion of the\nphase. If the phase is not complete, the executing thread may be suspended. Suspended thread resumes\nexecution when the specified phase completes OR before the phase completes following a\nsystem-dependent time limit. The optional 32-bit unsigned integer operand suspendTimeHint\nspecifies the time limit, in nanoseconds, that may be used for the time limit instead of the\nsystem-dependent limit.
\n
mbarrier.test_wait and mbarrier.try_wait test for completion of the phase :
\n
\n
Specified by the operand state, which was returned by an mbarrier.arrive instruction on\nthe same mbarrier object during the current or the immediately preceding phase. Or
\n
Indicated by the operand phaseParity, which is the integer parity of either the current phase\nor the immediately preceding phase of the mbarrier object.
\n
\n
The .parity variant of the instructions test for the completion of the phase indicated by the\noperand phaseParity, which is the integer parity of either the current phase or the immediately\npreceding phase of the mbarrier object. An even phase has integer parity 0 and an odd phase has\ninteger parity of 1. So the valid values of phaseParity operand are 0 and 1.
\n
Note: the use of the .parity variants of the instructions requires tracking the phase of an\nmbarrier object throughout its lifetime.
\n
The test_wait and try_wait operations are valid only for :
\n
\n
the current incomplete phase, for which waitComplete returns False.
\n
the immediately preceding phase, for which waitComplete returns True.
\n
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by addr does not fall within the address window of\n.shared::cta state space then the behavior is undefined.
When mbarrier.test_wait and mbarrier.try_wait operations return True, they form the\nacquire pattern as described in the Memory Consistency Model.
\n
The optional .scope qualifier indicates the set of threads that the mbarrier.test_wait and\nmbarrier.try_wait instructions can directly synchronize. If the .scope qualifier is not\nspecified then it defaults to .cta. In contrast, the .shared::<scope> indicates the state\nspace where the mbarrier resides.
\n
The following ordering of memory operations hold for the executing thread when\nmbarrier.test_wait or mbarrier.try_wait returns True :
\n\n
All memory accesses (except async operations ) requested prior, in program\norder, to mbarrier.arrive during the completed phase by the participating threads of the CTA\nare performed and are visible to the executing thread.
\n
All cp.async operations\nrequested prior, in program order, to cp.async.mbarrier.arrive during the completed phase by\nthe participating threads of the CTA are performed and made visible to the executing thread.
\n
All cp.async.bulk asynchronous operations using the same mbarrier object requested prior,\nin program order, to mbarrier.arrive during the completed phase by the participating threads\nof the CTA are performed and made visible to the executing thread.
\n
All memory accesses requested after the mbarrier.test_wait or mbarrier.try_wait, in\nprogram order, are not performed and not visible to memory accesses performed prior to\nmbarrier.arrive, in program order, by other threads participating in the mbarrier.
\n
There is no ordering and visibility guarantee for memory accesses requested by the thread after\nmbarrier.arrive and prior to mbarrier.test_wait, in program order.
\n\n
PTX ISA Notes
\n
mbarrier.test_wait introduced in PTX ISA version 7.0.
\n
Modifier .parity is introduced in PTX ISA version 7.1.
\n
mbarrier.try_wait introduced in PTX ISA version 7.8.
\n
Support for sub-qualifier ::cta on .shared introduced in PTX ISA version 7.8.
\n
Support for .scope and .sem qualifiers introduced in PTX ISA version 8.0
\n
Target ISA Notes
\n
mbarrier.test_wait requires sm_80 or higher.
\n
mbarrier.try_wait requires sm_90 or higher.
\n
Support for .cluster scope requires sm_90 or higher.
\n
Examples
\n
\n
// Example 1a, thread synchronization with test_wait:\n\n.reg .b64 %r1;\n.shared .b64 shMem;\n\nmbarrier.init.shared.b64 [shMem], N; // N threads participating in the mbarrier.\n...\nmbarrier.arrive.shared.b64 %r1, [shMem]; // N threads executing mbarrier.arrive\n\n// computation not requiring mbarrier synchronization...\n\nwaitLoop:\nmbarrier.test_wait.shared.b64 complete, [shMem], %r1;\n@!complete nanosleep.u32 20;\n@!complete bra waitLoop;\n\n// Example 1b, thread synchronization with try_wait :\n\n.reg .b64 %r1;\n.shared .b64 shMem;\n\nmbarrier.init.shared.b64 [shMem], N; // N threads participating in the mbarrier.\n...\nmbarrier.arrive.shared.b64 %r1, [shMem]; // N threads executing mbarrier.arrive\n\n// computation not requiring mbarrier synchronization...\n\nwaitLoop:\nmbarrier.try_wait.shared.b64 complete, [shMem], %r1;\n@!complete bra waitLoop;\n\n\n// Example 2, thread synchronization using phase parity :\n\n.reg .b32 i, parArg;\n.reg .b64 %r1;\n.shared .b64 shMem;\n\nmov.b32 i, 0;\nmbarrier.init.shared.b64 [shMem], N; // N threads participating in the mbarrier.\n...\nloopStart : // One phase per loop iteration\n ...\n mbarrier.arrive.shared.b64 %r1, [shMem]; // N threads\n ...\n and.b32 parArg, i, 1;\n waitLoop:\n mbarrier.test_wait.parity.shared.b64 complete, [shMem], parArg;\n @!complete nanosleep.u32 20;\n @!complete bra waitLoop;\n ...\n add.u32 i, i, 1;\n setp.lt.u32 p, i, IterMax;\n@p bra loopStart;\n\n\n// Example 3, Asynchronous copy completion waiting :\n\n.reg .b64 state;\n.shared .b64 shMem2;\n.shared .b64 shard1, shard2;\n.global .b64 gbl1, gbl2;\n\nmbarrier.init.shared.b64 [shMem2], threadCount;\n...\ncp.async.ca.shared.global [shard1], [gbl1], 4;\ncp.async.cg.shared.global [shard2], [gbl2], 16;\n\n// Absence of .noinc accounts for arrive-on from prior cp.async operation\ncp.async.mbarrier.arrive.shared.b64 [shMem2];\n...\nmbarrier.arrive.shared.b64 state, [shMem2];\n\nwaitLoop:\nmbarrier.test_wait.shared::cta.b64 p, [shMem2], state;\n@!p bra waitLoop;\n\n// Example 4, Synchronizing the CTA0 threads with cluster threads\n.reg .b64 %r1, addr, remAddr;\n.shared .b64 shMem;\n\ncvta.shared.u64 addr, shMem;\nmapa.u64 remAddr, addr, 0; // CTA0\u2019s shMem instance\n\n// One thread from CTA0 executing the below initialization operation\n@p0 mbarrier.init.shared::cta.b64 [shMem], N; // N = no of cluster threads\n\nbarrier.cluster.arrive;\nbarrier.cluster.wait;\n\n// Entire cluster executing the below arrive operation\nmbarrier.arrive.release.cluster.b64 _, [remAddr];\n\n// computation not requiring mbarrier synchronization ...\n\n// Only CTA0 threads executing the below wait operation\nwaitLoop:\nmbarrier.try_wait.parity.acquire.cluser.shared::cta.b64 complete, [shMem], 0;\n@!complete bra waitLoop;\n
\n
\n",
- "tooltip": "=====Parallel Synchronization and Communication Instructions: mbarrier\n\n\n\nSynchronizing any subset of threads within a CTA\n\nOne-way synchronization of threads across CTAs of a cluster. As noted in mbarrier support with\n\nshared memory, threads can\n\nperform only arrive operations but not *_wait on an mbarrier located in shared::cluster\n\nspace.\n\nWaiting for completion of asynchronous memory operations initiated by a thread and making them\n\nvisible to other threads.\n\nAn mbarrier o...\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.arrive\n\n\n\nPerforms arrive-on operation on the\n\nmbarrier object.\n\nSyntax\n\nmbarrier.arrive{.sem}{.scope}{.shared{::cta}}.b64 state, [addr]{, count};\n\nmbarrier.arrive{.sem}{.scope}{.shared::cluster}.b64 _, [addr] {,count}\n\nmbarrier.arrive.expect_tx{.sem}{.scope}{.shared{::cta}}.b64 state, [addr], txCount;\n\nmbarrier.arrive.expect_tx{.sem}{.scope}{.shared::cluster}.b64 _, [addr], txCount;\n\nmbarrier....\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.arrive_drop\n\n\n\nDecrements the expected count of the mbarrier object and performs arrive-on operation.\n\nSyntax\n\nmbarrier.arrive_drop{.sem}{.scope}{.shared{::cta}}.b64 state, [addr]{, count};\n\nmbarrier.arrive_drop{.sem}{.scope}{.shared::cluster}.b64 _, [addr] {,count};\n\nmbarrier.arrive_drop.expect_tx{.shared{::cta}}{.sem}{.scope}.b64 state, [addr], tx_count;\n\nmbarrier.arrive_drop.expect_tx{.shared...\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.complete_tx\n\n\n\nPerfoms complete-tx\n\noperation on the mbarrier object.\n\nSyntax\n\nmbarrier.complete_tx{.sem}{.scope}{.space}.b64 [addr], txCount;\n\n.sem = { .relaxed }\n\n.scope = { .cta, .cluster }\n\n.space = { .shared{::cta}, .shared::cluster }\n\nDescription\n\nA thread executing mbarrier.complete_tx performs a complete-tx\n\noperation on the mbarrier object at the location specified by the address operand addr. The\n\n32-bit unsig...\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.expect_tx\n\n\n\nPerfoms expect-tx operation on the mbarrier object.\n\nSyntax\n\nmbarrier.expect_tx{.sem}{.scope}{.space}.b64 [addr], txCount;\n\n.sem = { .relaxed }\n\n.scope = { .cta, .cluster }\n\n.space = { .shared{::cta}, .shared::cluster }\n\nDescription\n\nA thread executing mbarrier.expect_tx performs an expect-tx\n\noperation on the mbarrier object at the location specified by the address operand addr. The\n\n32-bit unsigned int...\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.init\n\n\n\nInitialize the mbarrier object.\n\nSyntax\n\nmbarrier.init{.shared{::cta}}.b64 [addr], count;\n\nDescription\n\nmbarrier.init initializes the mbarrier object at the location specified by the address operand\n\naddr with the unsigned 32-bit integer count. The value of operand count must be in the range\n\nas specified in Contents of the mbarrier object.\n\nInitialization of the mbarrier object involves :\n\nInitializing t...\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.inval\n\n\n\nInvalidates the mbarrier object.\n\nSyntax\n\nmbarrier.inval{.shared{::cta}}.b64 [addr];\n\nDescription\n\nmbarrier.inval invalidates the mbarrier object at the location specified by the address\n\noperand addr.\n\nAn mbarrier object must be invalidated before using its memory location for any other purpose.\n\nPerforming any mbarrier operation except mbarrier.init on an invalidated mbarrier object\n\nresults in undefine...\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.pending_count\n\n\n\nQuery the pending arrival count from the opaque mbarrier state.\n\nSyntax\n\nmbarrier.pending_count.b64 count, state;\n\nDescription\n\nThe pending count can be queried from the opaque mbarrier state using mbarrier.pending_count.\n\nThe state operand is a 64-bit register that must be the result of a prior\n\nmbarrier.arrive.noComplete or mbarrier.arrive_drop.noComplete instruction. Otherwise, the\n\nbehavior is undefi...\n\n=====Parallel Synchronization and Communication Instructions: mbarrier.test_wait/mbarrier.try_wait\n\n\n\nChecks whether the mbarrie ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-mbarrier"
+ "html": "
cp.async is a non-blocking instruction which initiates an asynchronous copy operation of data\nfrom the location specified by source address operand src to the location specified by\ndestination address operand dst. Operand src specifies a location in the global state space\nand dst specifies a location in the shared state space.
\nFor more information, visit mbarrier.test_wait .",
+ "tooltip": "Initiates an asynchronous copy operation from one state space to another.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-asynchronous-copy"
};
- case "membar/fence":
+ case "membar":
return {
- "html": "For more information, visit membar/fence .
Parallel Synchronization and Communication Instructions: membar/fence
The membar instruction guarantees that prior memory accesses requested by this thread (ld,\nst, atom and red instructions) are performed at the specified level, before later\nmemory operations requested by this thread following the membar instruction. The level\nqualifier specifies the set of threads that may observe the ordering effect of this operation.
\n
A memory read (e.g., by ld or atom) has been performed when the value read has been\ntransmitted from memory and cannot be modified by another thread at the indicated level. A memory\nwrite (e.g., by st, red or atom) has been performed when the value written has become\nvisible to other threads at the specified level, that is, when the previous value can no longer be\nread.
\n
The fence instruction establishes an ordering between memory accesses requested by this thread\n(ld, st, atom and red instructions) as described in the Memory Consistency Model. The scope qualifier specifies the set of threads that may\nobserve the ordering effect of this operation.
\n
fence.acq_rel is a light-weight fence that is sufficient for memory synchronization in most\nprograms. Instances of fence.acq_rel synchronize when combined with additional memory operations\nas described in acquire and release patterns in the Memory Consistency Model. If the optional .sem qualifier is absent, .acq_rel\nis assumed by default.
\n
fence.sc is a slower fence that can restore sequential consistency when used in sufficient\nplaces, at the cost of performance. Instances of fence.sc with sufficient scope always\nsynchronize by forming a total order per scope, determined at runtime. This total order can be\nconstrained further by other synchronization in the program.
\n
Qualifier .op_restrict restricts the class of prior memory operations for which the fence\ninstruction provides the memory ordering guarantees. When .op_restrict is .mbarrier_init,\nthe fence only applies to the prior mbarrier.init operations executed by the same thread on\nmbarrier objects in .shared::cta state space.
\n
The address operand addr and the operand size together specifies the memory range\n[addr,addr+size-1] on which the ordering guarantees on the memory accesses across the proxies is to be\nprovided. The only supported value for the size operand is 128. Generic Addressing\nis used unconditionally, and the address specified by the operand addr must fall within the .global\nstate space. Otherwise, the behavior is undefined.
\n
On sm_70 and higher membar is a synonym for fence.sc1, and the membar\nlevels cta, gl and sys are synonymous with the fence scopes cta, gpu and\nsys respectively.
\n
membar.proxy and fence.proxy instructions establish an ordering between memory accesses that\nmay happen through different proxies.
\n
A uni-directional proxy ordering from the from-proxykind to the to-proxykind establishes\nordering between a prior memory access performed via the from-proxykind and a subsequent memory access\nperformed via the to-proxykind.
\n
A bi-directional proxy ordering between two proxykinds establishes two uni-directional proxy orderings\n: one from the first proxykind to the second proxykind and the other from the second proxykind to the first\nproxykind.
\n
The .proxykind qualifier indicates the bi-directional proxy ordering that is established between the memory\naccesses done between the generic proxy and the proxy specified by .proxykind.
\n
Value .alias of the .proxykind qualifier refers to memory accesses performed using virtually\naliased addresses to the same memory location. Value .async of the .proxykind qualifier specifies\nthat the memory ordering is established between the async proxy and the generic proxy. The memory\nordering is limited only to the state space specified. If no state space is specified, then the memory\nordering applies on all state spaces.
\n
A .release proxy fence can form a release sequence that synchronizes with an acquire\nsequence that contains a .acquire proxy fence. The .to_proxykind and\n.from_proxykind qualifiers indicate the uni-directional proxy ordering that is established.
\n
On sm_70 and higher, membar.proxy is a synonym for fence.proxy.
\n
1 The semantics of fence.sc introduced with sm_70 is a superset of the semantics of\nmembar and the two are compatible; when executing on sm_70 or later architectures,\nmembar acquires the full semantics of fence.sc.
\n
PTX ISA Notes
\n
membar.{cta,gl} introduced in PTX ISA version 1.4.
\n
membar.sys introduced in PTX ISA version 2.0.
\n
fence introduced in PTX ISA version 6.0.
\n
membar.proxy and fence.proxy introduced in PTX ISA version 7.5.
\n
.cluster scope qualifier introduced in PTX ISA version 7.8.
\n
.op_restrict qualifier introduced in PTX ISA version 8.0.
\n
fence.proxy.async is introduced in PTX ISA version 8.0.
\n
.to_proxykind::from_proxykind qualifier introduced in PTX ISA version 8.3.
\n
Target ISA Notes
\n
membar.{cta,gl} supported on all target architectures.
\n
membar.sys requires sm_20 or higher.
\n
fence requires sm_70 or higher.
\n
membar.proxy requires sm_60 or higher.
\n
fence.proxy requires sm_70 or higher.
\n
.cluster scope qualifier requires sm_90 or higher.
\n
.op_restrict qualifier requires sm_90 or higher.
\n
fence.proxy.async requires sm_90 or higher.
\n
.to_proxykind::from_proxykind qualifier requires sm_90 or higher.
\n",
- "tooltip": "Enforce an ordering of memory operations.\n\nSyntax\n\n// Thread fence :\n\nfence{.sem}.scope;\n\n// Operation fence :\n\nfence.op_restrict.release.cluster;\n\n// Proxy fence (bi-directional) :\n\nfence.proxy.proxykind;\n\n// Proxy fence (uni-directional) :\n\nfence.proxy.to_proxykind::from_proxykind.release.scope;\n\nfence.proxy.to_proxykind::from_proxykind.acquire.scope [addr], size;\n\n// Old style membar :\n\nmembar.level;\n\nmembar.proxy.proxykind;\n\n.sem = { .sc, .acq_rel };\n\n.scope = { .cta, .cluster, .gpu, .sys };\n\n.level = { .cta, .gl, .sys };\n\n.proxykind = { .alias, .async, async.global, .async.shared::{cta, cluster} };\n\n.op_restrict = { .mbarrier_init };\n\n.to_proxykind::from_proxykind = {.tensormap::generic};\n\nDescription\n\nThe membar instruction guarantees that prior memory accesses requested by this thread (ld,\n\nst, atom and red instructions) are performed at the specified level, before later\n\nmemory operations requested by this thread following the membar instruction. The level\n\nqualifier specifies the set of threads that may observe the ordering effect of this operation.\n\nA memory read (e.g., by ld or atom) has been performed when the value read has been\n\ntransmitted from memory and cannot be modified by another thread at the indicated level. A memory\n\nwrite (e.g., by st, red or atom) has been performed when the value written has become\n\nvisible to other threads at the specified level, that is, when the previous value can no longer be\n\nread.\n\nThe fence instruction establishes an ordering between memory accesses requested by this thread\n\n(ld, st, atom and red instructions) as described in the Memory Consistency Model. The scope qualifier specifies the set of threads that may\n\nobserve the ordering effect of this operation.\n\nfence.acq_rel is a light-weight fence that is sufficient for memory synchronization in most\n\nprograms. Instances of fence.acq_rel synchronize when combined with additional memory operations\n\nas described in acquire and release patterns in the Memory Consistency Model. If the optional .sem qualifier is absent, .acq_rel\n\nis assumed by default.\n\nfence.sc is a slower fence that can restore sequential consistency when used in sufficient\n\nplaces, at the cost of performance. Instances of fence.sc with sufficient scope always\n\nsynchronize by forming a total order per scope, determined at runtime. This total order can be\n\nconstrained further by other synchronization in the program.\n\nQualifier .op_restrict restricts the class of prior memory operations for which the fence\n\ninstruction provides the memory ordering guarantees. When .op_restrict is .mbarrier_init,\n\nthe fence only applies to the prior mbarrier.init operations executed by the same thread on\n\nmbarrier objects in .shared::cta state space.\n\nThe address operand addr and the operand size together specifies the memory range\n\n[addr, addr+size-1] on which the ordering guarantees on the memory accesses across the proxies is to be\n\nprovided. The only supported value for the size operand is 128. Generic Addressing\n\nis used unconditionally, and the address specified by the operand addr must fall within the .global\n\nstate space. Otherwise, the behavior is undefined.\n\nOn sm_70 and higher membar is a synonym for fence.sc1, and the membar\n\nlevels cta, gl and sys are synonymous with the fence scopes cta, gpu and\n\nsys respectively.\n\nmembar.proxy and fence.proxy instructions establish an ordering between memory accesses that\n\nmay happen through different proxies.\n\nA uni-directional proxy ordering from the from-proxykind to the to-proxykind establishes\n\nordering between a prior memory access performed via the from-proxykind and a subsequent memory access\n\nperformed via the to-proxykind.\n\nA bi-directional proxy ordering between two proxykinds establishes two uni-directional proxy orderings\n\n: one from the first proxykind to the second proxykind and the other from the second proxykind to the first\n\nproxykind.\n\nThe .proxykind qualifier indicates the bi-directional proxy ordering that is established between the memory\n\naccesses done betwee ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-membar-fence"
+ "html": "
The membar instruction guarantees that prior memory accesses requested by this thread (ld,\nst, atom and red instructions) are performed at the specified level, before later\nmemory operations requested by this thread following the membar instruction. The level\nqualifier specifies the set of threads that may observe the ordering effect of this operation.
\nFor more information, visit membar .",
+ "tooltip": "Enforce an ordering of memory operations.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-membar"
};
case "min":
return {
- "html": "For more information, visit min(fp) , min(fp16) , min(int) .
Floating Point Instructions: min
\n\n\n
Find the minimum of two values.
\n
Syntax
\n
\n
min{.ftz}{.NaN}{.xorsign.abs}.f32 d, a, b;\nmin.f64 d, a, b;\n
\n
\n
Description
\n
Store the minimum of a and b in d.
\n
If .NaN modifier is specified, then the result is canonical NaN if either of the inputs is\nNaN.
\n
If .abs modifier is specified, the magnitude of destination operand d is the minimum of\nabsolute values of both the input arguments.
\n
If .xorsign modifier is specified, the sign bit of destination d is equal to the XOR of the\nsign bits of both the inputs.
\n
Modifiers .abs and .xorsign must be specified together and .xorsign considers the sign\nbit of both inputs before applying .abs operation.
\n
If the result of min is NaN then the .xorsign and .abs modifiers will be ignored.
\n
Semantics
\n
\n
if (.xorsign) {\n xorsign = getSignBit(a) ^ getSignBit(b);\n if (.abs) {\n a = |a|;\n b = |b|;\n }\n}\nif (isNaN(a) && isNaN(b)) d = NaN;\nelse if (.NaN && (isNaN(a) || isNaN(b))) d = NaN;\nelse if (isNaN(a)) d = b;\nelse if (isNaN(b)) d = a;\nelse d = (a < b) ? a : b;\nif (.xorsign && !isNaN(d)) {\n setSignBit(d, xorsign);\n}\n
\n
\n
Notes
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
min.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
min.f64 supports subnormal numbers.
\n
min.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
If values of both inputs are 0.0, then +0.0 > -0.0.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
min.NaNintroduced in PTX ISA version 7.0.
\n
min.xorsign.abs introduced in PTX ISA version 7.2.
\n
Target ISA Notes
\n
min.f32 supported on all target architectures.
\n
min.f64 requires sm_13 or higher.
\n
min.NaNrequires sm_80 or higher.
\n
min.xorsign.abs requires sm_86 or higher.
\n
Examples
\n
\n
@p min.ftz.f32 z,z,x;\n min.f64 a,b,c;\n // fp32 min with .NaN\n min.NaN.f32 f0,f1,f2;\n // fp32 min with .xorsign.abs\n min.xorsign.abs.f32 Rd, Ra, Rb;\n
\n
\n\n
Half Precision Floating Point Instructions: min
\n\n\n
Find the minimum of two values.
\n
Syntax
\n
\n
min{.ftz}{.NaN}{.xorsign.abs}.f16 d, a, b;\nmin{.ftz}{.NaN}{.xorsign.abs}.f16x2 d, a, b;\nmin{.NaN}{.xorsign.abs}.bf16 d, a, b;\nmin{.NaN}{.xorsign.abs}.bf16x2 d, a, b;\n
\n
\n
Description
\n
Store the minimum of a and b in d.
\n
For .f16x2 and .bf16x2 instruction types, input vectors are formed with half-word values\nfrom source operands. Half-word operands are then processed in parallel to store .f16x2 or\n.bf16x2 result in destination.
\n
For .f16 instruction type, operands d and a have .f16 or .b16 type. For\n.f16x2 instruction type, operands d and a have .f16x2 or .b32 type. For\n.bf16 instruction type, operands d and a have .b16 type. For .bf16x2 instruction\ntype, operands d and a have .b32 type.
\n
If .NaN modifier is specified, then the result is canonical NaN if either of the inputs is\nNaN.
\n
If .abs modifier is specified, the magnitude of destination operand d is the minimum of\nabsolute values of both the input arguments.
\n
If .xorsign modifier is specified, the sign bit of destination d is equal to the XOR of the\nsign bits of both the inputs.
\n
Modifiers .abs and .xorsign must be specified together and .xorsign considers the sign\nbit of both inputs before applying .abs operation.
\n
If the result of min is NaN then the .xorsign and .abs modifiers will be ignored.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n if (.xorsign) {\n xorsign = getSignBit(a) ^ getSignBit(b);\n if (.abs) {\n a = |a|;\n b = |b|;\n }\n }\n if (isNaN(a) && isNaN(b)) d = NaN;\n if (.NaN && (isNaN(a) || isNaN(b))) d = NaN;\n else if (isNaN(a)) d = b;\n else if (isNaN(b)) d = a;\n else d = (a < b) ? a : b;\n if (.xorsign && !isNaN(d)) {\n setSignBit(d, xorsign);\n }\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n if (.xorsign) {\n xorsign = getSignBit(fA[i]) ^ getSignBit(fB[i]);\n if (.abs) {\n fA[i] = |fA[i]|;\n fB[i] = |fB[i]|;\n }\n }\n if (isNaN(fA[i]) && isNaN(fB[i])) d[i] = NaN;\n if (.NaN && (isNaN(fA[i]) || isNaN(fB[i]))) d[i] = NaN;\n else if (isNaN(fA[i])) d[i] = fB[i];\n else if (isNaN(fB[i])) d[i] = fA[i];\n else d[i] = (fA[i] < fB[i]) ? fA[i] : fB[i];\n if (.xorsign && !isNaN(d[i])) {\n setSignBit(d[i], xorsign);\n }\n }\n}\n
\n
\n
Notes
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nmin.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
If values of both inputs are 0.0, then +0.0 > -0.0.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
min.xorsign introduced in PTX ISA version 7.2.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
min.xorsign.abs support requires sm_86 or higher.
\n
Examples
\n
\n
min.ftz.f16 h0,h1,h2;\nmin.f16x2 b0,b1,b2;\n// SIMD fp16 min with .NaN\nmin.NaN.f16x2 b0,b1,b2;\nmin.bf16 h0, h1, h2;\n// SIMD bf16 min with NaN\nmin.NaN.bf16x2 b0, b1, b2;\n// scalar bf16 min with xorsign.abs\nmin.xorsign.abs.bf16 Rd, Ra, Rb\n
For .u16x2, .s16x2 instruction types, forms input vectors by half word values from source\noperands. Half-word operands are then processed in parallel to produce .u16x2, .s16x2 result\nin destination.
\n
Operands d, a and b have the same type as the instruction type. For instruction types\n.u16x2, .s16x2, operands d, a and b have type .b32.
\n
Semantics
\n
\n
if (type == u16x2 || type == s16x2) {\n iA[0] = a[0:15];\n iA[1] = a[16:31];\n iB[0] = b[0:15];\n iB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = (iA[i] < iB[i]) ? iA[i] : iB[i];\n }\n} else {\n d = (a < b) ? a : b; // Integer (signed and unsigned)\n}\n
\n
\n
Notes
\n
Signed and unsigned differ.
\n
\n
Saturation modifier:
\n
\n
min.relu.{s16x2,s32} clamps the result to 0 if negative.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
min.u16x2, min{.relu}.s16x2 and min.relu.s32 introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
min.u16x2, min{.relu}.s16x2 and min.relu.s32 require sm_90 or higher.
\n",
- "tooltip": "=====Floating Point Instructions: min\n\n\n\nFind the minimum of two values.\n\nSyntax\n\nmin{.ftz}{.NaN}{.xorsign.abs}.f32 d, a, b;\n\nmin.f64 d, a, b;\n\nDescription\n\nStore the minimum of a and b in d.\n\nIf .NaN modifier is specified, then the result is canonical NaN if either of the inputs is\n\nNaN.\n\nIf .abs modifier is specified, the magnitude of destination operand d is the minimum of\n\nabsolute values of both the input argument...\n\n=====Half Precision Floating Point Instructions: min\n\n\n\nFind the minimum of two values.\n\nSyntax\n\nmin{.ftz}{.NaN}{.xorsign.abs}.f16 d, a, b;\n\nmin{.ftz}{.NaN}{.xorsign.abs}.f16x2 d, a, b;\n\nmin{.NaN}{.xorsign.abs}.bf16 d, a, b;\n\nmin{.NaN}{.xorsign.abs}.bf16x2 d, a, b;\n\nDescription\n\nStore the minimum of a and b in d.\n\nFor .f16x2 and .bf16x2 instruction types, input vectors are formed with half-word values\n\nfrom source operands. Half-word o...\n\n=====Integer Arithmetic Instructions: min\n\n\n\nFind the minimum of two values.\n\nSyntax\n\nmin.atype d, a, b;\n\nmin{.relu}.btype d, a, b;\n\n.atype = { .u16, .u32, .u64,\n\n .u16x2, .s16, .s64 };\n\n.btype = { .s16x2, .s32 };\n\nDescription\n\nStore the minimum of a and b in d.\n\nFor .u16x2, .s16x2 instruction types, forms input vectors by half word values from source\n\noperands. Half-word operands are then processed in parallel to produce .u16x2, .s... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-min"
+ "html": "
Store the minimum of a and b in d.
\nFor more information, visit min(int) .",
+ "tooltip": "Find the minimum of two values.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-min"
};
- case "minnctapersm":
+ case "mma":
return {
- "html": "For more information, visit minnctapersm .
Performance-Tuning Directives: .minnctapersm
\n\n\n
Minimum number of CTAs per SM.
\n
Syntax
\n
\n
.minnctapersm ncta\n
\n
\n
Description
\n
Declare the minimum number of CTAs from the kernel\u2019s grid to be mapped to a single multiprocessor\n(SM).
\n
Notes
\n
Optimizations based on .minnctapersm need either .maxntid or .reqntid to be specified as\nwell.
\n
If the total number of threads on a single SM resulting from .minnctapersm and .maxntid /\n.reqntid exceed maximum number of threads supported by an SM then directive .minnctapersm\nwill be ignored.
\n
In PTX ISA version 2.1 or higher, a warning is generated if .minnctapersm is specified without\nspecifying either .maxntid or .reqntid.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0 as a replacement for .maxnctapersm.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.entry foo .maxntid 256 .minnctapersm 4 { ... }\n
\n
\n",
- "tooltip": "Minimum number of CTAs per SM.\n\nSyntax\n\n.minnctapersm ncta\n\nDescription\n\nDeclare the minimum number of CTAs from the kernel\u2019s grid to be mapped to a single multiprocessor\n\n(SM).\n\nNotes\n\nOptimizations based on .minnctapersm need either .maxntid or .reqntid to be specified as\n\nwell.\n\nIf the total number of threads on a single SM resulting from .minnctapersm and .maxntid /\n\n.reqntid exceed maximum number of threads supported by an SM then directive .minnctapersm\n\nwill be ignored.\n\nIn PTX ISA version 2.1 or higher, a warning is generated if .minnctapersm is specified without\n\nspecifying either .maxntid or .reqntid.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0 as a replacement for .maxnctapersm.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.entry foo .maxntid 256 .minnctapersm 4 { ... }\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#performance-tuning-directives-minnctapersm"
+ "html": "
Perform a MxNxK matrix multiply and accumulate operation, D=A*B+C, where the A matrix is\nMxK, the B matrix is KxN, and the C and D matrices are MxN.
Set a register variable with the value of a register variable or an immediate value. Take the\nnon-generic address of a variable in global, local, or shared state space.
\n
Syntax
\n
\n
mov.type d, a;\nmov.type d, sreg;\nmov.type d, avar; // get address of variable\nmov.type d, avar+imm; // get address of variable with offset\nmov.u32 d, fname; // get address of device function\nmov.u64 d, fname; // get address of device function\nmov.u32 d, kernel; // get address of entry function\nmov.u64 d, kernel; // get address of entry function\n\n.type = { .pred,\n .b16, .b32, .b64,\n .u16, .u32, .u64,\n .s16, .s32, .s64,\n .f32, .f64 };\n
\n
\n
Description
\n
Write register d with the value of a.
\n
Operand a may be a register, special register, variable with optional offset in an addressable\nmemory space, or function name.
\n
For variables declared in .const, .global, .local, and .shared state spaces, mov\nplaces the non-generic address of the variable (i.e., the address of the variable in its state\nspace) into the destination register. The generic address of a variable in const, global,\nlocal, or shared state space may be generated by first taking the address within the state\nspace with mov and then converting it to a generic address using the cvta instruction;\nalternately, the generic address of a variable declared in const, global, local, or\nshared state space may be taken directly using the cvta instruction.
\n
Note that if the address of a device function parameter is moved to a register, the parameter will\nbe copied onto the stack and the address will be in the local state space.
\n
Semantics
\n
\n
d = a;\nd = sreg;\nd = &avar; // address is non-generic; i.e., within the variable's declared state space\nd = &avar+imm;\n
\n
\n
Notes
\n
\n
Although only predicate and bit-size types are required, we include the arithmetic types for the\nprogrammer\u2019s convenience: their use enhances program readability and allows additional type\nchecking.
\n
When moving address of a kernel or a device function, only .u32 or .u64 instruction types\nare allowed. However, if a signed type is used, it is not treated as a compilation error. The\ncompiler issues a warning in this case.
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Taking the address of kernel entry functions requires PTX ISA version 3.1 or later. Kernel function\naddresses should only be used in the context of CUDA Dynamic Parallelism system calls. See the CUDA\nDynamic Parallelism Programming Guide for details.
\n
Target ISA Notes
\n
mov.f64 requires sm_13 or higher.
\n
Taking the address of kernel entry functions requires sm_35 or higher.
\n
Examples
\n
\n
mov.f32 d,a;\nmov.u16 u,v;\nmov.f32 k,0.1;\nmov.u32 ptr, A; // move address of A into ptr\nmov.u32 ptr, A[5]; // move address of A[5] into ptr\nmov.u32 ptr, A+20; // move address with offset into ptr\nmov.u32 addr, myFunc; // get address of device function 'myFunc'\nmov.u64 kptr, main; // get address of entry function 'main'\n
\n
\n\n
Data Movement and Conversion Instructions: mov
\n\n\n
Move vector-to-scalar (pack) or scalar-to-vector (unpack).
Write scalar register d with the packed value of vector register a, or write vector register\nd with the unpacked values from scalar register a.
\n
When destination operand d is a vector register, the sink symbol '_' may be used for one or\nmore elements provided that at least one element is a scalar register.
\n
For bit-size types, mov may be used to pack vector elements into a scalar register or unpack\nsub-fields of a scalar register into a vector. Both the overall size of the vector and the size of\nthe scalar must match the size of the instruction type.
\n
Semantics
\n
\n
// pack two 8-bit elements into .b16\nd = a.x | (a.y << 8)\n// pack four 8-bit elements into .b32\nd = a.x | (a.y << 8) | (a.z << 16) | (a.w << 24)\n// pack two 16-bit elements into .b32\nd = a.x | (a.y << 16)\n// pack four 16-bit elements into .b64\nd = a.x | (a.y << 16) | (a.z << 32) | (a.w << 48)\n// pack two 32-bit elements into .b64\nd = a.x | (a.y << 32)\n// pack four 32-bit elements into .b128\nd = a.x | (a.y << 32) | (a.z << 64) | (a.w << 96)\n// pack two 64-bit elements into .b128\nd = a.x | (a.y << 64)\n\n// unpack 8-bit elements from .b16\n{ d.x, d.y } = { a[0..7], a[8..15] }\n// unpack 8-bit elements from .b32\n{ d.x, d.y, d.z, d.w }\n { a[0..7], a[8..15], a[16..23], a[24..31] }\n\n// unpack 16-bit elements from .b32\n{ d.x, d.y } = { a[0..15], a[16..31] }\n// unpack 16-bit elements from .b64\n{ d.x, d.y, d.z, d.w } =\n { a[0..15], a[16..31], a[32..47], a[48..63] }\n\n// unpack 32-bit elements from .b64\n{ d.x, d.y } = { a[0..31], a[32..63] }\n\n// unpack 32-bit elements from .b128\n{ d.x, d.y, d.z, d.w } =\n { a[0..31], a[32..63], a[64..95], a[96..127] }\n// unpack 64-bit elements from .b128\n{ d.x, d.y } = { a[0..63], a[64..127] }\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Support for .b128 type introduced in PTX ISA version 8.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Support for .b128 type requires sm_70 or higher.
\n
Examples
\n
\n
mov.b32 %r1,{a,b}; // a,b have type .u16\nmov.b64 {lo,hi}, %x; // %x is a double; lo,hi are .u32\nmov.b32 %r1,{x,y,z,w}; // x,y,z,w have type .b8\nmov.b32 {r,g,b,a},%r1; // r,g,b,a have type .u8\nmov.b64 {%r1, _}, %x; // %x is.b64, %r1 is .b32\nmov.b128 {%b1, %b2}, %y; // %y is.b128, %b1 and % b2 are .b64\nmov.b128 %y, {%b1, %b2}; // %y is.b128, %b1 and % b2 are .b64\n
\n
\n",
- "tooltip": "=====Data Movement and Conversion Instructions: mov\n\n\n\nSet a register variable with the value of a register variable or an immediate value. Take the\n\nnon-generic address of a variable in global, local, or shared state space.\n\nSyntax\n\nmov.type d, a;\n\nmov.type d, sreg;\n\nmov.type d, avar; // get address of variable\n\nmov.type d, avar+imm; // get address of variable with offset\n\nmov.u32 d, fname; // get address of device function\n\nmov.u64 d, f...\n\n=====Data Movement and Conversion Instructions: mov\n\n\n\nMove vector-to-scalar (pack) or scalar-to-vector (unpack).\n\nSyntax\n\nmov.type d, a;\n\n.type = { .b16, .b32, .b64, .b128 };\n\nDescription\n\nWrite scalar register d with the packed value of vector register a, or write vector register\n\nd with the unpacked values from scalar register a.\n\nWhen destination operand d is a vector register, the sink symbol '_' may be used for one or\n\nmore elements provided that at le... ...",
+ "html": "
Write register d with the value of a.
\nFor more information, visit mov .",
+ "tooltip": "Write registerdwith the value ofa.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-mov"
};
+ case "movmatrix":
+ return {
+ "html": "
Move a row-major matrix across all threads in a warp, reading elements from source a, and\nwriting the transposed elements to destination d.
\nFor more information, visit movmatrix .",
+ "tooltip": "Transpose a matrix in registers across the warp.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-movmatrix"
+ };
+
case "mul":
return {
- "html": "For more information, visit mul(fp) , mul(fp16) , mul(int) .
Floating Point Instructions: mul
\n\n\n
Multiply two values.
\n
Syntax
\n
\n
mul{.rnd}{.ftz}{.sat}.f32 d, a, b;\nmul{.rnd}.f64 d, a, b;\n\n.rnd = { .rn, .rz, .rm, .rp };\n
\n
\n
Description
\n
Compute the product of two values.
\n
Semantics
\n
\n
d = a * b;\n
\n
\n
Notes
\n
For floating-point multiplication, all operands must be the same size.
\n
Rounding modifiers:
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
The default value of rounding modifier is .rn. Note that a mul instruction with an explicit\nrounding modifier is treated conservatively by the code optimizer. A mul instruction with no\nrounding modifier defaults to round-to-nearest-even and may be optimized aggressively by the code\noptimizer. In particular, mul/add and mul/sub sequences with no rounding modifiers may be\noptimized to use fused-multiply-add instructions on the target device.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
mul.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
\n
sm_1x
\n
\n
mul.f64 supports subnormal numbers.
\n
mul.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
Saturation modifier:
\n
mul.sat.f32 clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
mul.f32 supported on all target architectures.
\n
mul.f64 requires sm_13 or higher.
\n
Rounding modifiers have the following target requirements:
\n
\n
\n.rn, .rz\n
\n
\n
available for all targets
\n
\n
\n.rm, .rp\n
\n
\n
for mul.f64, requires sm_13 or higher.
\n
for mul.f32, requires sm_20 or higher.
\n
\n
\n
Examples
\n
\n
mul.ftz.f32 circumf,radius,pi // a single-precision multiply\n
\n
\n\n
Half Precision Floating Point Instructions: mul
\n\n\n
Multiply two values.
\n
Syntax
\n
\n
mul{.rnd}{.ftz}{.sat}.f16 d, a, b;\nmul{.rnd}{.ftz}{.sat}.f16x2 d, a, b;\n\nmul{.rnd}.bf16 d, a, b;\nmul{.rnd}.bf16x2 d, a, b;\n\n.rnd = { .rn };\n
\n
\n
Description
\n
Performs multiplication and writes the resulting value into a destination register.
\n
For .f16x2 and .bf16x2 instruction type, forms input vectors by half word values from source\noperands. Half-word operands are then multiplied in parallel to produce .f16x2 or .bf16x2\nresult in destination.
\n
For .f16 instruction type, operands d, a and b have .f16 or .b16 type. For\n.f16x2 instruction type, operands d, a and b have .b32 type. For .bf16\ninstruction type, operands d, a, b have .b16 type. For .bf16x2 instruction type,\noperands d, a, b have .b32 type.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n d = a * b;\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = fA[i] * fB[i];\n }\n}\n
\n
\n
Notes
\n
Rounding modifiers:
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
\n
The default value of rounding modifier is .rn. Note that a mul instruction with an explicit\nrounding modifier is treated conservatively by the code optimizer. A mul instruction with no\nrounding modifier defaults to round-to-nearest-even and may be optimized aggressively by the code\noptimizer. In particular, mul/add and mul/sub sequences with no rounding modifiers may\nbe optimized to use fused-multiply-add instructions on the target device.
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nmul.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
Saturation modifier:
\n
\n
mul.sat.{f16,f16x2} clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.2.
\n
mul{.rnd}.bf16 and mul{.rnd}.bf16x2 introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_53 or higher.
\n
mul{.rnd}.bf16 and mul{.rnd}.bf16x2 requires sm_90 or higher.
\n
Examples
\n
\n
// scalar f16 multiplications\nmul.f16 d0, a0, b0;\nmul.rn.f16 d1, a1, b1;\nmul.bf16 bd0, ba0, bb0;\nmul.rn.bf16 bd1, ba1, bb1;\n\n// SIMD f16 multiplication\ncvt.rn.f16.f32 h0, f0;\ncvt.rn.f16.f32 h1, f1;\ncvt.rn.f16.f32 h2, f2;\ncvt.rn.f16.f32 h3, f3;\nmov.b32 p1, {h0, h1}; // pack two f16 to 32bit f16x2\nmov.b32 p2, {h2, h3}; // pack two f16 to 32bit f16x2\nmul.f16x2 p3, p1, p2; // SIMD f16x2 multiplication\n\n// SIMD bf16 multiplication\ncvt.rn.bf16x2.f32 p4, f4, f5; // Convert two f32 into packed bf16x2\ncvt.rn.bf16x2.f32 p5, f6, f7; // Convert two f32 into packed bf16x2\nmul.bf16x2 p6, p4, p5; // SIMD bf16x2 multiplication\n\n// SIMD fp16 multiplication\nld.global.b32 f0, [addr]; // load 32 bit which hold packed f16x2\nld.global.b32 f1, [addr + 4]; // load 32 bit which hold packed f16x2\nmul.f16x2 f2, f0, f1; // SIMD f16x2 multiplication\n\n// SIMD bf16 multiplication\nld.global.b32 f3, [addr + 8]; // load 32 bit which hold packed bf16x2\nld.global.b32 f4, [addr + 12]; // load 32 bit which hold packed bf16x2\nmul.bf16x2 f5, f3, f4; // SIMD bf16x2 multiplication\n
t = a * b;\nn = bitwidth of type;\nd = t; // for .wide\nd = t<2n-1..n>; // for .hi variant\nd = t<n-1..0>; // for .lo variant\n
\n
\n
Notes
\n
The type of the operation represents the types of the a and b operands. If .hi or\n.lo is specified, then d is the same size as a and b, and either the upper or lower\nhalf of the result is written to the destination register. If .wide is specified, then d is\ntwice as wide as a and b to receive the full result of the multiplication.
\n
The .wide suffix is supported only for 16- and 32-bit integer types.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mul.wide.s16 fa,fxs,fys; // 16*16 bits yields 32 bits\nmul.lo.s16 fa,fxs,fys; // 16*16 bits, save only the low 16 bits\nmul.wide.s32 z,x,y; // 32*32 bits, creates 64 bit result\n
\n
\n",
- "tooltip": "=====Floating Point Instructions: mul\n\n\n\nMultiply two values.\n\nSyntax\n\nmul{.rnd}{.ftz}{.sat}.f32 d, a, b;\n\nmul{.rnd}.f64 d, a, b;\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nCompute the product of two values.\n\nSemantics\n\nd = a * b;\n\nNotes\n\nFor floating-point multiplication, all operands must be the same size.\n\nRounding modifiers:\n\n.rn\n\nmantissa LSB rounds to nearest even\n\n.rz\n\nmantissa LSB rounds towards zero\n\n.rm\n\nmantissa LSB rounds tow...\n\n=====Half Precision Floating Point Instructions: mul\n\n\n\nMultiply two values.\n\nSyntax\n\nmul{.rnd}{.ftz}{.sat}.f16 d, a, b;\n\nmul{.rnd}{.ftz}{.sat}.f16x2 d, a, b;\n\nmul{.rnd}.bf16 d, a, b;\n\nmul{.rnd}.bf16x2 d, a, b;\n\n.rnd = { .rn };\n\nDescription\n\nPerforms multiplication and writes the resulting value into a destination register.\n\nFor .f16x2 and .bf16x2 instruction type, forms input vectors by half word values from source\n\noperands. Half-word operands are then mul...\n\n=====Integer Arithmetic Instructions: mul\n\n\n\nMultiply two values.\n\nSyntax\n\nmul.mode.type d, a, b;\n\n.mode = { .hi, .lo, .wide };\n\n.type = { .u16, .u32, .u64,\n\n .s16, .s32, .s64 };\n\nDescription\n\nCompute the product of two values.\n\nSemantics\n\nt = a * b;\n\nn = bitwidth of type;\n\nd = t; // for .wide\n\nd = t<2n-1..n>; // for .hi variant\n\nd = t; // for .lo variant\n\nNotes\n\nThe type of the operation represents the types of the a and ... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-mul"
+ "html": "
Compute the product of two values.
\nFor more information, visit mul(int) .",
+ "tooltip": "Multiply two values.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-mul"
};
case "mul24":
return {
- "html": "For more information, visit mul24(int) .
Compute the product of two 24-bit integer values held in 32-bit source registers, and return either\nthe high or low 32-bits of the 48-bit result.
\n
Semantics
\n
\n
t = a * b;\nd = t<47..16>; // for .hi variant\nd = t<31..0>; // for .lo variant\n
\n
\n
Notes
\n
Integer multiplication yields a result that is twice the size of the input operands, i.e., 48-bits.
\n
mul24.hi performs a 24x24-bit multiply and returns the high 32 bits of the 48-bit result.
\n
mul24.lo performs a 24x24-bit multiply and returns the low 32 bits of the 48-bit result.
\n
All operands are of the same type and size.
\n
mul24.hi may be less efficient on machines without hardware support for 24-bit multiply.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mul24.lo.s32 d,a,b; // low 32-bits of 24x24-bit signed multiply.\n
\n
\n",
- "tooltip": "Multiply two 24-bit integer values.\n\nSyntax\n\nmul24.mode.type d, a, b;\n\n.mode = { .hi, .lo };\n\n.type = { .u32, .s32 };\n\nDescription\n\nCompute the product of two 24-bit integer values held in 32-bit source registers, and return either\n\nthe high or low 32-bits of the 48-bit result.\n\nSemantics\n\nt = a * b;\n\nd = t<47..16>; // for .hi variant\n\nd = t<31..0>; // for .lo variant\n\nNotes\n\nInteger multiplication yields a result that is twice the size of the input operands, i.e., 48-bits.\n\nmul24.hi performs a 24x24-bit multiply and returns the high 32 bits of the 48-bit result.\n\nmul24.lo performs a 24x24-bit multiply and returns the low 32 bits of the 48-bit result.\n\nAll operands are of the same type and size.\n\nmul24.hi may be less efficient on machines without hardware support for 24-bit multiply.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmul24.lo.s32 d,a,b; // low 32-bits of 24x24-bit signed multiply.\n\n ...",
+ "html": "
Compute the product of two 24-bit integer values held in 32-bit source registers, and return either\nthe high or low 32-bits of the 48-bit result.
\nFor more information, visit mul24(int) .",
+ "tooltip": "Multiply two 24-bit integer values.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-mul24"
};
case "multimem":
return {
- "html": "For more information, visit multimem.ld_reduce , multimem.red , multimem.st .
Data Movement and Conversion Instructions: multimem.ld_reduce, multimem.st, multimem.red
\n\n\n
Multimem addresses can only be accessed only by multimem.* operations. Accessing a multimem address\nwith ld, st or any other memory operations results in undefined behavior.
\n
Refer to CUDA programming guide for creation and management of the multimem addresses.
\n
multimem.ld_reduce, multimem.st, multimem.red
\n
Perform memory operations on the multimem address.
Instruction multimem.ld_reduce performs the following operations:
\n
\n
load operation on the multimem address a, which involves loading of data from all of the\nmultiple memory locations pointed to by the multimem address a,
\n
reduction operation specified by .op on the multiple data loaded from the multimem address\na.
\n
\n
The result of the reduction operation in returned in register d.
\n
Instruction multimem.st performs a store operation of the input operand b to all the memory\nlocations pointed to by the multimem address a.
\n
Instruction multimem.red performs a reduction operation on all the memory locations pointed to\nby the multimem address a, with operand b.
\n
Instruction multimem.ld_reduce performs reduction on the values loaded from all the memory\nlocations that the multimem address points to. In contrast, the multimem.red perform reduction\non all the memory locations that the multimem address points to.
\n
Address operand a must be a multimem address. Otherwise, the behavior is undefined. Supported\naddressing modes for operand a and alignment requirements are described in Addresses as Operands.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by a does not fall within the address window of .global state\nspace then the behavior is undefined.
\n
For floating-point type multi- operations, the size of the specified type along with .vec must\nequal either 32-bits or 64-bits or 128-bits. No other combinations of .vec and type are\nallowed. Type .f64 cannot be used with .vec qualifier.
\n
The following table describes the valid combinations of .op and base type:
\n
\n
\n
\n
\n
\n\n
\n
op
\n
Base type
\n
\n\n\n
\n
.add
\n
\n
\n
\n.u32, .u64, .s32\n
\n
\n.f16, .f16x2, .bf16, .bf16x2\n
\n
\n.f32, .f64\n
\n
\n
\n
\n
\n
.and, .or, .xor
\n
.b32, .b64
\n
\n
\n
.min, .max
\n
\n
\n
\n.u32, .s32, .u64, .s64\n
\n
\n.f16, .f16x2, .bf16, .bf16x2\n
\n
\n
\n
\n\n
\n
For multimem.ld_reduce, the default precision of the intermediate accumulation is same as the\nspecified type. Optionally for .f16, .f16x2, .bf16 and .bf16x2 types, .acc::f32\ncan be specified to change the precision of the intermediate accumulation to .f32.
\n
Optional qualifiers .ldsem, .stsem and .redsem specify the memory synchronizing effect\nof the multimem.ld_reduce, multimem.st and multimem.red respectively, as described in\nMemory Consistency Model. If explicit semantics qualifiers\nare not specified, then multimem.ld_reduce and multimem.st default to .weak and\nmultimem.red defaults to .relaxed.
\n
The optional .scope qualifier specifies the set of threads that can directly observe the memory\nsynchronizing effect of this operation, as described in Memory Consistency Model. If the .scope qualifier is not specified for\nmultimem.red then .sys scope is assumed by default.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.1.
\n
Support for .acc::f32 qualifier introduced in PTX ISA version 8.2.
Data Movement and Conversion Instructions: multimem.ld_reduce, multimem.st, multimem.red
\n\n\n
Multimem addresses can only be accessed only by multimem.* operations. Accessing a multimem address\nwith ld, st or any other memory operations results in undefined behavior.
\n
Refer to CUDA programming guide for creation and management of the multimem addresses.
\n
multimem.ld_reduce, multimem.st, multimem.red
\n
Perform memory operations on the multimem address.
Instruction multimem.ld_reduce performs the following operations:
\n
\n
load operation on the multimem address a, which involves loading of data from all of the\nmultiple memory locations pointed to by the multimem address a,
\n
reduction operation specified by .op on the multiple data loaded from the multimem address\na.
\n
\n
The result of the reduction operation in returned in register d.
\n
Instruction multimem.st performs a store operation of the input operand b to all the memory\nlocations pointed to by the multimem address a.
\n
Instruction multimem.red performs a reduction operation on all the memory locations pointed to\nby the multimem address a, with operand b.
\n
Instruction multimem.ld_reduce performs reduction on the values loaded from all the memory\nlocations that the multimem address points to. In contrast, the multimem.red perform reduction\non all the memory locations that the multimem address points to.
\n
Address operand a must be a multimem address. Otherwise, the behavior is undefined. Supported\naddressing modes for operand a and alignment requirements are described in Addresses as Operands.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by a does not fall within the address window of .global state\nspace then the behavior is undefined.
\n
For floating-point type multi- operations, the size of the specified type along with .vec must\nequal either 32-bits or 64-bits or 128-bits. No other combinations of .vec and type are\nallowed. Type .f64 cannot be used with .vec qualifier.
\n
The following table describes the valid combinations of .op and base type:
\n
\n
\n
\n
\n
\n\n
\n
op
\n
Base type
\n
\n\n\n
\n
.add
\n
\n
\n
\n.u32, .u64, .s32\n
\n
\n.f16, .f16x2, .bf16, .bf16x2\n
\n
\n.f32, .f64\n
\n
\n
\n
\n
\n
.and, .or, .xor
\n
.b32, .b64
\n
\n
\n
.min, .max
\n
\n
\n
\n.u32, .s32, .u64, .s64\n
\n
\n.f16, .f16x2, .bf16, .bf16x2\n
\n
\n
\n
\n\n
\n
For multimem.ld_reduce, the default precision of the intermediate accumulation is same as the\nspecified type. Optionally for .f16, .f16x2, .bf16 and .bf16x2 types, .acc::f32\ncan be specified to change the precision of the intermediate accumulation to .f32.
\n
Optional qualifiers .ldsem, .stsem and .redsem specify the memory synchronizing effect\nof the multimem.ld_reduce, multimem.st and multimem.red respectively, as described in\nMemory Consistency Model. If explicit semantics qualifiers\nare not specified, then multimem.ld_reduce and multimem.st default to .weak and\nmultimem.red defaults to .relaxed.
\n
The optional .scope qualifier specifies the set of threads that can directly observe the memory\nsynchronizing effect of this operation, as described in Memory Consistency Model. If the .scope qualifier is not specified for\nmultimem.red then .sys scope is assumed by default.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.1.
\n
Support for .acc::f32 qualifier introduced in PTX ISA version 8.2.
Data Movement and Conversion Instructions: multimem.ld_reduce, multimem.st, multimem.red
\n\n\n
Multimem addresses can only be accessed only by multimem.* operations. Accessing a multimem address\nwith ld, st or any other memory operations results in undefined behavior.
\n
Refer to CUDA programming guide for creation and management of the multimem addresses.
\n
multimem.ld_reduce, multimem.st, multimem.red
\n
Perform memory operations on the multimem address.
Instruction multimem.ld_reduce performs the following operations:
\n
\n
load operation on the multimem address a, which involves loading of data from all of the\nmultiple memory locations pointed to by the multimem address a,
\n
reduction operation specified by .op on the multiple data loaded from the multimem address\na.
\n
\n
The result of the reduction operation in returned in register d.
\n
Instruction multimem.st performs a store operation of the input operand b to all the memory\nlocations pointed to by the multimem address a.
\n
Instruction multimem.red performs a reduction operation on all the memory locations pointed to\nby the multimem address a, with operand b.
\n
Instruction multimem.ld_reduce performs reduction on the values loaded from all the memory\nlocations that the multimem address points to. In contrast, the multimem.red perform reduction\non all the memory locations that the multimem address points to.
\n
Address operand a must be a multimem address. Otherwise, the behavior is undefined. Supported\naddressing modes for operand a and alignment requirements are described in Addresses as Operands.
\n
If no state space is specified then Generic Addressing is\nused. If the address specified by a does not fall within the address window of .global state\nspace then the behavior is undefined.
\n
For floating-point type multi- operations, the size of the specified type along with .vec must\nequal either 32-bits or 64-bits or 128-bits. No other combinations of .vec and type are\nallowed. Type .f64 cannot be used with .vec qualifier.
\n
The following table describes the valid combinations of .op and base type:
\n
\n
\n
\n
\n
\n\n
\n
op
\n
Base type
\n
\n\n\n
\n
.add
\n
\n
\n
\n.u32, .u64, .s32\n
\n
\n.f16, .f16x2, .bf16, .bf16x2\n
\n
\n.f32, .f64\n
\n
\n
\n
\n
\n
.and, .or, .xor
\n
.b32, .b64
\n
\n
\n
.min, .max
\n
\n
\n
\n.u32, .s32, .u64, .s64\n
\n
\n.f16, .f16x2, .bf16, .bf16x2\n
\n
\n
\n
\n\n
\n
For multimem.ld_reduce, the default precision of the intermediate accumulation is same as the\nspecified type. Optionally for .f16, .f16x2, .bf16 and .bf16x2 types, .acc::f32\ncan be specified to change the precision of the intermediate accumulation to .f32.
\n
Optional qualifiers .ldsem, .stsem and .redsem specify the memory synchronizing effect\nof the multimem.ld_reduce, multimem.st and multimem.red respectively, as described in\nMemory Consistency Model. If explicit semantics qualifiers\nare not specified, then multimem.ld_reduce and multimem.st default to .weak and\nmultimem.red defaults to .relaxed.
\n
The optional .scope qualifier specifies the set of threads that can directly observe the memory\nsynchronizing effect of this operation, as described in Memory Consistency Model. If the .scope qualifier is not specified for\nmultimem.red then .sys scope is assumed by default.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.1.
\n
Support for .acc::f32 qualifier introduced in PTX ISA version 8.2.
\n",
- "tooltip": "locations which the multimem address points to.\n\nMultimem addresses can only be accessed only by multimem.* operations. Accessing a multimem address\n\nwith ld, st or any other memory operations results in undefined behavior.\n\nRefer to CUDA programming guide for creation and management of the multimem addresses.\n\nmultimem.ld_reduce, multimem.st, multimem.red\n\nPerform memory operations on the multimem address.\n\nSyntax\n\n// Integer type:\n\nmultimem.ld_reduce{.ldsem}{.scope}{.ss}.op.type d, [a];\n\nmultimem.st{.stsem}{.scope}{.ss}.type [a], b;\n\nmultimem.red{.redsem}{.scope}{.ss}.op.type [a], b;\n\n.ss = { .global }\n\n.ldsem = { .weak, .relaxed, .acquire }\n\n.stsem = { .weak, .relaxed, .release }\n\n.redsem = { .relaxed, .release }\n\n.scope = { .cta, .cluster, .gpu, .sys }\n\n.op = { .min, .max, .add, .and, .or, .xor }\n\n.type = { .b32, .b64, .u32, .u64, .s32, .s64 }\n\n// Floating point type:\n\nmultimem.ld_reduce{.ldsem}{.scope}{.ss}.op{.acc_prec}{.vec}.type d, [a];\n\nmultimem.st{.stsem}{.scope}{.ss}{.vec}.type [a], b;\n\nmultimem.red{.redsem}{.scope}{.ss}.redop{.vec}.type [a], b;\n\n.ss = { .global }\n\n.ldsem = { .weak, .relaxed, .acquire }\n\n.stsem = { .weak, .relaxed, .release }\n\n.redsem = { .relaxed, .release }\n\n.scope = { .cta, .cluster, .gpu, .sys }\n\n.op = { .min, .max, .add }\n\n.redop = { .add }\n\n.acc_prec = { .acc::f32 }\n\n.vec = { .v2, .v4, .v8 }\n\n.type= { .f16, .f16x2, .bf16, .bf16x2, .f32, .f64 }\n\nDescription\n\nInstruction multimem.ld_reduce performs the following operations:\n\nload operation on the multimem address a, which involves loading of data from all of the\n\nmultiple memory locations pointed to by the multimem address a,\n\nreduction operation specified by .op on the multiple data loaded from the multimem address\n\na.\n\nThe result of the reduction operation in returned in register d.\n\nInstruction multimem.st performs a store operation of the input operand b to all the memory\n\nlocations pointed to by the multimem address a.\n\nInstruction multimem.red performs a reduction operation on all the memory locations pointed to\n\nby the multimem address a, with operand b.\n\nInstruction multimem.ld_reduce performs reduction on the values loaded from all the memory\n\nlocations that the multimem address points to. In contrast, the multimem.red perform reduction\n\non all the memory locations that the multimem address points to.\n\nAddress operand a must be a multimem address. Otherwise, the behavior is undefined. Supported\n\naddressing modes for operand a and alignment requirements are described in Addresses as Operands.\n\nIf no state space is specified then Generic Addressing is\n\nused. If the address specified by a does not fall within the address window of .global state\n\nspace then the behavior is undefined.\n\nFor floating-point type multi- operations, the size of the specified type along with .vec must\n\nequal either 32-bits or 64-bits or 128-bits. No other combinations of .vec and type are\n\nallowed. Type .f64 cannot be used with .vec qualifier.\n\nThe following table describes the valid combinations of .op and base type:\n\n\n\nop\n\nBase type\n\n\n\n.add\n\n.u32, .u64, .s32\n\n.f16, .f16x2, .bf16, .bf16x2\n\n.f32, .f64\n\n\n\n.and, .or, .xor\n\n.b32, .b64\n\n.min, .max\n\n.u32, .s32, .u64, .s64\n\n.f16, .f16x2, .bf16, .bf16x2\n\n\n\nFor multimem.ld_reduce, the default precision of the intermediate accumulation is same as the\n\nspecified type. Optionally for .f16, .f16x2, .bf16 and .bf16x2 types, .acc::f32\n\ncan be specified to change the precision of the intermediate accumulation to .f32.\n\nOptional qualifiers .ldsem, .stsem and .redsem specify the memory synchronizing effect\n\nof the multimem.ld_reduce, multimem.st and multimem.red respectively, as described in\n\nMemory Consistency Model. If explicit semantics qualifiers\n\nare not specified, then multimem.ld_reduce and multimem.st default to .weak and\n\nmultimem.red defaults to .relaxed.\n\nThe optional .scope qualifier specifies the set of threads that can directly observe the memory\n\nsynchronizi ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-multimem-ld-reduce-multimem-st-multimem-red"
+ "html": "
Instruction multimem.ld_reduce performs the following operations:
\nFor more information, visit multimem.ld_reduce .",
+ "tooltip": "Perform memory operations on the multimem address.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-multimem"
};
case "nanosleep":
return {
- "html": "For more information, visit nanosleep .
Miscellaneous Instructions: nanosleep
\n\n\n
Suspend the thread for an approximate delay given in nanoseconds.
\n
Syntax
\n
\n
nanosleep.u32 t;\n
\n
\n
Description
\n
Suspends the thread for a sleep duration approximately close to the delay t, specified in\nnanoseconds. t may be a register or an immediate value.
\n
The sleep duration is approximated, but guaranteed to be in the interval [0,2*t]. The maximum\nsleep duration is 1 millisecond. The implementation may reduce the sleep duration for individual\nthreads within a warp such that all sleeping threads in the warp wake up together.
\n",
- "tooltip": "Suspend the thread for an approximate delay given in nanoseconds.\n\nSyntax\n\nnanosleep.u32 t;\n\nDescription\n\nSuspends the thread for a sleep duration approximately close to the delay t, specified in\n\nnanoseconds. t may be a register or an immediate value.\n\nThe sleep duration is approximated, but guaranteed to be in the interval [0, 2*t]. The maximum\n\nsleep duration is 1 millisecond. The implementation may reduce the sleep duration for individual\n\nthreads within a warp such that all sleeping threads in the warp wake up together.\n\nPTX ISA Notes\n\nnanosleep introduced in PTX ISA 6.3.\n\nTarget ISA Notes\n\nnanosleep requires sm_70 or higher.\n\nExamples\n\n.reg .b32 r;\n\n.reg .pred p;\n\nnanosleep.u32 r;\n\nnanosleep.u32 42;\n\n@p nanosleep.u32 r;\n\n ...",
+ "html": "
Suspends the thread for a sleep duration approximately close to the delay t, specified in\nnanoseconds. t may be a register or an immediate value.
\nFor more information, visit nanosleep .",
+ "tooltip": "Suspend the thread for an approximate delay given in nanoseconds.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#miscellaneous-instructions-nanosleep"
};
- case "nclusterid":
- return {
- "html": "For more information, visit nclusterid .
A predefined, read-only special register initialized with the number of clusters in each grid\ndimension.
\n
The %nclusterid special register contains a 3D grid shape vector that holds the grid dimensions\nin terms of clusters. The fourth element is unused and always returns zero.
\n
Refer to the Cuda Programming Guide for details on the maximum values of %nclusterid.{x,y,z}.
\n",
- "tooltip": "Number of cluster identifiers per grid.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %nclusterid;\n\n.sreg .u32 %nclusterid.x, %nclusterid.y, %nclusterid.z;\n\nDescription\n\nA predefined, read-only special register initialized with the number of clusters in each grid\n\ndimension.\n\nThe %nclusterid special register contains a 3D grid shape vector that holds the grid dimensions\n\nin terms of clusters. The fourth element is unused and always returns zero.\n\nRefer to the Cuda Programming Guide for details on the maximum values of %nclusterid.{x,y,z}.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.reg .b32 %r<2>;\n\n.reg .v4 .b32 %rx;\n\nmov.u32 %r0, %nclusterid.x;\n\nmov.u32 %r1, %nclusterid.z;\n\nmov.v4.u32 %rx, %nclusterid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-nclusterid"
- };
-
- case "nctaid":
- return {
- "html": "For more information, visit nctaid .
A predefined, read-only special register initialized with the number of CTAs in each grid\ndimension. The %nctaid special register contains a 3D grid shape vector, with each element\nhaving a value of at least 1. The fourth element is unused and always returns zero.
\n
Maximum values of %nctaid.{x,y,z} are as follows:
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
.target architecture
\n
%nctaid.x
\n
%nctaid.y
\n
%nctaid.z
\n
\n\n\n
\n
sm_1x, sm_20
\n
65535
\n
65535
\n
65535
\n
\n
\n
sm_3x, sm_5x, sm_6x, sm_7x,\nsm_8x, sm_9x
\n
231 -1
\n
65535
\n
65535
\n
\n\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0 with type .v4.u16.
\n
Redefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n%nctaid.
\n",
- "tooltip": "Number of CTA ids per grid.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %nctaid // Grid shape vector\n\n.sreg .u32 %nctaid.x,%nctaid.y,%nctaid.z; // Grid dimensions\n\nDescription\n\nA predefined, read-only special register initialized with the number of CTAs in each grid\n\ndimension. The %nctaid special register contains a 3D grid shape vector, with each element\n\nhaving a value of at least 1. The fourth element is unused and always returns zero.\n\nMaximum values of %nctaid.{x,y,z} are as follows:\n\n\n\n\n\n.target architecture\n\n%nctaid.x\n\n%nctaid.y\n\n%nctaid.z\n\n\n\nsm_1x, sm_20\n\n65535\n\n65535\n\n65535\n\nsm_3x, sm_5x, sm_6x, sm_7x,\n\nsm_8x, sm_9x\n\n231 -1\n\n65535\n\n65535\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0 with type .v4.u16.\n\nRedefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\n\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n\n%nctaid.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.u32 %r0,%nctaid.x;\n\nmov.u16 %rh,%nctaid.x; // legacy code\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-nctaid"
- };
-
case "neg":
return {
- "html": "For more information, visit neg(fp) , neg(fp16) , neg(int) .
Floating Point Instructions: neg
\n\n\n
Arithmetic negate.
\n
Syntax
\n
\n
neg{.ftz}.f32 d, a;\nneg.f64 d, a;\n
\n
\n
Description
\n
Negate the sign of a and store the result in d.
\n
Semantics
\n
\n
d = -a;\n
\n
\n
Notes
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
neg.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
neg.f64 supports subnormal numbers.
\n
neg.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
NaN inputs yield an unspecified NaN. Future implementations may comply with the IEEE 754\nstandard by preserving payload and modifying only the sign bit.
For .f16x2 and .bf16x2 instruction type, forms input vector by extracting half word values\nfrom the source operand. Half-word operands are then negated in parallel to produce .f16x2 or\n.bf16x2 result in destination.
\n
For .f16 instruction type, operands d and a have .f16 or .b16 type. For\n.f16x2 instruction type, operands d and a have .b32 type. For .bf16 instruction\ntype, operands d and a have .b16 type. For .bf16x2 instruction type, operands d\nand a have .b32 type.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n d = -a;\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = -fA[i];\n }\n}\n
\n
\n
Notes
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nneg.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
NaN inputs yield an unspecified NaN. Future implementations may comply with the IEEE 754\nstandard by preserving payload and modifying only the sign bit.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.0.
\n
neg.bf16 and neg.bf16x2 introduced in PTX ISA 7.0.
\n
Target ISA Notes
\n
Requires sm_53 or higher.
\n
neg.bf16 and neg.bf16x2 requires architecture sm_80 or higher.
\n",
- "tooltip": "=====Floating Point Instructions: neg\n\n\n\nArithmetic negate.\n\nSyntax\n\nneg{.ftz}.f32 d, a;\n\nneg.f64 d, a;\n\nDescription\n\nNegate the sign of a and store the result in d.\n\nSemantics\n\nd = -a;\n\nNotes\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, subnormal numbers are supported.\n\nneg.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.\n\nsm_1x\n\nneg.f64 supports subnormal numbers.\n\nneg.f32 flushes subnormal inputs and results to sign-preservi...\n\n=====Half Precision Floating Point Instructions: neg\n\n\n\nArithmetic negate.\n\nSyntax\n\nneg{.ftz}.f16 d, a;\n\nneg{.ftz}.f16x2 d, a;\n\nneg.bf16 d, a;\n\nneg.bf16x2 d, a;\n\nDescription\n\nNegate the sign of a and store the result in d.\n\nFor .f16x2 and .bf16x2 instruction type, forms input vector by extracting half word values\n\nfrom the source operand. Half-word operands are then negated in parallel to produce .f16x2 or\n\n.bf16x2 result in destination.\n\nFor .f...\n\n=====Integer Arithmetic Instructions: neg\n\n\n\nArithmetic negate.\n\nSyntax\n\nneg.type d, a;\n\n.type = { .s16, .s32, .s64 };\n\nDescription\n\nNegate the sign of a and store the result in d.\n\nSemantics\n\nd = -a;\n\nNotes\n\nOnly for signed integers.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nneg.s32 r0,a;\n\n... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-neg"
- };
-
- case "noreturn":
- return {
- "html": "For more information, visit noreturn .
Performance-Tuning Directives: .noreturn
\n\n\n
Indicate that the function does not return to its caller function.
\n
Syntax
\n
\n
.noreturn\n
\n
\n
Description
\n
Indicate that the function does not return to its caller function.
\n
Semantics
\n
An optional .noreturn directive indicates that the function does not return to caller\nfunction. .noreturn directive can only be specified on device functions and must appear between\na .func directive and its body.
\n
The directive cannot be specified on functions which have return parameters.
\n
If a function with .noreturn directive returns to the caller function at runtime, then the\nbehavior is undefined.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.4.
\n
Target ISA Notes
\n
Requires sm_30 or higher.
\n
Examples
\n
\n
.func foo .noreturn { ... }\n
\n
\n",
- "tooltip": "Indicate that the function does not return to its caller function.\n\nSyntax\n\n.noreturn\n\nDescription\n\nIndicate that the function does not return to its caller function.\n\nSemantics\n\nAn optional .noreturn directive indicates that the function does not return to caller\n\nfunction. .noreturn directive can only be specified on device functions and must appear between\n\na .func directive and its body.\n\nThe directive cannot be specified on functions which have return parameters.\n\nIf a function with .noreturn directive returns to the caller function at runtime, then the\n\nbehavior is undefined.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 6.4.\n\nTarget ISA Notes\n\nRequires sm_30 or higher.\n\nExamples\n\n.func foo .noreturn { ... }\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#performance-tuning-directives-noreturn"
+ "html": "
Negate the sign of a and store the result in d.
\nFor more information, visit neg(int) .",
+ "tooltip": "Arithmetic negate.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-neg"
};
case "not":
return {
- "html": "For more information, visit not .
The size of the operands must match, but not necessarily the type.
\n
Allowed types include predicates.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
not.b32 mask,mask;\nnot.pred p,q;\n
\n
\n",
- "tooltip": "Bitwise negation; one\u2019s complement.\n\nSyntax\n\nnot.type d, a;\n\n.type = { .pred, .b16, .b32, .b64 };\n\nDescription\n\nInvert the bits in a.\n\nSemantics\n\nd = ~a;\n\nNotes\n\nThe size of the operands must match, but not necessarily the type.\n\nAllowed types include predicates.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nnot.b32 mask,mask;\n\nnot.pred p,q;\n\n ...",
+ "html": "
Invert the bits in a.
\nFor more information, visit not .",
+ "tooltip": "Bitwise negation; one\u2019s complement.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-not"
};
- case "nsmid":
- return {
- "html": "For more information, visit nsmid .
Special Registers: %nsmid
\n\n\n
Number of SM identifiers.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %nsmid;\n
\n
\n
Description
\n
A predefined, read-only special register that returns the maximum number of SM identifiers. The SM\nidentifier numbering is not guaranteed to be contiguous, so %nsmid may be larger than the\nphysical number of SMs in the device.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%nsmid requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %nsmid;\n
\n
\n",
- "tooltip": "Number of SM identifiers.\n\nSyntax (predefined)\n\n.sreg .u32 %nsmid;\n\nDescription\n\nA predefined, read-only special register that returns the maximum number of SM identifiers. The SM\n\nidentifier numbering is not guaranteed to be contiguous, so %nsmid may be larger than the\n\nphysical number of SMs in the device.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%nsmid requires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %nsmid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-nsmid"
- };
-
- case "ntid":
- return {
- "html": "For more information, visit ntid .
A predefined, read-only special register initialized with the number of thread ids in each CTA\ndimension. The %ntid special register contains a 3D CTA shape vector that holds the CTA\ndimensions. CTA dimensions are non-zero; the fourth element is unused and always returns zero. The\ntotal number of threads in a CTA is (%ntid.x*%ntid.y*%ntid.z).
\n
\n
%ntid.y == %ntid.z == 1 in 1D CTAs.\n%ntid.z ==1 in 2D CTAs.\n
\n
\n
Maximum values of %ntid.{x,y,z} are as follows:
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
.target architecture
\n
%ntid.x
\n
%ntid.y
\n
%ntid.z
\n
\n\n\n
\n
sm_1x
\n
512
\n
512
\n
64
\n
\n
\n
sm_20, sm_3x, sm_5x, sm_6x,\nsm_7x, sm_8x, sm_9x
\n
1024
\n
1024
\n
64
\n
\n\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0 with type .v4.u16.
\n
Redefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n%ntid.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
// compute unified thread id for 2D CTA\nmov.u32 %r0,%tid.x;\nmov.u32 %h1,%tid.y;\nmov.u32 %h2,%ntid.x;\nmad.u32 %r0,%h1,%h2,%r0;\n\nmov.u16 %rh,%ntid.x; // legacy code\n
\n
\n",
- "tooltip": "Number of thread IDs per CTA.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %ntid; // CTA shape vector\n\n.sreg .u32 %ntid.x, %ntid.y, %ntid.z; // CTA dimensions\n\nDescription\n\nA predefined, read-only special register initialized with the number of thread ids in each CTA\n\ndimension. The %ntid special register contains a 3D CTA shape vector that holds the CTA\n\ndimensions. CTA dimensions are non-zero; the fourth element is unused and always returns zero. The\n\ntotal number of threads in a CTA is (%ntid.x * %ntid.y * %ntid.z).\n\n%ntid.y == %ntid.z == 1 in 1D CTAs.\n\n%ntid.z ==1 in 2D CTAs.\n\nMaximum values of %ntid.{x,y,z} are as follows:\n\n\n\n\n\n.target architecture\n\n%ntid.x\n\n%ntid.y\n\n%ntid.z\n\n\n\nsm_1x\n\n512\n\n512\n\n64\n\nsm_20, sm_3x, sm_5x, sm_6x,\n\nsm_7x, sm_8x, sm_9x\n\n1024\n\n1024\n\n64\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0 with type .v4.u16.\n\nRedefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\n\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n\n%ntid.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n// compute unified thread id for 2D CTA\n\nmov.u32 %r0,%tid.x;\n\nmov.u32 %h1,%tid.y;\n\nmov.u32 %h2,%ntid.x;\n\nmad.u32 %r0,%h1,%h2,%r0;\n\nmov.u16 %rh,%ntid.x; // legacy code\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-ntid"
- };
-
- case "nwarpid":
- return {
- "html": "For more information, visit nwarpid .
Special Registers: %nwarpid
\n\n\n
Number of warp identifiers.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %nwarpid;\n
\n
\n
Description
\n
A predefined, read-only special register that returns the maximum number of warp identifiers.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
%nwarpid requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %nwarpid;\n
\n
\n",
- "tooltip": "Number of warp identifiers.\n\nSyntax (predefined)\n\n.sreg .u32 %nwarpid;\n\nDescription\n\nA predefined, read-only special register that returns the maximum number of warp identifiers.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\n%nwarpid requires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %nwarpid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-nwarpid"
- };
-
case "or":
return {
- "html": "For more information, visit or .
Compute the bit-wise or operation for the bits in a and b.
\n
Semantics
\n
\n
d = a | b;\n
\n
\n
Notes
\n
The size of the operands must match, but not necessarily the type.
\n
Allowed types include predicate registers.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
or.b32 mask mask,0x00010001\nor.pred p,q,r;\n
\n
\n",
- "tooltip": "Biwise OR.\n\nSyntax\n\nor.type d, a, b;\n\n.type = { .pred, .b16, .b32, .b64 };\n\nDescription\n\nCompute the bit-wise or operation for the bits in a and b.\n\nSemantics\n\nd = a | b;\n\nNotes\n\nThe size of the operands must match, but not necessarily the type.\n\nAllowed types include predicate registers.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nor.b32 mask mask,0x00010001\n\nor.pred p,q,r;\n\n ...",
+ "html": "
Compute the bit-wise or operation for the bits in a and b.
\nFor more information, visit or .",
+ "tooltip": "Biwise OR.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-or"
};
- case "pm0":
- return {
- "html": "For more information, visit pm0..%pm7 .
Special Registers: %pm0..%pm7
\n\n\n
Performance monitoring counters.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %pm<8>;\n
\n
\n
Description
\n
Special registers %pm0..%pm7 are unsigned 32-bit read-only performance monitor counters. Their\nbehavior is currently undefined.
\n
PTX ISA Notes
\n
%pm0..%pm3 introduced in PTX ISA version 1.3.
\n
%pm4..%pm7 introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
%pm0..%pm3 supported on all target architectures.
\n
%pm4..%pm7 require sm_20 or higher.
\n
Examples
\n
\n
mov.u32 r1,%pm0;\nmov.u32 r1,%pm7;\n
\n
\n",
- "tooltip": "Performance monitoring counters.\n\nSyntax (predefined)\n\n.sreg .u32 %pm<8>;\n\nDescription\n\nSpecial registers %pm0..%pm7 are unsigned 32-bit read-only performance monitor counters. Their\n\nbehavior is currently undefined.\n\nPTX ISA Notes\n\n%pm0..%pm3 introduced in PTX ISA version 1.3.\n\n%pm4..%pm7 introduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\n%pm0..%pm3 supported on all target architectures.\n\n%pm4..%pm7 require sm_20 or higher.\n\nExamples\n\nmov.u32 r1,%pm0;\n\nmov.u32 r1,%pm7;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-pm0-pm7"
- };
-
- case "pm0_64":
- return {
- "html": "For more information, visit pm0_64..%pm7_64 .
Special registers %pm0_64..%pm7_64 are unsigned 64-bit read-only performance monitor\ncounters. Their behavior is currently undefined.
\n
Notes
\n
The lower 32bits of %pm0_64..%pm7_64 are identical to %pm0..%pm7.
\n
PTX ISA Notes
\n
%pm0_64..%pm7_64 introduced in PTX ISA version 4.0.
\n
Target ISA Notes
\n
%pm0_64..%pm7_64 require sm_50 or higher.
\n
Examples
\n
\n
mov.u32 r1,%pm0_64;\nmov.u32 r1,%pm7_64;\n
\n
\n",
- "tooltip": "64 bit Performance monitoring counters.\n\nSyntax (predefined)\n\n.sreg .u64 %pm0_64;\n\n.sreg .u64 %pm1_64;\n\n.sreg .u64 %pm2_64;\n\n.sreg .u64 %pm3_64;\n\n.sreg .u64 %pm4_64;\n\n.sreg .u64 %pm5_64;\n\n.sreg .u64 %pm6_64;\n\n.sreg .u64 %pm7_64;\n\nDescription\n\nSpecial registers %pm0_64..%pm7_64 are unsigned 64-bit read-only performance monitor\n\ncounters. Their behavior is currently undefined.\n\nNotes\n\nThe lower 32bits of %pm0_64..%pm7_64 are identical to %pm0..%pm7.\n\nPTX ISA Notes\n\n%pm0_64..%pm7_64 introduced in PTX ISA version 4.0.\n\nTarget ISA Notes\n\n%pm0_64..%pm7_64 require sm_50 or higher.\n\nExamples\n\nmov.u32 r1,%pm0_64;\n\nmov.u32 r1,%pm7_64;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-pm0-64-pm7-64"
- };
-
case "pmevent":
return {
- "html": "For more information, visit pmevent .
Miscellaneous Instructions: pmevent
\n\n\n
Trigger one or more Performance Monitor events.
\n
Syntax
\n
\n
pmevent a; // trigger a single performance monitor event\npmevent.mask a; // trigger one or more performance monitor events\n
\n
\n
Description
\n
Triggers one or more of a fixed number of performance monitor events, with event index or mask\nspecified by immediate operand a.
\n
pmevent (without modifier .mask) triggers a single performance monitor event indexed by\nimmediate operand a, in the range 0..15.
\n
pmevent.mask triggers one or more of the performance monitor events. Each bit in the 16-bit\nimmediate operand a controls an event.
\n
Programmatic performance moniter events may be combined with other hardware events using Boolean\nfunctions to increment one of the four performance counters. The relationship between events and\ncounters is programmed via API calls from the host.
\n
Notes
\n
Currently, there are sixteen performance monitor events, numbered 0 through 15.
\n",
- "tooltip": "Trigger one or more Performance Monitor events.\n\nSyntax\n\npmevent a; // trigger a single performance monitor event\n\npmevent.mask a; // trigger one or more performance monitor events\n\nDescription\n\nTriggers one or more of a fixed number of performance monitor events, with event index or mask\n\nspecified by immediate operand a.\n\npmevent (without modifier .mask) triggers a single performance monitor event indexed by\n\nimmediate operand a, in the range 0..15.\n\npmevent.mask triggers one or more of the performance monitor events. Each bit in the 16-bit\n\nimmediate operand a controls an event.\n\nProgrammatic performance moniter events may be combined with other hardware events using Boolean\n\nfunctions to increment one of the four performance counters. The relationship between events and\n\ncounters is programmed via API calls from the host.\n\nNotes\n\nCurrently, there are sixteen performance monitor events, numbered 0 through 15.\n\nPTX ISA Notes\n\npmevent introduced in PTX ISA version 1.4.\n\npmevent.mask introduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\npmevent supported on all target architectures.\n\npmevent.mask requires sm_20 or higher.\n\nExamples\n\n pmevent 1;\n\n@p pmevent 7;\n\n@q pmevent.mask 0xff;\n\n ...",
+ "html": "
Triggers one or more of a fixed number of performance monitor events, with event index or mask\nspecified by immediate operand a.
\nFor more information, visit pmevent .",
+ "tooltip": "Trigger one or more Performance Monitor events.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#miscellaneous-instructions-pmevent"
};
case "popc":
return {
- "html": "For more information, visit popc(int) .
Integer Arithmetic Instructions: popc
\n\n\n
Population count.
\n
Syntax
\n
\n
popc.type d, a;\n\n.type = { .b32, .b64 };\n
\n
\n
Description
\n
Count the number of one bits in a and place the resulting population count in 32-bit\ndestination register d. Operand a has the instruction type and destination d has type\n.u32.
\n
Semantics
\n
\n
.u32 d = 0;\nwhile (a != 0) {\n if (a & 0x1) d++;\n a = a >> 1;\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
popc requires sm_20 or higher.
\n
Examples
\n
\n
popc.b32 d, a;\npopc.b64 cnt, X; // cnt is .u32\n
\n
\n",
- "tooltip": "Population count.\n\nSyntax\n\npopc.type d, a;\n\n.type = { .b32, .b64 };\n\nDescription\n\nCount the number of one bits in a and place the resulting population count in 32-bit\n\ndestination register d. Operand a has the instruction type and destination d has type\n\n.u32.\n\nSemantics\n\n.u32 d = 0;\n\nwhile (a != 0) {\n\n if (a & 0x1) d++;\n\n a = a >> 1;\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\npopc requires sm_20 or higher.\n\nExamples\n\npopc.b32 d, a;\n\npopc.b64 cnt, X; // cnt is .u32\n\n ...",
+ "html": "
Count the number of one bits in a and place the resulting population count in 32-bit\ndestination register d. Operand a has the instruction type and destination d has type\n.u32.
\nFor more information, visit popc(int) .",
+ "tooltip": "Population count.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-popc"
};
- case "pragma":
- return {
- "html": "For more information, visit pragma .
Performance-Tuning Directives: .pragma
\n\n\n
Pass directives to PTX backend compiler.
\n
Syntax
\n
\n
.pragma list-of-strings ;\n
\n
\n
Description
\n
Pass module-scoped, entry-scoped, or statement-level directives to the PTX backend compiler.
\n
The .pragma directive may occur at module-scope, at entry-scope, or at statement-level.
\n
Semantics
\n
The interpretation of .pragma directive strings is implementation-specific and has no impact on\nPTX semantics. See Descriptions of .pragma Strings for\ndescriptions of the pragma strings defined in ptxas.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.pragma \"nounroll\"; // disable unrolling in backend\n\n// disable unrolling for current kernel\n.entry foo .pragma \"nounroll\"; { ... }\n
\n
\n",
- "tooltip": "Pass directives to PTX backend compiler.\n\nSyntax\n\n.pragma list-of-strings ;\n\nDescription\n\nPass module-scoped, entry-scoped, or statement-level directives to the PTX backend compiler.\n\nThe .pragma directive may occur at module-scope, at entry-scope, or at statement-level.\n\nSemantics\n\nThe interpretation of .pragma directive strings is implementation-specific and has no impact on\n\nPTX semantics. See Descriptions of .pragma Strings for\n\ndescriptions of the pragma strings defined in ptxas.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.pragma \"nounroll\"; // disable unrolling in backend\n\n// disable unrolling for current kernel\n\n.entry foo .pragma \"nounroll\"; { ... }\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#performance-tuning-directives-pragma"
- };
-
case "prefetch":
return {
- "html": "For more information, visit prefetch .
Data Movement and Conversion Instructions: prefetch, prefetchu
\n\n\n
Prefetch line containing a generic address at a specified level of memory hierarchy, in specified\nstate space.
\n
Syntax
\n
\n
prefetch{.space}.level [a]; // prefetch to data cache\nprefetch.global.level::eviction_priority [a]; // prefetch to data cache\n\nprefetchu.L1 [a]; // prefetch to uniform cache\n\nprefetch{.tensormap_space}.tensormap [a]; // prefetch the tensormap\n\n.space = { .global, .local };\n.level = { .L1, .L2 };\n.level::eviction_priority = { .L2::evict_last, .L2::evict_normal };\n.tensormap_space = { .const, .param };\n
\n
\n
Description
\n
The prefetch instruction brings the cache line containing the specified address in global or\nlocal memory state space into the specified cache level.
\n
If the .tensormap qualifier is specified then the prefetch instruction brings the cache line\ncontaining the specified address in the .const or .param memory state space for subsequent\nuse by the cp.async.bulk.tensor instruction.
Optionally, the eviction priority to be applied on the prefetched cache line can be specified by the\nmodifier .level::eviction_priority.
\n
Supported addressing modes for operand a and alignment requirements are described in Addresses\nas Operands
\n
The prefetchu instruction brings the cache line containing the specified generic address into\nthe specified uniform cache level.
\n
A prefetch to a shared memory location performs no operation.
\n
A prefetch into the uniform cache requires a generic address, and no operation occurs if the\naddress maps to a const, local, or shared memory location.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Support for .level::eviction_priority qualifier introduced in PTX ISA version 7.4.
\n
Support for the .tensormap qualifier is introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
prefetch and prefetchu require sm_20 or higher.
\n
Support for .level::eviction_priority qualifier requires sm_80 or higher.
\n
Support for the .tensormap qualifier requires sm_90 or higher.
\n",
- "tooltip": "Prefetch line containing a generic address at a specified level of memory hierarchy, in specified\n\nstate space.\n\nSyntax\n\nprefetch{.space}.level [a]; // prefetch to data cache\n\nprefetch.global.level::eviction_priority [a]; // prefetch to data cache\n\nprefetchu.L1 [a]; // prefetch to uniform cache\n\nprefetch{.tensormap_space}.tensormap [a]; // prefetch the tensormap\n\n.space = { .global, .local };\n\n.level = { .L1, .L2 };\n\n.level::eviction_priority = { .L2::evict_last, .L2::evict_normal };\n\n.tensormap_space = { .const, .param };\n\nDescription\n\nThe prefetch instruction brings the cache line containing the specified address in global or\n\nlocal memory state space into the specified cache level.\n\nIf the .tensormap qualifier is specified then the prefetch instruction brings the cache line\n\ncontaining the specified address in the .const or .param memory state space for subsequent\n\nuse by the cp.async.bulk.tensor instruction.\n\nIf no state space is given, the prefetch uses Generic Addressing.\n\nOptionally, the eviction priority to be applied on the prefetched cache line can be specified by the\n\nmodifier .level::eviction_priority.\n\nSupported addressing modes for operand a and alignment requirements are described in Addresses\n\nas Operands\n\nThe prefetchu instruction brings the cache line containing the specified generic address into\n\nthe specified uniform cache level.\n\nA prefetch to a shared memory location performs no operation.\n\nA prefetch into the uniform cache requires a generic address, and no operation occurs if the\n\naddress maps to a const, local, or shared memory location.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nSupport for .level::eviction_priority qualifier introduced in PTX ISA version 7.4.\n\nSupport for the .tensormap qualifier is introduced in PTX ISA version 8.0.\n\nTarget ISA Notes\n\nprefetch and prefetchu require sm_20 or higher.\n\nSupport for .level::eviction_priority qualifier requires sm_80 or higher.\n\nSupport for the .tensormap qualifier requires sm_90 or higher.\n\nExamples\n\nprefetch.global.L1 [ptr];\n\nprefetch.global.L2::evict_last [ptr];\n\nprefetchu.L1 [addr];\n\nprefetch.const.tensormap [ptr];\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-prefetch-prefetchu"
- };
-
- case "prefetchu":
- return {
- "html": "For more information, visit prefetchu .
Data Movement and Conversion Instructions: prefetch, prefetchu
\n\n\n
Prefetch line containing a generic address at a specified level of memory hierarchy, in specified\nstate space.
\n
Syntax
\n
\n
prefetch{.space}.level [a]; // prefetch to data cache\nprefetch.global.level::eviction_priority [a]; // prefetch to data cache\n\nprefetchu.L1 [a]; // prefetch to uniform cache\n\nprefetch{.tensormap_space}.tensormap [a]; // prefetch the tensormap\n\n.space = { .global, .local };\n.level = { .L1, .L2 };\n.level::eviction_priority = { .L2::evict_last, .L2::evict_normal };\n.tensormap_space = { .const, .param };\n
\n
\n
Description
\n
The prefetch instruction brings the cache line containing the specified address in global or\nlocal memory state space into the specified cache level.
\n
If the .tensormap qualifier is specified then the prefetch instruction brings the cache line\ncontaining the specified address in the .const or .param memory state space for subsequent\nuse by the cp.async.bulk.tensor instruction.
Optionally, the eviction priority to be applied on the prefetched cache line can be specified by the\nmodifier .level::eviction_priority.
\n
Supported addressing modes for operand a and alignment requirements are described in Addresses\nas Operands
\n
The prefetchu instruction brings the cache line containing the specified generic address into\nthe specified uniform cache level.
\n
A prefetch to a shared memory location performs no operation.
\n
A prefetch into the uniform cache requires a generic address, and no operation occurs if the\naddress maps to a const, local, or shared memory location.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Support for .level::eviction_priority qualifier introduced in PTX ISA version 7.4.
\n
Support for the .tensormap qualifier is introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
prefetch and prefetchu require sm_20 or higher.
\n
Support for .level::eviction_priority qualifier requires sm_80 or higher.
\n
Support for the .tensormap qualifier requires sm_90 or higher.
\n",
- "tooltip": "Prefetch line containing a generic address at a specified level of memory hierarchy, in specified\n\nstate space.\n\nSyntax\n\nprefetch{.space}.level [a]; // prefetch to data cache\n\nprefetch.global.level::eviction_priority [a]; // prefetch to data cache\n\nprefetchu.L1 [a]; // prefetch to uniform cache\n\nprefetch{.tensormap_space}.tensormap [a]; // prefetch the tensormap\n\n.space = { .global, .local };\n\n.level = { .L1, .L2 };\n\n.level::eviction_priority = { .L2::evict_last, .L2::evict_normal };\n\n.tensormap_space = { .const, .param };\n\nDescription\n\nThe prefetch instruction brings the cache line containing the specified address in global or\n\nlocal memory state space into the specified cache level.\n\nIf the .tensormap qualifier is specified then the prefetch instruction brings the cache line\n\ncontaining the specified address in the .const or .param memory state space for subsequent\n\nuse by the cp.async.bulk.tensor instruction.\n\nIf no state space is given, the prefetch uses Generic Addressing.\n\nOptionally, the eviction priority to be applied on the prefetched cache line can be specified by the\n\nmodifier .level::eviction_priority.\n\nSupported addressing modes for operand a and alignment requirements are described in Addresses\n\nas Operands\n\nThe prefetchu instruction brings the cache line containing the specified generic address into\n\nthe specified uniform cache level.\n\nA prefetch to a shared memory location performs no operation.\n\nA prefetch into the uniform cache requires a generic address, and no operation occurs if the\n\naddress maps to a const, local, or shared memory location.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nSupport for .level::eviction_priority qualifier introduced in PTX ISA version 7.4.\n\nSupport for the .tensormap qualifier is introduced in PTX ISA version 8.0.\n\nTarget ISA Notes\n\nprefetch and prefetchu require sm_20 or higher.\n\nSupport for .level::eviction_priority qualifier requires sm_80 or higher.\n\nSupport for the .tensormap qualifier requires sm_90 or higher.\n\nExamples\n\nprefetch.global.L1 [ptr];\n\nprefetch.global.L2::evict_last [ptr];\n\nprefetchu.L1 [addr];\n\nprefetch.const.tensormap [ptr];\n\n ...",
+ "html": "
The prefetch instruction brings the cache line containing the specified address in global or\nlocal memory state space into the specified cache level.
\nFor more information, visit prefetch .",
+ "tooltip": "Theprefetchinstruction brings the cache line containing the specified address in global or\n\nlocal memory state space into the specified cache level.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-prefetch-prefetchu"
};
case "prmt":
return {
- "html": "For more information, visit prmt .
Pick four arbitrary bytes from two 32-bit registers, and reassemble them into a 32-bit destination\nregister.
\n
In the generic form (no mode specified), the permute control consists of four 4-bit selection\nvalues. The bytes in the two source registers are numbered from 0 to 7: {b,a}={{b7,b6,b5,\nb4},{b3,b2,b1,b0}}. For each byte in the target register, a 4-bit selection value is defined.
\n
The 3 lsbs of the selection value specify which of the 8 source bytes should be moved into the\ntarget position. The msb defines if the byte value should be copied, or if the sign (msb of the\nbyte) should be replicated over all 8 bits of the target position (sign extend of the byte value);\nmsb=0 means copy the literal value; msb=1 means replicate the sign. Note that the sign\nextension is only performed as part of generic form.
\n
Thus, the four 4-bit values fully specify an arbitrary byte permute, as a 16b permute code.
\n
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
default mode
\n
\n
d.b3
\n
source select
\n
\n
\n
d.b2
\n
source select
\n
\n
\n
d.b1
\n
source select
\n
\n
\n
d.b0
\n
source select
\n
\n
\n\n\n
\n
index
\n
c[15:12]
\n
c[11:8]
\n
c[7:4]
\n
c[3:0]
\n
\n\n
\n
The more specialized form of the permute control uses the two lsb\u2019s of operand c (which is\ntypically an address pointer) to control the byte extraction.
\n",
- "tooltip": "Permute bytes from register pair.\n\nSyntax\n\nprmt.b32{.mode} d, a, b, c;\n\n.mode = { .f4e, .b4e, .rc8, .ecl, .ecr, .rc16 };\n\nDescription\n\nPick four arbitrary bytes from two 32-bit registers, and reassemble them into a 32-bit destination\n\nregister.\n\nIn the generic form (no mode specified), the permute control consists of four 4-bit selection\n\nvalues. The bytes in the two source registers are numbered from 0 to 7: {b, a} = {{b7, b6, b5,\n\nb4}, {b3, b2, b1, b0}}. For each byte in the target register, a 4-bit selection value is defined.\n\nThe 3 lsbs of the selection value specify which of the 8 source bytes should be moved into the\n\ntarget position. The msb defines if the byte value should be copied, or if the sign (msb of the\n\nbyte) should be replicated over all 8 bits of the target position (sign extend of the byte value);\n\nmsb=0 means copy the literal value; msb=1 means replicate the sign. Note that the sign\n\nextension is only performed as part of generic form.\n\nThus, the four 4-bit values fully specify an arbitrary byte permute, as a 16b permute code.\n\n\n\n\n\ndefault mode\n\nd.b3\n\nsource select\n\nd.b2\n\nsource select\n\nd.b1\n\nsource select\n\nd.b0\n\nsource select\n\n\n\nindex\n\nc[15:12]\n\nc[11:8]\n\nc[7:4]\n\nc[3:0]\n\nThe more specialized form of the permute control uses the two lsb\u2019s of operand c (which is\n\ntypically an address pointer) to control the byte extraction.\n\n\n\n\n\nmode\n\nselector\n\nc[1:0]\n\nd.b3\n\nsource\n\nd.b2\n\nsource\n\nd.b1\n\nsource\n\nd.b0\n\nsource\n\n\n\nf4e (forward 4 extract)\n\n0\n\n3\n\n2\n\n1\n\n0\n\n1\n\n4\n\n3\n\n2\n\n1\n\n2\n\n5\n\n4\n\n3\n\n2\n\n3\n\n6\n\n5\n\n4\n\n3\n\nb4e (backward 4 extract)\n\n0\n\n5\n\n6\n\n7\n\n0\n\n1\n\n6\n\n7\n\n0\n\n1\n\n2\n\n7\n\n0\n\n1\n\n2\n\n3\n\n0\n\n1\n\n2\n\n3\n\nrc8 (replicate 8)\n\n0\n\n0\n\n0\n\n0\n\n0\n\n1\n\n1\n\n1\n\n1\n\n1\n\n2\n\n2\n\n2\n\n2\n\n2\n\n3\n\n3\n\n3\n\n3\n\n3\n\necl (edge clamp left)\n\n0\n\n3\n\n2\n\n1\n\n0\n\n1\n\n3\n\n2\n\n1\n\n1\n\n2\n\n3\n\n2\n\n2\n\n2\n\n3\n\n3\n\n3\n\n3\n\n3\n\necr (edge clamp right)\n\n0\n\n0\n\n0\n\n0\n\n0\n\n1\n\n1\n\n1\n\n1\n\n0\n\n2\n\n2\n\n2\n\n1\n\n0\n\n3\n\n3\n\n2\n\n1\n\n0\n\nrc16 (replicate 16)\n\n0\n\n1\n\n0\n\n1\n\n0\n\n1\n\n3\n\n2\n\n3\n\n2\n\n2\n\n1\n\n0\n\n1\n\n0\n\n3\n\n3\n\n2\n\n3\n\n2\n\nSemantics\n\ntmp64 = (b<<32) | a; // create 8 byte source\n\nif ( ! mode ) {\n\n ctl[0] = (c >> 0) & 0xf;\n\n ctl[1] = (c >> 4) & 0xf;\n\n ctl[2] = (c >> 8) & 0xf;\n\n ctl[3] = (c >> 12) & 0xf;\n\n} else {\n\n ctl[0] = ctl[1] = ctl[2] = ctl[3] = (c >> 0) & 0x3;\n\n}\n\ntmp[07:00] = ReadByte( mode, ctl[0], tmp64 );\n\ntmp[15:08] = ReadByte( mode, ctl[1], tmp64 );\n\ntmp[23:16] = ReadByte( mode, ctl[2], tmp64 );\n\ntmp[31:24] = ReadByte( mode, ctl[3], tmp64 );\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nprmt requires sm_20 or higher.\n\nExamples\n\nprmt.b32 r1, r2, r3, r4;\n\nprmt.b32.f4e r1, r2, r3, r4;\n\n ...",
+ "html": "
Pick four arbitrary bytes from two 32-bit registers, and reassemble them into a 32-bit destination\nregister.
\nFor more information, visit prmt .",
+ "tooltip": "Permute bytes from register pair.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-prmt"
};
case "rcp":
return {
- "html": "For more information, visit rcp(fp) , rcp.approx.ftz.f64(fp) .
rcp.approx.f32 implements a fast approximation to reciprocal. The maximum absolute error is 2-23.0 over the range 1.0-2.0.
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
-0.0
\n
\n
\n
-subnormal
\n
-Inf
\n
\n
\n
-0.0
\n
-Inf
\n
\n
\n
+0.0
\n
+Inf
\n
\n
\n
+subnormal
\n
+Inf
\n
\n
\n
+Inf
\n
+0.0
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
Reciprocal with IEEE 754 compliant rounding:
\n
Rounding modifiers (no default):
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
rcp.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
rcp.f64 supports subnormal numbers.
\n
rcp.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
rcp.f32 and rcp.f64 introduced in PTX ISA version 1.0. rcp.rn.f64 and explicit modifiers\n.approx and .ftz were introduced in PTX ISA version 1.4. General rounding modifiers were\nadded in PTX ISA version 2.0.
\n
For PTX ISA version 1.4 and later, one of .approx or .rnd is required.
\n
For PTX ISA versions 1.0 through 1.3, rcp.f32 defaults to rcp.approx.ftz.f32, and\nrcp.f64 defaults to rcp.rn.f64.
\n
Target ISA Notes
\n
rcp.approx.f32 supported on all target architectures.
\n
rcp.rnd.f32 requires sm_20 or higher.
\n
rcp.rn.f64 requires sm_13 or higher, or .targetmap_f64_to_f32.
Compute a fast, gross approximation to the reciprocal of a value.
\n
Syntax
\n
\n
rcp.approx.ftz.f64 d, a;\n
\n
\n
Description
\n
Compute a fast, gross approximation to the reciprocal as follows:
\n\n
extract the most-significant 32 bits of .f64 operand a in 1.11.20 IEEE floating-point\nformat (i.e., ignore the least-significant 32 bits of a),
\n
compute an approximate .f64 reciprocal of this value using the most-significant 20 bits of\nthe mantissa of operand a,
\n
place the resulting 32-bits in 1.11.20 IEEE floating-point format in the most-significant 32-bits\nof destination d,and
\n
zero the least significant 32 mantissa bits of .f64 destination d.
\n\n
Semantics
\n
\n
tmp = a[63:32]; // upper word of a, 1.11.20 format\nd[63:32] = 1.0 / tmp;\nd[31:0] = 0x00000000;\n
\n
\n
Notes
\n
rcp.approx.ftz.f64 implements a fast, gross approximation to reciprocal.
\n
\n
\n
\n
\n
\n\n
\n
Input a[63:32]
\n
Result d[63:32]
\n
\n\n\n
\n
-Inf
\n
-0.0
\n
\n
\n
-subnormal
\n
-Inf
\n
\n
\n
-0.0
\n
-Inf
\n
\n
\n
+0.0
\n
+Inf
\n
\n
\n
+subnormal
\n
+Inf
\n
\n
\n
+Inf
\n
+0.0
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
Input NaNs map to a canonical NaN with encoding 0x7fffffff00000000.
\n
Subnormal inputs and results are flushed to sign-preserving zero.
\n
PTX ISA Notes
\n
rcp.approx.ftz.f64 introduced in PTX ISA version 2.1.
\n
Target ISA Notes
\n
rcp.approx.ftz.f64 requires sm_20 or higher.
\n
Examples
\n
\n
rcp.ftz.f64 xi,x;\n
\n
\n",
- "tooltip": "=====Floating Point Instructions: rcp\n\n\n\nTake the reciprocal of a value.\n\nSyntax\n\nrcp.approx{.ftz}.f32 d, a; // fast, approximate reciprocal\n\nrcp.rnd{.ftz}.f32 d, a; // IEEE 754 compliant rounding\n\nrcp.rnd.f64 d, a; // IEEE 754 compliant rounding\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nCompute 1/a, store result in d.\n\nSemantics\n\nd = 1 / a;\n\nNotes\n\nFast, approximate single-precision reciprocal:\n\nrcp.approx.f32 implements a fas...\n\n=====Floating Point Instructions: rcp.approx.ftz.f64\n\n\n\nCompute a fast, gross approximation to the reciprocal of a value.\n\nSyntax\n\nrcp.approx.ftz.f64 d, a;\n\nDescription\n\nCompute a fast, gross approximation to the reciprocal as follows:\n\nextract the most-significant 32 bits of .f64 operand a in 1.11.20 IEEE floating-point\n\nformat (i.e., ignore the least-significant 32 bits of a),\n\ncompute an approximate .f64 reciprocal of this value using the most-significant... ...",
+ "html": "
Compute 1/a, store result in d.
\nFor more information, visit rcp(fp) .",
+ "tooltip": "Take the reciprocal of a value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-rcp"
};
case "red":
return {
- "html": "For more information, visit red , red.async .
Parallel Synchronization and Communication Instructions: red
Performs a reduction operation with operand b and the value in location a, and stores the\nresult of the specified operation at location a, overwriting the original value. Operand a\nspecifies a location in the specified state space. If no state space is given, perform the memory\naccesses using Generic Addressing. red with scalar type may\nbe used only with .global and .shared spaces and with generic addressing, where the address\npoints to .global or .shared space. red with vector type may be used only with\n.global space and with generic addressing where the address points to .global space.
\n
For red with vector type, operand b is brace-enclosed vector expressions, size of which is\nequal to the size of vector qualifier.
\n
If no sub-qualifier is specified with .shared state space, then ::cta is assumed by default.
\n
The optional .sem qualifier specifies a memory synchronizing effect as described in the Memory\nConsistency Model. If the .sem qualifier is absent,\n.relaxed is assumed by default.
\n
The optional .scope qualifier specifies the set of threads that can directly observe the memory\nsynchronizing effect of this operation, as described in the Memory Consistency Model. If the .scope qualifier is absent, .gpu scope is\nassumed by default.
\n
For red with vector type, the supported combinations of vector qualifier, types and reduction\noperations supported on these combinations are depicted in following table:
\n
\n
\n
\n
\n
\n
\n
\n\n
\n
Vector qualifier
\n
Types
\n
\n
\n
.f16/ bf16
\n
.f16x2/ bf16x2
\n
.f32
\n
\n\n\n
\n
.v2
\n
.add, .min, .max
\n
.add, .min, .max
\n
.add
\n
\n
\n
.v4
\n
.add, .min, .max
\n
.add, .min, .max
\n
.add
\n
\n
\n
.v8
\n
.add, .min, .max
\n
Not supported
\n
Not Supported
\n
\n\n
\n
Two atomic operations {atom or red} are performed atomically with respect to each other only\nif each operation specifies a scope that includes the other. When this condition is not met, each\noperation observes the other operation being performed as if it were split into a read followed by a\ndependent write.
\n
red instruction on packed type or vector type, accesses adjacent scalar elements in memory. In\nsuch case, the atomicity is guaranteed separately for each of the individual scalar elements; the\nentire red is not guaranteed to be atomic as a single access.
\n
For sm_6x and earlier architectures, red operations on .shared state space do not\nguarantee atomicity with respect to normal store instructions to the same address. It is the\nprogrammer\u2019s responsibility to guarantee correctness of programs that use shared memory reduction\ninstructions, e.g., by inserting barriers between normal stores and reduction operations to a common\naddress, or by using atom.exch to store to locations accessed by other reduction operations.
\n
Supported addressing modes for operand a and alignment requirements are described in Addresses\nas Operands
\n
The bit-size operations are .and, .or, and .xor.
\n
The integer operations are .add, .inc, .dec, .min, .max. The .inc and\n.dec operations return a result in the range [0..b].
\n
The floating-point operation .add operation rounds to nearest even. Current implementation of\nred.add.f32 on global memory flushes subnormal inputs and results to sign-preserving zero;\nwhereas red.add.f32 on shared memory supports subnormal inputs and results and doesn\u2019t flush\nthem to zero.
\n
red.add.f16, red.add.f16x2, red.add.bf16 and red.add.bf16x2 operation requires the\n.noftz qualifier; it preserves subnormal inputs and results, and does not flush them to zero.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
The qualifier .level::cache_hint is only supported for .global state space and for generic\naddressing where the address points to the .global state space.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
red.async is a non-blocking instruction which initiates an asynchronous reduction operation\nspecified by .op, with the operand b and the value at destination shared memory location\nspecified by operand a.
\n
The .inc and .dec operations return a result in the range [0..b].
\n
The modifier .completion_mechanism specifies that upon completion of the asynchronous operation,\ncomplete-tx\noperation, with completeCount argument equal to amount of data stored in bytes, will be\nperformed on the mbarrier object specified by the operand mbar.
\n
Operand a represents destination address and must be a register or of the form register+\nimmOff as described in Addresses as Operands.
\n
The shared memory addresses of destination operand a and the mbarrier objectmbar, must\nmeet all of the following conditions:
\n
\n
They Belong to the same CTA.
\n
They are different to the CTA of the executing thread but must be within the same cluster.
\n
\n
Otherwise, the behavior is undefined.
\n
The state space of the address {.ss}, if specified, is applicable to both operands a and\nmbar. If not specified, then Generic Addressing is used for\nboth a and mbar.
\n
With .shared::cluster, if the addresses specified do not fall within the address window of\n.shared::cluster state space, then the behaviour is undefined.
\n
The reduce operation in red.async is treated as a relaxed memory operation and the complete_tx\noperation on the mbarrier has .release semantics at the .cluster scope as described in the\nMemory Consistency Model.
\n",
- "tooltip": "=====Parallel Synchronization and Communication Instructions: red\n\n\n\nReduction operations on global and shared memory.\n\nSyntax\n\nReduction operation with scalar type:\n\nred{.sem}{.scope}{.space}.op{.level::cache_hint}.type [a], b{, cache-policy};\n\nred{.sem}{.scope}{.space}.add.noftz{.level::cache_hint}.f16 [a], b{, cache-policy};\n\nred{.sem}{.scope}{.space}.add.noftz{.level::cache_hint}.f16x2 [a], b{, cache-policy};\n\nred{.sem}{.scope}{.space}.add.noftz{.level::...\n\n=====Parallel Synchronization and Communication Instructions: red.async\n\n\n\nAsynchronous reduction operation on shared memory.\n\nSyntax\n\n// Increment and Decrement reductions\n\nred.async.relaxed.cluster{.ss}.completion_mechanism.op.type [a], b, [mbar];\n\n.ss = { .shared::cluster };\n\n.op = { .inc, .dec };\n\n.type = { .u32 };\n\n.completion_mechanism = { .mbarrier::complete_tx::bytes };\n\n// MIN and MAX reductions\n\nred.async.relaxed.clust... ...",
+ "html": "
Performs a reduction operation with operand b and the value in location a, and stores the\nresult of the specified operation at location a, overwriting the original value. Operand a\nspecifies a location in the specified state space. If no state space is given, perform the memory\naccesses using Generic Addressing. red with scalar type may\nbe used only with .global and .shared spaces and with generic addressing, where the address\npoints to .global or .shared space. red with vector type may be used only with\n.global space and with generic addressing where the address points to .global space.
\nFor more information, visit red .",
+ "tooltip": "Reduction operations on global and shared memory.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-red"
};
case "redux":
return {
- "html": "For more information, visit redux.sync .
Parallel Synchronization and Communication Instructions: redux.sync
\n\n\n
Perform reduction operation on the data from each predicated active thread in the thread group.
redux.sync will cause the executing thread to wait until all non-exited threads corresponding to\nmembermask have executed redux.sync with the same qualifiers and same membermask value\nbefore resuming execution.
\n
Operand membermask specifies a 32-bit integer which is a mask indicating threads participating\nin this instruction where the bit position corresponds to thread\u2019s laneid.
\n
redux.sync performs a reduction operation .op of the 32 bit source register src across\nall non-exited threads in the membermask. The result of the reduction operation is written to\nthe 32 bit destination register dst.
\n
Reduction operation can be one of the bitwise operation in .and, .or, .xor or arithmetic\noperation in .add, .min , .max.
\n
For the .add operation result is truncated to 32 bits.
\n
The behavior of redux.sync is undefined if the executing thread is not in the membermask.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Target ISA Notes
\n
Requires sm_80 or higher.
\n
Release Notes
\n
Note that redux.sync applies to threads in a single warp, not across an entire CTA.
\n",
- "tooltip": "Perform reduction operation on the data from each predicated active thread in the thread group.\n\nSyntax\n\nredux.sync.op.type dst, src, membermask;\n\n.op = {.add, .min, .max}\n\n.type = {.u32, .s32}\n\nredux.sync.op.b32 dst, src, membermask;\n\n.op = {.and, .or, .xor}\n\nDescription\n\nredux.sync will cause the executing thread to wait until all non-exited threads corresponding to\n\nmembermask have executed redux.sync with the same qualifiers and same membermask value\n\nbefore resuming execution.\n\nOperand membermask specifies a 32-bit integer which is a mask indicating threads participating\n\nin this instruction where the bit position corresponds to thread\u2019s laneid.\n\nredux.sync performs a reduction operation .op of the 32 bit source register src across\n\nall non-exited threads in the membermask. The result of the reduction operation is written to\n\nthe 32 bit destination register dst.\n\nReduction operation can be one of the bitwise operation in .and, .or, .xor or arithmetic\n\noperation in .add, .min , .max.\n\nFor the .add operation result is truncated to 32 bits.\n\nThe behavior of redux.sync is undefined if the executing thread is not in the membermask.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.0.\n\nTarget ISA Notes\n\nRequires sm_80 or higher.\n\nRelease Notes\n\nNote that redux.sync applies to threads in a single warp, not across an entire CTA.\n\nExamples\n\n.reg .b32 dst, src, init, mask;\n\nredux.sync.add.s32 dst, src, 0xff;\n\nredux.sync.xor.b32 dst, src, mask;\n\n ...",
+ "html": "
redux.sync will cause the executing thread to wait until all non-exited threads corresponding to\nmembermask have executed redux.sync with the same qualifiers and same membermask value\nbefore resuming execution.
\nFor more information, visit redux.sync .",
+ "tooltip": "Perform reduction operation on the data from each predicated active thread in the thread group.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-redux-sync"
};
case "rem":
return {
- "html": "For more information, visit rem(int) .
The behavior for negative numbers is machine-dependent and depends on whether divide rounds towards\nzero or negative infinity.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
rem.s32 x,x,8; // x = x%8;\n
\n
\n",
- "tooltip": "The remainder of integer division.\n\nSyntax\n\nrem.type d, a, b;\n\n.type = { .u16, .u32, .u64,\n\n .s16, .s32, .s64 };\n\nDescription\n\nDivides a by b, store the remainder in d.\n\nSemantics\n\nd = a % b;\n\nNotes\n\nThe behavior for negative numbers is machine-dependent and depends on whether divide rounds towards\n\nzero or negative infinity.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nrem.s32 x,x,8; // x = x%8;\n\n ...",
+ "html": "
Divides a by b, store the remainder in d.
\nFor more information, visit rem(int) .",
+ "tooltip": "The remainder of integer division.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-rem"
};
- case "reqnctapercluster":
- return {
- "html": "For more information, visit reqnctapercluster .
Set the number of thread blocks (CTAs) in the cluster by specifying the extent of each dimension of\nthe 1D, 2D, or 3D cluster. The total number of CTAs is the product of the number of CTAs in each\ndimension. For kernels with .reqnctapercluster directive specified, runtime will use the\nspecified values for configuring the launch if the same are not specified at launch time.
\n
Semantics
\n
If cluster dimension is explicitly specified at launch time, it should be equal to the values\nspecified in this directive. Specifying a different cluster dimension at launch will result in a\nruntime error or kernel launch failure.
\n",
- "tooltip": "Declare the number of CTAs in the cluster.\n\nSyntax\n\n.reqnctapercluster nx\n\n.reqnctapercluster nx, ny\n\n.reqnctapercluster nx, ny, nz\n\nDescription\n\nSet the number of thread blocks (CTAs) in the cluster by specifying the extent of each dimension of\n\nthe 1D, 2D, or 3D cluster. The total number of CTAs is the product of the number of CTAs in each\n\ndimension. For kernels with .reqnctapercluster directive specified, runtime will use the\n\nspecified values for configuring the launch if the same are not specified at launch time.\n\nSemantics\n\nIf cluster dimension is explicitly specified at launch time, it should be equal to the values\n\nspecified in this directive. Specifying a different cluster dimension at launch will result in a\n\nruntime error or kernel launch failure.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.8.\n\nTarget ISA Notes\n\nRequires sm_90 or higher.\n\nExamples\n\n.entry foo .reqnctapercluster 2 { . . . }\n\n.entry bar .reqnctapercluster 2, 2, 1 { . . . }\n\n.entry ker .reqnctapercluster 3, 2 { . . . }\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#cluster-dimension-directives-reqnctapercluster"
- };
-
- case "reqntid":
- return {
- "html": "For more information, visit reqntid .
Declare the number of threads in the thread block (CTA) by specifying the extent of each dimension\nof the 1D, 2D, or 3D CTA. The total number of threads is the product of the number of threads in\neach dimension.
\n
Semantics
\n
The size of each CTA dimension specified in any invocation of the kernel is required to be equal to\nthat specified in this directive. Specifying a different CTA dimension at launch will result in a\nruntime error or kernel launch failure.
\n
Notes
\n
The .reqntid directive cannot be used in conjunction with the .maxntid directive.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.1.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.entry foo .reqntid 256 { ... } // num threads = 256\n.entry bar .reqntid 16,16,4 { ... } // num threads = 1024\n
\n
\n",
- "tooltip": "Number of threads in the thread block (CTA).\n\nSyntax\n\n.reqntid nx\n\n.reqntid nx, ny\n\n.reqntid nx, ny, nz\n\nDescription\n\nDeclare the number of threads in the thread block (CTA) by specifying the extent of each dimension\n\nof the 1D, 2D, or 3D CTA. The total number of threads is the product of the number of threads in\n\neach dimension.\n\nSemantics\n\nThe size of each CTA dimension specified in any invocation of the kernel is required to be equal to\n\nthat specified in this directive. Specifying a different CTA dimension at launch will result in a\n\nruntime error or kernel launch failure.\n\nNotes\n\nThe .reqntid directive cannot be used in conjunction with the .maxntid directive.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.1.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.entry foo .reqntid 256 { ... } // num threads = 256\n\n.entry bar .reqntid 16,16,4 { ... } // num threads = 1024\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#performance-tuning-directives-reqntid"
- };
-
- case "reserved_smem_offset_<2>":
- return {
- "html": "For more information, visit reserved_smem_offset_<2> .
Special Registers: %reserved_smem_offset_begin, %reserved_smem_offset_end, %reserved_smem_offset_cap, %reserved_smem_offset_<2>
These are predefined, read-only special registers containing information about the shared memory\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\nCUDA Programming Guide for details.
\n",
- "tooltip": "%reserved_smem_offset_begin\n\nStart of the reserved shared memory region.\n\n%reserved_smem_offset_end\n\nEnd of the reserved shared memory region.\n\n%reserved_smem_offset_cap\n\nTotal size of the reserved shared memory region.\n\n%reserved_smem_offset_<2>\n\nOffsets in the reserved shared memory region.\n\nSyntax (predefined)\n\n.sreg .b32 %reserved_smem_offset_begin;\n\n.sreg .b32 %reserved_smem_offset_end;\n\n.sreg .b32 %reserved_smem_offset_cap;\n\n.sreg .b32 %reserved_smem_offset_<2>;\n\nDescription\n\nThese are predefined, read-only special registers containing information about the shared memory\n\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\n\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\n\nCUDA Programming Guide for details.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.6.\n\nTarget ISA Notes\n\nRequire sm_80 or higher.\n\nExamples\n\n.reg .b32 %reg_begin, %reg_end, %reg_cap, %reg_offset0, %reg_offset1;\n\nmov.b32 %reg_begin, %reserved_smem_offset_begin;\n\nmov.b32 %reg_end, %reserved_smem_offset_end;\n\nmov.b32 %reg_cap, %reserved_smem_offset_cap;\n\nmov.b32 %reg_offset0, %reserved_smem_offset_0;\n\nmov.b32 %reg_offset1, %reserved_smem_offset_1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-reserved-smem-offset-begin-reserved-smem-offset-end-reserved-smem-offset-cap-reserved-smem-offset-2"
- };
-
- case "reserved_smem_offset_begin":
- return {
- "html": "For more information, visit reserved_smem_offset_begin .
Special Registers: %reserved_smem_offset_begin, %reserved_smem_offset_end, %reserved_smem_offset_cap, %reserved_smem_offset_<2>
These are predefined, read-only special registers containing information about the shared memory\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\nCUDA Programming Guide for details.
\n",
- "tooltip": "%reserved_smem_offset_begin\n\nStart of the reserved shared memory region.\n\n%reserved_smem_offset_end\n\nEnd of the reserved shared memory region.\n\n%reserved_smem_offset_cap\n\nTotal size of the reserved shared memory region.\n\n%reserved_smem_offset_<2>\n\nOffsets in the reserved shared memory region.\n\nSyntax (predefined)\n\n.sreg .b32 %reserved_smem_offset_begin;\n\n.sreg .b32 %reserved_smem_offset_end;\n\n.sreg .b32 %reserved_smem_offset_cap;\n\n.sreg .b32 %reserved_smem_offset_<2>;\n\nDescription\n\nThese are predefined, read-only special registers containing information about the shared memory\n\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\n\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\n\nCUDA Programming Guide for details.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.6.\n\nTarget ISA Notes\n\nRequire sm_80 or higher.\n\nExamples\n\n.reg .b32 %reg_begin, %reg_end, %reg_cap, %reg_offset0, %reg_offset1;\n\nmov.b32 %reg_begin, %reserved_smem_offset_begin;\n\nmov.b32 %reg_end, %reserved_smem_offset_end;\n\nmov.b32 %reg_cap, %reserved_smem_offset_cap;\n\nmov.b32 %reg_offset0, %reserved_smem_offset_0;\n\nmov.b32 %reg_offset1, %reserved_smem_offset_1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-reserved-smem-offset-begin-reserved-smem-offset-end-reserved-smem-offset-cap-reserved-smem-offset-2"
- };
-
- case "reserved_smem_offset_cap":
- return {
- "html": "For more information, visit reserved_smem_offset_cap .
Special Registers: %reserved_smem_offset_begin, %reserved_smem_offset_end, %reserved_smem_offset_cap, %reserved_smem_offset_<2>
These are predefined, read-only special registers containing information about the shared memory\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\nCUDA Programming Guide for details.
\n",
- "tooltip": "%reserved_smem_offset_begin\n\nStart of the reserved shared memory region.\n\n%reserved_smem_offset_end\n\nEnd of the reserved shared memory region.\n\n%reserved_smem_offset_cap\n\nTotal size of the reserved shared memory region.\n\n%reserved_smem_offset_<2>\n\nOffsets in the reserved shared memory region.\n\nSyntax (predefined)\n\n.sreg .b32 %reserved_smem_offset_begin;\n\n.sreg .b32 %reserved_smem_offset_end;\n\n.sreg .b32 %reserved_smem_offset_cap;\n\n.sreg .b32 %reserved_smem_offset_<2>;\n\nDescription\n\nThese are predefined, read-only special registers containing information about the shared memory\n\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\n\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\n\nCUDA Programming Guide for details.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.6.\n\nTarget ISA Notes\n\nRequire sm_80 or higher.\n\nExamples\n\n.reg .b32 %reg_begin, %reg_end, %reg_cap, %reg_offset0, %reg_offset1;\n\nmov.b32 %reg_begin, %reserved_smem_offset_begin;\n\nmov.b32 %reg_end, %reserved_smem_offset_end;\n\nmov.b32 %reg_cap, %reserved_smem_offset_cap;\n\nmov.b32 %reg_offset0, %reserved_smem_offset_0;\n\nmov.b32 %reg_offset1, %reserved_smem_offset_1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-reserved-smem-offset-begin-reserved-smem-offset-end-reserved-smem-offset-cap-reserved-smem-offset-2"
- };
-
- case "reserved_smem_offset_end":
- return {
- "html": "For more information, visit reserved_smem_offset_end .
Special Registers: %reserved_smem_offset_begin, %reserved_smem_offset_end, %reserved_smem_offset_cap, %reserved_smem_offset_<2>
These are predefined, read-only special registers containing information about the shared memory\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\nCUDA Programming Guide for details.
\n",
- "tooltip": "%reserved_smem_offset_begin\n\nStart of the reserved shared memory region.\n\n%reserved_smem_offset_end\n\nEnd of the reserved shared memory region.\n\n%reserved_smem_offset_cap\n\nTotal size of the reserved shared memory region.\n\n%reserved_smem_offset_<2>\n\nOffsets in the reserved shared memory region.\n\nSyntax (predefined)\n\n.sreg .b32 %reserved_smem_offset_begin;\n\n.sreg .b32 %reserved_smem_offset_end;\n\n.sreg .b32 %reserved_smem_offset_cap;\n\n.sreg .b32 %reserved_smem_offset_<2>;\n\nDescription\n\nThese are predefined, read-only special registers containing information about the shared memory\n\nregion which is reserved for the NVIDIA system software use. This region of shared memory is not\n\navailable to users, and accessing this region from user code results in undefined behavior. Refer to\n\nCUDA Programming Guide for details.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.6.\n\nTarget ISA Notes\n\nRequire sm_80 or higher.\n\nExamples\n\n.reg .b32 %reg_begin, %reg_end, %reg_cap, %reg_offset0, %reg_offset1;\n\nmov.b32 %reg_begin, %reserved_smem_offset_begin;\n\nmov.b32 %reg_end, %reserved_smem_offset_end;\n\nmov.b32 %reg_cap, %reserved_smem_offset_cap;\n\nmov.b32 %reg_offset0, %reserved_smem_offset_0;\n\nmov.b32 %reg_offset1, %reserved_smem_offset_1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-reserved-smem-offset-begin-reserved-smem-offset-end-reserved-smem-offset-cap-reserved-smem-offset-2"
- };
-
case "ret":
return {
- "html": "For more information, visit ret .
Control Flow Instructions: ret
\n\n\n
Return from function to instruction after call.
\n
Syntax
\n
\n
ret{.uni};\n
\n
\n
Description
\n
Return execution to caller\u2019s environment. A divergent return suspends threads until all threads are\nready to return to the caller. This allows multiple divergent ret instructions.
\n
A ret is assumed to be divergent unless the .uni suffix is present, indicating that the\nreturn is guaranteed to be non-divergent.
\n
Any values returned from a function should be moved into the return parameter variables prior to\nexecuting the ret instruction.
\n
A return instruction executed in a top-level entry routine will terminate thread execution.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
ret;\n@p ret;\n
\n
\n",
- "tooltip": "Return from function to instruction after call.\n\nSyntax\n\nret{.uni};\n\nDescription\n\nReturn execution to caller\u2019s environment. A divergent return suspends threads until all threads are\n\nready to return to the caller. This allows multiple divergent ret instructions.\n\nA ret is assumed to be divergent unless the .uni suffix is present, indicating that the\n\nreturn is guaranteed to be non-divergent.\n\nAny values returned from a function should be moved into the return parameter variables prior to\n\nexecuting the ret instruction.\n\nA return instruction executed in a top-level entry routine will terminate thread execution.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n ret;\n\n@p ret;\n\n ...",
+ "html": "
Return execution to caller\u2019s environment. A divergent return suspends threads until all threads are\nready to return to the caller. This allows multiple divergent ret instructions.
\nFor more information, visit ret .",
+ "tooltip": "Return from function to instruction after call.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#control-flow-instructions-ret"
};
case "rsqrt":
return {
- "html": "For more information, visit rsqrt(fp) , rsqrt.approx.ftz.f64(fp) .
Floating Point Instructions: rsqrt
\n\n\n
Take the reciprocal of the square root of a value.
Compute an approximation of the square root reciprocal of a value.
\n
Syntax
\n
\n
rsqrt.approx.ftz.f64 d, a;\n
\n
\n
Description
\n
Compute a double-precision (.f64) approximation of the square root reciprocal of a value. The\nleast significant 32 bits of the double-precision (.f64) destination d are all zeros.
\n
Semantics
\n
\n
tmp = a[63:32]; // upper word of a, 1.11.20 format\nd[63:32] = 1.0 / sqrt(tmp);\nd[31:0] = 0x00000000;\n
\n
\n
Notes
\n
rsqrt.approx.ftz.f64 implements a fast approximation of the square root reciprocal of a value.
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
NaN
\n
\n
\n
-subnormal
\n
-Inf
\n
\n
\n
-0.0
\n
-Inf
\n
\n
\n
+0.0
\n
+Inf
\n
\n
\n
+subnormal
\n
+Inf
\n
\n
\n
+Inf
\n
+0.0
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
Input NaNs map to a canonical NaN with encoding 0x7fffffff00000000.
\n
Subnormal inputs and results are flushed to sign-preserving zero.
\n
PTX ISA Notes
\n
rsqrt.approx.ftz.f64 introduced in PTX ISA version 4.0.
\n
Target ISA Notes
\n
rsqrt.approx.ftz.f64 requires sm_20 or higher.
\n
Examples
\n
\n
rsqrt.approx.ftz.f64 xi,x;\n
\n
\n",
- "tooltip": "=====Floating Point Instructions: rsqrt\n\n\n\nTake the reciprocal of the square root of a value.\n\nSyntax\n\nrsqrt.approx{.ftz}.f32 d, a;\n\nrsqrt.approx.f64 d, a;\n\nDescription\n\nCompute 1/sqrt(a) and store the result in d.\n\nSemantics\n\nd = 1/sqrt(a);\n\nNotes\n\nrsqrt.approx implements an approximation to the reciprocal square root.\n\n\n\nInput\n\nResult\n\n\n\n-Inf\n\nNaN\n\n-normal\n\nNaN\n\n-subnormal\n\n-Inf\n\n-0.0\n\n-Inf\n\n+0.0\n\n+Inf\n\n+subnormal\n\n+Inf\n\n+Inf\n\n+0.0\n\nNaN\n\nNaN\n\nThe maximum abso...\n\n=====Floating Point Instructions: rsqrt.approx.ftz.f64\n\n\n\nCompute an approximation of the square root reciprocal of a value.\n\nSyntax\n\nrsqrt.approx.ftz.f64 d, a;\n\nDescription\n\nCompute a double-precision (.f64) approximation of the square root reciprocal of a value. The\n\nleast significant 32 bits of the double-precision (.f64) destination d are all zeros.\n\nSemantics\n\ntmp = a[63:32]; // upper word of a, 1.11.20 format\n\nd[63:32] = 1.0 / sqrt(tmp);\n\nd[31:0] = 0x000000... ...",
+ "html": "
Compute 1/sqrt(a) and store the result in d.
\nFor more information, visit rsqrt(fp) .",
+ "tooltip": "Take the reciprocal of the square root of a value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-rsqrt"
};
case "sad":
return {
- "html": "For more information, visit sad(int) .
\n",
- "tooltip": "Sum of absolute differences.\n\nSyntax\n\nsad.type d, a, b, c;\n\n.type = { .u16, .u32, .u64,\n\n .s16, .s32, .s64 };\n\nDescription\n\nAdds the absolute value of a-b to c and writes the resulting value into d.\n\nSemantics\n\nd = c + ((aAdds the absolute value of a-b to c and writes the resulting value into d.\nFor more information, visit sad(int) .",
+ "tooltip": "Sum of absolute differences.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-sad"
};
- case "section":
- return {
- "html": "For more information, visit section .
Debugging Directives: .section
\n\n\n
PTX section definition.
\n
Syntax
\n
\n
.section section_name { dwarf-lines }\n\ndwarf-lines have the following formats:\n .b8 byte-list // comma-separated list of integers\n // in range [-128..255]\n .b16 int16-list // comma-separated list of integers\n // in range [-2^15..2^16-1]\n .b32 int32-list // comma-separated list of integers\n // in range [-2^31..2^32-1]\n label: // Define label inside the debug section\n .b64 int64-list // comma-separated list of integers\n // in range [-2^63..2^64-1]\n .b32 label\n .b64 label\n .b32 label+imm // a sum of label address plus a constant integer byte\n // offset(signed, 32bit)\n .b64 label+imm // a sum of label address plus a constant integer byte\n // offset(signed, 64bit)\n .b32 label1-label2 // a difference in label addresses between labels in\n // the same dwarf section (32bit)\n .b64 label3-label4 // a difference in label addresses between labels in\n // the same dwarf section (64bit)\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0, replaces @@DWARF syntax.
\n
label+imm expression introduced in PTX ISA version 3.2.
\n
Support for .b16 integers in dwarf-lines introduced in PTX ISA version 6.0.
\n
Support for defining label inside the DWARF section is introduced in PTX ISA version 7.2.
\n
label1-label2 expression introduced in PTX ISA version 7.5.
\n
Negative numbers in dwarf lines introduced in PTX ISA version 7.5.
\n",
- "tooltip": "PTX section definition.\n\nSyntax\n\n.section section_name { dwarf-lines }\n\ndwarf-lines have the following formats:\n\n .b8 byte-list // comma-separated list of integers\n\n // in range [-128..255]\n\n .b16 int16-list // comma-separated list of integers\n\n // in range [-2^15..2^16-1]\n\n .b32 int32-list // comma-separated list of integers\n\n // in range [-2^31..2^32-1]\n\n label: // Define label inside the debug section\n\n .b64 int64-list // comma-separated list of integers\n\n // in range [-2^63..2^64-1]\n\n .b32 label\n\n .b64 label\n\n .b32 label+imm // a sum of label address plus a constant integer byte\n\n // offset(signed, 32bit)\n\n .b64 label+imm // a sum of label address plus a constant integer byte\n\n // offset(signed, 64bit)\n\n .b32 label1-label2 // a difference in label addresses between labels in\n\n // the same dwarf section (32bit)\n\n .b64 label3-label4 // a difference in label addresses between labels in\n\n // the same dwarf section (64bit)\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0, replaces @@DWARF syntax.\n\nlabel+imm expression introduced in PTX ISA version 3.2.\n\nSupport for .b16 integers in dwarf-lines introduced in PTX ISA version 6.0.\n\nSupport for defining label inside the DWARF section is introduced in PTX ISA version 7.2.\n\nlabel1-label2 expression introduced in PTX ISA version 7.5.\n\nNegative numbers in dwarf lines introduced in PTX ISA version 7.5.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.section .debug_pubnames\n\n{\n\n .b32 LpubNames_end0-LpubNames_begin0\n\n LpubNames_begin0:\n\n .b8 0x2b, 0x00, 0x00, 0x00, 0x02, 0x00\n\n .b32 .debug_info\n\n info_label1:\n\n .b32 0x000006b5, 0x00000364, 0x61395a5f, 0x5f736f63\n\n .b32 0x6e69616d, 0x63613031, 0x6150736f, 0x736d6172\n\n .b8 0x00, 0x00, 0x00, 0x00, 0x00\n\n LpubNames_end0:\n\n}\n\n.section .debug_info\n\n{\n\n .b32 11430\n\n .b8 2, 0\n\n .b32 .debug_abbrev\n\n .b8 8, 1, 108, 103, 101, 110, 102, 101, 58, 32, 69, 68, 71, 32, 52, 46, 49\n\n .b8 0\n\n .b32 3, 37, 176, -99\n\n .b32 info_label1\n\n .b32 .debug_loc+0x4\n\n .b8 -11, 11, 112, 97\n\n .b32 info_label1+12\n\n .b64 -1\n\n .b16 -5, -65535\n\n}\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#debugging-directives-section"
- };
-
case "selp":
return {
- "html": "For more information, visit selp .
Comparison and Selection Instructions: selp
\n\n\n
Select between source operands, based on the value of the predicate source operand.
Conditional selection. If c is True, a is stored in d, b otherwise. Operands\nd, a, and b must be of the same type. Operand c is a predicate.
\n
Semantics
\n
\n
d = (c == 1) ? a : b;\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
selp.f64 requires sm_13 or higher.
\n
Examples
\n
\n
selp.s32 r0,r,g,p;\n@q selp.f32 f0,t,x,xp;\n
\n
\n",
- "tooltip": "Select between source operands, based on the value of the predicate source operand.\n\nSyntax\n\nselp.type d, a, b, c;\n\n.type = { .b16, .b32, .b64,\n\n .u16, .u32, .u64,\n\n .s16, .s32, .s64,\n\n .f32, .f64 };\n\nDescription\n\nConditional selection. If c is True, a is stored in d, b otherwise. Operands\n\nd, a, and b must be of the same type. Operand c is a predicate.\n\nSemantics\n\nd = (c == 1) ? a : b;\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nselp.f64 requires sm_13 or higher.\n\nExamples\n\n selp.s32 r0,r,g,p;\n\n@q selp.f32 f0,t,x,xp;\n\n ...",
+ "html": "
Conditional selection. If c is True, a is stored in d, b otherwise. Operands\nd, a, and b must be of the same type. Operand c is a predicate.
\nFor more information, visit selp .",
+ "tooltip": "Select between source operands, based on the value of the predicate source operand.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#comparison-and-selection-instructions-selp"
};
case "set":
return {
- "html": "For more information, visit set , set .
Comparison and Selection Instructions: set
\n\n\n
Compare two numeric values with a relational operator, and optionally combine this result with a\npredicate value by applying a Boolean operator.
Compares two numeric values and optionally combines the result with another predicate value by\napplying a Boolean operator. If this result is True, 1.0f is written for floating-point\ndestination types, and 0xffffffff is written for integer destination types. Otherwise,\n0x00000000 is written.
\n
Operand dhas type .dtype; operands a and b have type .stype; operand c has\ntype .pred.
\n
Semantics
\n
\n
t = (a CmpOp b) ? 1 : 0;\nif (isFloat(dtype))\n d = BoolOp(t, c) ? 1.0f : 0x00000000;\nelse\n d = BoolOp(t, c) ? 0xffffffff : 0x00000000;\n
\n
\n
Integer Notes
\n
The signed and unsigned comparison operators are eq, ne, lt, le, gt, ge.
\n
For unsigned values, the comparison operators lo, ls, hi, and hs for lower,\nlower-or-same, higher, and higher-or-same may be used instead of lt, le, gt, ge,\nrespectively.
\n
The untyped, bit-size comparisons are eq and ne.
\n
Floating Point Notes
\n
The ordered comparisons are eq, ne, lt, le, gt, ge. If either operand is NaN, the result is False.
\n
To aid comparison operations in the presence of NaN values, unordered versions are included:\nequ, neu, ltu, leu, gtu, geu. If both operands are numeric values (not\nNaN), then these comparisons have the same result as their ordered counterparts. If either\noperand is NaN, then the result of these comparisons is True.
\n
num returns True if both operands are numeric values (not NaN), and nan returns\nTrue if either operand is NaN.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
set.ftz.dtype.f32 flushes subnormal inputs to sign-preserving zero.
\n
\n
sm_1x
\n
\n
set.dtype.f64 supports subnormal numbers.
\n
set.dtype.f32 flushes subnormal inputs to sign-preserving zero.
\n
\n
\n
Modifier .ftz applies only to .f32 comparisons.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
set with .f64 source type requires sm_13 or higher.
Compare two numeric values with a relational operator, and optionally combine this result with a\npredicate value by applying a Boolean operator.
\n
Syntax
\n
\n
set.CmpOp{.ftz}.f16.stype d, a, b;\nset.CmpOp.BoolOp{.ftz}.f16.stype d, a, b, {!}c;\n\nset.CmpOp.bf16.stype d, a, b;\nset.CmpOp.BoolOp.bf16.stype d, a, b, {!}c;\n\nset.CmpOp{.ftz}.dtype.f16 d, a, b;\nset.CmpOp.BoolOp{.ftz}.dtype.f16 d, a, b, {!}c;\n.dtype = { .u16, .s16, .u32, .s32}\n\nset.CmpOp.dtype.bf16 d, a, b;\nset.CmpOp.BoolOp.dtype.bf16 d, a, b, {!}c;\n.dtype = { .u16, .s16, .u32, .s32}\n\nset.CmpOp{.ftz}.dtype.f16x2 d, a, b;\nset.CmpOp.BoolOp{.ftz}.dtype.f16x2 d, a, b, {!}c;\n.dtype = { .f16x2, .u32, .s32}\n\nset.CmpOp.dtype.bf16x2 d, a, b;\nset.CmpOp.BoolOp.dtype.bf16x2 d, a, b, {!}c;\n.dtype = { .bf16x2, .u32, .s32}\n\n.CmpOp = { eq, ne, lt, le, gt, ge,\n equ, neu, ltu, leu, gtu, geu, num, nan };\n.BoolOp = { and, or, xor };\n.stype = { .b16, .b32, .b64,\n .u16, .u32, .u64,\n .s16, .s32, .s64,\n .f16, .f32, .f64};\n
\n
\n
Description
\n
Compares two numeric values and optionally combines the result with another predicate value by\napplying a Boolean operator.
\n
Result of this computation is written in destination register in the following way:
\n
\n
\n
If result is True,
\n
\n
0xffffffff is written for destination types .u32/.s32.
\n
0xffff is written for destination types .u16/.s16.
\n
1.0 in target precision floating point format is written for destination type .f16,\n.bf16.
\n
\n
\n
\n
If result is False,
\n
\n
0x0 is written for all integer destination types.
\n
0.0 in target precision floating point format is written for destination type .f16,\n.bf16.
\n
\n
\n
\n
If the source type is .f16x2 or .bf16x2 then result of individual operations are packed in\nthe 32-bit destination operand.
\n
Operand c has type .pred.
\n
Semantics
\n
\n
if (stype == .f16x2 || stype == .bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n t[0] = (fA[0] CmpOp fB[0]) ? 1 : 0;\n t[1] = (fA[1] CmpOp fB[1]) ? 1 : 0;\n if (dtype == .f16x2 || stype == .bf16x2) {\n for (i = 0; i < 2; i++) {\n d[i] = BoolOp(t[i], c) ? 1.0 : 0.0;\n }\n } else {\n for (i = 0; i < 2; i++) {\n d[i] = BoolOp(t[i], c) ? 0xffff : 0;\n }\n }\n} else if (dtype == .f16 || stype == .bf16) {\n t = (a CmpOp b) ? 1 : 0;\n d = BoolOp(t, c) ? 1.0 : 0.0;\n} else { // Integer destination type\n trueVal = (isU16(dtype) || isS16(dtype)) ? 0xffff : 0xffffffff;\n t = (a CmpOp b) ? 1 : 0;\n d = BoolOp(t, c) ? trueVal : 0;\n}\n
\n
\n
Floating Point Notes
\n
The ordered comparisons are eq, ne, lt, le, gt, ge. If either operand is\nNaN, the result is False.
\n
To aid comparison operations in the presence of NaN values, unordered versions are included:\nequ, neu, ltu, leu, gtu, geu. If both operands are numeric values (not\nNaN), then these comparisons have the same result as their ordered counterparts. If either\noperand is NaN, then the result of these comparisons is True.
\n
num returns True if both operands are numeric values (not NaN), and nan returns\nTrue if either operand is NaN.
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.
\n
When .ftz modifier is specified then subnormal inputs and results are flushed to sign\npreserving zero.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.2.
\n
set.{u16,u32,s16,s32}.f16 and set.{u32,s32}.f16x2 are introduced in PTX ISA version 6.5.
\n
set.{u16,u32,s16,s32}.bf16, set.{u32,s32,bf16x2}.bf16x2,\nset.bf16.{s16,u16,f16,b16,s32,u32,f32,b32,s64,u64,f64,b64} are introduced in PTX ISA version\n7.8.
\n
Target ISA Notes
\n
Requires sm_53 or higher.
\n
set.{u16,u32,s16,s32}.bf16, set.{u32,s32,bf16x2}.bf16x2,\nset.bf16.{s16,u16,f16,b16,s32,u32,f32,b32,s64,u64,f64,b64} require sm_90 or higher.
\n",
- "tooltip": "Compare two numeric values with a relational operator, and optionally combine this result with a\n\npredicate value by applying a Boolean operator.\n\nSyntax\n\nset.CmpOp{.ftz}. ...",
+ "html": "
Compares two numeric values and optionally combines the result with another predicate value by\napplying a Boolean operator. If this result is True, 1.0f is written for floating-point\ndestination types, and 0xffffffff is written for integer destination types. Otherwise,\n0x00000000 is written.
\nFor more information, visit set .",
+ "tooltip": "Compares two numeric values and optionally combines the result with another predicate value by\n\napplying a Boolean operator. If this result isTrue,1.0fis written for floating-point\n\ndestination types, a...",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#comparison-and-selection-instructions-set"
};
case "setmaxnreg":
return {
- "html": "For more information, visit setmaxnreg .
Miscellaneous Instructions: setmaxnreg
\n\n\n
Hint to change the number of registers owned by the warp.
setmaxnreg provides a hint to the system to update the maximum number of per-thread registers\nowned by the executing warp to the value specified by the imm-reg-count operand.
\n
Qualifier .dec is used to release extra registers such that the absolute per-thread maximum\nregister count is reduced from its current value to imm-reg-count. Qualifier .inc is used to\nrequest additional registers such that the absolute per-thread maximum register count is increased\nfrom its current value to imm-reg-count.
\n
A pool of available registers is maintained per-CTA. Register adjustments requested by the\nsetmaxnreg instructions are handled by supplying extra registers from this pool to the\nrequesting warp or by releasing extra registers from the requesting warp to this pool, depending\nupon the value of the .action qualifier.
\n
The setmaxnreg.inc instruction blocks the execution until enough registers are available in the\nCTA\u2019s register pool. After the instruction setmaxnreg.inc obtains new registers from the CTA\npool, the initial contents of the new registers are undefined. The new registers must be initialized\nbefore they are used.
\n
The same setmaxnreg instruction must be executed by all warps in a warpgroup. After executing a\nsetmaxnreg instruction, all warps in the warpgroup must synchronize explicitly before\nexecuting subsequent setmaxnreg instructions. If a setmaxnreg instruction is not executed by all\nwarps in the warpgroup, then the behavior is undefined.
\n
Operand imm-reg-count is an integer constant. The value of imm-reg-count must be in the\nrange 24 to 256 (both inclusive) and must be a multiple of 8.
\n
Changes to the register file of the warp always happen at the tail-end of the register file.
\n
The setmaxnreg instruction requires that the kernel has been launched with a valid value of\nmaximum number of per-thread registers specified via the appropriate compilation via the appropriate\ncompile-time option or the appropriate performance tuning directive. Otherwise, the setmaxnreg\ninstruction may have no effect.
\n
When qualifier .dec is specified, the maximum number of per-thread registers owned by the warp\nprior to the execution of setmaxnreg instruction should be greater than or equal to the\nimm-reg-count. Otherwise, the behaviour is undefined.
\n
When qualifier .inc is specified, the maximum number of per-thread registers owned by the warp\nprior to the execution of setmaxnreg instruction should be less than or equal to the\nimm-reg-count. Otherwise, the behaviour is undefined.
\n
The mandatory .sync qualifier indicates that setmaxnreg instruction causes the executing\nthread to wait until all threads in the warp execute the same setmaxnreg instruction before\nresuming execution.
\n
The mandatory .aligned qualifier indicates that all threads in the warpgroup must execute the\nsame setmaxnreg instruction. In conditionally executed code, setmaxnreg instruction should\nonly be used if it is known that all threads in warpgroup evaluate the condition identically,\notherwise the behavior is undefined.
\n",
- "tooltip": "Hint to change the number of registers owned by the warp.\n\nSyntax\n\nsetmaxnreg.action.sync.aligned.u32 imm-reg-count;\n\n.action = { .inc, .dec };\n\nDescription\n\nsetmaxnreg provides a hint to the system to update the maximum number of per-thread registers\n\nowned by the executing warp to the value specified by the imm-reg-count operand.\n\nQualifier .dec is used to release extra registers such that the absolute per-thread maximum\n\nregister count is reduced from its current value to imm-reg-count. Qualifier .inc is used to\n\nrequest additional registers such that the absolute per-thread maximum register count is increased\n\nfrom its current value to imm-reg-count.\n\nA pool of available registers is maintained per-CTA. Register adjustments requested by the\n\nsetmaxnreg instructions are handled by supplying extra registers from this pool to the\n\nrequesting warp or by releasing extra registers from the requesting warp to this pool, depending\n\nupon the value of the .action qualifier.\n\nThe setmaxnreg.inc instruction blocks the execution until enough registers are available in the\n\nCTA\u2019s register pool. After the instruction setmaxnreg.inc obtains new registers from the CTA\n\npool, the initial contents of the new registers are undefined. The new registers must be initialized\n\nbefore they are used.\n\nThe same setmaxnreg instruction must be executed by all warps in a warpgroup. After executing a\n\nsetmaxnreg instruction, all warps in the warpgroup must synchronize explicitly before\n\nexecuting subsequent setmaxnreg instructions. If a setmaxnreg instruction is not executed by all\n\nwarps in the warpgroup, then the behavior is undefined.\n\nOperand imm-reg-count is an integer constant. The value of imm-reg-count must be in the\n\nrange 24 to 256 (both inclusive) and must be a multiple of 8.\n\nChanges to the register file of the warp always happen at the tail-end of the register file.\n\nThe setmaxnreg instruction requires that the kernel has been launched with a valid value of\n\nmaximum number of per-thread registers specified via the appropriate compilation via the appropriate\n\ncompile-time option or the appropriate performance tuning directive. Otherwise, the setmaxnreg\n\ninstruction may have no effect.\n\nWhen qualifier .dec is specified, the maximum number of per-thread registers owned by the warp\n\nprior to the execution of setmaxnreg instruction should be greater than or equal to the\n\nimm-reg-count. Otherwise, the behaviour is undefined.\n\nWhen qualifier .inc is specified, the maximum number of per-thread registers owned by the warp\n\nprior to the execution of setmaxnreg instruction should be less than or equal to the\n\nimm-reg-count. Otherwise, the behaviour is undefined.\n\nThe mandatory .sync qualifier indicates that setmaxnreg instruction causes the executing\n\nthread to wait until all threads in the warp execute the same setmaxnreg instruction before\n\nresuming execution.\n\nThe mandatory .aligned qualifier indicates that all threads in the warpgroup must execute the\n\nsame setmaxnreg instruction. In conditionally executed code, setmaxnreg instruction should\n\nonly be used if it is known that all threads in warpgroup evaluate the condition identically,\n\notherwise the behavior is undefined.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 8.0.\n\nTarget ISA Notes\n\nRequires sm_90a.\n\nExamples\n\nsetmaxnreg.dec.sync.aligned.u32 64;\n\nsetmaxnreg.inc.sync.aligned.u32 192;\n\n ...",
+ "html": "
setmaxnreg provides a hint to the system to update the maximum number of per-thread registers\nowned by the executing warp to the value specified by the imm-reg-count operand.
\nFor more information, visit setmaxnreg .",
+ "tooltip": "Hint to change the number of registers owned by the warp.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#miscellaneous-instructions-setmaxnreg"
};
case "setp":
return {
- "html": "For more information, visit setp , setp .
Comparison and Selection Instructions: setp
\n\n\n
Compare\u00a0two numeric values with a relational operator, and (optionally) combine this result with a\npredicate value by applying a Boolean operator.
Compares two values and combines the result with another predicate value by applying a Boolean\noperator. This result is written to the first destination operand. A related value computed using\nthe complement of the compare result is written to the second destination operand.
\n
Applies to all numeric types. Operands a and b have type .type; operands p, q,\nand c have type .pred. The sink symbol \u2018_\u2019 may be used in place of any one of the\ndestination operands.
\n
Semantics
\n
\n
t = (a CmpOp b) ? 1 : 0;\np = BoolOp(t, c);\nq = BoolOp(!t, c);\n
\n
\n
Integer Notes
\n
The signed and unsigned comparison operators are eq, ne, lt, le, gt, ge.
\n
For unsigned values, the comparison operators lo, ls, hi, and hs for lower,\nlower-or-same, higher, and higher-or-same may be used instead of lt, le, gt, ge,\nrespectively.
\n
The untyped, bit-size comparisons are eq and ne.
\n
Floating Point Notes
\n
The ordered comparisons are eq, ne, lt, le, gt, ge. If either operand is NaN, the result is False.
\n
To aid comparison operations in the presence of NaN values, unordered versions are included:\nequ, neu, ltu, leu, gtu, geu. If both operands are numeric values (not\nNaN), then these comparisons have the same result as their ordered counterparts. If either\noperand is NaN, then the result of these comparisons is True.
\n
num returns True if both operands are numeric values (not NaN), and nan returns\nTrue if either operand is NaN.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
setp.ftz.dtype.f32 flushes subnormal inputs to sign-preserving zero.
\n
\n
sm_1x
\n
\n
setp.dtype.f64 supports subnormal numbers.
\n
setp.dtype.f32 flushes subnormal inputs to sign-preserving zero.
\n
\n
\n
Modifier .ftz applies only to .f32 comparisons.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
setp with .f64 source type requires sm_13 or higher.
Compare two numeric values with a relational operator, and optionally combine this result with a\npredicate value by applying a Boolean operator.
\n
Syntax
\n
\n
setp.CmpOp{.ftz}.f16 p, a, b;\nsetp.CmpOp.BoolOp{.ftz}.f16 p, a, b, {!}c;\n\nsetp.CmpOp{.ftz}.f16x2 p|q, a, b;\nsetp.CmpOp.BoolOp{.ftz}.f16x2 p|q, a, b, {!}c;\n\nsetp.CmpOp.bf16 p, a, b;\nsetp.CmpOp.BoolOp.bf16 p, a, b, {!}c;\n\nsetp.CmpOp.bf16x2 p|q, a, b;\nsetp.CmpOp.BoolOp.bf16x2 p|q, a, b, {!}c;\n\n.CmpOp = { eq, ne, lt, le, gt, ge,\n equ, neu, ltu, leu, gtu, geu, num, nan };\n.BoolOp = { and, or, xor };\n
\n
\n
Description
\n
Compares two values and combines the result with another predicate value by applying a Boolean\noperator. This result is written to the destination operand.
\n
Operand c, p and q has type .pred.
\n
For instruction type .f16, operands a and b have type .b16 or .f16.
\n
For instruction type .f16x2, operands a and b have type .b32.
\n
For instruction type .bf16, operands a and b have type .b16.
\n
For instruction type .bf16x2, operands a and b have type .b32.
\n
Semantics
\n
\n
if (type == .f16 || type == .bf16) {\n t = (a CmpOp b) ? 1 : 0;\n p = BoolOp(t, c);\n} else if (type == .f16x2 || type == .bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n t[0] = (fA[0] CmpOp fB[0]) ? 1 : 0;\n t[1] = (fA[1] CmpOp fB[1]) ? 1 : 0;\n p = BoolOp(t[0], c);\n q = BoolOp(t[1], c);\n}\n
\n
\n
Floating Point Notes
\n
The ordered comparisons are eq, ne, lt, le, gt, ge. If either operand is\nNaN, the result is False.
\n
To aid comparison operations in the presence of NaN values, unordered versions are included:\nequ, neu, ltu, leu, gtu, geu. If both operands are numeric values (not\nNaN), then these comparisons have the same result as their ordered counterparts. If either\noperand is NaN, then the result of these comparisons is True.
\n
num returns True if both operands are numeric values (not NaN), and nan returns\nTrue if either operand is NaN.
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.
\n
setp.ftz.{f16,f16x2} flushes subnormal inputs to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.2.
\n
setp.{bf16/bf16x2} introduced in PTX ISA version 7.8.
\n",
- "tooltip": "=====Comparison and Selection Instructions: setp\n\n\n\nCompare\u00a0two numeric values with a relational operator, and (optionally) combine this result with a\n\npredicate value by applying a Boolean operator.\n\nSyntax\n\nsetp.CmpOp{.ftz}.type p[|q], a, b;\n\nsetp.CmpOp.BoolOp{.ftz}.type p[|q], a, b, {!}c;\n\n.CmpOp = { eq, ne, lt, le, gt, ge, lo, ls, hi, hs,\n\n equ, neu, ltu, leu, gtu, geu, num, nan };\n\n.BoolOp = { and, or, xor };\n\n.type = { .b16, .b...\n\n=====Half Precision Comparison Instructions: setp\n\n\n\nCompare two numeric values with a relational operator, and optionally combine this result with a\n\npredicate value by applying a Boolean operator.\n\nSyntax\n\nsetp.CmpOp{.ftz}.f16 p, a, b;\n\nsetp.CmpOp.BoolOp{.ftz}.f16 p, a, b, {!}c;\n\nsetp.CmpOp{.ftz}.f16x2 p|q, a, b;\n\nsetp.CmpOp.BoolOp{.ftz}.f16x2 p|q, a, b, {!}c;\n\nsetp.CmpOp.bf16 p, a, b;\n\nsetp.CmpOp.BoolOp.bf16 p... ...",
+ "html": "
Compares two values and combines the result with another predicate value by applying a Boolean\noperator. This result is written to the first destination operand. A related value computed using\nthe complement of the compare result is written to the second destination operand.
\nFor more information, visit setp .",
+ "tooltip": "Compares two values and combines the result with another predicate value by applying a Boolean\n\noperator. This result is written to the first destination operand. A related value computed using\n\nthe com...",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#comparison-and-selection-instructions-setp"
};
case "shf":
return {
- "html": "For more information, visit shf .
Logic and Shift Instructions: shf
\n\n\n
Funnel shift.
\n
Syntax
\n
\n
shf.l.mode.b32 d, a, b, c; // left shift\nshf.r.mode.b32 d, a, b, c; // right shift\n\n.mode = { .clamp, .wrap };\n
\n
\n
Description
\n
Shift the 64-bit value formed by concatenating operands a and b left or right by the amount\nspecified by the unsigned 32-bit value in c. Operand b holds bits 63:32 and operand a\nholds bits 31:0 of the 64-bit source value. The source is shifted left or right by the clamped\nor wrapped value in c. For shf.l, the most-significant 32-bits of the result are written\ninto d; for shf.r, the least-significant 32-bits of the result are written into d.
\n
Semantics
\n
\n
u32 n = (.mode == .clamp) ? min(c, 32) : c & 0x1f;\nswitch (shf.dir) { // shift concatenation of [b, a]\n case shf.l: // extract 32 msbs\n u32 d = (b << n) | (a >> (32-n));\n case shf.r: // extract 32 lsbs\n u32 d = (b << (32-n)) | (a >> n);\n}\n
\n
\n
Notes
\n
Use funnel shift for multi-word shift operations and for rotate operations. The shift amount is\nlimited to the range 0..32 in clamp mode and 0..31 in wrap mode, so shifting multi-word\nvalues by distances greater than 32 requires first moving 32-bit words, then using shf to shift\nthe remaining 0..31 distance.
\n
To shift data sizes greater than 64 bits to the right, use repeated shf.r instructions applied\nto adjacent words, operating from least-significant word towards most-significant word. At each\nstep, a single word of the shifted result is computed. The most-significant word of the result is\ncomputed using a shr.{u32,s32} instruction, which zero or sign fills based on the instruction\ntype.
\n
To shift data sizes greater than 64 bits to the left, use repeated shf.l instructions applied to\nadjacent words, operating from most-significant word towards least-significant word. At each step, a\nsingle word of the shifted result is computed. The least-significant word of the result is computed\nusing a shl instruction.
\n
Use funnel shift to perform 32-bit left or right rotate by supplying the same value for source\narguments a and b.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.1.
\n
Target ISA Notes
\n
Requires sm_32 or higher.
\n
Example
\n
\n
shf.l.clamp.b32 r3,r1,r0,16;\n\n// 128-bit left shift; n < 32\n// [r7,r6,r5,r4] = [r3,r2,r1,r0] << n\nshf.l.clamp.b32 r7,r2,r3,n;\nshf.l.clamp.b32 r6,r1,r2,n;\nshf.l.clamp.b32 r5,r0,r1,n;\nshl.b32 r4,r0,n;\n\n// 128-bit right shift, arithmetic; n < 32\n// [r7,r6,r5,r4] = [r3,r2,r1,r0] >> n\nshf.r.clamp.b32 r4,r0,r1,n;\nshf.r.clamp.b32 r5,r1,r2,n;\nshf.r.clamp.b32 r6,r2,r3,n;\nshr.s32 r7,r3,n; // result is sign-extended\n\nshf.r.clamp.b32 r1,r0,r0,n; // rotate right by n; n < 32\nshf.l.clamp.b32 r1,r0,r0,n; // rotate left by n; n < 32\n\n// extract 32-bits from [r1,r0] starting at position n < 32\nshf.r.clamp.b32 r0,r0,r1,n;\n
\n
\n",
- "tooltip": "Funnel shift.\n\nSyntax\n\nshf.l.mode.b32 d, a, b, c; // left shift\n\nshf.r.mode.b32 d, a, b, c; // right shift\n\n.mode = { .clamp, .wrap };\n\nDescription\n\nShift the 64-bit value formed by concatenating operands a and b left or right by the amount\n\nspecified by the unsigned 32-bit value in c. Operand b holds bits 63:32 and operand a\n\nholds bits 31:0 of the 64-bit source value. The source is shifted left or right by the clamped\n\nor wrapped value in c. For shf.l, the most-significant 32-bits of the result are written\n\ninto d; for shf.r, the least-significant 32-bits of the result are written into d.\n\nSemantics\n\nu32 n = (.mode == .clamp) ? min(c, 32) : c & 0x1f;\n\nswitch (shf.dir) { // shift concatenation of [b, a]\n\n case shf.l: // extract 32 msbs\n\n u32 d = (b << n) | (a >> (32-n));\n\n case shf.r: // extract 32 lsbs\n\n u32 d = (b << (32-n)) | (a >> n);\n\n}\n\nNotes\n\nUse funnel shift for multi-word shift operations and for rotate operations. The shift amount is\n\nlimited to the range 0..32 in clamp mode and 0..31 in wrap mode, so shifting multi-word\n\nvalues by distances greater than 32 requires first moving 32-bit words, then using shf to shift\n\nthe remaining 0..31 distance.\n\nTo shift data sizes greater than 64 bits to the right, use repeated shf.r instructions applied\n\nto adjacent words, operating from least-significant word towards most-significant word. At each\n\nstep, a single word of the shifted result is computed. The most-significant word of the result is\n\ncomputed using a shr.{u32,s32} instruction, which zero or sign fills based on the instruction\n\ntype.\n\nTo shift data sizes greater than 64 bits to the left, use repeated shf.l instructions applied to\n\nadjacent words, operating from most-significant word towards least-significant word. At each step, a\n\nsingle word of the shifted result is computed. The least-significant word of the result is computed\n\nusing a shl instruction.\n\nUse funnel shift to perform 32-bit left or right rotate by supplying the same value for source\n\narguments a and b.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.1.\n\nTarget ISA Notes\n\nRequires sm_32 or higher.\n\nExample\n\nshf.l.clamp.b32 r3,r1,r0,16;\n\n// 128-bit left shift; n < 32\n\n// [r7,r6,r5,r4] = [r3,r2,r1,r0] << n\n\nshf.l.clamp.b32 r7,r2,r3,n;\n\nshf.l.clamp.b32 r6,r1,r2,n;\n\nshf.l.clamp.b32 r5,r0,r1,n;\n\nshl.b32 r4,r0,n;\n\n// 128-bit right shift, arithmetic; n < 32\n\n// [r7,r6,r5,r4] = [r3,r2,r1,r0] >> n\n\nshf.r.clamp.b32 r4,r0,r1,n;\n\nshf.r.clamp.b32 r5,r1,r2,n;\n\nshf.r.clamp.b32 r6,r2,r3,n;\n\nshr.s32 r7,r3,n; // result is sign-extended\n\nshf.r.clamp.b32 r1,r0,r0,n; // rotate right by n; n < 32\n\nshf.l.clamp.b32 r1,r0,r0,n; // rotate left by n; n < 32\n\n// extract 32-bits from [r1,r0] starting at position n < 32\n\nshf.r.clamp.b32 r0,r0,r1,n;\n\n ...",
+ "html": "
Shift the 64-bit value formed by concatenating operands a and b left or right by the amount\nspecified by the unsigned 32-bit value in c. Operand b holds bits 63:32 and operand a\nholds bits 31:0 of the 64-bit source value. The source is shifted left or right by the clamped\nor wrapped value in c. For shf.l, the most-significant 32-bits of the result are written\ninto d; for shf.r, the least-significant 32-bits of the result are written into d.
\nFor more information, visit shf .",
+ "tooltip": "Funnel shift.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-shf"
};
case "shfl":
return {
- "html": "For more information, visit shfl.sync .
Data Movement and Conversion Instructions: shfl.sync
shfl.sync will cause executing thread to wait until all non-exited threads corresponding to\nmembermask have executed shfl.sync with the same qualifiers and same membermask value\nbefore resuming execution.
\n
Operand membermask specifies a 32-bit integer which is a mask indicating threads participating\nin barrier where the bit position corresponds to thread\u2019s laneid.
\n
shfl.sync exchanges register data between threads in membermask.
\n
Each thread in the currently executing warp will compute a source lane index j based on input\noperands b and c and the mode. If the computed source lane index j is in range, the\nthread will copy the input operand a from lane j into its own destination register d;\notherwise, the thread will simply copy its own input a to destination d. The optional\ndestination predicate p is set to True if the computed source lane is in range, and\notherwise set to False.
\n
Note that an out of range value of b may still result in a valid computed source lane index\nj. In this case, a data transfer occurs and the destination predicate p is True.
\n
Note that results are undefined if a thread sources a register from an inactive thread or a thread\nthat is not in membermask.
\n
Operand b specifies a source lane or source lane offset, depending on the mode.
\n
Operand c contains two packed values specifying a mask for logically splitting warps into\nsub-segments and an upper bound for clamping the source lane index.
\n
The behavior of shfl.sync is undefined if the executing thread is not in the membermask.
\n
\n
Note
\n
For .target sm_6x or below, all threads in membermask must execute the same shfl.sync\ninstruction in convergence, and only threads belonging to some membermask can be active when\nthe shfl.sync instruction is executed. Otherwise, the behavior is undefined.
\n
\n
Semantics
\n
\n
// wait for all threads in membermask to arrive\nwait_for_specified_threads(membermask);\n\nlane[4:0] = [Thread].laneid; // position of thread in warp\nbval[4:0] = b[4:0]; // source lane or lane offset (0..31)\ncval[4:0] = c[4:0]; // clamp value\nsegmask[4:0] = c[12:8];\n\n// get value of source register a if thread is active and\n// guard predicate true, else unpredictable\nif (isActive(Thread) && isGuardPredicateTrue(Thread)) {\n SourceA[lane] = a;\n} else {\n // Value of SourceA[lane] is unpredictable for\n // inactive/predicated-off threads in warp\n}\nmaxLane = (lane[4:0] & segmask[4:0]) | (cval[4:0] & ~segmask[4:0]);\nminLane = (lane[4:0] & segmask[4:0]);\n\nswitch (.mode) {\n case .up: j = lane - bval; pval = (j >= maxLane); break;\n case .down: j = lane + bval; pval = (j <= maxLane); break;\n case .bfly: j = lane ^ bval; pval = (j <= maxLane); break;\n case .idx: j = minLane | (bval[4:0] & ~segmask[4:0]);\n pval = (j <= maxLane); break;\n}\nif (!pval) j = lane; // copy from own lane\nd = SourceA[j]; // copy input a from lane j\nif (dest predicate selected)\n p = pval;\n
\n",
- "tooltip": "Register data shuffle within threads of a warp.\n\nSyntax\n\nshfl.sync.mode.b32 d[|p], a, b, c, membermask;\n\n.mode = { .up, .down, .bfly, .idx };\n\nDescription\n\nExchange register data between threads of a warp.\n\nshfl.sync will cause executing thread to wait until all non-exited threads corresponding to\n\nmembermask have executed shfl.sync with the same qualifiers and same membermask value\n\nbefore resuming execution.\n\nOperand membermask specifies a 32-bit integer which is a mask indicating threads participating\n\nin barrier where the bit position corresponds to thread\u2019s laneid.\n\nshfl.sync exchanges register data between threads in membermask.\n\nEach thread in the currently executing warp will compute a source lane index j based on input\n\noperands b and c and the mode. If the computed source lane index j is in range, the\n\nthread will copy the input operand a from lane j into its own destination register d;\n\notherwise, the thread will simply copy its own input a to destination d. The optional\n\ndestination predicate p is set to True if the computed source lane is in range, and\n\notherwise set to False.\n\nNote that an out of range value of b may still result in a valid computed source lane index\n\nj. In this case, a data transfer occurs and the destination predicate p is True.\n\nNote that results are undefined if a thread sources a register from an inactive thread or a thread\n\nthat is not in membermask.\n\nOperand b specifies a source lane or source lane offset, depending on the mode.\n\nOperand c contains two packed values specifying a mask for logically splitting warps into\n\nsub-segments and an upper bound for clamping the source lane index.\n\nThe behavior of shfl.sync is undefined if the executing thread is not in the membermask.\n\nNote\n\nFor .target sm_6x or below, all threads in membermask must execute the same shfl.sync\n\ninstruction in convergence, and only threads belonging to some membermask can be active when\n\nthe shfl.sync instruction is executed. Otherwise, the behavior is undefined.\n\nSemantics\n\n// wait for all threads in membermask to arrive\n\nwait_for_specified_threads(membermask);\n\nlane[4:0] = [Thread].laneid; // position of thread in warp\n\nbval[4:0] = b[4:0]; // source lane or lane offset (0..31)\n\ncval[4:0] = c[4:0]; // clamp value\n\nsegmask[4:0] = c[12:8];\n\n// get value of source register a if thread is active and\n\n// guard predicate true, else unpredictable\n\nif (isActive(Thread) && isGuardPredicateTrue(Thread)) {\n\n SourceA[lane] = a;\n\n} else {\n\n // Value of SourceA[lane] is unpredictable for\n\n // inactive/predicated-off threads in warp\n\n}\n\nmaxLane = (lane[4:0] & segmask[4:0]) | (cval[4:0] & ~segmask[4:0]);\n\nminLane = (lane[4:0] & segmask[4:0]);\n\nswitch (.mode) {\n\n case .up: j = lane - bval; pval = (j >= maxLane); break;\n\n case .down: j = lane + bval; pval = (j <= maxLane); break;\n\n case .bfly: j = lane ^ bval; pval = (j <= maxLane); break;\n\n case .idx: j = minLane | (bval[4:0] & ~segmask[4:0]);\n\n pval = (j <= maxLane); break;\n\n}\n\nif (!pval) j = lane; // copy from own lane\n\nd = SourceA[j]; // copy input a from lane j\n\nif (dest predicate selected)\n\n p = pval;\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 6.0.\n\nTarget ISA Notes\n\nRequires sm_30 or higher.\n\nExamples\n\nshfl.sync.up.b32 Ry|p, Rx, 0x1, 0x0, 0xffffffff;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-shfl-sync"
+ "html": "
Exchange register data between threads of a warp.
\nFor more information, visit shfl .",
+ "tooltip": "Register data shuffle within threads of a warp.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-shfl"
};
case "shl":
return {
- "html": "For more information, visit shl .
Logic and Shift Instructions: shl
\n\n\n
Shift bits left, zero-fill on right.
\n
Syntax
\n
\n
shl.type d, a, b;\n\n.type = { .b16, .b32, .b64 };\n
\n
\n
Description
\n
Shift a left by the amount specified by unsigned 32-bit value in b.
\n
Semantics
\n
\n
d = a << b;\n
\n
\n
Notes
\n
Shift amounts greater than the register width N are clamped to N.
\n
The sizes of the destination and first source operand must match, but not necessarily the type. The\nb operand must be a 32-bit value, regardless of the instruction type.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Example
\n
\n
shl.b32 q,a,2;\n
\n
\n",
- "tooltip": "Shift bits left, zero-fill on right.\n\nSyntax\n\nshl.type d, a, b;\n\n.type = { .b16, .b32, .b64 };\n\nDescription\n\nShift a left by the amount specified by unsigned 32-bit value in b.\n\nSemantics\n\nd = a << b;\n\nNotes\n\nShift amounts greater than the register width N are clamped to N.\n\nThe sizes of the destination and first source operand must match, but not necessarily the type. The\n\nb operand must be a 32-bit value, regardless of the instruction type.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExample\n\nshl.b32 q,a,2;\n\n ...",
+ "html": "
Shift a left by the amount specified by unsigned 32-bit value in b.
\nFor more information, visit shl .",
+ "tooltip": "Shift bits left, zero-fill on right.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-shl"
};
case "shr":
return {
- "html": "For more information, visit shr .
Shift a right by the amount specified by unsigned 32-bit value in b. Signed shifts fill with\nthe sign bit, unsigned and untyped shifts fill with 0.
\n
Semantics
\n
\n
d = a >> b;\n
\n
\n
Notes
\n
Shift amounts greater than the register width N are clamped to N.
\n
The sizes of the destination and first source operand must match, but not necessarily the type. The\nb operand must be a 32-bit value, regardless of the instruction type.
\n
Bit-size types are included for symmetry with shl.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Example
\n
\n
shr.u16 c,a,2;\nshr.s32 i,i,1;\nshr.b16 k,i,j;\n
\n
\n",
- "tooltip": "Shift bits right, sign or zero-fill on left.\n\nSyntax\n\nshr.type d, a, b;\n\n.type = { .b16, .b32, .b64,\n\n .u16, .u32, .u64,\n\n .s16, .s32, .s64 };\n\nDescription\n\nShift a right by the amount specified by unsigned 32-bit value in b. Signed shifts fill with\n\nthe sign bit, unsigned and untyped shifts fill with 0.\n\nSemantics\n\nd = a >> b;\n\nNotes\n\nShift amounts greater than the register width N are clamped to N.\n\nThe sizes of the destination and first source operand must match, but not necessarily the type. The\n\nb operand must be a 32-bit value, regardless of the instruction type.\n\nBit-size types are included for symmetry with shl.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExample\n\nshr.u16 c,a,2;\n\nshr.s32 i,i,1;\n\nshr.b16 k,i,j;\n\n ...",
+ "html": "
Shift a right by the amount specified by unsigned 32-bit value in b. Signed shifts fill with\nthe sign bit, unsigned and untyped shifts fill with 0.
\nFor more information, visit shr .",
+ "tooltip": "Shift bits right, sign or zero-fill on left.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-shr"
};
case "sin":
return {
- "html": "For more information, visit sin(fp) .
Floating Point Instructions: sin
\n\n\n
Find the sine of a value.
\n
Syntax
\n
\n
sin.approx{.ftz}.f32 d, a;\n
\n
\n
Description
\n
Find the sine of the angle a (in radians).
\n
Semantics
\n
\n
d = sin(a);\n
\n
\n
Notes
\n
sin.approx.f32 implements a fast approximation to sine.
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
NaN
\n
\n
\n
-subnormal
\n
-0.0
\n
\n
\n
-0.0
\n
-0.0
\n
\n
\n
+0.0
\n
+0.0
\n
\n
\n
+subnormal
\n
+0.0
\n
\n
\n
+Inf
\n
NaN
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
The maximum absolute error is 2-20.9 in quadrant 00.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
sin.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
Subnormal inputs and results to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
sin.f32 introduced in PTX ISA version 1.0. Explicit modifiers .approx and .ftz\nintroduced in PTX ISA version 1.4.
\n
For PTX ISA version 1.4 and later, the .approx modifier is required.
\n
For PTX ISA versions 1.0 through 1.3, sin.f32 defaults to sin.approx.ftz.f32.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
sin.approx.ftz.f32 sa, a;\n
\n
\n",
- "tooltip": "Find the sine of a value.\n\nSyntax\n\nsin.approx{.ftz}.f32 d, a;\n\nDescription\n\nFind the sine of the angle a (in radians).\n\nSemantics\n\nd = sin(a);\n\nNotes\n\nsin.approx.f32 implements a fast approximation to sine.\n\n\n\nInput\n\nResult\n\n\n\n-Inf\n\nNaN\n\n-subnormal\n\n-0.0\n\n-0.0\n\n-0.0\n\n+0.0\n\n+0.0\n\n+subnormal\n\n+0.0\n\n+Inf\n\nNaN\n\nNaN\n\nNaN\n\nThe maximum absolute error is 2-20.9 in quadrant 00.\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, subnormal numbers are supported.\n\nsin.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.\n\nsm_1x\n\nSubnormal inputs and results to sign-preserving zero.\n\nPTX ISA Notes\n\nsin.f32 introduced in PTX ISA version 1.0. Explicit modifiers .approx and .ftz\n\nintroduced in PTX ISA version 1.4.\n\nFor PTX ISA version 1.4 and later, the .approx modifier is required.\n\nFor PTX ISA versions 1.0 through 1.3, sin.f32 defaults to sin.approx.ftz.f32.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nsin.approx.ftz.f32 sa, a;\n\n ...",
+ "html": "
Find the sine of the angle a (in radians).
\nFor more information, visit sin(fp) .",
+ "tooltip": "Find the sine of a value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-sin"
};
case "slct":
return {
- "html": "For more information, visit slct .
Comparison and Selection Instructions: slct
\n\n\n
Select one source operand, based on the sign of the third operand.
Conditional selection. If c \u2265 0, a is stored in d, otherwise b is stored in\nd. Operands d, a, and b are treated as a bitsize type of the same width as the first\ninstruction type; operand c must match the second instruction type (.s32 or .f32). The\nselected input is copied to the output without modification.
\n
Semantics
\n
\n
d = (c >= 0) ? a : b;\n
\n
\n
Floating Point Notes
\n
For .f32 comparisons, negative zero equals zero.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
slct.ftz.dtype.f32 flushes subnormal values of operand c to sign-preserving zero, and\noperand a is selected.
\n
\n
sm_1x
\n
\n
slct.dtype.f32 flushes subnormal values of operand c to sign-preserving zero, and operand\na is selected.
\n
\n
\n
Modifier .ftz applies only to .f32 comparisons.
\n
If operand c is NaN, the comparison is unordered and operand b is selected.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
slct.f64 requires sm_13 or higher.
\n
Examples
\n
\n
slct.u32.s32 x, y, z, val;\nslct.ftz.u64.f32 A, B, C, fval;\n
\n
\n",
- "tooltip": "Select one source operand, based on the sign of the third operand.\n\nSyntax\n\nslct.dtype.s32 d, a, b, c;\n\nslct{.ftz}.dtype.f32 d, a, b, c;\n\n.dtype = { .b16, .b32, .b64,\n\n .u16, .u32, .u64,\n\n .s16, .s32, .s64,\n\n .f32, .f64 };\n\nDescription\n\nConditional selection. If c \u2265 0, a is stored in d, otherwise b is stored in\n\nd. Operands d, a, and b are treated as a bitsize type of the same width as the first\n\ninstruction type; operand c must match the second instruction type (.s32 or .f32). The\n\nselected input is copied to the output without modification.\n\nSemantics\n\nd = (c >= 0) ? a : b;\n\nFloating Point Notes\n\nFor .f32 comparisons, negative zero equals zero.\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, subnormal numbers are supported.\n\nslct.ftz.dtype.f32 flushes subnormal values of operand c to sign-preserving zero, and\n\noperand a is selected.\n\nsm_1x\n\nslct.dtype.f32 flushes subnormal values of operand c to sign-preserving zero, and operand\n\na is selected.\n\nModifier .ftz applies only to .f32 comparisons.\n\nIf operand c is NaN, the comparison is unordered and operand b is selected.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nslct.f64 requires sm_13 or higher.\n\nExamples\n\nslct.u32.s32 x, y, z, val;\n\nslct.ftz.u64.f32 A, B, C, fval;\n\n ...",
+ "html": "
Conditional selection. If c >= 0, a is stored in d, otherwise b is stored in\nd. Operands d, a, and b are treated as a bitsize type of the same width as the first\ninstruction type; operand c must match the second instruction type (.s32 or .f32). The\nselected input is copied to the output without modification.
\nFor more information, visit slct .",
+ "tooltip": "Select one source operand, based on the sign of the third operand.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#comparison-and-selection-instructions-slct"
};
- case "smid":
- return {
- "html": "For more information, visit smid .
Special Registers: %smid
\n\n\n
SM identifier.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %smid;\n
\n
\n
Description
\n
A predefined, read-only special register that returns the processor (SM) identifier on which a\nparticular thread is executing. The SM identifier ranges from 0 to %nsmid-1. The SM\nidentifier numbering is not guaranteed to be contiguous.
\n
Notes
\n
Note that %smid is volatile and returns the location of a thread at the moment when read, but\nits value may change during execution, e.g. due to rescheduling of threads following\npreemption. %smid is intended mainly to enable profiling and diagnostic code to sample and log\ninformation such as work place mapping and load distribution.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mov.u32 %r, %smid;\n
\n
\n",
- "tooltip": "SM identifier.\n\nSyntax (predefined)\n\n.sreg .u32 %smid;\n\nDescription\n\nA predefined, read-only special register that returns the processor (SM) identifier on which a\n\nparticular thread is executing. The SM identifier ranges from 0 to %nsmid-1. The SM\n\nidentifier numbering is not guaranteed to be contiguous.\n\nNotes\n\nNote that %smid is volatile and returns the location of a thread at the moment when read, but\n\nits value may change during execution, e.g. due to rescheduling of threads following\n\npreemption. %smid is intended mainly to enable profiling and diagnostic code to sample and log\n\ninformation such as work place mapping and load distribution.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.3.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.u32 %r, %smid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-smid"
- };
-
case "sqrt":
return {
- "html": "For more information, visit sqrt(fp) .
sqrt.approx.f32 implements a fast approximation to square root.
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
NaN
\n
\n
\n
-normal
\n
NaN
\n
\n
\n
-subnormal
\n
-0.0
\n
\n
\n
-0.0
\n
-0.0
\n
\n
\n
+0.0
\n
+0.0
\n
\n
\n
+subnormal
\n
+0.0
\n
\n
\n
+Inf
\n
+Inf
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
Square root with IEEE 754 compliant rounding:
\n
Rounding modifiers (no default):
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
sqrt.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
sm_1x
\n
\n
sqrt.f64 supports subnormal numbers.
\n
sqrt.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
PTX ISA Notes
\n
sqrt.f32 and sqrt.f64 introduced in PTX ISA version 1.0. sqrt.rn.f64 and explicit\nmodifiers .approx and .ftz were introduced in PTX ISA version 1.4. General rounding\nmodifiers were added in PTX ISA version 2.0.
\n
For PTX ISA version 1.4 and later, one of .approx or .rnd is required.
\n
For PTX ISA versions 1.0 through 1.3, sqrt.f32 defaults to sqrt.approx.ftz.f32, and\nsqrt.f64 defaults to sqrt.rn.f64.
\n
Target ISA Notes
\n
sqrt.approx.f32 supported on all target architectures.
\n
sqrt.rnd.f32 requires sm_20 or higher.
\n
sqrt.rn.f64 requires sm_13 or higher, or .targetmap_f64_to_f32.
\n",
- "tooltip": "Take the square root of a value.\n\nSyntax\n\nsqrt.approx{.ftz}.f32 d, a; // fast, approximate square root\n\nsqrt.rnd{.ftz}.f32 d, a; // IEEE 754 compliant rounding\n\nsqrt.rnd.f64 d, a; // IEEE 754 compliant rounding\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nCompute sqrt(a) and store the result in d.\n\nSemantics\n\nd = sqrt(a);\n\nNotes\n\nsqrt.approx.f32 implements a fast approximation to square root.\n\n\n\nInput\n\nResult\n\n\n\n-Inf\n\nNaN\n\n-normal\n\nNaN\n\n-subnormal\n\n-0.0\n\n-0.0\n\n-0.0\n\n+0.0\n\n+0.0\n\n+subnormal\n\n+0.0\n\n+Inf\n\n+Inf\n\nNaN\n\nNaN\n\nSquare root with IEEE 754 compliant rounding:\n\nRounding modifiers (no default):\n\n.rn\n\nmantissa LSB rounds to nearest even\n\n.rz\n\nmantissa LSB rounds towards zero\n\n.rm\n\nmantissa LSB rounds towards negative infinity\n\n.rp\n\nmantissa LSB rounds towards positive infinity\n\nSubnormal numbers:\n\nsm_20+\n\nBy default, subnormal numbers are supported.\n\nsqrt.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.\n\nsm_1x\n\nsqrt.f64 supports subnormal numbers.\n\nsqrt.f32 flushes subnormal inputs and results to sign-preserving zero.\n\nPTX ISA Notes\n\nsqrt.f32 and sqrt.f64 introduced in PTX ISA version 1.0. sqrt.rn.f64 and explicit\n\nmodifiers .approx and .ftz were introduced in PTX ISA version 1.4. General rounding\n\nmodifiers were added in PTX ISA version 2.0.\n\nFor PTX ISA version 1.4 and later, one of .approx or .rnd is required.\n\nFor PTX ISA versions 1.0 through 1.3, sqrt.f32 defaults to sqrt.approx.ftz.f32, and\n\nsqrt.f64 defaults to sqrt.rn.f64.\n\nTarget ISA Notes\n\nsqrt.approx.f32 supported on all target architectures.\n\nsqrt.rnd.f32 requires sm_20 or higher.\n\nsqrt.rn.f64 requires sm_13 or higher, or .target map_f64_to_f32.\n\nsqrt.{rz,rm,rp}.f64 requires sm_20 or higher.\n\nExamples\n\nsqrt.approx.ftz.f32 r,x;\n\nsqrt.rn.ftz.f32 r,x;\n\nsqrt.rn.f64 r,x;\n\n ...",
+ "html": "
Compute sqrt(a) and store the result in d.
\nFor more information, visit sqrt(fp) .",
+ "tooltip": "Take the square root of a value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-sqrt"
};
case "st":
return {
- "html": "For more information, visit st , st.async .
Data Movement and Conversion Instructions: st
\n\n\n
Store data to an addressable state space variable.
Store the value of operand b in the location specified by the destination address\noperand a in specified state space. If no state space is given, perform the store using Generic\nAddressing. Stores to const memory are illegal.
\n
If no sub-qualifier is specified with .shared state space, then ::cta is assumed by default.
\n
Supported addressing modes for operand a and alignment requirements are described in Addresses\nas Operands
\n
If .param is specified without any sub-qualifiers then it defaults to .param::func.
The qualifiers .relaxed and .release indicate memory synchronization as described in the\nMemory Consistency Model. The .scope qualifier\nindicates the set of threads with which an st.relaxed or st.release instruction can directly\nsynchronize1. The .weak qualifier indicates a memory instruction with no synchronization.\nThe effects of this instruction become visible to other threads only when synchronization is established\nby other means.
\n
The semantic details of .mmio qualifier are described in the Memory Consistency Model. Only .sys thread scope is valid for st.mmio operation. The\nqualifiers .mmio and .relaxed must be specified together.
\n
The .weak, .volatile, .relaxed and .release qualifiers are mutually exclusive. When\nnone of these is specified, the .weak qualifier is assumed by default.
\n
An st.volatile operation is always performed and it will not be reordered with respect to other\nvolatile operations to the same memory location. st.volatile has the same memory\nsynchronization semantics as st.relaxed.sys.
\n
The qualifiers .volatile, .relaxed and .release may be used only with .global and\n.shared spaces and with generic addressing, where the address points to .global or\n.shared space. Cache operations are not permitted with these qualifiers. The qualifier .mmio\nmay be used only with .global space and with generic addressing, where the address points to\n.global space.
\n
The qualifier .level::eviction_priority specifies the eviction policy that will be used during\nmemory access.
\n
When the optional argument cache-policy is specified, the qualifier .level::cache_hint is\nrequired. The 64-bit operand cache-policy specifies the cache eviction policy that may be used\nduring the memory access.
\n
The qualifier .level::cache_hint is only supported for .global state space and for generic\naddressing where the address points to the .global state space.
\n
cache-policy is a hint to the cache subsystem and may not always be respected. It is treated as\na performance hint only, and does not change the memory consistency behavior of the program.
\n
1 This synchronization is further extended to other threads through the transitive nature of\ncausality order, as described in the memory consistency model.
A source register wider than the specified type may be used. The lower n bits corresponding to\nthe instruction-type width are stored to memory. See\nTable 26\nfor a description of these relaxed type-checking rules.
\n
.f16 data resulting from a cvt instruction may be stored using st.b16.
\n
.f16x2 data may be stored using st.b32.
\n
PTX ISA Notes
\n
st introduced in PTX ISA version 1.0. st.volatile introduced in PTX ISA version 1.1.
\n
Generic addressing and cache operations introduced in PTX ISA version 2.0.
\n
Support for scope qualifier, .relaxed, .release, .weak qualifiers introduced in PTX ISA\nversion 6.0.
\n
Support for .level::eviction_priority and .level::cache_hint qualifiers introduced in PTX\nISA version 7.4.
\n
Support for .cluster scope qualifier introduced in PTX ISA version 7.8.
\n
Support for ::cta and ::cluster sub-qualifiers introduced in PTX ISA version 7.8.
\n
Support for .mmio qualifier introduced in PTX ISA version 8.2.
\n
Support for ::func sub-qualifier on .param space introduced in PTX ISA version 8.3.
\n
Support for .b128 type introduced in PTX ISA version 8.3.
\n
Support for .sys scope with .b128 type introduced in PTX ISA version 8.4.
\n
Target ISA Notes
\n
st.f64 requires sm_13 or higher.
\n
Support for scope qualifier, .relaxed, .release, .weak qualifiers require sm_70 or\nhigher.
\n
Generic addressing requires sm_20 or higher.
\n
Cache operations require sm_20 or higher.
\n
Support for .level::eviction_priority qualifier requires sm_70 or higher.
\n
Support for .level::cache_hint qualifier requires sm_80 or higher.
\n
Support for .cluster scope qualifier requires sm_90 or higher.
\n
Sub-qualifier ::cta requires sm_30 or higher.
\n
Sub-qualifier ::cluster requires sm_90 or higher.
\n
Support for .mmio qualifier requires sm_70 or higher.
st.async is a non-blocking instruction which initiates an asynchronous store operation that\nstores the value specified by source operand b to the destination memory location\nspecified by operand a.
\n
The modifier .completion_mechanism specifies that upon completion of the asynchronous operation,\ncomplete-tx\noperation, with completeCount argument equal to amount of data stored in bytes, will be\nperformed on the mbarrier object specified by the operand mbar.
\n
Operand a represents destination address and must be a register or of the form register+\nimmOff as described in Addresses as Operands.
\n
The shared memory addresses of destination operand a and the mbarrier objectmbar, must\nmeet all of the following conditions:
\n
\n
They belong to the same CTA.
\n
They are different to the CTA of the executing thread but must be within the same cluster.
\n
\n
Otherwise, the behavior is undefined.
\n
The state space of the address {.ss}, if specified, is applicable to both operands a and\nmbar. If not specified, then Generic Addressing is used for\nboth a and mbar. If the generic addresses specified do not fall within the address window of\n.shared::cluster state space, then the behaviour is undefined.
\n
The store operation in st.async is treated as a weak memory operation and the complete_tx\noperation on the mbarrier has .release semantics at the .cluster scope as described in the\nMemory Consistency Model.
\n",
- "tooltip": "=====Data Movement and Conversion Instructions: st\n\n\n\nStore data to an addressable state space variable.\n\nSyntax\n\nst{.weak}{.ss}{.cop}{.level::cache_hint}{.vec}.type [a], b{, cache-policy};\n\nst{.weak}{.ss}{.level::eviction_priority}{.level::cache_hint}{.vec}.type\n\n [a], b{, cache-policy};\n\nst.volatile{.ss}{.vec}.type [a], b;\n\nst.relaxed.scope{.ss}{.level::eviction_priority}{.l...\n\n=====Data Movement and Conversion Instructions: st.async\n\n\n\nAsynchronous store operation on shared memory.\n\nSyntax\n\nst.async{.weak}{.ss}{.completion_mechanism}{.vec}.type [a], b, [mbar];\n\n.ss = { .shared::cluster };\n\n.type = { .b32, .b64,\n\n .u32, .u64,\n\n .s32, .s64,\n\n .f32, .f64 };\n\n.vec = { .v2, .v4 };\n\n.completion_mechanism = { .mbarrier::... ...",
+ "html": "
Store the value of operand b in the location specified by the destination address\noperand a in specified state space. If no state space is given, perform the store using\nGeneric Addressing. Stores to const memory are illegal.
\nFor more information, visit st .",
+ "tooltip": "Store data to an addressable state space variable.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-st"
};
case "stackrestore":
return {
- "html": "For more information, visit stackrestore .
Stack Manipulation Instructions: stackrestore
\n\n\n
Update the stack pointer with a new value.
\n
Syntax
\n
\n
stackrestore.type a;\n\n.type = { .u32, .u64 };\n
\n
\n
Description
\n
Sets the current stack pointer to source register a.
\n
When stackrestore is used with operand a written by a prior stacksave instruction, it\nwill effectively restore the state of stack as it was before stacksave was executed. Note that\nif stackrestore is used with an arbitrary value of a, it may cause corruption of stack\npointer. This implies that the correct use of this feature requires that stackrestore.typea is\nused after stacksave.typea without redefining the value of a between them.
\n
Operand a has the same type as the instruction type.
\n
Semantics
\n
\n
stackptr = a;\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.3.
\n
\n
Preview Feature:
\n
\n
stackrestore is a preview feature in PTX ISA version 7.3. All details are subject to change\nwith no guarantees of backward compatibility on future PTX ISA versions or SM architectures.
\n
\n
\n
Target ISA Notes
\n
stackrestore requires sm_52 or higher.
\n
Examples
\n
\n
.reg .u32 ra;\nstacksave.u32 ra;\n// Code that may modify stack pointer\n...\nstackrestore.u32 ra;\n
\n
\n",
- "tooltip": "Update the stack pointer with a new value.\n\nSyntax\n\nstackrestore.type a;\n\n.type = { .u32, .u64 };\n\nDescription\n\nSets the current stack pointer to source register a.\n\nWhen stackrestore is used with operand a written by a prior stacksave instruction, it\n\nwill effectively restore the state of stack as it was before stacksave was executed. Note that\n\nif stackrestore is used with an arbitrary value of a, it may cause corruption of stack\n\npointer. This implies that the correct use of this feature requires that stackrestore.type a is\n\nused after stacksave.type a without redefining the value of a between them.\n\nOperand a has the same type as the instruction type.\n\nSemantics\n\nstackptr = a;\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.3.\n\nPreview Feature:\n\nstackrestore is a preview feature in PTX ISA version 7.3. All details are subject to change\n\nwith no guarantees of backward compatibility on future PTX ISA versions or SM architectures.\n\nTarget ISA Notes\n\nstackrestore requires sm_52 or higher.\n\nExamples\n\n.reg .u32 ra;\n\nstacksave.u32 ra;\n\n// Code that may modify stack pointer\n\n...\n\nstackrestore.u32 ra;\n\n ...",
+ "html": "
Sets the current stack pointer to source register a.
\nFor more information, visit stackrestore .",
+ "tooltip": "Update the stack pointer with a new value.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#stack-manipulation-instructions-stackrestore"
};
case "stacksave":
return {
- "html": "For more information, visit stacksave .
Stack Manipulation Instructions: stacksave
\n\n\n
Save the value of stack pointer into a register.
\n
Syntax
\n
\n
stacksave.type d;\n\n.type = { .u32, .u64 };\n
\n
\n
Description
\n
Copies the current value of stack pointer into the destination register d. Pointer returned by\nstacksave can be used in a subsequent stackrestore instruction to restore the stack\npointer. If d is modified prior to use in stackrestore instruction, it may corrupt data in\nthe stack.
\n
Destination operand d has the same type as the instruction type.
\n
Semantics
\n
\n
d = stackptr;\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.3.
\n
\n
Preview Feature:
\n
\n
stacksave is a preview feature in PTX ISA version 7.3. All details are subject to change with\nno guarantees of backward compatibility on future PTX ISA versions or SM architectures.
\n",
- "tooltip": "Save the value of stack pointer into a register.\n\nSyntax\n\nstacksave.type d;\n\n.type = { .u32, .u64 };\n\nDescription\n\nCopies the current value of stack pointer into the destination register d. Pointer returned by\n\nstacksave can be used in a subsequent stackrestore instruction to restore the stack\n\npointer. If d is modified prior to use in stackrestore instruction, it may corrupt data in\n\nthe stack.\n\nDestination operand d has the same type as the instruction type.\n\nSemantics\n\nd = stackptr;\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.3.\n\nPreview Feature:\n\nstacksave is a preview feature in PTX ISA version 7.3. All details are subject to change with\n\nno guarantees of backward compatibility on future PTX ISA versions or SM architectures.\n\nTarget ISA Notes\n\nstacksave requires sm_52 or higher.\n\nExamples\n\n.reg .u32 rd;\n\nstacksave.u32 rd;\n\n.reg .u64 rd1;\n\nstacksave.u64 rd1;\n\n ...",
+ "html": "
Copies the current value of stack pointer into the destination register d. Pointer returned by\nstacksave can be used in a subsequent stackrestore instruction to restore the stack\npointer. If d is modified prior to use in stackrestore instruction, it may corrupt data in\nthe stack.
\nFor more information, visit stacksave .",
+ "tooltip": "Save the value of stack pointer into a register.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#stack-manipulation-instructions-stacksave"
};
+ case "stmatrix":
+ return {
+ "html": "
Collectively store one or more matrices across all threads in a warp to the location indicated by\nthe address operand p, in .shared state space. If no state space is provided, generic\naddressing is used, such that the address in p points into .shared space. If the generic\naddress doesn\u2019t fall in .shared state space, then the behavior is undefined.
\nFor more information, visit stmatrix .",
+ "tooltip": "Collectively store one or more matrices to shared memory.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-stmatrix"
+ };
+
case "sub":
return {
- "html": "For more information, visit sub(fp) , sub(fp16) , sub(int) , sub.cc .
Floating Point Instructions: sub
\n\n\n
Subtract one value from another.
\n
Syntax
\n
\n
sub{.rnd}{.ftz}{.sat}.f32 d, a, b;\nsub{.rnd}.f64 d, a, b;\n\n.rnd = { .rn, .rz, .rm, .rp };\n
\n
\n
Description
\n
Performs subtraction and writes the resulting value into a destination register.
\n
Semantics
\n
\n
d = a - b;\n
\n
\n
Notes
\n
Rounding modifiers:
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
.rz
\n
\n
mantissa LSB rounds towards zero
\n
\n
.rm
\n
\n
mantissa LSB rounds towards negative infinity
\n
\n
.rp
\n
\n
mantissa LSB rounds towards positive infinity
\n
\n
\n
The default value of rounding modifier is .rn. Note that a sub instruction with an explicit\nrounding modifier is treated conservatively by the code optimizer. A sub instruction with no\nrounding modifier defaults to round-to-nearest-even and may be optimized aggressively by the code\noptimizer. In particular, mul/sub sequences with no rounding modifiers may be optimized to\nuse fused-multiply-add instructions on the target device.
\n
Subnormal numbers:
\n
\n
sm_20+
\n
\n
By default, subnormal numbers are supported.
\n
sub.ftz.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
\n
sm_1x
\n
\n
sub.f64 supports subnormal numbers.
\n
sub.f32 flushes subnormal inputs and results to sign-preserving zero.
\n
\n
\n
Saturation modifier:
\n
sub.sat.f32 clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
sub.f32 supported on all target architectures.
\n
sub.f64 requires sm_13 or higher.
\n
Rounding modifiers have the following target requirements:
\n
\n
\n.rn, .rz\n
\n
\n
available for all targets
\n
\n
\n.rm, .rp\n
\n
\n
for sub.f64, requires sm_13 or higher.
\n
for sub.f32, requires sm_20 or higher.
\n
\n
\n
Examples
\n
\n
sub.f32 c,a,b;\nsub.rn.ftz.f32 f1,f2,f3;\n
\n
\n\n
Half Precision Floating Point Instructions: sub
\n\n\n
Subtract two values.
\n
Syntax
\n
\n
sub{.rnd}{.ftz}{.sat}.f16 d, a, b;\nsub{.rnd}{.ftz}{.sat}.f16x2 d, a, b;\n\nsub{.rnd}.bf16 d, a, b;\nsub{.rnd}.bf16x2 d, a, b;\n\n.rnd = { .rn };\n
\n
\n
Description
\n
Performs subtraction and writes the resulting value into a destination register.
\n
For .f16x2 and .bf16x2 instruction type, forms input vectors by half word values from source\noperands. Half-word operands are then subtracted in parallel to produce .f16x2 or .bf16x2\nresult in destination.
\n
For .f16 instruction type, operands d, a and b have .f16 or .b16 type. For\n.f16x2 instruction type, operands d, a and b have .b32 type. For .bf16\ninstruction type, operands d, a, b have .b16 type. For .bf16x2 instruction type,\noperands d, a, b have .b32 type.
\n
Semantics
\n
\n
if (type == f16 || type == bf16) {\n d = a - b;\n} else if (type == f16x2 || type == bf16x2) {\n fA[0] = a[0:15];\n fA[1] = a[16:31];\n fB[0] = b[0:15];\n fB[1] = b[16:31];\n for (i = 0; i < 2; i++) {\n d[i] = fA[i] - fB[i];\n }\n}\n
\n
\n
Notes
\n
Rounding modifiers:
\n
\n
.rn
\n
\n
mantissa LSB rounds to nearest even
\n
\n
\n
The default value of rounding modifier is .rn. Note that a sub instruction with an explicit\nrounding modifier is treated conservatively by the code optimizer. A sub instruction with no\nrounding modifier defaults to round-to-nearest-even and may be optimized aggressively by the code\noptimizer. In particular, mul/sub sequences with no rounding modifiers may be optimized to\nuse fused-multiply-add instructions on the target device.
\n
\n
Subnormal numbers:
\n
\n
By default, subnormal numbers are supported.\nsub.ftz.{f16,f16x2} flushes subnormal inputs and results to sign-preserving zero.
\n
\n
Saturation modifier:
\n
\n
sub.sat.{f16,f16x2} clamps the result to [0.0, 1.0]. NaN results are flushed to +0.0f.
\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.2.
\n
sub{.rnd}.bf16 and sub{.rnd}.bf16x2 introduced in PTX ISA version 7.8.
\n
Target ISA Notes
\n
Requires sm_53 or higher.
\n
sub{.rnd}.bf16 and sub{.rnd}.bf16x2 requires sm_90 or higher.
\n
Examples
\n
\n
// scalar f16 subtractions\nsub.f16 d0, a0, b0;\nsub.rn.f16 d1, a1, b1;\nsub.bf16 bd0, ba0, bb0;\nsub.rn.bf16 bd1, ba1, bb1;\n\n// SIMD f16 subtraction\ncvt.rn.f16.f32 h0, f0;\ncvt.rn.f16.f32 h1, f1;\ncvt.rn.f16.f32 h2, f2;\ncvt.rn.f16.f32 h3, f3;\nmov.b32 p1, {h0, h1}; // pack two f16 to 32bit f16x2\nmov.b32 p2, {h2, h3}; // pack two f16 to 32bit f16x2\nsub.f16x2 p3, p1, p2; // SIMD f16x2 subtraction\n\n// SIMD bf16 subtraction\ncvt.rn.bf16x2.f32 p4, f4, f5; // Convert two f32 into packed bf16x2\ncvt.rn.bf16x2.f32 p5, f6, f7; // Convert two f32 into packed bf16x2\nsub.bf16x2 p6, p4, p5; // SIMD bf16x2 subtraction\n\n// SIMD fp16 subtraction\nld.global.b32 f0, [addr]; // load 32 bit which hold packed f16x2\nld.global.b32 f1, [addr + 4]; // load 32 bit which hold packed f16x2\nsub.f16x2 f2, f0, f1; // SIMD f16x2 subtraction\n\n// SIMD bf16 subtraction\nld.global.b32 f3, [addr + 8]; // load 32 bit which hold packed bf16x2\nld.global.b32 f4, [addr + 12]; // load 32 bit which hold packed bf16x2\nsub.bf16x2 f5, f3, f4; // SIMD bf16x2 subtraction\n
\n
\n\n
Integer Arithmetic Instructions: sub
\n\n\n
Subtract one value from another.
\n
Syntax
\n
\n
sub.type d, a, b;\nsub{.sat}.s32 d, a, b; // .sat applies only to .s32\n\n.type = { .u16, .u32, .u64,\n .s16, .s32, .s64 };\n
\n
\n
Description
\n
Performs subtraction and writes the resulting value into a destination register.
\n
Semantics
\n
\n
d = a - b;\n
\n
\n
Notes
\n
Saturation modifier:
\n
\n
.sat
\n
\n
limits result to MININT..MAXINT (no overflow) for the size of the operation. Applies only to\n.s32 type.
Performs integer subtraction and writes the borrow-out value into the condition code register.
\n
Semantics
\n
\n
d = a - b;\n
\n
\n
borrow-out written to CC.CF
\n
Notes
\n
No integer rounding modifiers.
\n
No saturation.
\n
Behavior is the same for unsigned and signed integers.
\n
PTX ISA Notes
\n
32-bit sub.cc introduced in PTX ISA version 1.2.
\n
64-bit sub.cc introduced in PTX ISA version 4.3.
\n
Target ISA Notes
\n
32-bit sub.cc is supported on all target architectures.
\n
64-bit sub.cc requires sm_20 or higher.
\n
Examples
\n
\n
@p sub.cc.u32 x1,y1,z1; // extended-precision subtraction\n@p subc.cc.u32 x2,y2,z2; // of two 128-bit values\n@p subc.cc.u32 x3,y3,z3;\n@p subc.u32 x4,y4,z4;\n
\n
\n",
- "tooltip": "=====Floating Point Instructions: sub\n\n\n\nSubtract one value from another.\n\nSyntax\n\nsub{.rnd}{.ftz}{.sat}.f32 d, a, b;\n\nsub{.rnd}.f64 d, a, b;\n\n.rnd = { .rn, .rz, .rm, .rp };\n\nDescription\n\nPerforms subtraction and writes the resulting value into a destination register.\n\nSemantics\n\nd = a - b;\n\nNotes\n\nRounding modifiers:\n\n.rn\n\nmantissa LSB rounds to nearest even\n\n.rz\n\nmantissa LSB rounds towards zero\n\n.rm\n\nmantissa LSB rounds towards negative...\n\n=====Half Precision Floating Point Instructions: sub\n\n\n\nSubtract two values.\n\nSyntax\n\nsub{.rnd}{.ftz}{.sat}.f16 d, a, b;\n\nsub{.rnd}{.ftz}{.sat}.f16x2 d, a, b;\n\nsub{.rnd}.bf16 d, a, b;\n\nsub{.rnd}.bf16x2 d, a, b;\n\n.rnd = { .rn };\n\nDescription\n\nPerforms subtraction and writes the resulting value into a destination register.\n\nFor .f16x2 and .bf16x2 instruction type, forms input vectors by half word values from source\n\noperands. Half-word operands are then subtra...\n\n=====Integer Arithmetic Instructions: sub\n\n\n\nSubtract one value from another.\n\nSyntax\n\nsub.type d, a, b;\n\nsub{.sat}.s32 d, a, b; // .sat applies only to .s32\n\n.type = { .u16, .u32, .u64,\n\n .s16, .s32, .s64 };\n\nDescription\n\nPerforms subtraction and writes the resulting value into a destination register.\n\nSemantics\n\nd = a - b;\n\nNotes\n\nSaturation modifier:\n\n.sat\n\nlimits result to MININT..MAXINT (no overflow) for the size of the operation...\n\n=====Extended-Precision Arithmetic Instructions: sub.cc\n\n\n\nSubtract one value from another, with borrow-out.\n\nSyntax\n\nsub.cc.type d, a, b;\n\n.type = { .u32, .s32, .u64, .s64 };\n\nDescription\n\nPerforms integer subtraction and writes the borrow-out value into the condition code register.\n\nSemantics\n\nd = a - b;\n\nborrow-out written to CC.CF\n\nNotes\n\nNo integer rounding modifiers.\n\nNo saturation.\n\nBehavior is the same for unsigned and signed integers.\n\nPTX ISA Notes\n\n32-bit s... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-sub"
+ "html": "
Performs subtraction and writes the resulting value into a destination register.
\nFor more information, visit sub(int) .",
+ "tooltip": "Subtract one value from another.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-sub"
};
case "subc":
return {
- "html": "For more information, visit subc .
Extended-Precision Arithmetic Instructions: subc
\n\n\n
Subtract one value from another, with borrow-in and optional borrow-out.
Performs integer subtraction with borrow-in and optionally writes the borrow-out value into the\ncondition code register.
\n
Semantics
\n
\n
d = a - (b + CC.CF);\n
\n
\n
if .cc specified, borrow-out written to CC.CF
\n
Notes
\n
No integer rounding modifiers.
\n
No saturation.
\n
Behavior is the same for unsigned and signed integers.
\n
PTX ISA Notes
\n
32-bit subc introduced in PTX ISA version 1.2.
\n
64-bit subc introduced in PTX ISA version 4.3.
\n
Target ISA Notes
\n
32-bit subc is supported on all target architectures.
\n
64-bit subc requires sm_20 or higher.
\n
Examples
\n
\n
@p sub.cc.u32 x1,y1,z1; // extended-precision subtraction\n@p subc.cc.u32 x2,y2,z2; // of two 128-bit values\n@p subc.cc.u32 x3,y3,z3;\n@p subc.u32 x4,y4,z4;\n
\n
\n",
- "tooltip": "Subtract one value from another, with borrow-in and optional borrow-out.\n\nSyntax\n\nsubc{.cc}.type d, a, b;\n\n.type = { .u32, .s32, .u64, .s64 };\n\nDescription\n\nPerforms integer subtraction with borrow-in and optionally writes the borrow-out value into the\n\ncondition code register.\n\nSemantics\n\nd = a - (b + CC.CF);\n\nif .cc specified, borrow-out written to CC.CF\n\nNotes\n\nNo integer rounding modifiers.\n\nNo saturation.\n\nBehavior is the same for unsigned and signed integers.\n\nPTX ISA Notes\n\n32-bit subc introduced in PTX ISA version 1.2.\n\n64-bit subc introduced in PTX ISA version 4.3.\n\nTarget ISA Notes\n\n32-bit subc is supported on all target architectures.\n\n64-bit subc requires sm_20 or higher.\n\nExamples\n\n@p sub.cc.u32 x1,y1,z1; // extended-precision subtraction\n\n@p subc.cc.u32 x2,y2,z2; // of two 128-bit values\n\n@p subc.cc.u32 x3,y3,z3;\n\n@p subc.u32 x4,y4,z4;\n\n ...",
+ "html": "
Performs integer subtraction with borrow-in and optionally writes the borrow-out value into the\ncondition code register.
\nFor more information, visit subc .",
+ "tooltip": "Subtract one value from another, with borrow-in and optional borrow-out.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#extended-precision-arithmetic-instructions-subc"
};
case "suld":
return {
- "html": "For more information, visit suld .
Load from surface memory using a surface coordinate vector. The instruction loads data from the\nsurface named by operand a at coordinates given by operand b into destination d. Operand\na is a .surfref variable or .u64 register. Operand b is a scalar or singleton tuple\nfor 1d surfaces; is a two-element vector for 2d surfaces; and is a four-element vector for 3d\nsurfaces, where the fourth element is ignored. Coordinate elements are of type .s32.
\n
suld.b performs an unformatted load of binary data. The lowest dimension coordinate represents a\nbyte offset into the surface and is not scaled, and the size of the data transfer matches the size\nof destination operand d.
\n
suld.b.{a1d,a2d}
\n
Surface layer selection, followed by a load from the selected surface. The instruction first selects\na surface layer from the surface array named by operand a using the index given by the first\nelement of the array coordinate vector b. The instruction then loads data from the selected\nsurface at coordinates given by the remaining elements of operand b into destination\nd. Operand a is a .surfref variable or .u64 register. Operand b is a bit-size\ntype vector or tuple containing an index into the array of surfaces followed by coordinates within\nthe selected surface, as follows:
\n
For 1d surface arrays, operand b has type .v2.b32. The first element is interpreted as an\nunsigned integer index (.u32) into the surface array, and the second element is interpreted as a\n1d surface coordinate of type .s32.
\n
For 2d surface arrays, operand b has type .v4.b32. The first element is interpreted as an\nunsigned integer index (.u32) into the surface array, and the next two elements are interpreted\nas 2d surface coordinates of type .s32. The fourth element is ignored.
\n
A surface base address is assumed to be aligned to a 16 byte boundary, and the address given by the\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.
\n
The .clamp field specifies how to handle out-of-bounds addresses:
\n
\n
.trap
\n
\n
causes an execution trap on out-of-bounds addresses
\n
\n
.clamp
\n
\n
loads data at the nearest surface location (sized appropriately)
\n
\n
.zero
\n
\n
loads zero for out-of-bounds addresses
\n
\n
\n
Indirect surface access
\n
Beginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\na .surfref variable.
\n
PTX ISA Notes
\n
suld.b.trap introduced in PTX ISA version 1.5.
\n
Additional clamp modifiers and cache operations introduced in PTX ISA version 2.0.
\n
suld.b.3d andsuld.b.{a1d,a2d} introduced in PTX ISA version 3.0.
\n
Indirect surface access introduced in PTX ISA version 3.1.
\n
Target ISA Notes
\n
suld.b supported on all target architectures.
\n
sm_1x targets support only the .trap clamping modifier.
\n
suld.3d andsuld.{a1d,a2d} require sm_20 or higher.
\n",
- "tooltip": "Load from surface memory.\n\nSyntax\n\nsuld.b.geom{.cop}.vec.dtype.clamp d, [a, b]; // unformatted\n\n.geom = { .1d, .2d, .3d, .a1d, .a2d };\n\n.cop = { .ca, .cg, .cs, .cv }; // cache operation\n\n.vec = { none, .v2, .v4 };\n\n.dtype = { .b8 , .b16, .b32, .b64 };\n\n.clamp = { .trap, .clamp, .zero };\n\nDescription\n\nsuld.b.{1d,2d,3d}\n\nLoad from surface memory using a surface coordinate vector. The instruction loads data from the\n\nsurface named by operand a at coordinates given by operand b into destination d. Operand\n\na is a .surfref variable or .u64 register. Operand b is a scalar or singleton tuple\n\nfor 1d surfaces; is a two-element vector for 2d surfaces; and is a four-element vector for 3d\n\nsurfaces, where the fourth element is ignored. Coordinate elements are of type .s32.\n\nsuld.b performs an unformatted load of binary data. The lowest dimension coordinate represents a\n\nbyte offset into the surface and is not scaled, and the size of the data transfer matches the size\n\nof destination operand d.\n\nsuld.b.{a1d,a2d}\n\nSurface layer selection, followed by a load from the selected surface. The instruction first selects\n\na surface layer from the surface array named by operand a using the index given by the first\n\nelement of the array coordinate vector b. The instruction then loads data from the selected\n\nsurface at coordinates given by the remaining elements of operand b into destination\n\nd. Operand a is a .surfref variable or .u64 register. Operand b is a bit-size\n\ntype vector or tuple containing an index into the array of surfaces followed by coordinates within\n\nthe selected surface, as follows:\n\nFor 1d surface arrays, operand b has type .v2.b32. The first element is interpreted as an\n\nunsigned integer index (.u32) into the surface array, and the second element is interpreted as a\n\n1d surface coordinate of type .s32.\n\nFor 2d surface arrays, operand b has type .v4.b32. The first element is interpreted as an\n\nunsigned integer index (.u32) into the surface array, and the next two elements are interpreted\n\nas 2d surface coordinates of type .s32. The fourth element is ignored.\n\nA surface base address is assumed to be aligned to a 16 byte boundary, and the address given by the\n\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\n\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\n\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.\n\nThe .clamp field specifies how to handle out-of-bounds addresses:\n\n.trap\n\ncauses an execution trap on out-of-bounds addresses\n\n.clamp\n\nloads data at the nearest surface location (sized appropriately)\n\n.zero\n\nloads zero for out-of-bounds addresses\n\nIndirect surface access\n\nBeginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\n\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\n\na .surfref variable.\n\nPTX ISA Notes\n\nsuld.b.trap introduced in PTX ISA version 1.5.\n\nAdditional clamp modifiers and cache operations introduced in PTX ISA version 2.0.\n\nsuld.b.3d andsuld.b.{a1d,a2d} introduced in PTX ISA version 3.0.\n\nIndirect surface access introduced in PTX ISA version 3.1.\n\nTarget ISA Notes\n\nsuld.b supported on all target architectures.\n\nsm_1x targets support only the .trap clamping modifier.\n\nsuld.3d andsuld.{a1d,a2d} require sm_20 or higher.\n\nIndirect surface access requires sm_20 or higher.\n\nCache operations require sm_20 or higher.\n\nExamples\n\nsuld.b.1d.v4.b32.trap {s1,s2,s3,s4}, [surf_B, {x}];\n\nsuld.b.3d.v2.b64.trap {r1,r2}, [surf_A, {x,y,z,w}];\n\nsuld.b.a1d.v2.b32 {r0,r1}, [surf_C, {idx,x}];\n\nsuld.b.a2d.b32 r0, [surf_D, {idx,x,y,z}]; // z ignored\n\n ...",
+ "html": "
suld.b.{1d,2d,3d}
\nFor more information, visit suld .",
+ "tooltip": "Load from surface memory.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#surface-instructions-suld"
};
case "suq":
return {
- "html": "For more information, visit suq .
Query an attribute of a surface. Operand a is a .surfref variable or a .u64 register.
\n
\n
\n
\n
\n
\n\n
\n
Query
\n
Returns
\n
\n\n\n
\n
\n
.width
\n
.height
\n
.depth
\n
\n
value in elements
\n
\n
\n
.channel_data_type
\n
Unsigned integer corresponding to source language\u2019s channel data\ntype enumeration. If the source language combines channel data\ntype and channel order into a single enumeration type, that value\nis returned for both channel_data_type and channel_order\nqueries.
\n
\n
\n
.channel_order
\n
Unsigned integer corresponding to source language\u2019s channel order\nenumeration. If the source language combines channel data type and\nchannel order into a single enumeration type, that value is\nreturned for both channel_data_type and channel_order\nqueries.
\n
\n
\n
.array_size
\n
For a surface array, number of surfaces in array, 0 otherwise.
\n
\n
\n
.memory_layout
\n
1 for surface with linear memory layout; 0 otherwise
\n
\n\n
\n
Indirect surface access
\n
Beginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\na .surfref variable.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.5.
\n
Channel data type and channel order queries added in PTX ISA version 2.1.
\n
Indirect surface access introduced in PTX ISA version 3.1.
\n
The .array_size query was added in PTX ISA version 4.1.
\n
The .memory_layout query was added in PTX ISA version 4.2.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Indirect surface access requires sm_20 or higher.
\n
Examples
\n
\n
suq.width.b32 %r1, [surf_A];\n
\n
\n",
- "tooltip": "Query a surface attribute.\n\nSyntax\n\nsuq.query.b32 d, [a];\n\n.query = { .width, .height, .depth,\n\n .channel_data_type, .channel_order,\n\n .array_size, .memory_layout };\n\nDescription\n\nQuery an attribute of a surface. Operand a is a .surfref variable or a .u64 register.\n\n\n\nQuery\n\nReturns\n\n\n\n.width\n\n.height\n\n.depth\n\nvalue in elements\n\n.channel_data_type\n\nUnsigned integer corresponding to source language\u2019s channel data\n\ntype enumeration. If the source language combines channel data\n\ntype and channel order into a single enumeration type, that value\n\nis returned for both channel_data_type and channel_order\n\nqueries.\n\n.channel_order\n\nUnsigned integer corresponding to source language\u2019s channel order\n\nenumeration. If the source language combines channel data type and\n\nchannel order into a single enumeration type, that value is\n\nreturned for both channel_data_type and channel_order\n\nqueries.\n\n.array_size\n\nFor a surface array, number of surfaces in array, 0 otherwise.\n\n.memory_layout\n\n1 for surface with linear memory layout; 0 otherwise\n\nIndirect surface access\n\nBeginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\n\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\n\na .surfref variable.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.5.\n\nChannel data type and channel order queries added in PTX ISA version 2.1.\n\nIndirect surface access introduced in PTX ISA version 3.1.\n\nThe .array_size query was added in PTX ISA version 4.1.\n\nThe .memory_layout query was added in PTX ISA version 4.2.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nIndirect surface access requires sm_20 or higher.\n\nExamples\n\nsuq.width.b32 %r1, [surf_A];\n\n ...",
+ "html": "
Query an attribute of a surface. Operand a is a .surfref variable or a .u64 register.
\nFor more information, visit suq .",
+ "tooltip": "Query a surface attribute.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#surface-instructions-suq"
};
case "sured":
return {
- "html": "For more information, visit sured .
Reduction to surface memory using a surface coordinate vector. The instruction performs a reduction\noperation with data from operand c to the surface named by operand a at coordinates given by\noperand b. Operand a is a .surfref variable or .u64 register. Operand b is a\nscalar or singleton tuple for 1d surfaces; is a two-element vector for 2d surfaces; and is a\nfour-element vector for 3d surfaces, where the fourth element is ignored. Coordinate elements are of\ntype .s32.
\n
sured.b performs an unformatted reduction on .u32, .s32, .b32, .u64, or .s64\ndata. The lowest dimension coordinate represents a byte offset into the surface and is not\nscaled. Operation add applies to .u32, .u64, and .s32 types; min and max\napply to .u32, .s32, .u64 and .s64 types; operations and and or apply to\n.b32 type.
\n
sured.p performs a reduction on sample-addressed data. The lowest dimension coordinate\nrepresents a sample offset rather than a byte offset. The instruction type .b64 is restricted to\nmin and max operations. For type .b32, the data is interpreted as .u32 or .s32\nbased on the surface sample format as follows: if the surface format contains UINT data, then\n.u32 is assumed; if the surface format contains SINT data, then .s32 is assumed. For\ntype .b64, if the surface format contains UINT data, then .u64 is assumed; if the\nsurface format contains SINT data, then .s64 is assumed.
\n
A surface base address is assumed to be aligned to a 16 byte boundary, and the address given by the\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.
\n
The .clamp field specifies how to handle out-of-bounds addresses:
\n
\n
.trap
\n
\n
causes an execution trap on out-of-bounds addresses
\n
\n
.clamp
\n
\n
stores data at the nearest surface location (sized appropriately)
\n
\n
.zero
\n
\n
drops stores to out-of-bounds addresses
\n
\n
\n
Indirect surface access
\n
Beginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\na .surfref variable.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Indirect surface access introduced in PTX ISA version 3.1.
\n
.u64/.s64/.b64 types with .min/.max operations introduced in PTX ISA version\n8.1.
\n
Target ISA Notes
\n
sured requires sm_20 or higher.
\n
Indirect surface access requires sm_20 or higher.
\n
.u64/.s64/.b64 types with .min/.max operations requires sm_50 or higher.
\n",
- "tooltip": "Reduce surface memory.\n\nSyntax\n\nsured.b.op.geom.ctype.clamp [a,b],c; // byte addressing\n\nsured.p.op.geom.ctype.clamp [a,b],c; // sample addressing\n\n.op = { .add, .min, .max, .and, .or };\n\n.geom = { .1d, .2d, .3d };\n\n.ctype = { .u32, .u64, .s32, .b32, .s64 }; // for sured.b\n\n.ctype = { .b32, .b64 }; // for sured.p\n\n.clamp = { .trap, .clamp, .zero };\n\nDescription\n\nReduction to surface memory using a surface coordinate vector. The instruction performs a reduction\n\noperation with data from operand c to the surface named by operand a at coordinates given by\n\noperand b. Operand a is a .surfref variable or .u64 register. Operand b is a\n\nscalar or singleton tuple for 1d surfaces; is a two-element vector for 2d surfaces; and is a\n\nfour-element vector for 3d surfaces, where the fourth element is ignored. Coordinate elements are of\n\ntype .s32.\n\nsured.b performs an unformatted reduction on .u32, .s32, .b32, .u64, or .s64\n\ndata. The lowest dimension coordinate represents a byte offset into the surface and is not\n\nscaled. Operation add applies to .u32, .u64, and .s32 types; min and max\n\napply to .u32, .s32, .u64 and .s64 types; operations and and or apply to\n\n.b32 type.\n\nsured.p performs a reduction on sample-addressed data. The lowest dimension coordinate\n\nrepresents a sample offset rather than a byte offset. The instruction type .b64 is restricted to\n\nmin and max operations. For type .b32, the data is interpreted as .u32 or .s32\n\nbased on the surface sample format as follows: if the surface format contains UINT data, then\n\n.u32 is assumed; if the surface format contains SINT data, then .s32 is assumed. For\n\ntype .b64, if the surface format contains UINT data, then .u64 is assumed; if the\n\nsurface format contains SINT data, then .s64 is assumed.\n\nA surface base address is assumed to be aligned to a 16 byte boundary, and the address given by the\n\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\n\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\n\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.\n\nThe .clamp field specifies how to handle out-of-bounds addresses:\n\n.trap\n\ncauses an execution trap on out-of-bounds addresses\n\n.clamp\n\nstores data at the nearest surface location (sized appropriately)\n\n.zero\n\ndrops stores to out-of-bounds addresses\n\nIndirect surface access\n\nBeginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\n\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\n\na .surfref variable.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nIndirect surface access introduced in PTX ISA version 3.1.\n\n.u64/.s64/.b64 types with .min/.max operations introduced in PTX ISA version\n\n8.1.\n\nTarget ISA Notes\n\nsured requires sm_20 or higher.\n\nIndirect surface access requires sm_20 or higher.\n\n.u64/.s64/.b64 types with .min/.max operations requires sm_50 or higher.\n\nExamples\n\nsured.b.add.2d.u32.trap [surf_A, {x,y}], r1;\n\nsured.p.min.1d.u32.trap [surf_B, {x}], r1;\n\nsured.b.max.1d.u64.trap [surf_C, {x}], r1;\n\nsured.p.min.1d.b64.trap [surf_D, {x}], r1;\n\n ...",
+ "html": "
Reduction to surface memory using a surface coordinate vector. The instruction performs a reduction\noperation with data from operand c to the surface named by operand a at coordinates given by\noperand b. Operand a is a .surfref variable or .u64 register. Operand b is a\nscalar or singleton tuple for 1d surfaces; is a two-element vector for 2d surfaces; and is a\nfour-element vector for 3d surfaces, where the fourth element is ignored. Coordinate elements are of\ntype .s32.
\nFor more information, visit sured .",
+ "tooltip": "Reduce surface memory.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#surface-instructions-sured"
};
case "sust":
return {
- "html": "For more information, visit sust .
Store to surface memory using a surface coordinate vector. The instruction stores data from operand\nc to the surface named by operand a at coordinates given by operand b. Operand a is\na .surfref variable or .u64 register. Operand b is a scalar or singleton tuple for 1d\nsurfaces; is a two-element vector for 2d surfaces; and is a four-element vector for 3d surfaces,\nwhere the fourth element is ignored. Coordinate elements are of type .s32.
\n
sust.b performs an unformatted store of binary data. The lowest dimension coordinate represents\na byte offset into the surface and is not scaled. The size of the data transfer matches the size of\nsource operand c.
\n
sust.p performs a formatted store of a vector of 32-bit data values to a surface sample. The\nsource vector elements are interpreted left-to-right as R, G, B, and A surface\ncomponents. These elements are written to the corresponding surface sample components. Source\nelements that do not occur in the surface sample are ignored. Surface sample components that do not\noccur in the source vector will be written with an unpredictable value. The lowest dimension\ncoordinate represents a sample offset rather than a byte offset.
\n
The source data interpretation is based on the surface sample format as follows: If the surface\nformat contains UNORM, SNORM, or FLOAT data, then .f32 is assumed; if the surface\nformat contains UINT data, then .u32 is assumed; if the surface format contains SINT\ndata, then .s32 is assumed. The source data is then converted from this type to the surface\nsample format.
\n
sust.b.{a1d,a2d}
\n
Surface layer selection, followed by an unformatted store to the selected surface. The instruction\nfirst selects a surface layer from the surface array named by operand a using the index given by\nthe first element of the array coordinate vector b. The instruction then stores the data in\noperand c to the selected surface at coordinates given by the remaining elements of operand\nb. Operand a is a .surfref variable or .u64 register. Operand b is a bit-size type\nvector or tuple containing an index into the array of surfaces followed by coordinates within the\nselected surface, as follows:
\n
\n
For 1d surface arrays, operand b has type .v2.b32. The first element is interpreted as an\nunsigned integer index (.u32) into the surface array, and the second element is interpreted as\na 1d surface coordinate of type .s32.
\n
For 2d surface arrays, operand b has type .v4.b32. The first element is interpreted as an\nunsigned integer index (.u32) into the surface array, and the next two elements are\ninterpreted as 2d surface coordinates of type .s32. The fourth element is ignored.
\n
\n
A surface base address is assumed to be aligned to a 16 byte boundary, and the address given by the\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.
\n
The .clamp field specifies how to handle out-of-bounds addresses:
\n
\n
.trap
\n
\n
causes an execution trap on out-of-bounds addresses
\n
\n
.clamp
\n
\n
stores data at the nearest surface location (sized appropriately)
\n
\n
.zero
\n
\n
drops stores to out-of-bounds addresses
\n
\n
\n
Indirect surface access
\n
Beginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\na .surfref variable.
\n
PTX ISA Notes
\n
sust.b.trap introduced in PTX ISA version 1.5.\u00a0 sust.p, additional clamp modifiers, and\ncache operations introduced in PTX ISA version 2.0.
\n
sust.b.3d and sust.b.{a1d,a2d} introduced in PTX ISA version 3.0.
\n
Indirect surface access introduced in PTX ISA version 3.1.
\n
Target ISA Notes
\n
sust.b supported on all target architectures.
\n
sm_1x targets support only the .trap clamping modifier.
\n
sust.3d and sust.{a1d,a2d} require sm_20 or higher.
\n",
- "tooltip": "Store to surface memory.\n\nSyntax\n\nsust.b.{1d,2d,3d}{.cop}.vec.ctype.clamp [a, b], c; // unformatted\n\nsust.p.{1d,2d,3d}.vec.b32.clamp [a, b], c; // formatted\n\nsust.b.{a1d,a2d}{.cop}.vec.ctype.clamp [a, b], c; // unformatted\n\n.cop = { .wb, .cg, .cs, .wt }; // cache operation\n\n.vec = { none, .v2, .v4 };\n\n.ctype = { .b8 , .b16, .b32, .b64 };\n\n.clamp = { .trap, .clamp, .zero };\n\nDescription\n\nsust.{1d,2d,3d}\n\nStore to surface memory using a surface coordinate vector. The instruction stores data from operand\n\nc to the surface named by operand a at coordinates given by operand b. Operand a is\n\na .surfref variable or .u64 register. Operand b is a scalar or singleton tuple for 1d\n\nsurfaces; is a two-element vector for 2d surfaces; and is a four-element vector for 3d surfaces,\n\nwhere the fourth element is ignored. Coordinate elements are of type .s32.\n\nsust.b performs an unformatted store of binary data. The lowest dimension coordinate represents\n\na byte offset into the surface and is not scaled. The size of the data transfer matches the size of\n\nsource operand c.\n\nsust.p performs a formatted store of a vector of 32-bit data values to a surface sample. The\n\nsource vector elements are interpreted left-to-right as R, G, B, and A surface\n\ncomponents. These elements are written to the corresponding surface sample components. Source\n\nelements that do not occur in the surface sample are ignored. Surface sample components that do not\n\noccur in the source vector will be written with an unpredictable value. The lowest dimension\n\ncoordinate represents a sample offset rather than a byte offset.\n\nThe source data interpretation is based on the surface sample format as follows: If the surface\n\nformat contains UNORM, SNORM, or FLOAT data, then .f32 is assumed; if the surface\n\nformat contains UINT data, then .u32 is assumed; if the surface format contains SINT\n\ndata, then .s32 is assumed. The source data is then converted from this type to the surface\n\nsample format.\n\nsust.b.{a1d,a2d}\n\nSurface layer selection, followed by an unformatted store to the selected surface. The instruction\n\nfirst selects a surface layer from the surface array named by operand a using the index given by\n\nthe first element of the array coordinate vector b. The instruction then stores the data in\n\noperand c to the selected surface at coordinates given by the remaining elements of operand\n\nb. Operand a is a .surfref variable or .u64 register. Operand b is a bit-size type\n\nvector or tuple containing an index into the array of surfaces followed by coordinates within the\n\nselected surface, as follows:\n\nFor 1d surface arrays, operand b has type .v2.b32. The first element is interpreted as an\n\nunsigned integer index (.u32) into the surface array, and the second element is interpreted as\n\na 1d surface coordinate of type .s32.\n\nFor 2d surface arrays, operand b has type .v4.b32. The first element is interpreted as an\n\nunsigned integer index (.u32) into the surface array, and the next two elements are\n\ninterpreted as 2d surface coordinates of type .s32. The fourth element is ignored.\n\nA surface base address is assumed to be aligned to a 16 byte boundary, and the address given by the\n\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\n\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\n\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.\n\nThe .clamp field specifies how to handle out-of-bounds addresses:\n\n.trap\n\ncauses an execution trap on out-of-bounds addresses\n\n.clamp\n\nstores data at the nearest surface location (sized appropriately)\n\n.zero\n\ndrops stores to out-of-bounds addresses\n\nIndirect surface access\n\nBeginning with PTX ISA version 3.1, indirect surface access is supported for target architecture\n\nsm_20 or higher. In indirect access, operand a is a .u64 register holding the address of\n\na .surfref variable.\n\nPTX ISA Notes\n\nsust.b.trap introduced in PTX ISA version 1.5.\u00a0 sus ...",
+ "html": "
sust.{1d,2d,3d}
\nFor more information, visit sust .",
+ "tooltip": "Store to surface memory.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#surface-instructions-sust"
};
case "szext":
return {
- "html": "For more information, visit szext(int) .
Sign-extends or zero-extends an N-bit value from operand a where N is specified in operand\nb. The resulting value is stored in the destination operand d.
\n
For the .s32 instruction type, the value in a is treated as an N-bit signed value and the\nmost significant bit of this N-bit value is replicated up to bit 31. For the .u32 instruction\ntype, the value in a is treated as an N-bit unsigned number and is zero-extended to 32\nbits. Operand b is an unsigned 32-bit value.
\n
If the value of N is 0, then the result of szext is 0. If the value of N is 32 or higher, then\nthe result of szext depends upon the value of the .mode qualifier as follows:
\n
\n
If .mode is .clamp, then the result is the same as the source operand a.
\n
If .mode is .wrap, then the result is computed using the wrapped value of N.
szext.clamp.s32 rd, ra, rb;\nszext.wrap.u32 rd, 0xffffffff, 0; // Result is 0.\n
\n
\n",
- "tooltip": "Sign-extend or Zero-extend.\n\nSyntax\n\nszext.mode.type d, a, b;\n\n.mode = { .clamp, .wrap };\n\n.type = { .u32, .s32 };\n\nDescription\n\nSign-extends or zero-extends an N-bit value from operand a where N is specified in operand\n\nb. The resulting value is stored in the destination operand d.\n\nFor the .s32 instruction type, the value in a is treated as an N-bit signed value and the\n\nmost significant bit of this N-bit value is replicated up to bit 31. For the .u32 instruction\n\ntype, the value in a is treated as an N-bit unsigned number and is zero-extended to 32\n\nbits. Operand b is an unsigned 32-bit value.\n\nIf the value of N is 0, then the result of szext is 0. If the value of N is 32 or higher, then\n\nthe result of szext depends upon the value of the .mode qualifier as follows:\n\nIf .mode is .clamp, then the result is the same as the source operand a.\n\nIf .mode is .wrap, then the result is computed using the wrapped value of N.\n\nSemantics\n\nb1 = b & 0x1f;\n\ntoo_large = (b >= 32 && .mode == .clamp) ? true : false;\n\nmask = too_large ? 0 : (~0) << b1;\n\nsign_pos = (b1 - 1) & 0x1f;\n\nif (b1 == 0 || too_large || .type != .s32) {\n\n sign_bit = false;\n\n} else {\n\n sign_bit = (a >> sign_pos) & 1;\n\n}\n\nd = (a & ~mask) | (sign_bit ? mask | 0);\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 7.6.\n\nTarget ISA Notes\n\nszext requires sm_70 or higher.\n\nExamples\n\nszext.clamp.s32 rd, ra, rb;\n\nszext.wrap.u32 rd, 0xffffffff, 0; // Result is 0.\n\n ...",
+ "html": "
Sign-extends or zero-extends an N-bit value from operand a where N is specified in operand\nb. The resulting value is stored in the destination operand d.
\nFor more information, visit szext(int) .",
+ "tooltip": "Sign-extend or Zero-extend.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-szext"
};
case "tanh":
return {
- "html": "For more information, visit tanh(fp) , tanh(fp16) .
Floating Point Instructions: tanh
\n\n\n
Find the hyperbolic tangent of a value (in radians)
\n
Syntax
\n
\n
tanh.approx.f32 d, a;\n
\n
\n
Description
\n
Take hyperbolic tangent value of a.
\n
The operands d and a are of type .f32.
\n
Semantics
\n
\n
d = tanh(a);\n
\n
\n
Notes
\n
tanh.approx.f32 implements a fast approximation to FP32 hyperbolic-tangent.
\n
Results of tanh for various corner-case inputs are as follows:
\n
\n
\n
\n
\n
\n\n
\n
Input
\n
Result
\n
\n\n\n
\n
-Inf
\n
-1.0
\n
\n
\n
-subnormal
\n
Same as input
\n
\n
\n
-0.0
\n
-0.0
\n
\n
\n
+0.0
\n
+0.0
\n
\n
\n
+subnormal
\n
Same as input
\n
\n
\n
+Inf
\n
1.0
\n
\n
\n
NaN
\n
NaN
\n
\n\n
\n
The subnormal numbers are supported.
\n
\n
Note
\n
The subnormal inputs gets passed through to the output since the value of tanh(x) for small\nvalues of x is approximately the same as x.
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 7.0.
\n
Target ISA Notes
\n
Requires sm_75 or higher.
\n
Examples
\n
\n
tanh.approx.f32 sa, a;\n
\n
\n\n
Half Precision Floating Point Instructions: tanh
\n\n\n
Find the hyperbolic tangent of a value (in radians)
The type of operands d and a are as specified by .type.
\n
For .f16x2 or .bf16x2 instruction type, each of the half-word operands are operated in\nparallel and the results are packed appropriately into a .f16x2 or .bf16x2.
\n",
- "tooltip": "=====Floating Point Instructions: tanh\n\n\n\nFind the hyperbolic tangent of a value (in radians)\n\nSyntax\n\ntanh.approx.f32 d, a;\n\nDescription\n\nTake hyperbolic tangent value of a.\n\nThe operands d and a are of type .f32.\n\nSemantics\n\nd = tanh(a);\n\nNotes\n\ntanh.approx.f32 implements a fast approximation to FP32 hyperbolic-tangent.\n\nResults of tanh for various corner-case inputs are as follows:\n\n\n\nInput\n\nResult\n\n\n\n-Inf\n\n-1.0\n\n-subnormal\n\nSame as input\n\n-0.0\n\n-0.0\n\n+0.0...\n\n=====Half Precision Floating Point Instructions: tanh\n\n\n\nFind the hyperbolic tangent of a value (in radians)\n\nSyntax\n\ntanh.approx.type d, a;\n\n.type = {.f16, .f16x2, .bf16, .bf16x2}\n\nDescription\n\nTake hyperbolic tangent value of a.\n\nThe type of operands d and a are as specified by .type.\n\nFor .f16x2 or .bf16x2 instruction type, each of the half-word operands are operated in\n\nparallel and the results are packed appropriately into a .f16x2 or .bf16x2.\n\nSemantics\n\nif... ...",
+ "html": "
Take hyperbolic tangent value of a.
\nFor more information, visit tanh(fp) .",
+ "tooltip": "Find the hyperbolic tangent of a value (in radians)",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-tanh"
};
- case "target":
+ case "tcgen05":
return {
- "html": "For more information, visit target .
Specifies the set of features in the target architecture for which the current PTX code was\ngenerated. In general, generations of SM architectures follow an onion layer model, where each\ngeneration adds new features and retains all features of previous generations. The onion layer model\nallows the PTX code generated for a given target to be run on later generation devices.
\n
Target architectures with suffix \u201ca\u201d, such as sm_90a, include architecture-accelerated\nfeatures that are supported on the specified architecture only, hence such targets do not follow the\nonion layer model. Therefore, PTX code generated for such targets cannot be run on later generation\ndevices. Architecture-accelerated features can only be used with targets that support these\nfeatures.
\n
Semantics
\n
Each PTX module must begin with a .version directive, immediately followed by a .target\ndirective containing a target architecture and optional platform options. A .target directive\nspecifies a single target architecture, but subsequent .target directives can be used to change\nthe set of target features allowed during parsing. A program with multiple .target directives\nwill compile and run only on devices that support all features of the highest-numbered architecture\nlisted in the program.
\n
PTX features are checked against the specified target architecture, and an error is generated if an\nunsupported feature is used.\u00a0 The following table summarizes the features in PTX that vary according\nto target architecture.
\n
\n
\n
\n
\n
\n\n
\n
Target
\n
Description
\n
\n\n\n
\n
sm_90
\n
Baseline feature set for sm_90 architecture.
\n
\n
\n
sm_90a
\n
Adds support for sm_90a accelerated wgmma and setmaxnreg instructions.
\n
\n\n
\n
\n
\n
\n
\n
\n\n
\n
Target
\n
Description
\n
\n\n\n
\n
sm_80
\n
Baseline feature set for sm_80 architecture.
\n
\n
\n
sm_86
\n
Adds support for .xorsign modifier on min and max instructions.
\n
\n
\n
sm_87
\n
Baseline feature set for sm_86 architecture.
\n
\n
\n
sm_89
\n
Baseline feature set for sm_86 architecture.
\n
\n\n
\n
\n
\n
\n
\n
\n\n
\n
Target
\n
Description
\n
\n\n\n
\n
sm_70
\n
Baseline feature set for sm_70 architecture.
\n
\n
\n
sm_72
\n
\n
Adds support for integer multiplicand and accumulator matrices in wmma instructions.
\n
Adds support for cvt.pack instruction.
\n
\n
\n
\n
sm_75
\n
\n
Adds support for sub-byte integer and single-bit multiplicant matrices in wmma instructions.
\n
Adds support for ldmatrix instruction.
\n
Adds support for movmatrix instruction.
\n
Adds support for tanh instruction.
\n
\n
\n\n
\n
\n
\n
\n
\n
\n\n
\n
Target
\n
Description
\n
\n\n\n
\n
sm_60
\n
Baseline feature set for sm_60 architecture.
\n
\n
\n
sm_61
\n
Adds support for dp2a and dp4a instructions.
\n
\n
\n
sm_62
\n
Baseline feature set for sm_61 architecture.
\n
\n\n
\n
\n
\n
\n
\n
\n\n
\n
Target
\n
Description
\n
\n\n\n
\n
sm_50
\n
Baseline feature set for sm_50 architecture.
\n
\n
\n
sm_52
\n
Baseline feature set for sm_50 architecture.
\n
\n
\n
sm_53
\n
Adds support for arithmetic, comparsion and texture instructions for .f16 and .f16x2 types.
Requires map_f64_to_f32 if any .f64 instructions used.
\n
\n
\n
\n
sm_13
\n
\n
Adds double-precision support, including expanded rounding modifiers.
\n
Disallows use of map_f64_to_f32.
\n
\n
\n\n
\n
The texturing mode is specified for an entire module and cannot be changed within the module.
\n
The .target debug option declares that the PTX file contains DWARF debug information, and\nsubsequent compilation of PTX will retain information needed for source-level debugging. If the\ndebug option is declared, an error message is generated if no DWARF information is found in the\nfile. The debug option requires PTX ISA version 3.0 or later.
\n
map_f64_to_f32 indicates that all double-precision instructions map to single-precision\nregardless of the target architecture. This enables high-level language compilers to compile\nprograms containing type double to target device that do not support double-precision\noperations. Note that .f64 storage remains as 64-bits, with only half being used by instructions\nconverted from .f64 to .f32.
\n
Notes
\n
Targets of the form compute_xx are also accepted as synonyms for sm_xx targets.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target strings sm_10 and sm_11 introduced in PTX ISA version 1.0.
\n
Target strings sm_12 and sm_13 introduced in PTX ISA version 1.2.
\n
Texturing mode introduced in PTX ISA version 1.5.
\n
Target string sm_20 introduced in PTX ISA version 2.0.
\n
Target string sm_30 introduced in PTX ISA version 3.0.
\n
Platform option debug introduced in PTX ISA version 3.0.
\n
Target string sm_35 introduced in PTX ISA version 3.1.
\n
Target strings sm_32 and sm_50 introduced in PTX ISA version 4.0.
\n
Target strings sm_37 and sm_52 introduced in PTX ISA version 4.1.
\n
Target string sm_53 introduced in PTX ISA version 4.2.
\n
Target string sm_60, sm_61, sm_62 introduced in PTX ISA version 5.0.
\n
Target string sm_70 introduced in PTX ISA version 6.0.
\n
Target string sm_72 introduced in PTX ISA version 6.1.
\n
Target string sm_75 introduced in PTX ISA version 6.3.
\n
Target string sm_80 introduced in PTX ISA version 7.0.
\n
Target string sm_86 introduced in PTX ISA version 7.1.
\n
Target string sm_87 introduced in PTX ISA version 7.4.
\n
Target string sm_89 introduced in PTX ISA version 7.8.
\n
Target string sm_90 introduced in PTX ISA version 7.8.
\n
Target string sm_90a introduced in PTX ISA version 8.0.
\n
Target ISA Notes
\n
The .target directive is supported on all target architectures.
\n",
- "tooltip": "Architecture and Platform target.\n\nSyntax\n\n.target stringlist // comma separated list of target specifiers\n\nstring = { sm_90a, sm_90, // sm_9x target architectures\n\n sm_80, sm_86, sm_87, sm_89, // sm_8x target architectures\n\n sm_70, sm_72, sm_75, // sm_7x target architectures\n\n sm_60, sm_61, sm_62, // sm_6x target architectures\n\n sm_50, sm_52, sm_53, // sm_5x target architectures\n\n sm_30, sm_32, sm_35, sm_37, // sm_3x target architectures\n\n sm_20, // sm_2x target architectures\n\n sm_10, sm_11, sm_12, sm_13, // sm_1x target architectures\n\n texmode_unified, texmode_independent, // texturing mode\n\n debug, // platform option\n\n map_f64_to_f32 }; // platform option\n\nDescription\n\nSpecifies the set of features in the target architecture for which the current PTX code was\n\ngenerated. In general, generations of SM architectures follow an onion layer model, where each\n\ngeneration adds new features and retains all features of previous generations. The onion layer model\n\nallows the PTX code generated for a given target to be run on later generation devices.\n\nTarget architectures with suffix \u201ca\u201d, such as sm_90a, include architecture-accelerated\n\nfeatures that are supported on the specified architecture only, hence such targets do not follow the\n\nonion layer model. Therefore, PTX code generated for such targets cannot be run on later generation\n\ndevices. Architecture-accelerated features can only be used with targets that support these\n\nfeatures.\n\nSemantics\n\nEach PTX module must begin with a .version directive, immediately followed by a .target\n\ndirective containing a target architecture and optional platform options. A .target directive\n\nspecifies a single target architecture, but subsequent .target directives can be used to change\n\nthe set of target features allowed during parsing. A program with multiple .target directives\n\nwill compile and run only on devices that support all features of the highest-numbered architecture\n\nlisted in the program.\n\nPTX features are checked against the specified target architecture, and an error is generated if an\n\nunsupported feature is used.\u00a0 The following table summarizes the features in PTX that vary according\n\nto target architecture.\n\n\n\nTarget\n\nDescription\n\n\n\nsm_90\n\nBaseline feature set for sm_90 architecture.\n\nsm_90a\n\nAdds support for sm_90a accelerated wgmma and setmaxnreg instructions.\n\n\n\n\n\nTarget\n\nDescription\n\n\n\nsm_80\n\nBaseline feature set for sm_80 architecture.\n\nsm_86\n\nAdds support for .xorsign modifier on min and max instructions.\n\nsm_87\n\nBaseline feature set for sm_86 architecture.\n\nsm_89\n\nBaseline feature set for sm_86 architecture.\n\n\n\n\n\nTarget\n\nDescription\n\n\n\nsm_70\n\nBaseline feature set for sm_70 architecture.\n\nsm_72\n\nAdds support for integer multiplicand and accumulator matrices in wmma instructions.\n\nAdds support for cvt.pack instruction.\n\nsm_75\n\nAdds support for sub-byte integer and single-bit multiplicant matrices in wmma instructions.\n\nAdds support for ldmatrix instruction.\n\nAdds support for movmatrix instruction.\n\nAdds support for tanh instruction.\n\n\n\n\n\nTarget\n\nDescription\n\n\n\nsm_60\n\nBaseline feature set for sm_60 architecture.\n\nsm_61\n\nAdds support for dp2a and dp4a instructions.\n\nsm_62\n\nBaseline feature set for sm_61 architecture.\n\n\n\n\n\nTarget\n\nDescription\n\n\n\nsm_50\n\nBaseline feature set for sm_50 architecture.\n\nsm_52\n\nBaseline feature set for sm_50 architecture.\n\nsm_53\n\nAdds support for arithmetic, comparsion and texture instructions for .f16 and .f16x2 types.\n\n\n\n\n\nTarget\n\nDescription\n\n\n\nsm_30\n\nBaseline feature set for sm_30 architecture.\n\nsm_32\n\nAdds 64-bit {atom,red}.{and,or,xor,min,max}\n\ninstructions.\n\nAdds shf instruction.\n\nAdds ld.global.nc instruction.\n\nsm_35\n\nAdds support for CUDA Dynamic Parallelism.\n\nsm_37\n\nBaseline feature set for sm_35 architecture.\n\n\n\n\n\nTarget\n\nDescription\n\n\n\nsm_20\n\nBaseline feature set for sm_20 architecture.\n\n\n\n\n\nTarget\n\nDescription\n\n\n\nsm_10\n\nBaseline fe ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#ptx-module-directives-target"
+ "html": "
tcgen05.alloc is a potentially blocking instruction which dynamically allocates\nthe specified number of columns in the Tensor Memory and writes\nthe address of the allocated Tensor Memory into shared memory\nat the location specified by address operand dst. The tcgen05.alloc blocks if the\nrequested amount of Tensor Memory is not available and unblocks\nas soon as the requested amount of Tensor Memory becomes\navailable for allocation.
\nFor more information, visit tcgen05.alloc .",
+ "tooltip": "DynamicTensor Memoryallocation management instructions",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#tcgen05-instructions-tcgen05-alloc-dealloc-relinquish-alloc-permit"
};
case "tensormap":
return {
- "html": "For more information, visit tensormap.cp_fenceproxy , tensormap.replace .
Parallel Synchronization and Communication Instructions: tensormap.cp_fenceproxy
The tensormap.cp_fence instructions perform the following operations in order :
\n
\n
Copies data of size specified by the size argument, in bytes, from the location specified\nby the address operand src in shared memory to the location specified by the address operand\ndst in the global memory, in the generic proxy.
\n
Establishes a uni-directional proxy release pattern on the ordering from the copy operation\nto the subsequent access performed in the tensormap proxy on the address dst.
\n
\n
The valid value of size operand is 128.
\n
The operands src and dst specify non-generic addresses in shared::cta and global\nstate space respectively.
\n
The optional .scope qualifier specifies the set of threads that can directly observe the proxy\nsynchronizing effect of this operation, as described in Memory Consistency Model.
\n
The mandatory .sync qualifier indicates that tensormap.cp_fenceproxy causes the executing\nthread to wait until all threads in the warp execute the same tensormap.cp_fenceproxy\ninstruction before resuming execution.
\n
The mandatory .aligned qualifier indicates that all threads in the warp must execute the same\ntensormap.cp_fenceproxy instruction. In conditionally executed code, an aligned tensormap.cp_fenceproxy\ninstruction should only be used if it is known that all threads in the warp evaluate the condition\nidentically, otherwise behavior is undefined.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 8.3.
\n
Target ISA Notes
\n
Requires sm_90 or higher.
\n
Examples
\n
\n
// Example: manipulate a tensor-map object and then consume it in cp.async.bulk.tensor\n\n.reg .b64 new_addr;\n.global .align 128 .b8 gbl[128];\n.shared .align 128 .b8 sMem[128];\n\ncp.async.bulk.shared::cluster.global.mbarrier::complete_tx::bytes [sMem], [gMem], 128, [mbar];\n...\ntry_wait_loop:\nmbarrier.try_wait.shared.b64 p, [mbar], state;\n@!p bra try_wait loop;\n\ntensormap.replace.tile.global_address.shared.b1024.b64 [sMem], new_addr;\ntensormap.cp_fenceproxy.global.shared::cta.proxy.tensormap::generic.release.gpu\n .sync.aligned [gbl], [sMem], 128;\nfence.proxy.tensormap::generic.acquire.gpu [gbl], 128;\ncp.async.bulk.tensor.1d.shared::cluster.global.tile [addr0], [gbl, {tc0}], [mbar0];\n
\n
\n\n
Data Movement and Conversion Instructions: tensormap.replace
The tensormap.replace instruction replaces the field, specified by .field qualifier,\nof the tensor-map object at the location specified by the address operand addr with a\nnew value. The new value is specified by the argument new_val.
\n
Qualifier .mode specifies the mode of the tensor-map object\nlocated at the address operand addr.
\n
Instruction type .b1024 indicates the size of the tensor-map\nobject, which is 1024 bits.
\n
Operand new_val has the type .type. When .field is specified as .global_address\nor .global_stride, .type must be .b64. Otherwise, .type must be .b32.
\n
The immediate integer operand ord specifies the ordinal of the field across the rank of the\ntensor which needs to be replaced in the tensor-map object.
\n
For field .rank, the operand new_val must be ones less than the desired tensor rank as\nthis field uses zero-based numbering.
\n
When .field3 is specified, the operand new_val must be an immediate and the\nTable 32 shows the mapping of the operand new_val across various fields.
If no state space is specified then Generic Addressing is used.\nIf the address specified by addr does not fall within the address window of .global\nor .shared::cta state space then the behavior is undefined.
\n
tensormap.replace is treated as a weak memory operation, on the entire 1024-bit opaque\ntensor-map object, in the Memory Consistency Model.
\n",
- "tooltip": "=====Parallel Synchronization and Communication Instructions: tensormap.cp_fenceproxy\n\n\n\nA fused copy and fence operation.\n\nSyntax\n\ntensormap.cp_fenceproxy.cp_qualifiers.fence_qualifiers.sync.aligned [dst], [src], size;\n\n.cp_qualifiers = { .global.shared::cta }\n\n.fence_qualifiers = { .to_proxy::from_proxy.release.scope }\n\n.to_proxy::from_proxy = { .tensormap::generic }\n\n.scope = { .cta, .cluster, .gpu , .sys }\n\nDescription\n\nThe tensormap.cp_fence instructions perform the follo...\n\n=====Data Movement and Conversion Instructions: tensormap.replace\n\n\n\nModifies the field of a tensor-map object.\n\nSyntax\n\ntensormap.replace.mode.field1{.ss}.b1024.type [addr], new_val;\n\ntensormap.replace.mode.field2{.ss}.b1024.type [addr], ord, new_val;\n\ntensormap.replace.mode.field3{.ss}.b1024.type [addr], new_val;\n\n.mode = { .tile }\n\n.field1 = { .global_address, .rank }\n\n.field2 = { .box_dim, .global_dim, .global_stride, .element_stride }\n\n.field3 = { .elemtype,... ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-tensormap-cp-fenceproxy"
+ "html": "
The tensormap.replace instruction replaces the field, specified by .field qualifier,\nof the tensor-map object at the location specified by the address operand addr with a\nnew value. The new value is specified by the argument new_val.
\nFor more information, visit tensormap.replace .",
+ "tooltip": "Modifies the field of a tensor-map object.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-tensormap-replace"
};
case "testp":
return {
- "html": "For more information, visit testp(fp) .
\n",
- "tooltip": "Test floating-point property.\n\nSyntax\n\ntestp.op.type p, a; // result is .pred\n\n.op = { .finite, .infinite,\n\n .number, .notanumber,\n\n .normal, .subnormal };\n\n.type = { .f32, .f64 };\n\nDescription\n\ntestp tests common properties of floating-point numbers and returns a predicate value of 1\n\nif True and 0 if False.\n\ntestp.finite\n\nTrue if the input is not infinite or NaN\n\ntestp.infinite\n\nTrue if the input is positive or negative infinity\n\ntestp.number\n\nTrue if the input is not NaN\n\ntestp.notanumber\n\nTrue if the input is NaN\n\ntestp.normal\n\nTrue if the input is a normal number (not NaN, not infinity)\n\ntestp.subnormal\n\nTrue if the input is a subnormal number (not NaN, not infinity)\n\nAs a special case, positive and negative zero are considered normal numbers.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nRequires sm_20 or higher.\n\nExamples\n\ntestp.notanumber.f32 isnan, f0;\n\ntestp.infinite.f64 p, X;\n\n ...",
+ "html": "
testp tests common properties of floating-point numbers and returns a predicate value of 1\nif True and 0 if False.
\nFor more information, visit testp(fp) .",
+ "tooltip": "Test floating-point property.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-testp"
};
case "tex":
return {
- "html": "For more information, visit tex .
Texture lookup using a texture coordinate vector. The instruction loads data from the texture named\nby operand a at coordinates given by operand c into destination d. Operand c is a\nscalar or singleton tuple for 1d textures; is a two-element vector for 2d textures; and is a\nfour-element vector for 3d textures, where the fourth element is ignored. An optional texture\nsampler b may be specified. If no sampler is specified, the sampler behavior is a property of\nthe named texture. The optional destination predicate p is set to True if data from texture\nat specified coordinates is resident in memory, False otherwise. When optional destination\npredicate p is set to False, data loaded will be all zeros. Memory residency of Texture Data\nat specified coordinates is dependent on execution environment setup using Driver API calls, prior\nto kernel launch. Refer to Driver API documentation for more details including any\nsystem/implementation specific behavior.
\n
An optional operand e may be specified. Operand e is a vector of .s32 values that\nspecifies coordinate offset. Offset is applied to coordinates before doing texture lookup. Offset\nvalue is in the range of -8 to +7. Operand e is a singleton tuple for 1d textures; is a two\nelement vector 2d textures; and is four-element vector for 3d textures, where the fourth element is\nignored.
\n
An optional operand f may be specified for depthtextures. Depth textures are special type\nof textures which hold data from the depth buffer. Depth buffer contains depth information of each\npixel. Operand f is .f32 scalar value that specifies depth compare value for depth\ntextures. Each element fetched from texture is compared against value given in f operand. If\ncomparison passes, result is 1.0; otherwise result is 0.0. These per-element comparison results are\nused for the filtering. When using depth compare operand, the elements in texture coordinate vector\nc have .f32 type.
\n
Depth compare operand is not supported for 3d textures.
\n
The instruction returns a two-element vector for destination type .f16x2. For all other\ndestination types, the instruction returns a four-element vector. Coordinates may be given in either\nsigned 32-bit integer or 32-bit floating point form.
\n
A texture base address is assumed to be aligned to a 16 byte boundary, and the address given by the\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.
\n
tex.{a1d,a2d}
\n
Texture array selection, followed by texture lookup. The instruction first selects a texture from\nthe texture array named by operand a using the index given by the first element of the array\ncoordinate vector c. The instruction then loads data from the selected texture at coordinates\ngiven by the remaining elements of operand c into destination d. Operand c is a bit-size\ntype vector or tuple containing an index into the array of textures followed by coordinates within\nthe selected texture, as follows:
\n
\n
For 1d texture arrays, operand c has type .v2.b32. The first element is interpreted as an\nunsigned integer index (.u32) into the texture array, and the second element is interpreted as\na 1d texture coordinate of type .ctype.
\n
For 2d texture arrays, operand c has type .v4.b32. The first element is interpreted as an\nunsigned integer index (.u32) into the texture array, and the next two elements are\ninterpreted as 2d texture coordinates of type .ctype. The fourth element is ignored.
\n
\n
An optional texture sampler b may be specified. If no sampler is specified, the sampler behavior\nis a property of the named texture.
\n
An optional operand e may be specified. Operand e is a vector of .s32 values that\nspecifies coordinate offset. Offset is applied to coordinates before doing texture lookup. Offset\nvalue is in the range of -8 to +7. Operand e is a singleton tuple for 1d texture arrays; and is\na two element vector 2d texture arrays.
\n
An optional operand f may be specified for depth textures arrays. Operand f is .f32\nscalar value that specifies depth compare value for depth textures. When using depth compare\noperand, the coordinates in texture coordinate vector c have .f32 type.
\n
The instruction returns a two-element vector for destination type .f16x2. For all other\ndestination types, the instruction returns a four-element vector. The texture array index is a\n32-bit unsigned integer, and texture coordinate elements are 32-bit signed integer or floating point\nvalues.
\n
The optional destination predicate p is set to True if data from texture at specified\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\nlaunch. Refer to Driver API documentation for more details including any system/implementation\nspecific behavior.
\n
tex.cube
\n
Cubemap texture lookup. The instruction loads data from the cubemap texture named by operand a\nat coordinates given by operand c into destination d. Cubemap textures are special\ntwo-dimensional layered textures consisting of six layers that represent the faces of a cube. All\nlayers in a cubemap are of the same size and are square (i.e., width equals height).
\n
When accessing a cubemap, the texture coordinate vector c has type .v4.f32, and comprises\nthree floating-point coordinates (s, t, r) and a fourth padding argument which is\nignored. Coordinates (s, t, r) are projected onto one of the six cube faces. The (s,\nt, r) coordinates can be thought of as a direction vector emanating from the center of the\ncube. Of the three coordinates (s, t, r), the coordinate of the largest magnitude (the\nmajor axis) selects the cube face. Then, the other two coordinates (the minor axes) are divided by\nthe absolute value of the major axis to produce a new (s, t) coordinate pair to lookup into\nthe selected cube face.
\n
An optional texture sampler b may be specified. If no sampler is specified, the sampler behavior\nis a property of the named texture.
\n
Offset vector operand e is not supported for cubemap textures.
\n
an optional operand f may be specified for cubemap depth textures. operand f is .f32\nscalar value that specifies depth compare value for cubemap depth textures.
\n
The optional destination predicate p is set to True if data from texture at specified\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\nlaunch. Refer to Driver API documentation for more details including any system/implementation\nspecific behavior.
\n
tex.acube
\n
Cubemap array selection, followed by cubemap lookup. The instruction first selects a cubemap texture\nfrom the cubemap array named by operand a using the index given by the first element of the\narray coordinate vector c. The instruction then loads data from the selected cubemap texture at\ncoordinates given by the remaining elements of operand c into destination d.
\n
Cubemap array textures consist of an array of cubemaps, i.e., the total number of layers is a\nmultiple of six. When accessing a cubemap array texture, the coordinate vector c has type\n.v4.b32. The first element is interpreted as an unsigned integer index (.u32) into the\ncubemap array, and the remaining three elements are interpreted as floating-point cubemap\ncoordinates (s, t, r), used to lookup in the selected cubemap as described above.
\n
An optional texture sampler b may be specified. If no sampler is specified, the sampler behavior\nis a property of the named texture.
\n
Offset vector operand e is not supported for cubemap texture arrays.
\n
An optional operand f may be specified for cubemap depth texture arrays. Operand f is\n.f32 scalar value that specifies depth compare value for cubemap depth textures.
\n
The optional destination predicate p is set to True if data from texture at specified\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\nlaunch. Refer to Driver API documentation for more details including any system/implementation\nspecific behavior.
\n
tex.2dms
\n
Multi-sample texture lookup using a texture coordinate vector. Multi-sample textures consist of\nmultiple samples per data element. The instruction loads data from the texture named by operand\na from sample number given by first element of the operand c, at coordinates given by\nremaining elements of operand c into destination d. When accessing a multi-sample texture,\ntexture coordinate vector c has type .v4.b32. The first element in operand c is\ninterpreted as unsigned integer sample number (.u32), and the next two elements are interpreted\nas signed integer (.s32) 2d texture coordinates. The fourth element is ignored. An optional\ntexture sampler b may be specified. If no sampler is specified, the sampler behavior is a\nproperty of the named texture.
\n
An optional operand e may be specified. Operand e is a vector of type .v2.s32 that\nspecifies coordinate offset. Offset is applied to coordinates before doing texture lookup. Offset\nvalue is in the range of -8 to +7.
\n
Depth compare operand f is not supported for multi-sample textures.
\n
The optional destination predicate p is set to True if data from texture at specified\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\nlaunch. Refer to Driver API documentation for more details including any system/implementation\nspecific behavior.
\n
tex.a2dms
\n
Multi-sample texture array selection, followed by multi-sample texture lookup. The instruction first\nselects a multi-sample texture from the multi-sample texture array named by operand a using the\nindex given by the first element of the array coordinate vector c. The instruction then loads\ndata from the selected multi-sample texture from sample number given by second element of the\noperand c, at coordinates given by remaining elements of operand c into destination\nd. When accessing a multi-sample texture array, texture coordinate vector c has type\n.v4.b32. The first element in operand c is interpreted as unsigned integer sampler number, the\nsecond element is interpreted as unsigned integer index (.u32) into the multi-sample texture\narray and the next two elements are interpreted as signed integer (.s32) 2d texture\ncoordinates. An optional texture sampler b may be specified. If no sampler is specified, the\nsampler behavior is a property of the named texture.
\n
An optional operand e may be specified. Operand e is a vector of type .v2.s32 values\nthat specifies coordinate offset. Offset is applied to coordinates before doing texture\nlookup. Offset value is in the range of -8 to +7.
\n
Depth compare operand f is not supported for multi-sample texture arrays.
\n
The optional destination predicate p is set to True if data from texture at specified\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\nlaunch. Refer to Driver API documentation for more details including any system/implementation\nspecific behavior.
\n
Mipmaps
\n
\n
\n.base (lod zero)
\n
\n
Pick level 0 (base level). This is the default if no mipmap mode is specified. No additional arguments.
\n
\n
\n.level (lod explicit)
\n
\n
Requires an additional 32-bit scalar argument, lod, which contains the LOD to fetch from. The\ntype of lod follows .ctype (either .s32 or .f32). Geometries .2dms and\n.a2dms are not supported in this mode.
\n
\n
\n.grad (lod gradient)
\n
\n
Requires two .f32 vectors, dPdx and dPdy, that specify the partials. The vectors are\nsingletons for 1d and a1d textures; are two-element vectors for 2d and a2d textures; and are\nfour-element vectors for 3d, cube and acube textures, where the fourth element is ignored for 3d\nand cube geometries. Geometries .2dms and .a2dms are not supported in this mode.
\n
\n
\n
For mipmap texture lookup, an optional operand e may be specified. Operand e is a vector of\n.s32 that specifies coordinate offset. Offset is applied to coordinates before doing texture\nlookup. Offset value is in the range of -8 to +7. Offset vector operand is not supported for cube\nand cubemap geometries.
\n
An optional operand f may be specified for mipmap textures. Operand f is .f32 scalar\nvalue that specifies depth compare value for depth textures. When using depth compare operand, the\ncoordinates in texture coordinate vector c have .f32 type.
\n
The optional destination predicate p is set to True if data from texture at specified\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\nlaunch. Refer to Driver API documentation for more details including any system/implementation\nspecific behavior.
\n
Depth compare operand is not supported for 3d textures.
\n
Indirect texture access
\n
Beginning with PTX ISA version 3.1, indirect texture access is supported in unified mode for target\narchitecture sm_20 or higher. In indirect access, operand a is a .u64 register holding\nthe address of a .texref variable.
\n
Notes
\n
For compatibility with prior versions of PTX, the square brackets are not required and .v4\ncoordinate vectors are allowed for any geometry, with the extra elements being ignored.
\n
PTX ISA Notes
\n
Unified mode texturing introduced in PTX ISA version 1.0. Extension using opaque .texref and\n.samplerref types and independent mode texturing introduced in PTX ISA version 1.5.
\n
Texture arrays tex.{a1d,a2d} introduced in PTX ISA version 2.3.
\n
Cubemaps and cubemap arrays introduced in PTX ISA version 3.0.
\n
Support for mipmaps introduced in PTX ISA version 3.1.
\n
Indirect texture access introduced in PTX ISA version 3.1.
\n
Multi-sample textures and multi-sample texture arrays introduced in PTX ISA version 3.2.
\n
Support for textures returning .f16 and .f16x2 data introduced in PTX ISA version 4.2.
\n
Support for tex.grad.{cube,acube} introduced in PTX ISA version 4.3.
\n
Offset vector operand introduced in PTX ISA version 4.3.
\n
Depth compare operand introduced in PTX ISA version 4.3.
\n
Support for optional destination predicate introduced in PTX ISA version 7.1.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
The cubemap array geometry (.acube) requires sm_20 or higher.
\n
Mipmaps require sm_20 or higher.
\n
Indirect texture access requires sm_20 or higher.
\n
Multi-sample textures and multi-sample texture arrays require sm_30 or higher.
\n
Texture fetch returning .f16 and .f16x2 data require sm_53 or higher.
\n
tex.grad.{cube,acube} requires sm_20 or higher.
\n
Offset vector operand requires sm_30 or higher.
\n
Depth compare operand requires sm_30 or higher.
\n
Support for optional destination predicate requires sm_60 or higher.
\n
Examples
\n
\n
// Example of unified mode texturing\n // - f4 is required to pad four-element tuple and is ignored\n tex.3d.v4.s32.s32 {r1,r2,r3,r4}, [tex_a,{f1,f2,f3,f4}];\n\n // Example of independent mode texturing\n tex.1d.v4.s32.f32 {r1,r2,r3,r4}, [tex_a,smpl_x,{f1}];\n\n // Example of 1D texture array, independent texturing mode\n tex.a1d.v4.s32.s32 {r1,r2,r3,r4}, [tex_a,smpl_x,{idx,s1}];\n\n // Example of 2D texture array, unified texturing mode\n // - f3 is required to pad four-element tuple and is ignored\n tex.a2d.v4.s32.f32 {r1,r2,r3,r4}, [tex_a,{idx,f1,f2,f3}];\n\n // Example of cubemap array, unified textureing mode\n tex.acube.v4.f32.f32 {r0,r1,r2,r3}, [tex_cuarray,{idx,f1,f2,f3}];\n\n // Example of multi-sample texture, unified texturing mode\n tex.2dms.v4.s32.s32 {r0,r1,r2,r3}, [tex_ms,{sample,r6,r7,r8}];\n\n // Example of multi-sample texture, independent texturing mode\n tex.2dms.v4.s32.s32 {r0,r1,r2,r3}, [tex_ms, smpl_x,{sample,r6,r7,r8}];\n\n // Example of multi-sample texture array, unified texturing mode\n tex.a2dms.v4.s32.s32 {r0,r1,r2,r3}, [tex_ams,{idx,sample,r6,r7}];\n\n // Example of texture returning .f16 data\n tex.1d.v4.f16.f32 {h1,h2,h3,h4}, [tex_a,smpl_x,{f1}];\n\n // Example of texture returning .f16x2 data\n tex.1d.v2.f16x2.f32 {h1,h2}, [tex_a,smpl_x,{f1}];\n\n // Example of 3d texture array access with tex.grad,unified texturing mode\n tex.grad.3d.v4.f32.f32 {%f4,%f5,%f6,%f7},[tex_3d,{%f0,%f0,%f0,%f0}],\n {fl0,fl1,fl2,fl3},{fl0,fl1,fl2,fl3};\n\n// Example of cube texture array access with tex.grad,unified texturing mode\n tex.grad.cube.v4.f32.f32{%f4,%f5,%f6,%f7},[tex_cube,{%f0,%f0,%f0,%f0}],\n {fl0,fl1,fl2,fl3},{fl0,fl1,fl2,fl3};\n\n // Example of 1d texture lookup with offset, unified texturing mode\n tex.1d.v4.s32.f32 {r1,r2,r3,r4}, [tex_a, {f1}], {r5};\n\n // Example of 2d texture array lookup with offset, unified texturing mode\n tex.a2d.v4.s32.f32 {r1,r2,r3,r4}, [tex_a,{idx,f1,f2}], {f5,f6};\n\n // Example of 2d mipmap texture lookup with offset, unified texturing mode\n tex.level.2d.v4.s32.f32 {r1,r2,r3,r4}, [tex_a,{f1,f2}],\n flvl, {r7, r8};\n\n // Example of 2d depth texture lookup with compare, unified texturing mode\n tex.1d.v4.f32.f32 {f1,f2,f3,f4}, [tex_a, {f1}], f0;\n\n // Example of depth 2d texture array lookup with offset, compare\n tex.a2d.v4.s32.f32 {f0,f1,f2,f3}, [tex_a,{idx,f4,f5}], {r5,r6}, f6;\n\n // Example of destination predicate use\n tex.3d.v4.s32.s32 {r1,r2,r3,r4}|p, [tex_a,{f1,f2,f3,f4}];\n
\n
\n",
- "tooltip": "Perform a texture memory lookup.\n\nSyntax\n\ntex.geom.v4.dtype.ctype d, [a, c] {, e} {, f};\n\ntex.geom.v4.dtype.ctype d[|p], [a, b, c] {, e} {, f}; // explicit sampler\n\ntex.geom.v2.f16x2.ctype d[|p], [a, c] {, e} {, f};\n\ntex.geom.v2.f16x2.ctype d[|p], [a, b, c] {, e} {, f}; // explicit sampler\n\n// mipmaps\n\ntex.base.geom.v4.dtype.ctype d[|p], [a, {b,} c] {, e} {, f};\n\ntex.level.geom.v4.dtype.ctype d[|p], [a, {b,} c], lod {, e} {, f};\n\ntex.grad.geom.v4.dtype.ctype d[|p], [a, {b,} c], dPdx, dPdy {, e} {, f};\n\ntex.base.geom.v2.f16x2.ctype d[|p], [a, {b,} c] {, e} {, f};\n\ntex.level.geom.v2.f16x2.ctype d[|p], [a, {b,} c], lod {, e} {, f};\n\ntex.grad.geom.v2.f16x2.ctype d[|p], [a, {b,} c], dPdx, dPdy {, e} {, f};\n\n.geom = { .1d, .2d, .3d, .a1d, .a2d, .cube, .acube, .2dms, .a2dms };\n\n.dtype = { .u32, .s32, .f16, .f32 };\n\n.ctype = { .s32, .f32 }; // .cube, .acube require .f32\n\n // .2dms, .a2dms require .s32\n\nDescription\n\ntex.{1d,2d,3d}\n\nTexture lookup using a texture coordinate vector. The instruction loads data from the texture named\n\nby operand a at coordinates given by operand c into destination d. Operand c is a\n\nscalar or singleton tuple for 1d textures; is a two-element vector for 2d textures; and is a\n\nfour-element vector for 3d textures, where the fourth element is ignored. An optional texture\n\nsampler b may be specified. If no sampler is specified, the sampler behavior is a property of\n\nthe named texture. The optional destination predicate p is set to True if data from texture\n\nat specified coordinates is resident in memory, False otherwise. When optional destination\n\npredicate p is set to False, data loaded will be all zeros. Memory residency of Texture Data\n\nat specified coordinates is dependent on execution environment setup using Driver API calls, prior\n\nto kernel launch. Refer to Driver API documentation for more details including any\n\nsystem/implementation specific behavior.\n\nAn optional operand e may be specified. Operand e is a vector of .s32 values that\n\nspecifies coordinate offset. Offset is applied to coordinates before doing texture lookup. Offset\n\nvalue is in the range of -8 to +7. Operand e is a singleton tuple for 1d textures; is a two\n\nelement vector 2d textures; and is four-element vector for 3d textures, where the fourth element is\n\nignored.\n\nAn optional operand f may be specified for depth textures. Depth textures are special type\n\nof textures which hold data from the depth buffer. Depth buffer contains depth information of each\n\npixel. Operand f is .f32 scalar value that specifies depth compare value for depth\n\ntextures. Each element fetched from texture is compared against value given in f operand. If\n\ncomparison passes, result is 1.0; otherwise result is 0.0. These per-element comparison results are\n\nused for the filtering. When using depth compare operand, the elements in texture coordinate vector\n\nc have .f32 type.\n\nDepth compare operand is not supported for 3d textures.\n\nThe instruction returns a two-element vector for destination type .f16x2. For all other\n\ndestination types, the instruction returns a four-element vector. Coordinates may be given in either\n\nsigned 32-bit integer or 32-bit floating point form.\n\nA texture base address is assumed to be aligned to a 16 byte boundary, and the address given by the\n\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\n\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\n\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.\n\ntex.{a1d,a2d}\n\nTexture array selection, followed by texture lookup. The instruction first selects a texture from\n\nthe texture array named by operand a using the index given by the first element of the array\n\ncoordinate vector c. The instruction then loads data from the selected texture at coordinates\n\ngiven by the remaining elements of operand c into destination d. Operand c is a bit-size\n\ntype vect ...",
+ "html": "
tex.{1d,2d,3d}
\nFor more information, visit tex .",
+ "tooltip": "Perform a texture memory lookup.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#texture-instructions-tex"
};
- case "tid":
- return {
- "html": "For more information, visit tid .
Special Registers: %tid
\n\n\n
Thread identifier within a CTA.
\n
Syntax (predefined)
\n
\n
.sreg .v4 .u32 %tid; // thread id vector\n.sreg .u32 %tid.x, %tid.y, %tid.z; // thread id components\n
\n
\n
Description
\n
A predefined, read-only, per-thread special register initialized with the thread identifier within\nthe CTA. The %tid special register contains a 1D, 2D, or 3D vector to match the CTA shape; the\n%tid value in unused dimensions is 0. The fourth element is unused and always returns\nzero. The number of threads in each dimension are specified by the predefined special register\n%ntid.
\n
Every thread in the CTA has a unique %tid.
\n
%tid component values range from 0 through %ntid-1 in each CTA dimension.
\n
%tid.y==%tid.z==0 in 1D CTAs. %tid.z==0 in 2D CTAs.
Introduced in PTX ISA version 1.0 with type .v4.u16.
\n
Redefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n%tid.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mov.u32 %r1,%tid.x; // move tid.x to %rh\n\n// legacy code accessing 16-bit components of %tid\nmov.u16 %rh,%tid.x;\ncvt.u32.u16 %r2,%tid.z; // zero-extend tid.z to %r2\n
\n
\n",
- "tooltip": "Thread identifier within a CTA.\n\nSyntax (predefined)\n\n.sreg .v4 .u32 %tid; // thread id vector\n\n.sreg .u32 %tid.x, %tid.y, %tid.z; // thread id components\n\nDescription\n\nA predefined, read-only, per-thread special register initialized with the thread identifier within\n\nthe CTA. The %tid special register contains a 1D, 2D, or 3D vector to match the CTA shape; the\n\n%tid value in unused dimensions is 0. The fourth element is unused and always returns\n\nzero. The number of threads in each dimension are specified by the predefined special register\n\n%ntid.\n\nEvery thread in the CTA has a unique %tid.\n\n%tid component values range from 0 through %ntid-1 in each CTA dimension.\n\n%tid.y == %tid.z == 0 in 1D CTAs. %tid.z == 0 in 2D CTAs.\n\nIt is guaranteed that:\n\n0 <= %tid.x < %ntid.x\n\n0 <= %tid.y < %ntid.y\n\n0 <= %tid.z < %ntid.z\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0 with type .v4.u16.\n\nRedefined as type .v4.u32 in PTX ISA version 2.0. For compatibility with legacy PTX code, 16-bit\n\nmov and cvt instructions may be used to read the lower 16-bits of each component of\n\n%tid.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.u32 %r1,%tid.x; // move tid.x to %rh\n\n// legacy code accessing 16-bit components of %tid\n\nmov.u16 %rh,%tid.x;\n\ncvt.u32.u16 %r2,%tid.z; // zero-extend tid.z to %r2\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-tid"
- };
-
case "tld4":
return {
- "html": "For more information, visit tld4 .
Texture Instructions: tld4
\n\n\n
Perform a texture fetch of the 4-texel bilerp footprint.
Texture fetch of the 4-texel bilerp footprint using a texture coordinate vector. The instruction\nloads the bilerp footprint from the texture named by operand a at coordinates given by operand\nc into vector destination d. The texture component fetched for each texel sample is\nspecified by .comp. The four texel samples are placed into destination vector d in\ncounter-clockwise order starting at lower left.
\n
An optional texture sampler b may be specified. If no sampler is specified, the sampler behavior\nis a property of the named texture.
\n
The optional destination predicate p is set to True if data from texture at specified\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\nlaunch. Refer to Driver API documentation for more details including any system/implementation\nspecific behavior.
\n
An optional operand f may be specified for depth textures. Depth textures are special type of\ntextures which hold data from the depth buffer. Depth buffer contains depth information of each\npixel. Operand f is .f32 scalar value that specifies depth compare value for depth\ntextures. Each element fetched from texture is compared against value given in f operand. If\ncomparison passes, result is 1.0; otherwise result is 0.0. These per-element comparison results are\nused for the filtering.
\n
A texture base address is assumed to be aligned to a 16 byte boundary, and the address given by the\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.
\n
tld4.2d
\n
For 2D textures, operand c specifies coordinates as a two-element, 32-bit floating-point vector.
\n
An optional operand e may be specified. Operand e is a vector of type .v2.s32 that\nspecifies coordinate offset. Offset is applied to coordinates before doing texture fetch. Offset\nvalue is in the range of -8 to +7.
\n
tld4.a2d
\n
Texture array selection, followed by tld4 texture fetch of 2d texture. For 2d texture arrays\noperand c is a four element, 32-bit vector. The first element in operand c is interpreted as an\nunsigned integer index (.u32) into the texture array, and the next two elements are interpreted\nas 32-bit floating point coordinates of 2d texture. The fourth element is ignored.
\n
An optional operand e may be specified. Operand e is a vector of type .v2.s32 that\nspecifies coordinate offset. Offset is applied to coordinates before doing texture fetch. Offset\nvalue is in the range of -8 to +7.
\n
tld4.cube
\n
For cubemap textures, operand c specifies four-element vector which comprises three\nfloating-point coordinates (s, t, r) and a fourth padding argument which is ignored.
\n
Cubemap textures are special two-dimensional layered textures consisting of six layers that\nrepresent the faces of a cube. All layers in a cubemap are of the same size and are square (i.e.,\nwidth equals height).
\n
Coordinates (s, t, r) are projected onto one of the six cube faces. The (s, t, r) coordinates can be\nthought of as a direction vector emanating from the center of the cube. Of the three coordinates (s,\nt, r), the coordinate of the largest magnitude (the major axis) selects the cube face. Then, the\nother two coordinates (the minor axes) are divided by the absolute value of the major axis to\nproduce a new (s, t) coordinate pair to lookup into the selected cube face.
\n
Offset vector operand e is not supported for cubemap textures.
\n
tld4.acube
\n
Cubemap array selection, followed by tld4 texture fetch of cubemap texture. The first element in\noperand c is interpreted as an unsigned integer index (.u32) into the cubemap texture array,\nand the remaining three elements are interpreted as floating-point cubemap coordinates (s, t, r),\nused to lookup in the selected cubemap.
\n
Offset vector operand e is not supported for cubemap texture arrays.
\n
Indirect texture access
\n
Beginning with PTX ISA version 3.1, indirect texture access is supported in unified mode for target\narchitecture sm_20 or higher. In indirect access, operand a is a .u64 register holding\nthe address of a .texref variable.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.2.
\n
Indirect texture access introduced in PTX ISA version 3.1.
\n
tld4.{a2d,cube,acube} introduced in PTX ISA version 4.3.
\n
Offset vector operand introduced in PTX ISA version 4.3.
\n
Depth compare operand introduced in PTX ISA version 4.3.
\n
Support for optional destination predicate introduced in PTX ISA version 7.1.
\n
Target ISA Notes
\n
tld4 requires sm_20 or higher.
\n
Indirect texture access requires sm_20 or higher.
\n
tld4.{a2d,cube,acube} requires sm_30 or higher.
\n
Offset vector operand requires sm_30 or higher.
\n
Depth compare operand requires sm_30 or higher.
\n
Support for optional destination predicate requires sm_60 or higher.
\n
Examples
\n
\n
//Example of unified mode texturing\ntld4.r.2d.v4.s32.f32 {r1,r2,r3,r4}, [tex_a,{f1,f2}];\n\n// Example of independent mode texturing\ntld4.r.2d.v4.u32.f32 {u1,u2,u3,u4}, [tex_a,smpl_x,{f1,f2}];\n\n// Example of unified mode texturing using offset\ntld4.r.2d.v4.s32.f32 {r1,r2,r3,r4}, [tex_a,{f1,f2}], {r5, r6};\n\n// Example of unified mode texturing using compare\ntld4.r.2d.v4.f32.f32 {f1,f2,f3,f4}, [tex_a,{f5,f6}], f7;\n\n// Example of optional destination predicate\ntld4.r.2d.v4.f32.f32 {f1,f2,f3,f4}|p, [tex_a,{f5,f6}], f7;\n
\n
\n",
- "tooltip": "Perform a texture fetch of the 4-texel bilerp footprint.\n\nSyntax\n\ntld4.comp.2d.v4.dtype.f32 d[|p], [a, c] {, e} {, f};\n\ntld4.comp.geom.v4.dtype.f32 d[|p], [a, b, c] {, e} {, f}; // explicit sampler\n\n.comp = { .r, .g, .b, .a };\n\n.geom = { .2d, .a2d, .cube, .acube };\n\n.dtype = { .u32, .s32, .f32 };\n\nDescription\n\nTexture fetch of the 4-texel bilerp footprint using a texture coordinate vector. The instruction\n\nloads the bilerp footprint from the texture named by operand a at coordinates given by operand\n\nc into vector destination d. The texture component fetched for each texel sample is\n\nspecified by .comp. The four texel samples are placed into destination vector d in\n\ncounter-clockwise order starting at lower left.\n\nAn optional texture sampler b may be specified. If no sampler is specified, the sampler behavior\n\nis a property of the named texture.\n\nThe optional destination predicate p is set to True if data from texture at specified\n\ncoordinates is resident in memory, False otherwise. When optional destination predicate p is\n\nset to False, data loaded will be all zeros. Memory residency of Texture Data at specified\n\ncoordinates is dependent on execution environment setup using Driver API calls, prior to kernel\n\nlaunch. Refer to Driver API documentation for more details including any system/implementation\n\nspecific behavior.\n\nAn optional operand f may be specified for depth textures. Depth textures are special type of\n\ntextures which hold data from the depth buffer. Depth buffer contains depth information of each\n\npixel. Operand f is .f32 scalar value that specifies depth compare value for depth\n\ntextures. Each element fetched from texture is compared against value given in f operand. If\n\ncomparison passes, result is 1.0; otherwise result is 0.0. These per-element comparison results are\n\nused for the filtering.\n\nA texture base address is assumed to be aligned to a 16 byte boundary, and the address given by the\n\ncoordinate vector must be naturally aligned to a multiple of the access size. If an address is not\n\nproperly aligned, the resulting behavior is undefined; i.e., the access may proceed by silently\n\nmasking off low-order address bits to achieve proper rounding, or the instruction may fault.\n\ntld4.2d\n\nFor 2D textures, operand c specifies coordinates as a two-element, 32-bit floating-point vector.\n\nAn optional operand e may be specified. Operand e is a vector of type .v2.s32 that\n\nspecifies coordinate offset. Offset is applied to coordinates before doing texture fetch. Offset\n\nvalue is in the range of -8 to +7.\n\ntld4.a2d\n\nTexture array selection, followed by tld4 texture fetch of 2d texture. For 2d texture arrays\n\noperand c is a four element, 32-bit vector. The first element in operand c is interpreted as an\n\nunsigned integer index (.u32) into the texture array, and the next two elements are interpreted\n\nas 32-bit floating point coordinates of 2d texture. The fourth element is ignored.\n\nAn optional operand e may be specified. Operand e is a vector of type .v2.s32 that\n\nspecifies coordinate offset. Offset is applied to coordinates before doing texture fetch. Offset\n\nvalue is in the range of -8 to +7.\n\ntld4.cube\n\nFor cubemap textures, operand c specifies four-element vector which comprises three\n\nfloating-point coordinates (s, t, r) and a fourth padding argument which is ignored.\n\nCubemap textures are special two-dimensional layered textures consisting of six layers that\n\nrepresent the faces of a cube. All layers in a cubemap are of the same size and are square (i.e.,\n\nwidth equals height).\n\nCoordinates (s, t, r) are projected onto one of the six cube faces. The (s, t, r) coordinates can be\n\nthought of as a direction vector emanating from the center of the cube. Of the three coordinates (s,\n\nt, r), the coordinate of the largest magnitude (the major axis) selects the cube face. Then, the\n\nother two coordinates (the minor axes) are divided by the absolute value of the major axis to\n\nproduce a new (s, t) coordinate pair to lookup into the selected cube face.\n\nOffset vector opera ...",
+ "html": "
Texture fetch of the 4-texel bilerp footprint using a texture coordinate vector. The instruction\nloads the bilerp footprint from the texture named by operand a at coordinates given by operand\nc into vector destination d. The texture component fetched for each texel sample is\nspecified by .comp. The four texel samples are placed into destination vector d in\ncounter-clockwise order starting at lower left.
\nFor more information, visit tld4 .",
+ "tooltip": "Perform a texture fetch of the 4-texel bilerp footprint.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#texture-instructions-tld4"
};
- case "total_smem_size":
- return {
- "html": "For more information, visit total_smem_size .
Special Registers: %total_smem_size
\n\n\n
Total size of shared memory used by a CTA of a kernel.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %total_smem_size;\n
\n
\n
Description
\n
A predefined, read-only special register initialized with total size of shared memory allocated\n(statically and dynamically, excluding the shared memory reserved for the NVIDIA system software\nuse) for the CTA of a kernel at launch time.
\n
Size is returned in multiples of shared memory allocation unit size supported by target\narchitecture.
\n
Allocation unit values are as follows:
\n
\n
\n
\n
\n
\n\n
\n
Target architecture
\n
Shared memory allocation unit size
\n
\n\n\n
\n
sm_2x
\n
128 bytes
\n
\n
\n
sm_3x, sm_5x, sm_6x, sm_7x
\n
256 bytes
\n
\n
\n
sm_8x, sm_9x
\n
128 bytes
\n
\n\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 4.1.
\n
Target ISA Notes
\n
Requires sm_20 or higher.
\n
Examples
\n
\n
mov.u32 %r, %total_smem_size;\n
\n
\n",
- "tooltip": "Total size of shared memory used by a CTA of a kernel.\n\nSyntax (predefined)\n\n.sreg .u32 %total_smem_size;\n\nDescription\n\nA predefined, read-only special register initialized with total size of shared memory allocated\n\n(statically and dynamically, excluding the shared memory reserved for the NVIDIA system software\n\nuse) for the CTA of a kernel at launch time.\n\nSize is returned in multiples of shared memory allocation unit size supported by target\n\narchitecture.\n\nAllocation unit values are as follows:\n\n\n\nTarget architecture\n\nShared memory allocation unit size\n\n\n\nsm_2x\n\n128 bytes\n\nsm_3x, sm_5x, sm_6x, sm_7x\n\n256 bytes\n\nsm_8x, sm_9x\n\n128 bytes\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 4.1.\n\nTarget ISA Notes\n\nRequires sm_20 or higher.\n\nExamples\n\nmov.u32 %r, %total_smem_size;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-total-smem-size"
- };
-
case "trap":
return {
- "html": "For more information, visit trap .
Miscellaneous Instructions: trap
\n\n\n
Perform trap operation.
\n
Syntax
\n
\n
trap;\n
\n
\n
Description
\n
Abort execution and generate an interrupt to the host CPU.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
trap;\n@p trap;\n
\n
\n",
- "tooltip": "Perform trap operation.\n\nSyntax\n\ntrap;\n\nDescription\n\nAbort execution and generate an interrupt to the host CPU.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n trap;\n\n@p trap;\n\n ...",
+ "html": "
Abort execution and generate an interrupt to the host CPU.
\nFor more information, visit trap .",
+ "tooltip": "Perform trap operation.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#miscellaneous-instructions-trap"
};
case "txq":
return {
- "html": "For more information, visit txq .
Query an attribute of a texture or sampler. Operand a is either a .texref or .samplerref variable, or a .u64 register.
\n
\n
\n
\n
\n
\n\n
\n
Query
\n
Returns
\n
\n\n\n
\n
\n
.width
\n
.height
\n
.depth
\n
\n
value in elements
\n
\n
\n
.channel_data_type
\n
Unsigned integer corresponding to source language\u2019s channel data type\nenumeration. If the source language combines channel data type and channel\norder into a single enumeration type, that value is returned for both\nchannel_data_type and channel_order queries.
\n
\n
\n
.channel_order
\n
Unsigned integer corresponding to source language\u2019s channel order\nenumeration. If the source language combines channel data type and channel\norder into a single enumeration type, that value is returned for both\nchannel_data_type and channel_order queries.
\n
\n
\n
.normalized_coords
\n
1 (True) or 0 (False).
\n
\n
\n
.force_unnormalized_coords
\n
1 (True) or 0 (False). Defined only for .samplerref\nvariables in independent texture mode. Overrides the normalized_coords\nfield of a .texref variable used with a .samplerref in a tex\ninstruction.
For a texture array, number of textures in array, 0 otherwise.
\n
\n
\n
.num_mipmap_levels
\n
For a mipmapped texture, number of levels of details (LOD), 0 otherwise.
\n
\n
\n
.num_samples
\n
For a multi-sample texture, number of samples, 0 otherwise.
\n
\n\n
\n
Texture attributes are queried by supplying a .texref argument to txq. In unified mode,\nsampler attributes are also accessed via a .texref argument, and in independent mode sampler\nattributes are accessed via a separate .samplerref argument.
\n
txq.level
\n
txq.level requires an additional 32bit integer argument, lod, which specifies LOD and\nqueries requested attribute for the specified LOD.
\n
Indirect texture access
\n
Beginning with PTX ISA version 3.1, indirect texture access is supported in unified mode for target\narchitecture sm_20 or higher. In indirect access, operand a is a .u64 register holding\nthe address of a .texref variable.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.5.
\n
Channel data type and channel order queries were added in PTX ISA version 2.1.
\n
The .force_unnormalized_coords query was added in PTX ISA version 2.2.
\n
Indirect texture access introduced in PTX ISA version 3.1.
\n
.array_size, .num_mipmap_levels, .num_samples samples queries were added in PTX ISA\nversion 4.1.
\n
txq.level introduced in PTX ISA version 4.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Indirect texture access requires sm_20 or higher.
\n
Querying the number of mipmap levels requires sm_20 or higher.
\n
Querying the number of samples requires sm_30 or higher.
\n",
- "tooltip": "Query texture and sampler attributes.\n\nSyntax\n\ntxq.tquery.b32 d, [a]; // texture attributes\n\ntxq.level.tlquery.b32 d, [a], lod; // texture attributes\n\ntxq.squery.b32 d, [a]; // sampler attributes\n\n.tquery = { .width, .height, .depth,\n\n .channel_data_type, .channel_order,\n\n .normalized_coords, .array_size,\n\n .num_mipmap_levels, .num_samples};\n\n.tlquery = { .width, .height, .depth };\n\n.squery = { .force_unnormalized_coords, .filter_mode,\n\n .addr_mode_0, addr_mode_1, addr_mode_2 };\n\nDescription\n\nQuery an attribute of a texture or sampler. Operand a is either a .texref or .samplerref variable, or a .u64 register.\n\n\n\nQuery\n\nReturns\n\n\n\n.width\n\n.height\n\n.depth\n\nvalue in elements\n\n.channel_data_type\n\nUnsigned integer corresponding to source language\u2019s channel data type\n\nenumeration. If the source language combines channel data type and channel\n\norder into a single enumeration type, that value is returned for both\n\nchannel_data_type and channel_order queries.\n\n.channel_order\n\nUnsigned integer corresponding to source language\u2019s channel order\n\nenumeration. If the source language combines channel data type and channel\n\norder into a single enumeration type, that value is returned for both\n\nchannel_data_type and channel_order queries.\n\n.normalized_coords\n\n1 (True) or 0 (False).\n\n.force_unnormalized_coords\n\n1 (True) or 0 (False). Defined only for .samplerref\n\nvariables in independent texture mode. Overrides the normalized_coords\n\nfield of a .texref variable used with a .samplerref in a tex\n\ninstruction.\n\n.filter_mode\n\nInteger from enum { nearest, linear }\n\n.addr_mode_0\n\n.addr_mode_1\n\n.addr_mode_2\n\nInteger from\n\nenum { wrap, mirror, clamp_ogl, clamp_to_edge, clamp_to_border }\n\n.array_size\n\nFor a texture array, number of textures in array, 0 otherwise.\n\n.num_mipmap_levels\n\nFor a mipmapped texture, number of levels of details (LOD), 0 otherwise.\n\n.num_samples\n\nFor a multi-sample texture, number of samples, 0 otherwise.\n\nTexture attributes are queried by supplying a .texref argument to txq. In unified mode,\n\nsampler attributes are also accessed via a .texref argument, and in independent mode sampler\n\nattributes are accessed via a separate .samplerref argument.\n\ntxq.level\n\ntxq.level requires an additional 32bit integer argument, lod, which specifies LOD and\n\nqueries requested attribute for the specified LOD.\n\nIndirect texture access\n\nBeginning with PTX ISA version 3.1, indirect texture access is supported in unified mode for target\n\narchitecture sm_20 or higher. In indirect access, operand a is a .u64 register holding\n\nthe address of a .texref variable.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.5.\n\nChannel data type and channel order queries were added in PTX ISA version 2.1.\n\nThe .force_unnormalized_coords query was added in PTX ISA version 2.2.\n\nIndirect texture access introduced in PTX ISA version 3.1.\n\n.array_size, .num_mipmap_levels, .num_samples samples queries were added in PTX ISA\n\nversion 4.1.\n\ntxq.level introduced in PTX ISA version 4.3.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nIndirect texture access requires sm_20 or higher.\n\nQuerying the number of mipmap levels requires sm_20 or higher.\n\nQuerying the number of samples requires sm_30 or higher.\n\ntxq.level requires sm_30 or higher.\n\nExamples\n\ntxq.width.b32 %r1, [tex_A];\n\ntxq.filter_mode.b32 %r1, [tex_A]; // unified mode\n\ntxq.addr_mode_0.b32 %r1, [smpl_B]; // independent mode\n\ntxq.level.width.b32 %r1, [tex_A], %r_lod;\n\n ...",
+ "html": "
Query an attribute of a texture or sampler. Operand a is either a .texref or .samplerref variable, or a .u64 register.
\nFor more information, visit txq .",
+ "tooltip": "Query texture and sampler attributes.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#texture-instructions-txq"
};
- case "vabsdiff":
- return {
- "html": "For more information, visit vabsdiff .
Scalar Video Instructions: vadd, vsub, vabsdiff, vmin, vmax
\n\n\n
Integer byte/half-word/word addition/subtraction.
\n
vabsdiff
\n
Integer byte/half-word/word absolute value of difference.
Perform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a, atype, asel );\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n case vadd: tmp = ta + tb;\n case vsub: tmp = ta - tb;\n case vabsdiff: tmp = | ta - tb |;\n case vmin: tmp = MIN( ta, tb );\n case vmax: tmp = MAX( ta, tb );\n}\n// saturate, taking into account destination type and merge operations\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
vadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.
\n",
- "tooltip": "Integer byte/half-word/word addition/subtraction.\n\nvabsdiff\n\nInteger byte/half-word/word absolute value of difference.\n\nvmin, vmax\n\nInteger byte/half-word/word minimum/maximum.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvop.dtype.atype.btype{.sat} d, a{.asel}, b{.bsel};\n\nvop.dtype.atype.btype{.sat}.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvop.dtype.atype.btype{.sat} d.dsel, a{.asel}, b{.bsel}, c;\n\n vop = { vadd, vsub, vabsdiff, vmin, vmax };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nPerform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a, atype, asel );\n\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n\n case vadd: tmp = ta + tb;\n\n case vsub: tmp = ta - tb;\n\n case vabsdiff: tmp = | ta - tb |;\n\n case vmin: tmp = MIN( ta, tb );\n\n case vmax: tmp = MAX( ta, tb );\n\n}\n\n// saturate, taking into account destination type and merge operations\n\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.\n\nExamples\n\nvadd.s32.u32.s32.sat r1, r2.b0, r3.h0;\n\nvsub.s32.s32.u32.sat r1, r2.h1, r3.h1;\n\nvabsdiff.s32.s32.s32.sat r1.h0, r2.b0, r3.b2, c;\n\nvmin.s32.s32.s32.sat.add r1, r2, r3, c;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vadd-vsub-vabsdiff-vmin-vmax"
- };
-
- case "vabsdiff2":
- return {
- "html": "For more information, visit vabsdiff2 .
SIMD Video Instructions: vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2
\n\n\n
Integer dual half-word SIMD addition/subtraction.
\n
vavrg2
\n
Integer dual half-word SIMD average.
\n
vabsdiff2
\n
Integer dual half-word SIMD absolute value of difference.
\n
vmin2, vmax2
\n
Integer dual half-word SIMD minimum/maximum.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n.dtype = .atype = .btype = { .u32, .s32 };\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n .asel defaults to .h10\n .bsel defaults to .h32\n
\n
\n
Description
\n
Two-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each dual half-word source to the operation are selected from any of the four half-words\nin the two source operands a and b using the asel and bsel modifiers.
\n
The selected half-words are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are copied into\ndestination d. For all other positions, the corresponding half-word from source operand c\nis copied to d.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are added to operand\nc, producing a result in d.
\n
\n
Semantics
\n
\n
// extract pairs of half-words and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_2( a, b, .asel, .atype );\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n switch ( vop2 ) {\n case vadd2: t[i] = Va[i] + Vb[i];\n case vsub2: t[i] = Va[i] - Vb[i];\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.
\n",
- "tooltip": "Integer dual half-word SIMD addition/subtraction.\n\nvavrg2\n\nInteger dual half-word SIMD average.\n\nvabsdiff2\n\nInteger dual half-word SIMD absolute value of difference.\n\nvmin2, vmax2\n\nInteger dual half-word SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n\n .asel defaults to .h10\n\n .bsel defaults to .h32\n\nDescription\n\nTwo-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each dual half-word source to the operation are selected from any of the four half-words\n\nin the two source operands a and b using the asel and bsel modifiers.\n\nThe selected half-words are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor half-word positions indicated in mask, the selected half-word results are copied into\n\ndestination d. For all other positions, the corresponding half-word from source operand c\n\nis copied to d.\n\nFor instructions with a secondary accumulate operation:\n\nFor half-word positions indicated in mask, the selected half-word results are added to operand\n\nc, producing a result in d.\n\nSemantics\n\n// extract pairs of half-words and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_2( a, b, .asel, .atype );\n\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n\n switch ( vop2 ) {\n\n case vadd2: t[i] = Va[i] + Vb[i];\n\n case vsub2: t[i] = Va[i] - Vb[i];\n\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.\n\nExamples\n\nvadd2.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub2.s32.s32.s32.sat r1.h0, r2.h10, r3.h32, r1;\n\nvmin2.s32.u32.u32.add r1.h10, r2.h00, r3.h22, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd2-vsub2-vavrg2-vabsdiff2-vmin2-vmax2"
- };
-
- case "vabsdiff4":
- return {
- "html": "For more information, visit vabsdiff4 .
SIMD Video Instructions: vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4
\n\n\n
Integer quad byte SIMD addition/subtraction.
\n
vavrg4
\n
Integer quad byte SIMD average.
\n
vabsdiff4
\n
Integer quad byte SIMD absolute value of difference.
Four-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each quad byte source to the operation are selected from any of the eight bytes in the\ntwo source operands a and b using the asel and bsel modifiers.
\n
The selected bytes are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For byte positions indicated in mask, the selected byte results are copied into destination\nd. For all other positions, the corresponding byte from source operand c is copied to\nd.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For byte positions indicated in mask, the selected byte results are added to operand c,\nproducing a result in d.
\n
\n
Semantics
\n
\n
// extract quads of bytes and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_4( a, b, .asel, .atype );\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\nVc = extractAndSignExt_4( c );\nfor (i=0; i<4; i++) {\n switch ( vop4 ) {\n case vadd4: t[i] = Va[i] + Vb[i];\n case vsub4: t[i] = Va[i] - Vb[i];\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.
\n",
- "tooltip": "Integer quad byte SIMD addition/subtraction.\n\nvavrg4\n\nInteger quad byte SIMD average.\n\nvabsdiff4\n\nInteger quad byte SIMD absolute value of difference.\n\nvmin4, vmax4\n\nInteger quad byte SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop4.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop4.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\nvop4 = { vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .b0,\n\n .b1, .b10\n\n .b2, .b20, .b21, .b210,\n\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n\n defaults to .b3210\n\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n\n .asel defaults to .b3210\n\n .bsel defaults to .b7654\n\nDescription\n\nFour-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each quad byte source to the operation are selected from any of the eight bytes in the\n\ntwo source operands a and b using the asel and bsel modifiers.\n\nThe selected bytes are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor byte positions indicated in mask, the selected byte results are copied into destination\n\nd. For all other positions, the corresponding byte from source operand c is copied to\n\nd.\n\nFor instructions with a secondary accumulate operation:\n\nFor byte positions indicated in mask, the selected byte results are added to operand c,\n\nproducing a result in d.\n\nSemantics\n\n// extract quads of bytes and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_4( a, b, .asel, .atype );\n\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_4( c );\n\nfor (i=0; i<4; i++) {\n\n switch ( vop4 ) {\n\n case vadd4: t[i] = Va[i] + Vb[i];\n\n case vsub4: t[i] = Va[i] - Vb[i];\n\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.\n\nExamples\n\nvadd4.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub4.s32.s32.s32.sat r1.b0, r2.b3210, r3.b7654, r1;\n\nvmin4.s32.u32.u32.add r1.b00, r2.b0000, r3.b2222, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd4-vsub4-vavrg4-vabsdiff4-vmin4-vmax4"
- };
-
case "vadd":
return {
- "html": "For more information, visit vadd .
Scalar Video Instructions: vadd, vsub, vabsdiff, vmin, vmax
\n\n\n
Integer byte/half-word/word addition/subtraction.
\n
vabsdiff
\n
Integer byte/half-word/word absolute value of difference.
Perform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a, atype, asel );\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n case vadd: tmp = ta + tb;\n case vsub: tmp = ta - tb;\n case vabsdiff: tmp = | ta - tb |;\n case vmin: tmp = MIN( ta, tb );\n case vmax: tmp = MAX( ta, tb );\n}\n// saturate, taking into account destination type and merge operations\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
vadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.
\n",
- "tooltip": "Integer byte/half-word/word addition/subtraction.\n\nvabsdiff\n\nInteger byte/half-word/word absolute value of difference.\n\nvmin, vmax\n\nInteger byte/half-word/word minimum/maximum.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvop.dtype.atype.btype{.sat} d, a{.asel}, b{.bsel};\n\nvop.dtype.atype.btype{.sat}.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvop.dtype.atype.btype{.sat} d.dsel, a{.asel}, b{.bsel}, c;\n\n vop = { vadd, vsub, vabsdiff, vmin, vmax };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nPerform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a, atype, asel );\n\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n\n case vadd: tmp = ta + tb;\n\n case vsub: tmp = ta - tb;\n\n case vabsdiff: tmp = | ta - tb |;\n\n case vmin: tmp = MIN( ta, tb );\n\n case vmax: tmp = MAX( ta, tb );\n\n}\n\n// saturate, taking into account destination type and merge operations\n\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.\n\nExamples\n\nvadd.s32.u32.s32.sat r1, r2.b0, r3.h0;\n\nvsub.s32.s32.u32.sat r1, r2.h1, r3.h1;\n\nvabsdiff.s32.s32.s32.sat r1.h0, r2.b0, r3.b2, c;\n\nvmin.s32.s32.s32.sat.add r1, r2, r3, c;\n\n ...",
+ "html": "
Perform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.
\nFor more information, visit vadd .",
+ "tooltip": "Integer byte/half-word/word addition/subtraction.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vadd-vsub-vabsdiff-vmin-vmax"
};
case "vadd2":
return {
- "html": "For more information, visit vadd2 .
SIMD Video Instructions: vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2
\n\n\n
Integer dual half-word SIMD addition/subtraction.
\n
vavrg2
\n
Integer dual half-word SIMD average.
\n
vabsdiff2
\n
Integer dual half-word SIMD absolute value of difference.
\n
vmin2, vmax2
\n
Integer dual half-word SIMD minimum/maximum.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n.dtype = .atype = .btype = { .u32, .s32 };\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n .asel defaults to .h10\n .bsel defaults to .h32\n
\n
\n
Description
\n
Two-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each dual half-word source to the operation are selected from any of the four half-words\nin the two source operands a and b using the asel and bsel modifiers.
\n
The selected half-words are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are copied into\ndestination d. For all other positions, the corresponding half-word from source operand c\nis copied to d.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are added to operand\nc, producing a result in d.
\n
\n
Semantics
\n
\n
// extract pairs of half-words and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_2( a, b, .asel, .atype );\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n switch ( vop2 ) {\n case vadd2: t[i] = Va[i] + Vb[i];\n case vsub2: t[i] = Va[i] - Vb[i];\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.
\n",
- "tooltip": "Integer dual half-word SIMD addition/subtraction.\n\nvavrg2\n\nInteger dual half-word SIMD average.\n\nvabsdiff2\n\nInteger dual half-word SIMD absolute value of difference.\n\nvmin2, vmax2\n\nInteger dual half-word SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n\n .asel defaults to .h10\n\n .bsel defaults to .h32\n\nDescription\n\nTwo-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each dual half-word source to the operation are selected from any of the four half-words\n\nin the two source operands a and b using the asel and bsel modifiers.\n\nThe selected half-words are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor half-word positions indicated in mask, the selected half-word results are copied into\n\ndestination d. For all other positions, the corresponding half-word from source operand c\n\nis copied to d.\n\nFor instructions with a secondary accumulate operation:\n\nFor half-word positions indicated in mask, the selected half-word results are added to operand\n\nc, producing a result in d.\n\nSemantics\n\n// extract pairs of half-words and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_2( a, b, .asel, .atype );\n\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n\n switch ( vop2 ) {\n\n case vadd2: t[i] = Va[i] + Vb[i];\n\n case vsub2: t[i] = Va[i] - Vb[i];\n\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.\n\nExamples\n\nvadd2.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub2.s32.s32.s32.sat r1.h0, r2.h10, r3.h32, r1;\n\nvmin2.s32.u32.u32.add r1.h10, r2.h00, r3.h22, r1;\n\n ...",
+ "html": "
Two-way SIMD parallel arithmetic operation with secondary operation.
\nFor more information, visit vadd2 .",
+ "tooltip": "Integer dual half-word SIMD addition/subtraction.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd2-vsub2-vavrg2-vabsdiff2-vmin2-vmax2"
};
case "vadd4":
return {
- "html": "For more information, visit vadd4 .
SIMD Video Instructions: vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4
\n\n\n
Integer quad byte SIMD addition/subtraction.
\n
vavrg4
\n
Integer quad byte SIMD average.
\n
vabsdiff4
\n
Integer quad byte SIMD absolute value of difference.
Four-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each quad byte source to the operation are selected from any of the eight bytes in the\ntwo source operands a and b using the asel and bsel modifiers.
\n
The selected bytes are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For byte positions indicated in mask, the selected byte results are copied into destination\nd. For all other positions, the corresponding byte from source operand c is copied to\nd.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For byte positions indicated in mask, the selected byte results are added to operand c,\nproducing a result in d.
\n
\n
Semantics
\n
\n
// extract quads of bytes and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_4( a, b, .asel, .atype );\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\nVc = extractAndSignExt_4( c );\nfor (i=0; i<4; i++) {\n switch ( vop4 ) {\n case vadd4: t[i] = Va[i] + Vb[i];\n case vsub4: t[i] = Va[i] - Vb[i];\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.
\n",
- "tooltip": "Integer quad byte SIMD addition/subtraction.\n\nvavrg4\n\nInteger quad byte SIMD average.\n\nvabsdiff4\n\nInteger quad byte SIMD absolute value of difference.\n\nvmin4, vmax4\n\nInteger quad byte SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop4.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop4.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\nvop4 = { vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .b0,\n\n .b1, .b10\n\n .b2, .b20, .b21, .b210,\n\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n\n defaults to .b3210\n\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n\n .asel defaults to .b3210\n\n .bsel defaults to .b7654\n\nDescription\n\nFour-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each quad byte source to the operation are selected from any of the eight bytes in the\n\ntwo source operands a and b using the asel and bsel modifiers.\n\nThe selected bytes are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor byte positions indicated in mask, the selected byte results are copied into destination\n\nd. For all other positions, the corresponding byte from source operand c is copied to\n\nd.\n\nFor instructions with a secondary accumulate operation:\n\nFor byte positions indicated in mask, the selected byte results are added to operand c,\n\nproducing a result in d.\n\nSemantics\n\n// extract quads of bytes and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_4( a, b, .asel, .atype );\n\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_4( c );\n\nfor (i=0; i<4; i++) {\n\n switch ( vop4 ) {\n\n case vadd4: t[i] = Va[i] + Vb[i];\n\n case vsub4: t[i] = Va[i] - Vb[i];\n\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.\n\nExamples\n\nvadd4.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub4.s32.s32.s32.sat r1.b0, r2.b3210, r3.b7654, r1;\n\nvmin4.s32.u32.u32.add r1.b00, r2.b0000, r3.b2222, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd4-vsub4-vavrg4-vabsdiff4-vmin4-vmax4"
- };
-
- case "vavrg2":
- return {
- "html": "For more information, visit vavrg2 .
SIMD Video Instructions: vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2
\n\n\n
Integer dual half-word SIMD addition/subtraction.
\n
vavrg2
\n
Integer dual half-word SIMD average.
\n
vabsdiff2
\n
Integer dual half-word SIMD absolute value of difference.
\n
vmin2, vmax2
\n
Integer dual half-word SIMD minimum/maximum.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n.dtype = .atype = .btype = { .u32, .s32 };\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n .asel defaults to .h10\n .bsel defaults to .h32\n
\n
\n
Description
\n
Two-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each dual half-word source to the operation are selected from any of the four half-words\nin the two source operands a and b using the asel and bsel modifiers.
\n
The selected half-words are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are copied into\ndestination d. For all other positions, the corresponding half-word from source operand c\nis copied to d.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are added to operand\nc, producing a result in d.
\n
\n
Semantics
\n
\n
// extract pairs of half-words and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_2( a, b, .asel, .atype );\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n switch ( vop2 ) {\n case vadd2: t[i] = Va[i] + Vb[i];\n case vsub2: t[i] = Va[i] - Vb[i];\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.
\n",
- "tooltip": "Integer dual half-word SIMD addition/subtraction.\n\nvavrg2\n\nInteger dual half-word SIMD average.\n\nvabsdiff2\n\nInteger dual half-word SIMD absolute value of difference.\n\nvmin2, vmax2\n\nInteger dual half-word SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n\n .asel defaults to .h10\n\n .bsel defaults to .h32\n\nDescription\n\nTwo-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each dual half-word source to the operation are selected from any of the four half-words\n\nin the two source operands a and b using the asel and bsel modifiers.\n\nThe selected half-words are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor half-word positions indicated in mask, the selected half-word results are copied into\n\ndestination d. For all other positions, the corresponding half-word from source operand c\n\nis copied to d.\n\nFor instructions with a secondary accumulate operation:\n\nFor half-word positions indicated in mask, the selected half-word results are added to operand\n\nc, producing a result in d.\n\nSemantics\n\n// extract pairs of half-words and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_2( a, b, .asel, .atype );\n\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n\n switch ( vop2 ) {\n\n case vadd2: t[i] = Va[i] + Vb[i];\n\n case vsub2: t[i] = Va[i] - Vb[i];\n\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.\n\nExamples\n\nvadd2.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub2.s32.s32.s32.sat r1.h0, r2.h10, r3.h32, r1;\n\nvmin2.s32.u32.u32.add r1.h10, r2.h00, r3.h22, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd2-vsub2-vavrg2-vabsdiff2-vmin2-vmax2"
- };
-
- case "vavrg4":
- return {
- "html": "For more information, visit vavrg4 .
SIMD Video Instructions: vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4
\n\n\n
Integer quad byte SIMD addition/subtraction.
\n
vavrg4
\n
Integer quad byte SIMD average.
\n
vabsdiff4
\n
Integer quad byte SIMD absolute value of difference.
Four-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each quad byte source to the operation are selected from any of the eight bytes in the\ntwo source operands a and b using the asel and bsel modifiers.
\n
The selected bytes are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For byte positions indicated in mask, the selected byte results are copied into destination\nd. For all other positions, the corresponding byte from source operand c is copied to\nd.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For byte positions indicated in mask, the selected byte results are added to operand c,\nproducing a result in d.
\n
\n
Semantics
\n
\n
// extract quads of bytes and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_4( a, b, .asel, .atype );\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\nVc = extractAndSignExt_4( c );\nfor (i=0; i<4; i++) {\n switch ( vop4 ) {\n case vadd4: t[i] = Va[i] + Vb[i];\n case vsub4: t[i] = Va[i] - Vb[i];\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.
\n",
- "tooltip": "Integer quad byte SIMD addition/subtraction.\n\nvavrg4\n\nInteger quad byte SIMD average.\n\nvabsdiff4\n\nInteger quad byte SIMD absolute value of difference.\n\nvmin4, vmax4\n\nInteger quad byte SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop4.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop4.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\nvop4 = { vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .b0,\n\n .b1, .b10\n\n .b2, .b20, .b21, .b210,\n\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n\n defaults to .b3210\n\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n\n .asel defaults to .b3210\n\n .bsel defaults to .b7654\n\nDescription\n\nFour-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each quad byte source to the operation are selected from any of the eight bytes in the\n\ntwo source operands a and b using the asel and bsel modifiers.\n\nThe selected bytes are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor byte positions indicated in mask, the selected byte results are copied into destination\n\nd. For all other positions, the corresponding byte from source operand c is copied to\n\nd.\n\nFor instructions with a secondary accumulate operation:\n\nFor byte positions indicated in mask, the selected byte results are added to operand c,\n\nproducing a result in d.\n\nSemantics\n\n// extract quads of bytes and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_4( a, b, .asel, .atype );\n\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_4( c );\n\nfor (i=0; i<4; i++) {\n\n switch ( vop4 ) {\n\n case vadd4: t[i] = Va[i] + Vb[i];\n\n case vsub4: t[i] = Va[i] - Vb[i];\n\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.\n\nExamples\n\nvadd4.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub4.s32.s32.s32.sat r1.b0, r2.b3210, r3.b7654, r1;\n\nvmin4.s32.u32.u32.add r1.b00, r2.b0000, r3.b2222, r1;\n\n ...",
+ "html": "
Four-way SIMD parallel arithmetic operation with secondary operation.
\nFor more information, visit vadd4 .",
+ "tooltip": "Integer quad byte SIMD addition/subtraction.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd4-vsub4-vavrg4-vabsdiff4-vmin4-vmax4"
};
- case "version":
- return {
- "html": "For more information, visit version .
PTX Module Directives: .version
\n\n\n
PTX ISA version number.
\n
Syntax
\n
\n
.version major.minor // major, minor are integers\n
\n
\n
Description
\n
Specifies the PTX language version number.
\n
The major number is incremented when there are incompatible changes to the PTX language, such as\nchanges to the syntax or semantics. The version major number is used by the PTX compiler to ensure\ncorrect execution of legacy PTX code.
\n
The minor number is incremented when new features are added to PTX.
\n
Semantics
\n
Indicates that this module must be compiled with tools that support an equal or greater version\nnumber.
\n
Each PTX module must begin with a .version directive, and no other .version directive is\nallowed anywhere else within the module.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.version 3.1\n.version 3.0\n.version 2.3\n
\n
\n",
- "tooltip": "PTX ISA version number.\n\nSyntax\n\n.version major.minor // major, minor are integers\n\nDescription\n\nSpecifies the PTX language version number.\n\nThe major number is incremented when there are incompatible changes to the PTX language, such as\n\nchanges to the syntax or semantics. The version major number is used by the PTX compiler to ensure\n\ncorrect execution of legacy PTX code.\n\nThe minor number is incremented when new features are added to PTX.\n\nSemantics\n\nIndicates that this module must be compiled with tools that support an equal or greater version\n\nnumber.\n\nEach PTX module must begin with a .version directive, and no other .version directive is\n\nallowed anywhere else within the module.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.version 3.1\n\n.version 3.0\n\n.version 2.3\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#ptx-module-directives-version"
- };
-
- case "visible":
- return {
- "html": "For more information, visit visible .
Linking Directives: .visible
\n\n\n
Visible (externally) symbol declaration.
\n
Syntax
\n
\n
.visible identifier\n
\n
\n
Description
\n
Declares identifier to be globally visible. Unlike C, where identifiers are globally visible unless\ndeclared static, PTX identifiers are visible only within the current module unless declared\n.visible outside the current.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.visible .global .b32 foo; // foo will be externally visible\n
\n
\n",
- "tooltip": "Visible (externally) symbol declaration.\n\nSyntax\n\n.visible identifier\n\nDescription\n\nDeclares identifier to be globally visible. Unlike C, where identifiers are globally visible unless\n\ndeclared static, PTX identifiers are visible only within the current module unless declared\n\n.visible outside the current.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.visible .global .b32 foo; // foo will be externally visible\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#linking-directives-visible"
- };
-
case "vmad":
return {
- "html": "For more information, visit vmad .
Calculate (a*b)+c, with optional operand negates, plus one mode, and scaling.
\n
The source operands support optional negation with some restrictions. Although PTX syntax allows\nseparate negation of the a and b operands, internally this is represented as negation of the\nproduct (a*b). That is, (a*b) is negated if and only if exactly one of a or b is\nnegated. PTX allows negation of either (a*b) or c.
\n
The plus one mode (.po) computes (a*b)+c+1, which is used in computing averages. Source\noperands may not be negated in .po mode.
\n
The intermediate result of (a*b) is unsigned if atype and btype are unsigned and the product\n(a*b) is not negated; otherwise, the intermediate result is signed. Input c has the same\nsign as the intermediate result.
\n
The final result is unsigned if the intermediate result is unsigned and c is not negated.
\n
Depending on the sign of the a and b operands, and the operand negates, the following\ncombinations of operands are supported for VMAD:
\n
\n
(u32 * u32) + u32 // intermediate unsigned; final unsigned\n-(u32 * u32) + s32 // intermediate signed; final signed\n (u32 * u32) - u32 // intermediate unsigned; final signed\n (u32 * s32) + s32 // intermediate signed; final signed\n-(u32 * s32) + s32 // intermediate signed; final signed\n (u32 * s32) - s32 // intermediate signed; final signed\n (s32 * u32) + s32 // intermediate signed; final signed\n-(s32 * u32) + s32 // intermediate signed; final signed\n (s32 * u32) - s32 // intermediate signed; final signed\n (s32 * s32) + s32 // intermediate signed; final signed\n-(s32 * s32) + s32 // intermediate signed; final signed\n (s32 * s32) - s32 // intermediate signed; final signed\n
\n
\n
The intermediate result is optionally scaled via right-shift; this result is sign-extended if the\nfinal result is signed, and zero-extended otherwise.
\n
The final result is optionally saturated to the appropriate 32-bit range based on the type (signed\nor unsigned) of the final result.
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a, atype, asel );\ntb = partSelectSignExtend( b, btype, bsel );\nsignedFinal = isSigned(atype) || isSigned(btype) ||\n (a.negate ^ b.negate) || c.negate;\ntmp[127:0] = ta * tb;\n\nlsb = 0;\nif ( .po ) { lsb = 1; } else\nif ( a.negate ^ b.negate ) { tmp = ~tmp; lsb = 1; } else\nif ( c.negate ) { c = ~c; lsb = 1; }\n\nc128[127:0] = (signedFinal) sext32( c ) : zext ( c );\ntmp = tmp + c128 + lsb;\nswitch( scale ) {\n case .shr7: result = (tmp >> 7) & 0xffffffffffffffff;\n case .shr15: result = (tmp >> 15) & 0xffffffffffffffff;\n}\nif ( .sat ) {\n if (signedFinal) result = CLAMP(result, S32_MAX, S32_MIN);\n else result = CLAMP(result, U32_MAX, U32_MIN);\n}\n
\n",
- "tooltip": "Integer byte/half-word/word multiply-accumulate.\n\nSyntax\n\n// 32-bit scalar operation\n\nvmad.dtype.atype.btype{.sat}{.scale} d, {-}a{.asel}, {-}b{.bsel},\n\n {-}c;\n\nvmad.dtype.atype.btype.po{.sat}{.scale} d, a{.asel}, b{.bsel}, c;\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.scale = { .shr7, .shr15 };\n\nDescription\n\nCalculate (a*b) + c, with optional operand negates, plus one mode, and scaling.\n\nThe source operands support optional negation with some restrictions. Although PTX syntax allows\n\nseparate negation of the a and b operands, internally this is represented as negation of the\n\nproduct (a*b). That is, (a*b) is negated if and only if exactly one of a or b is\n\nnegated. PTX allows negation of either (a*b) or c.\n\nThe plus one mode (.po) computes (a*b) + c + 1, which is used in computing averages. Source\n\noperands may not be negated in .po mode.\n\nThe intermediate result of (a*b) is unsigned if atype and btype are unsigned and the product\n\n(a*b) is not negated; otherwise, the intermediate result is signed. Input c has the same\n\nsign as the intermediate result.\n\nThe final result is unsigned if the intermediate result is unsigned and c is not negated.\n\nDepending on the sign of the a and b operands, and the operand negates, the following\n\ncombinations of operands are supported for VMAD:\n\n (u32 * u32) + u32 // intermediate unsigned; final unsigned\n\n-(u32 * u32) + s32 // intermediate signed; final signed\n\n (u32 * u32) - u32 // intermediate unsigned; final signed\n\n (u32 * s32) + s32 // intermediate signed; final signed\n\n-(u32 * s32) + s32 // intermediate signed; final signed\n\n (u32 * s32) - s32 // intermediate signed; final signed\n\n (s32 * u32) + s32 // intermediate signed; final signed\n\n-(s32 * u32) + s32 // intermediate signed; final signed\n\n (s32 * u32) - s32 // intermediate signed; final signed\n\n (s32 * s32) + s32 // intermediate signed; final signed\n\n-(s32 * s32) + s32 // intermediate signed; final signed\n\n (s32 * s32) - s32 // intermediate signed; final signed\n\nThe intermediate result is optionally scaled via right-shift; this result is sign-extended if the\n\nfinal result is signed, and zero-extended otherwise.\n\nThe final result is optionally saturated to the appropriate 32-bit range based on the type (signed\n\nor unsigned) of the final result.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a, atype, asel );\n\ntb = partSelectSignExtend( b, btype, bsel );\n\nsignedFinal = isSigned(atype) || isSigned(btype) ||\n\n (a.negate ^ b.negate) || c.negate;\n\ntmp[127:0] = ta * tb;\n\nlsb = 0;\n\nif ( .po ) { lsb = 1; } else\n\nif ( a.negate ^ b.negate ) { tmp = ~tmp; lsb = 1; } else\n\nif ( c.negate ) { c = ~c; lsb = 1; }\n\nc128[127:0] = (signedFinal) sext32( c ) : zext ( c );\n\ntmp = tmp + c128 + lsb;\n\nswitch( scale ) {\n\n case .shr7: result = (tmp >> 7) & 0xffffffffffffffff;\n\n case .shr15: result = (tmp >> 15) & 0xffffffffffffffff;\n\n}\n\nif ( .sat ) {\n\n if (signedFinal) result = CLAMP(result, S32_MAX, S32_MIN);\n\n else result = CLAMP(result, U32_MAX, U32_MIN);\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvmad requires sm_20 or higher.\n\nExamples\n\nvmad.s32.s32.u32.sat r0, r1, r2, -r3;\n\nvmad.u32.u32.u32.shr15 r0, r1.h0, r2.h0, r3;\n\n ...",
+ "html": "
Calculate (a*b)+c, with optional operand negates, plus one mode, and scaling.
\nFor more information, visit vmad .",
+ "tooltip": "Integer byte/half-word/word multiply-accumulate.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vmad"
};
- case "vmax":
- return {
- "html": "For more information, visit vmax .
Scalar Video Instructions: vadd, vsub, vabsdiff, vmin, vmax
\n\n\n
Integer byte/half-word/word addition/subtraction.
\n
vabsdiff
\n
Integer byte/half-word/word absolute value of difference.
Perform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a, atype, asel );\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n case vadd: tmp = ta + tb;\n case vsub: tmp = ta - tb;\n case vabsdiff: tmp = | ta - tb |;\n case vmin: tmp = MIN( ta, tb );\n case vmax: tmp = MAX( ta, tb );\n}\n// saturate, taking into account destination type and merge operations\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
vadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.
\n",
- "tooltip": "Integer byte/half-word/word addition/subtraction.\n\nvabsdiff\n\nInteger byte/half-word/word absolute value of difference.\n\nvmin, vmax\n\nInteger byte/half-word/word minimum/maximum.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvop.dtype.atype.btype{.sat} d, a{.asel}, b{.bsel};\n\nvop.dtype.atype.btype{.sat}.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvop.dtype.atype.btype{.sat} d.dsel, a{.asel}, b{.bsel}, c;\n\n vop = { vadd, vsub, vabsdiff, vmin, vmax };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nPerform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a, atype, asel );\n\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n\n case vadd: tmp = ta + tb;\n\n case vsub: tmp = ta - tb;\n\n case vabsdiff: tmp = | ta - tb |;\n\n case vmin: tmp = MIN( ta, tb );\n\n case vmax: tmp = MAX( ta, tb );\n\n}\n\n// saturate, taking into account destination type and merge operations\n\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.\n\nExamples\n\nvadd.s32.u32.s32.sat r1, r2.b0, r3.h0;\n\nvsub.s32.s32.u32.sat r1, r2.h1, r3.h1;\n\nvabsdiff.s32.s32.s32.sat r1.h0, r2.b0, r3.b2, c;\n\nvmin.s32.s32.s32.sat.add r1, r2, r3, c;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vadd-vsub-vabsdiff-vmin-vmax"
- };
-
- case "vmax2":
- return {
- "html": "For more information, visit vmax2 .
SIMD Video Instructions: vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2
\n\n\n
Integer dual half-word SIMD addition/subtraction.
\n
vavrg2
\n
Integer dual half-word SIMD average.
\n
vabsdiff2
\n
Integer dual half-word SIMD absolute value of difference.
\n
vmin2, vmax2
\n
Integer dual half-word SIMD minimum/maximum.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n.dtype = .atype = .btype = { .u32, .s32 };\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n .asel defaults to .h10\n .bsel defaults to .h32\n
\n
\n
Description
\n
Two-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each dual half-word source to the operation are selected from any of the four half-words\nin the two source operands a and b using the asel and bsel modifiers.
\n
The selected half-words are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are copied into\ndestination d. For all other positions, the corresponding half-word from source operand c\nis copied to d.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are added to operand\nc, producing a result in d.
\n
\n
Semantics
\n
\n
// extract pairs of half-words and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_2( a, b, .asel, .atype );\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n switch ( vop2 ) {\n case vadd2: t[i] = Va[i] + Vb[i];\n case vsub2: t[i] = Va[i] - Vb[i];\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.
\n",
- "tooltip": "Integer dual half-word SIMD addition/subtraction.\n\nvavrg2\n\nInteger dual half-word SIMD average.\n\nvabsdiff2\n\nInteger dual half-word SIMD absolute value of difference.\n\nvmin2, vmax2\n\nInteger dual half-word SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n\n .asel defaults to .h10\n\n .bsel defaults to .h32\n\nDescription\n\nTwo-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each dual half-word source to the operation are selected from any of the four half-words\n\nin the two source operands a and b using the asel and bsel modifiers.\n\nThe selected half-words are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor half-word positions indicated in mask, the selected half-word results are copied into\n\ndestination d. For all other positions, the corresponding half-word from source operand c\n\nis copied to d.\n\nFor instructions with a secondary accumulate operation:\n\nFor half-word positions indicated in mask, the selected half-word results are added to operand\n\nc, producing a result in d.\n\nSemantics\n\n// extract pairs of half-words and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_2( a, b, .asel, .atype );\n\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n\n switch ( vop2 ) {\n\n case vadd2: t[i] = Va[i] + Vb[i];\n\n case vsub2: t[i] = Va[i] - Vb[i];\n\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.\n\nExamples\n\nvadd2.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub2.s32.s32.s32.sat r1.h0, r2.h10, r3.h32, r1;\n\nvmin2.s32.u32.u32.add r1.h10, r2.h00, r3.h22, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd2-vsub2-vavrg2-vabsdiff2-vmin2-vmax2"
- };
-
- case "vmax4":
- return {
- "html": "For more information, visit vmax4 .
SIMD Video Instructions: vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4
\n\n\n
Integer quad byte SIMD addition/subtraction.
\n
vavrg4
\n
Integer quad byte SIMD average.
\n
vabsdiff4
\n
Integer quad byte SIMD absolute value of difference.
Four-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each quad byte source to the operation are selected from any of the eight bytes in the\ntwo source operands a and b using the asel and bsel modifiers.
\n
The selected bytes are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For byte positions indicated in mask, the selected byte results are copied into destination\nd. For all other positions, the corresponding byte from source operand c is copied to\nd.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For byte positions indicated in mask, the selected byte results are added to operand c,\nproducing a result in d.
\n
\n
Semantics
\n
\n
// extract quads of bytes and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_4( a, b, .asel, .atype );\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\nVc = extractAndSignExt_4( c );\nfor (i=0; i<4; i++) {\n switch ( vop4 ) {\n case vadd4: t[i] = Va[i] + Vb[i];\n case vsub4: t[i] = Va[i] - Vb[i];\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.
\n",
- "tooltip": "Integer quad byte SIMD addition/subtraction.\n\nvavrg4\n\nInteger quad byte SIMD average.\n\nvabsdiff4\n\nInteger quad byte SIMD absolute value of difference.\n\nvmin4, vmax4\n\nInteger quad byte SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop4.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop4.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\nvop4 = { vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .b0,\n\n .b1, .b10\n\n .b2, .b20, .b21, .b210,\n\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n\n defaults to .b3210\n\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n\n .asel defaults to .b3210\n\n .bsel defaults to .b7654\n\nDescription\n\nFour-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each quad byte source to the operation are selected from any of the eight bytes in the\n\ntwo source operands a and b using the asel and bsel modifiers.\n\nThe selected bytes are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor byte positions indicated in mask, the selected byte results are copied into destination\n\nd. For all other positions, the corresponding byte from source operand c is copied to\n\nd.\n\nFor instructions with a secondary accumulate operation:\n\nFor byte positions indicated in mask, the selected byte results are added to operand c,\n\nproducing a result in d.\n\nSemantics\n\n// extract quads of bytes and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_4( a, b, .asel, .atype );\n\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_4( c );\n\nfor (i=0; i<4; i++) {\n\n switch ( vop4 ) {\n\n case vadd4: t[i] = Va[i] + Vb[i];\n\n case vsub4: t[i] = Va[i] - Vb[i];\n\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.\n\nExamples\n\nvadd4.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub4.s32.s32.s32.sat r1.b0, r2.b3210, r3.b7654, r1;\n\nvmin4.s32.u32.u32.add r1.b00, r2.b0000, r3.b2222, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd4-vsub4-vavrg4-vabsdiff4-vmin4-vmax4"
- };
-
- case "vmin":
- return {
- "html": "For more information, visit vmin .
Scalar Video Instructions: vadd, vsub, vabsdiff, vmin, vmax
\n\n\n
Integer byte/half-word/word addition/subtraction.
\n
vabsdiff
\n
Integer byte/half-word/word absolute value of difference.
Perform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a, atype, asel );\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n case vadd: tmp = ta + tb;\n case vsub: tmp = ta - tb;\n case vabsdiff: tmp = | ta - tb |;\n case vmin: tmp = MIN( ta, tb );\n case vmax: tmp = MAX( ta, tb );\n}\n// saturate, taking into account destination type and merge operations\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
vadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.
\n",
- "tooltip": "Integer byte/half-word/word addition/subtraction.\n\nvabsdiff\n\nInteger byte/half-word/word absolute value of difference.\n\nvmin, vmax\n\nInteger byte/half-word/word minimum/maximum.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvop.dtype.atype.btype{.sat} d, a{.asel}, b{.bsel};\n\nvop.dtype.atype.btype{.sat}.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvop.dtype.atype.btype{.sat} d.dsel, a{.asel}, b{.bsel}, c;\n\n vop = { vadd, vsub, vabsdiff, vmin, vmax };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nPerform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a, atype, asel );\n\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n\n case vadd: tmp = ta + tb;\n\n case vsub: tmp = ta - tb;\n\n case vabsdiff: tmp = | ta - tb |;\n\n case vmin: tmp = MIN( ta, tb );\n\n case vmax: tmp = MAX( ta, tb );\n\n}\n\n// saturate, taking into account destination type and merge operations\n\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.\n\nExamples\n\nvadd.s32.u32.s32.sat r1, r2.b0, r3.h0;\n\nvsub.s32.s32.u32.sat r1, r2.h1, r3.h1;\n\nvabsdiff.s32.s32.s32.sat r1.h0, r2.b0, r3.b2, c;\n\nvmin.s32.s32.s32.sat.add r1, r2, r3, c;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vadd-vsub-vabsdiff-vmin-vmax"
- };
-
- case "vmin2":
- return {
- "html": "For more information, visit vmin2 .
SIMD Video Instructions: vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2
\n\n\n
Integer dual half-word SIMD addition/subtraction.
\n
vavrg2
\n
Integer dual half-word SIMD average.
\n
vabsdiff2
\n
Integer dual half-word SIMD absolute value of difference.
\n
vmin2, vmax2
\n
Integer dual half-word SIMD minimum/maximum.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n.dtype = .atype = .btype = { .u32, .s32 };\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n .asel defaults to .h10\n .bsel defaults to .h32\n
\n
\n
Description
\n
Two-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each dual half-word source to the operation are selected from any of the four half-words\nin the two source operands a and b using the asel and bsel modifiers.
\n
The selected half-words are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are copied into\ndestination d. For all other positions, the corresponding half-word from source operand c\nis copied to d.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are added to operand\nc, producing a result in d.
\n
\n
Semantics
\n
\n
// extract pairs of half-words and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_2( a, b, .asel, .atype );\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n switch ( vop2 ) {\n case vadd2: t[i] = Va[i] + Vb[i];\n case vsub2: t[i] = Va[i] - Vb[i];\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.
\n",
- "tooltip": "Integer dual half-word SIMD addition/subtraction.\n\nvavrg2\n\nInteger dual half-word SIMD average.\n\nvabsdiff2\n\nInteger dual half-word SIMD absolute value of difference.\n\nvmin2, vmax2\n\nInteger dual half-word SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n\n .asel defaults to .h10\n\n .bsel defaults to .h32\n\nDescription\n\nTwo-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each dual half-word source to the operation are selected from any of the four half-words\n\nin the two source operands a and b using the asel and bsel modifiers.\n\nThe selected half-words are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor half-word positions indicated in mask, the selected half-word results are copied into\n\ndestination d. For all other positions, the corresponding half-word from source operand c\n\nis copied to d.\n\nFor instructions with a secondary accumulate operation:\n\nFor half-word positions indicated in mask, the selected half-word results are added to operand\n\nc, producing a result in d.\n\nSemantics\n\n// extract pairs of half-words and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_2( a, b, .asel, .atype );\n\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n\n switch ( vop2 ) {\n\n case vadd2: t[i] = Va[i] + Vb[i];\n\n case vsub2: t[i] = Va[i] - Vb[i];\n\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.\n\nExamples\n\nvadd2.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub2.s32.s32.s32.sat r1.h0, r2.h10, r3.h32, r1;\n\nvmin2.s32.u32.u32.add r1.h10, r2.h00, r3.h22, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd2-vsub2-vavrg2-vabsdiff2-vmin2-vmax2"
- };
-
- case "vmin4":
- return {
- "html": "For more information, visit vmin4 .
SIMD Video Instructions: vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4
\n\n\n
Integer quad byte SIMD addition/subtraction.
\n
vavrg4
\n
Integer quad byte SIMD average.
\n
vabsdiff4
\n
Integer quad byte SIMD absolute value of difference.
Four-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each quad byte source to the operation are selected from any of the eight bytes in the\ntwo source operands a and b using the asel and bsel modifiers.
\n
The selected bytes are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For byte positions indicated in mask, the selected byte results are copied into destination\nd. For all other positions, the corresponding byte from source operand c is copied to\nd.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For byte positions indicated in mask, the selected byte results are added to operand c,\nproducing a result in d.
\n
\n
Semantics
\n
\n
// extract quads of bytes and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_4( a, b, .asel, .atype );\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\nVc = extractAndSignExt_4( c );\nfor (i=0; i<4; i++) {\n switch ( vop4 ) {\n case vadd4: t[i] = Va[i] + Vb[i];\n case vsub4: t[i] = Va[i] - Vb[i];\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.
\n",
- "tooltip": "Integer quad byte SIMD addition/subtraction.\n\nvavrg4\n\nInteger quad byte SIMD average.\n\nvabsdiff4\n\nInteger quad byte SIMD absolute value of difference.\n\nvmin4, vmax4\n\nInteger quad byte SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop4.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop4.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\nvop4 = { vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .b0,\n\n .b1, .b10\n\n .b2, .b20, .b21, .b210,\n\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n\n defaults to .b3210\n\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n\n .asel defaults to .b3210\n\n .bsel defaults to .b7654\n\nDescription\n\nFour-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each quad byte source to the operation are selected from any of the eight bytes in the\n\ntwo source operands a and b using the asel and bsel modifiers.\n\nThe selected bytes are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor byte positions indicated in mask, the selected byte results are copied into destination\n\nd. For all other positions, the corresponding byte from source operand c is copied to\n\nd.\n\nFor instructions with a secondary accumulate operation:\n\nFor byte positions indicated in mask, the selected byte results are added to operand c,\n\nproducing a result in d.\n\nSemantics\n\n// extract quads of bytes and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_4( a, b, .asel, .atype );\n\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_4( c );\n\nfor (i=0; i<4; i++) {\n\n switch ( vop4 ) {\n\n case vadd4: t[i] = Va[i] + Vb[i];\n\n case vsub4: t[i] = Va[i] - Vb[i];\n\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.\n\nExamples\n\nvadd4.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub4.s32.s32.s32.sat r1.b0, r2.b3210, r3.b7654, r1;\n\nvmin4.s32.u32.u32.add r1.b00, r2.b0000, r3.b2222, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd4-vsub4-vavrg4-vabsdiff4-vmin4-vmax4"
- };
-
case "vote":
return {
- "html": "For more information, visit vote.sync .
Parallel Synchronization and Communication Instructions: vote.sync
vote.sync will cause executing thread to wait until all non-exited threads corresponding to\nmembermask have executed vote.sync with the same qualifiers and same membermask value\nbefore resuming execution.
\n
Operand membermask specifies a 32-bit integer which is a mask indicating threads participating\nin this instruction where the bit position corresponds to thread\u2019s laneid. Operand a is a\npredicate register.
\n
In the mode form, vote.sync performs a reduction of the source predicate across all non-exited\nthreads in membermask. The destination operand d is a predicate register and its value is\nthe same across all threads in membermask.
\n
The reduction modes are:
\n
\n
.all
\n
\n
True if source predicate is True for all non-exited threads in membermask. Negate the\nsource predicate to compute .none.
\n
\n
.any
\n
\n
True if source predicate is True for some thread in membermask. Negate the source\npredicate to compute .not_all.
\n
\n
.uni
\n
\n
True if source predicate has the same value in all non-exited threads in\nmembermask. Negating the source predicate also computes .uni.
\n
\n
\n
In the ballot form, the destination operand d is a .b32 register. In this form,\nvote.sync.ballot.b32 simply copies the predicate from each thread in membermask into the\ncorresponding bit position of destination register d, where the bit position corresponds to the\nthread\u2019s lane id.
\n
A thread not specified in membermask will contribute a 0 for its entry in\nvote.sync.ballot.b32.
\n
The behavior of vote.sync is undefined if the executing thread is not in the membermask.
\n
\n
Note
\n
For .target sm_6x or below, all threads in membermask must execute the same vote.sync\ninstruction in convergence, and only threads belonging to some membermask can be active when\nthe vote.sync instruction is executed. Otherwise, the behavior is undefined.
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 6.0.
\n
Target ISA Notes
\n
Requires sm_30 or higher.
\n
Examples
\n
\n
vote.sync.all.pred p,q,0xffffffff;\nvote.sync.ballot.b32 r1,p,0xffffffff; // get 'ballot' across warp\n
\n
\n",
- "tooltip": "Vote across thread group.\n\nSyntax\n\nvote.sync.mode.pred d, {!}a, membermask;\n\nvote.sync.ballot.b32 d, {!}a, membermask; // 'ballot' form, returns bitmask\n\n.mode = { .all, .any, .uni };\n\nDescription\n\nvote.sync will cause executing thread to wait until all non-exited threads corresponding to\n\nmembermask have executed vote.sync with the same qualifiers and same membermask value\n\nbefore resuming execution.\n\nOperand membermask specifies a 32-bit integer which is a mask indicating threads participating\n\nin this instruction where the bit position corresponds to thread\u2019s laneid. Operand a is a\n\npredicate register.\n\nIn the mode form, vote.sync performs a reduction of the source predicate across all non-exited\n\nthreads in membermask. The destination operand d is a predicate register and its value is\n\nthe same across all threads in membermask.\n\nThe reduction modes are:\n\n.all\n\nTrue if source predicate is True for all non-exited threads in membermask. Negate the\n\nsource predicate to compute .none.\n\n.any\n\nTrue if source predicate is True for some thread in membermask. Negate the source\n\npredicate to compute .not_all.\n\n.uni\n\nTrue if source predicate has the same value in all non-exited threads in\n\nmembermask. Negating the source predicate also computes .uni.\n\nIn the ballot form, the destination operand d is a .b32 register. In this form,\n\nvote.sync.ballot.b32 simply copies the predicate from each thread in membermask into the\n\ncorresponding bit position of destination register d, where the bit position corresponds to the\n\nthread\u2019s lane id.\n\nA thread not specified in membermask will contribute a 0 for its entry in\n\nvote.sync.ballot.b32.\n\nThe behavior of vote.sync is undefined if the executing thread is not in the membermask.\n\nNote\n\nFor .target sm_6x or below, all threads in membermask must execute the same vote.sync\n\ninstruction in convergence, and only threads belonging to some membermask can be active when\n\nthe vote.sync instruction is executed. Otherwise, the behavior is undefined.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 6.0.\n\nTarget ISA Notes\n\nRequires sm_30 or higher.\n\nExamples\n\nvote.sync.all.pred p,q,0xffffffff;\n\nvote.sync.ballot.b32 r1,p,0xffffffff; // get 'ballot' across warp\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-vote-sync"
+ "html": "
Performs a reduction of the source predicate across all active threads in a warp. The destination\npredicate value is the same across all threads in the warp.
\nFor more information, visit vote .",
+ "tooltip": "Vote across thread group.",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-vote"
};
case "vset":
return {
- "html": "For more information, visit vset .
\n",
- "tooltip": "Integer byte/half-word/word comparison.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvset.atype.btype.cmp d, a{.asel}, b{.bsel};\n\nvset.atype.btype.cmp.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvset.atype.btype.cmp d.dsel, a{.asel}, b{.bsel}, c;\n\n.atype = .btype = { .u32, .s32 };\n\n.cmp = { .eq, .ne, .lt, .le, .gt, .ge };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nCompare input values using specified comparison, with optional secondary arithmetic operation or\n\nsubword data merge.\n\nThe intermediate result of the comparison is always unsigned, and therefore destination d and\n\noperand c are also unsigned.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a, atype, asel );\n\ntb = partSelectSignExtend( b, btype, bsel );\n\ntmp = compare( ta, tb, cmp ) ? 1 : 0;\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvset requires sm_20 or higher.\n\nExamples\n\nvset.s32.u32.lt r1, r2, r3;\n\nvset.u32.u32.ne r1, r2, r3.h1;\n\n ...",
+ "html": "
Compare input values using specified comparison, with optional secondary arithmetic operation or\nsubword data merge.
\nFor more information, visit vset .",
+ "tooltip": "Integer byte/half-word/word comparison.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vset"
};
case "vset2":
return {
- "html": "For more information, visit vset2 .
SIMD Video Instructions: vset2
\n\n\n
Integer dual half-word SIMD comparison.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvset2.atype.btype.cmp d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvset2.atype.btype.cmp.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n.atype = .btype = { .u32, .s32 };\n.cmp = { .eq, .ne, .lt, .le, .gt, .ge };\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n .asel defaults to .h10\n .bsel defaults to .h32\n
\n
\n
Description
\n
Two-way SIMD parallel comparison with secondary operation.
\n
Elements of each dual half-word source to the operation are selected from any of the four half-words\nin the two source operands a and b using the asel and bsel modifiers.
\n
The selected half-words are then compared in parallel.
\n
The intermediate result of the comparison is always unsigned, and therefore the half-words of\ndestination d and operand c are also unsigned.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are copied into\ndestination d. For all other positions, the corresponding half-word from source operand b\nis copied to d.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are added to operand\nc, producing a result in d.
\n
\n
Semantics
\n
\n
// extract pairs of half-words and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_2( a, b, .asel, .atype );\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\nVc = extractAndSignExt_2( c );\nfor (i=0; i<2; i++) {\n t[i] = compare( Va[i], Vb[i], .cmp ) ? 1 : 0;\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n",
- "tooltip": "Integer dual half-word SIMD comparison.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvset2.atype.btype.cmp d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvset2.atype.btype.cmp.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n.atype = .btype = { .u32, .s32 };\n\n.cmp = { .eq, .ne, .lt, .le, .gt, .ge };\n\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n\n .asel defaults to .h10\n\n .bsel defaults to .h32\n\nDescription\n\nTwo-way SIMD parallel comparison with secondary operation.\n\nElements of each dual half-word source to the operation are selected from any of the four half-words\n\nin the two source operands a and b using the asel and bsel modifiers.\n\nThe selected half-words are then compared in parallel.\n\nThe intermediate result of the comparison is always unsigned, and therefore the half-words of\n\ndestination d and operand c are also unsigned.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor half-word positions indicated in mask, the selected half-word results are copied into\n\ndestination d. For all other positions, the corresponding half-word from source operand b\n\nis copied to d.\n\nFor instructions with a secondary accumulate operation:\n\nFor half-word positions indicated in mask, the selected half-word results are added to operand\n\nc, producing a result in d.\n\nSemantics\n\n// extract pairs of half-words and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_2( a, b, .asel, .atype );\n\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n\n t[i] = compare( Va[i], Vb[i], .cmp ) ? 1 : 0;\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvset2 requires sm_30 or higher.\n\nExamples\n\nvset2.s32.u32.lt r1, r2, r3, r0;\n\nvset2.u32.u32.ne.add r1, r2, r3, r0;\n\n ...",
+ "html": "
Two-way SIMD parallel comparison with secondary operation.
\nFor more information, visit vset2 .",
+ "tooltip": "Integer dual half-word SIMD comparison.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vset2"
};
case "vset4":
return {
- "html": "For more information, visit vset4 .
SIMD Video Instructions: vset4
\n\n\n
Integer quad byte SIMD comparison.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvset4.atype.btype.cmp d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvset4.atype.btype.cmp.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n.atype = .btype = { .u32, .s32 };\n.cmp = { .eq, .ne, .lt, .le, .gt, .ge };\n.mask = { .b0,\n .b1, .b10\n .b2, .b20, .b21, .b210,\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n defaults to .b3210\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n .asel defaults to .b3210\n .bsel defaults to .b7654\n
\n
\n
Description
\n
Four-way SIMD parallel comparison with secondary operation.
\n
Elements of each quad byte source to the operation are selected from any of the eight bytes in the\ntwo source operands a and b using the asel and bsel modifiers.
\n
The selected bytes are then compared in parallel.
\n
The intermediate result of the comparison is always unsigned, and therefore the bytes of destination\nd and operand c are also unsigned.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For byte positions indicated in mask, the selected byte results are copied into destination\nd. For all other positions, the corresponding byte from source operand b is copied to\nd.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For byte positions indicated in mask, the selected byte results are added to operand c,\nproducing a result in d.
\n
\n
Semantics
\n
\n
// extract quads of bytes and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_4( a, b, .asel, .atype );\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\nVc = extractAndSignExt_4( c );\nfor (i=0; i<4; i++) {\n t[i] = compare( Va[i], Vb[i], cmp ) ? 1 : 0;\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n",
- "tooltip": "Integer quad byte SIMD comparison.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvset4.atype.btype.cmp d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvset4.atype.btype.cmp.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n.atype = .btype = { .u32, .s32 };\n\n.cmp = { .eq, .ne, .lt, .le, .gt, .ge };\n\n.mask = { .b0,\n\n .b1, .b10\n\n .b2, .b20, .b21, .b210,\n\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n\n defaults to .b3210\n\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n\n .asel defaults to .b3210\n\n .bsel defaults to .b7654\n\nDescription\n\nFour-way SIMD parallel comparison with secondary operation.\n\nElements of each quad byte source to the operation are selected from any of the eight bytes in the\n\ntwo source operands a and b using the asel and bsel modifiers.\n\nThe selected bytes are then compared in parallel.\n\nThe intermediate result of the comparison is always unsigned, and therefore the bytes of destination\n\nd and operand c are also unsigned.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor byte positions indicated in mask, the selected byte results are copied into destination\n\nd. For all other positions, the corresponding byte from source operand b is copied to\n\nd.\n\nFor instructions with a secondary accumulate operation:\n\nFor byte positions indicated in mask, the selected byte results are added to operand c,\n\nproducing a result in d.\n\nSemantics\n\n// extract quads of bytes and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_4( a, b, .asel, .atype );\n\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_4( c );\n\nfor (i=0; i<4; i++) {\n\n t[i] = compare( Va[i], Vb[i], cmp ) ? 1 : 0;\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvset4 requires sm_30 or higher.\n\nExamples\n\nvset4.s32.u32.lt r1, r2, r3, r0;\n\nvset4.u32.u32.ne.max r1, r2, r3, r0;\n\n ...",
+ "html": "
Four-way SIMD parallel comparison with secondary operation.
\nFor more information, visit vset4 .",
+ "tooltip": "Integer quad byte SIMD comparison.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vset4"
};
case "vshl":
return {
- "html": "For more information, visit vshl .
Shift a left by unsigned amount in b with optional saturate, and optional secondary\narithmetic operation or subword data merge. Left shift fills with zero.
\n
\n
vshr
\n
\n
Shift a right by unsigned amount in b with optional saturate, and optional secondary\narithmetic operation or subword data merge. Signed shift fills with the sign bit, unsigned shift\nfills with zero.
\n
\n
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a,atype, asel );\ntb = partSelectSignExtend( b, .u32, bsel );\nif ( mode == .clamp && tb > 32 ) tb = 32;\nif ( mode == .wrap ) tb = tb & 0x1f;\nswitch ( vop ){\n case vshl: tmp = ta << tb;\n case vshr: tmp = ta >> tb;\n}\n// saturate, taking into account destination type and merge operations\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n
\n",
- "tooltip": "Integer byte/half-word/word left/right shift.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvop.dtype.atype.u32{.sat}.mode d, a{.asel}, b{.bsel};\n\nvop.dtype.atype.u32{.sat}.mode.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvop.dtype.atype.u32{.sat}.mode d.dsel, a{.asel}, b{.bsel}, c;\n\n vop = { vshl, vshr };\n\n.dtype = .atype = { .u32, .s32 };\n\n.mode = { .clamp, .wrap };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nvshl\n\nShift a left by unsigned amount in b with optional saturate, and optional secondary\n\narithmetic operation or subword data merge. Left shift fills with zero.\n\nvshr\n\nShift a right by unsigned amount in b with optional saturate, and optional secondary\n\narithmetic operation or subword data merge. Signed shift fills with the sign bit, unsigned shift\n\nfills with zero.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a,atype, asel );\n\ntb = partSelectSignExtend( b, .u32, bsel );\n\nif ( mode == .clamp && tb > 32 ) tb = 32;\n\nif ( mode == .wrap ) tb = tb & 0x1f;\n\nswitch ( vop ){\n\n case vshl: tmp = ta << tb;\n\n case vshr: tmp = ta >> tb;\n\n}\n\n// saturate, taking into account destination type and merge operations\n\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvshl, vshr require sm_20 or higher.\n\nExamples\n\nvshl.s32.u32.u32.clamp r1, r2, r3;\n\nvshr.u32.u32.u32.wrap r1, r2, r3.h1;\n\n ...",
+ "html": "
\n
vshl
\n
\n
Shift a left by unsigned amount in b with optional saturate, and optional secondary\narithmetic operation or subword data merge. Left shift fills with zero.
\n
\n
vshr
\n
\n
Shift a right by unsigned amount in b with optional saturate, and optional secondary\narithmetic operation or subword data merge. Signed shift fills with the sign bit, unsigned shift\nfills with zero.
\n
\n
\nFor more information, visit vshl .",
+ "tooltip": "Integer byte/half-word/word left/right shift.",
"url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vshl-vshr"
};
- case "vshr":
+ case "wgmma":
return {
- "html": "For more information, visit vshr .
Shift a left by unsigned amount in b with optional saturate, and optional secondary\narithmetic operation or subword data merge. Left shift fills with zero.
\n
\n
vshr
\n
\n
Shift a right by unsigned amount in b with optional saturate, and optional secondary\narithmetic operation or subword data merge. Signed shift fills with the sign bit, unsigned shift\nfills with zero.
\n
\n
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a,atype, asel );\ntb = partSelectSignExtend( b, .u32, bsel );\nif ( mode == .clamp && tb > 32 ) tb = 32;\nif ( mode == .wrap ) tb = tb & 0x1f;\nswitch ( vop ){\n case vshl: tmp = ta << tb;\n case vshr: tmp = ta >> tb;\n}\n// saturate, taking into account destination type and merge operations\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n
\n",
- "tooltip": "Integer byte/half-word/word left/right shift.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvop.dtype.atype.u32{.sat}.mode d, a{.asel}, b{.bsel};\n\nvop.dtype.atype.u32{.sat}.mode.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvop.dtype.atype.u32{.sat}.mode d.dsel, a{.asel}, b{.bsel}, c;\n\n vop = { vshl, vshr };\n\n.dtype = .atype = { .u32, .s32 };\n\n.mode = { .clamp, .wrap };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nvshl\n\nShift a left by unsigned amount in b with optional saturate, and optional secondary\n\narithmetic operation or subword data merge. Left shift fills with zero.\n\nvshr\n\nShift a right by unsigned amount in b with optional saturate, and optional secondary\n\narithmetic operation or subword data merge. Signed shift fills with the sign bit, unsigned shift\n\nfills with zero.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a,atype, asel );\n\ntb = partSelectSignExtend( b, .u32, bsel );\n\nif ( mode == .clamp && tb > 32 ) tb = 32;\n\nif ( mode == .wrap ) tb = tb & 0x1f;\n\nswitch ( vop ){\n\n case vshl: tmp = ta << tb;\n\n case vshr: tmp = ta >> tb;\n\n}\n\n// saturate, taking into account destination type and merge operations\n\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvshl, vshr require sm_20 or higher.\n\nExamples\n\nvshl.s32.u32.u32.clamp r1, r2, r3;\n\nvshr.u32.u32.u32.wrap r1, r2, r3.h1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vshl-vshr"
+ "html": "
Instruction wgmma.mma_async issues a MxNxK matrix multiply and accumulate operation, D=\nA*B+D, where the A matrix is MxK, the B matrix is KxN, and the D matrix is MxN.
\nFor more information, visit wgmma.mma_async , wgmma.mma_async , wgmma.mma_async , wgmma.mma_async.sp , wgmma.mma_async.sp .",
+ "tooltip": "Perform matrix multiply-and-accumulate operation across warpgroup",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#asynchronous-warpgroup-level-matrix-instructions-for-sparse-wgmma"
};
- case "vsub":
+ case "wmma":
return {
- "html": "For more information, visit vsub .
Scalar Video Instructions: vadd, vsub, vabsdiff, vmin, vmax
\n\n\n
Integer byte/half-word/word addition/subtraction.
\n
vabsdiff
\n
Integer byte/half-word/word absolute value of difference.
Perform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.
\n
Semantics
\n
\n
// extract byte/half-word/word and sign- or zero-extend\n// based on source operand type\nta = partSelectSignExtend( a, atype, asel );\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n case vadd: tmp = ta + tb;\n case vsub: tmp = ta - tb;\n case vabsdiff: tmp = | ta - tb |;\n case vmin: tmp = MIN( ta, tb );\n case vmax: tmp = MAX( ta, tb );\n}\n// saturate, taking into account destination type and merge operations\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 2.0.
\n
Target ISA Notes
\n
vadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.
\n",
- "tooltip": "Integer byte/half-word/word addition/subtraction.\n\nvabsdiff\n\nInteger byte/half-word/word absolute value of difference.\n\nvmin, vmax\n\nInteger byte/half-word/word minimum/maximum.\n\nSyntax\n\n// 32-bit scalar operation, with optional secondary operation\n\nvop.dtype.atype.btype{.sat} d, a{.asel}, b{.bsel};\n\nvop.dtype.atype.btype{.sat}.op2 d, a{.asel}, b{.bsel}, c;\n\n// 32-bit scalar operation, with optional data merge\n\nvop.dtype.atype.btype{.sat} d.dsel, a{.asel}, b{.bsel}, c;\n\n vop = { vadd, vsub, vabsdiff, vmin, vmax };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.dsel = .asel = .bsel = { .b0, .b1, .b2, .b3, .h0, .h1 };\n\n.op2 = { .add, .min, .max };\n\nDescription\n\nPerform scalar arithmetic operation with optional saturate, and optional secondary arithmetic operation or subword data merge.\n\nSemantics\n\n// extract byte/half-word/word and sign- or zero-extend\n\n// based on source operand type\n\nta = partSelectSignExtend( a, atype, asel );\n\ntb = partSelectSignExtend( b, btype, bsel );\n\nswitch ( vop ) {\n\n case vadd: tmp = ta + tb;\n\n case vsub: tmp = ta - tb;\n\n case vabsdiff: tmp = | ta - tb |;\n\n case vmin: tmp = MIN( ta, tb );\n\n case vmax: tmp = MAX( ta, tb );\n\n}\n\n// saturate, taking into account destination type and merge operations\n\ntmp = optSaturate( tmp, sat, isSigned(dtype), dsel );\n\nd = optSecondaryOp( op2, tmp, c ); // optional secondary operation\n\nd = optMerge( dsel, tmp, c ); // optional merge with c operand\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 2.0.\n\nTarget ISA Notes\n\nvadd, vsub, vabsdiff, vmin, vmax require sm_20 or higher.\n\nExamples\n\nvadd.s32.u32.s32.sat r1, r2.b0, r3.h0;\n\nvsub.s32.s32.u32.sat r1, r2.h1, r3.h1;\n\nvabsdiff.s32.s32.s32.sat r1.h0, r2.b0, r3.b2, c;\n\nvmin.s32.s32.s32.sat.add r1, r2, r3, c;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vadd-vsub-vabsdiff-vmin-vmax"
+ "html": "
Collectively load a matrix across all threads in a warp from the location indicated by address\noperand p in the specified state space into destination register r.
\nFor more information, visit wmma , wmma.load , wmma.load,wmma.mma , wmma.store .",
+ "tooltip": "Multiplicands (A or B):",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#warp-level-matrix-instructions-wmma"
};
- case "vsub2":
- return {
- "html": "For more information, visit vsub2 .
SIMD Video Instructions: vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2
\n\n\n
Integer dual half-word SIMD addition/subtraction.
\n
vavrg2
\n
Integer dual half-word SIMD average.
\n
vabsdiff2
\n
Integer dual half-word SIMD absolute value of difference.
\n
vmin2, vmax2
\n
Integer dual half-word SIMD minimum/maximum.
\n
Syntax
\n
\n
// SIMD instruction with secondary SIMD merge operation\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n.dtype = .atype = .btype = { .u32, .s32 };\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n .asel defaults to .h10\n .bsel defaults to .h32\n
\n
\n
Description
\n
Two-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each dual half-word source to the operation are selected from any of the four half-words\nin the two source operands a and b using the asel and bsel modifiers.
\n
The selected half-words are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are copied into\ndestination d. For all other positions, the corresponding half-word from source operand c\nis copied to d.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For half-word positions indicated in mask, the selected half-word results are added to operand\nc, producing a result in d.
\n
\n
Semantics
\n
\n
// extract pairs of half-words and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_2( a, b, .asel, .atype );\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n switch ( vop2 ) {\n case vadd2: t[i] = Va[i] + Vb[i];\n case vsub2: t[i] = Va[i] - Vb[i];\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.
\n",
- "tooltip": "Integer dual half-word SIMD addition/subtraction.\n\nvavrg2\n\nInteger dual half-word SIMD average.\n\nvabsdiff2\n\nInteger dual half-word SIMD absolute value of difference.\n\nvmin2, vmax2\n\nInteger dual half-word SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop2.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop2.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\n vop2 = { vadd2, vsub2, vavrg2, vabsdiff2, vmin2, vmax2 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .h0, .h1, .h10 }; // defaults to .h10\n\n.asel = .bsel = { .hxy, where x,y are from { 0, 1, 2, 3 } };\n\n .asel defaults to .h10\n\n .bsel defaults to .h32\n\nDescription\n\nTwo-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each dual half-word source to the operation are selected from any of the four half-words\n\nin the two source operands a and b using the asel and bsel modifiers.\n\nThe selected half-words are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor half-word positions indicated in mask, the selected half-word results are copied into\n\ndestination d. For all other positions, the corresponding half-word from source operand c\n\nis copied to d.\n\nFor instructions with a secondary accumulate operation:\n\nFor half-word positions indicated in mask, the selected half-word results are added to operand\n\nc, producing a result in d.\n\nSemantics\n\n// extract pairs of half-words and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_2( a, b, .asel, .atype );\n\nVb = extractAndSignExt_2( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_2( c );\n\nfor (i=0; i<2; i++) {\n\n switch ( vop2 ) {\n\n case vadd2: t[i] = Va[i] + Vb[i];\n\n case vsub2: t[i] = Va[i] - Vb[i];\n\n case vavrg2: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff2: t[i] = | Va[i] - Vb[i] |;\n\n case vmin2: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax2: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S16_MAX, S16_MIN );\n\n else t[i] = CLAMP( t[i], U16_MAX, U16_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<2; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<2; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd2, vsub2, varvg2, vabsdiff2, vmin2, vmax2 require sm_30 or higher.\n\nExamples\n\nvadd2.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub2.s32.s32.s32.sat r1.h0, r2.h10, r3.h32, r1;\n\nvmin2.s32.u32.u32.add r1.h10, r2.h00, r3.h22, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd2-vsub2-vavrg2-vabsdiff2-vmin2-vmax2"
- };
-
- case "vsub4":
- return {
- "html": "For more information, visit vsub4 .
SIMD Video Instructions: vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4
\n\n\n
Integer quad byte SIMD addition/subtraction.
\n
vavrg4
\n
Integer quad byte SIMD average.
\n
vabsdiff4
\n
Integer quad byte SIMD absolute value of difference.
Four-way SIMD parallel arithmetic operation with secondary operation.
\n
Elements of each quad byte source to the operation are selected from any of the eight bytes in the\ntwo source operands a and b using the asel and bsel modifiers.
\n
The selected bytes are then operated on in parallel.
\n
The results are optionally clamped to the appropriate range determined by the destination type\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.
\n
For instructions with a secondary SIMD merge operation:
\n
\n
For byte positions indicated in mask, the selected byte results are copied into destination\nd. For all other positions, the corresponding byte from source operand c is copied to\nd.
\n
\n
For instructions with a secondary accumulate operation:
\n
\n
For byte positions indicated in mask, the selected byte results are added to operand c,\nproducing a result in d.
\n
\n
Semantics
\n
\n
// extract quads of bytes and sign- or zero-extend\n// based on operand type\nVa = extractAndSignExt_4( a, b, .asel, .atype );\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\nVc = extractAndSignExt_4( c );\nfor (i=0; i<4; i++) {\n switch ( vop4 ) {\n case vadd4: t[i] = Va[i] + Vb[i];\n case vsub4: t[i] = Va[i] - Vb[i];\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n } else {\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n }\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n }\n if (.sat) {\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n }\n}\n// secondary accumulate or SIMD merge\nmask = extractMaskBits( .mask );\nif (.add) {\n d = c;\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n} else {\n d = 0;\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n}\n
\n
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.0.
\n
Target ISA Notes
\n
vadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.
\n",
- "tooltip": "Integer quad byte SIMD addition/subtraction.\n\nvavrg4\n\nInteger quad byte SIMD average.\n\nvabsdiff4\n\nInteger quad byte SIMD absolute value of difference.\n\nvmin4, vmax4\n\nInteger quad byte SIMD minimum/maximum.\n\nSyntax\n\n// SIMD instruction with secondary SIMD merge operation\n\nvop4.dtype.atype.btype{.sat} d{.mask}, a{.asel}, b{.bsel}, c;\n\n// SIMD instruction with secondary accumulate operation\n\nvop4.dtype.atype.btype.add d{.mask}, a{.asel}, b{.bsel}, c;\n\nvop4 = { vadd4, vsub4, vavrg4, vabsdiff4, vmin4, vmax4 };\n\n.dtype = .atype = .btype = { .u32, .s32 };\n\n.mask = { .b0,\n\n .b1, .b10\n\n .b2, .b20, .b21, .b210,\n\n .b3, .b30, .b31, .b310, .b32, .b320, .b321, .b3210 };\n\n defaults to .b3210\n\n.asel = .bsel = .bxyzw, where x,y,z,w are from { 0, ..., 7 };\n\n .asel defaults to .b3210\n\n .bsel defaults to .b7654\n\nDescription\n\nFour-way SIMD parallel arithmetic operation with secondary operation.\n\nElements of each quad byte source to the operation are selected from any of the eight bytes in the\n\ntwo source operands a and b using the asel and bsel modifiers.\n\nThe selected bytes are then operated on in parallel.\n\nThe results are optionally clamped to the appropriate range determined by the destination type\n\n(signed or unsigned). Saturation cannot be used with the secondary accumulate operation.\n\nFor instructions with a secondary SIMD merge operation:\n\nFor byte positions indicated in mask, the selected byte results are copied into destination\n\nd. For all other positions, the corresponding byte from source operand c is copied to\n\nd.\n\nFor instructions with a secondary accumulate operation:\n\nFor byte positions indicated in mask, the selected byte results are added to operand c,\n\nproducing a result in d.\n\nSemantics\n\n// extract quads of bytes and sign- or zero-extend\n\n// based on operand type\n\nVa = extractAndSignExt_4( a, b, .asel, .atype );\n\nVb = extractAndSignExt_4( a, b, .bsel, .btype );\n\nVc = extractAndSignExt_4( c );\n\nfor (i=0; i<4; i++) {\n\n switch ( vop4 ) {\n\n case vadd4: t[i] = Va[i] + Vb[i];\n\n case vsub4: t[i] = Va[i] - Vb[i];\n\n case vavrg4: if ( ( Va[i] + Vb[i] ) >= 0 ) {\n\n t[i] = ( Va[i] + Vb[i] + 1 ) >> 1;\n\n } else {\n\n t[i] = ( Va[i] + Vb[i] ) >> 1;\n\n }\n\n case vabsdiff4: t[i] = | Va[i] - Vb[i] |;\n\n case vmin4: t[i] = MIN( Va[i], Vb[i] );\n\n case vmax4: t[i] = MAX( Va[i], Vb[i] );\n\n }\n\n if (.sat) {\n\n if ( .dtype == .s32 ) t[i] = CLAMP( t[i], S8_MAX, S8_MIN );\n\n else t[i] = CLAMP( t[i], U8_MAX, U8_MIN );\n\n }\n\n}\n\n// secondary accumulate or SIMD merge\n\nmask = extractMaskBits( .mask );\n\nif (.add) {\n\n d = c;\n\n for (i=0; i<4; i++) { d += mask[i] ? t[i] : 0; }\n\n} else {\n\n d = 0;\n\n for (i=0; i<4; i++) { d |= mask[i] ? t[i] : Vc[i]; }\n\n}\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.0.\n\nTarget ISA Notes\n\nvadd4, vsub4, varvg4, vabsdiff4, vmin4, vmax4 require sm_30 or higher.\n\nExamples\n\nvadd4.s32.s32.u32.sat r1, r2, r3, r1;\n\nvsub4.s32.s32.s32.sat r1.b0, r2.b3210, r3.b7654, r1;\n\nvmin4.s32.u32.u32.add r1.b00, r2.b0000, r3.b2222, r1;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#simd-video-instructions-vadd4-vsub4-vavrg4-vabsdiff4-vmin4-vmax4"
- };
-
- case "warpid":
- return {
- "html": "For more information, visit warpid .
Special Registers: %warpid
\n\n\n
Warp identifier.
\n
Syntax (predefined)
\n
\n
.sreg .u32 %warpid;\n
\n
\n
Description
\n
A predefined, read-only special register that returns the thread\u2019s warp identifier. The warp\nidentifier provides a unique warp number within a CTA but not across CTAs within a grid. The warp\nidentifier will be the same for all threads within a single warp.
\n
Note that %warpid is volatile and returns the location of a thread at the moment when read, but\nits value may change during execution, e.g., due to rescheduling of threads following\npreemption. For this reason, %ctaid and %tid should be used to compute a virtual warp index\nif such a value is needed in kernel code; %warpid is intended mainly to enable profiling and\ndiagnostic code to sample and log information such as work place mapping and load distribution.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.3.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
mov.u32 %r, %warpid;\n
\n
\n",
- "tooltip": "Warp identifier.\n\nSyntax (predefined)\n\n.sreg .u32 %warpid;\n\nDescription\n\nA predefined, read-only special register that returns the thread\u2019s warp identifier. The warp\n\nidentifier provides a unique warp number within a CTA but not across CTAs within a grid. The warp\n\nidentifier will be the same for all threads within a single warp.\n\nNote that %warpid is volatile and returns the location of a thread at the moment when read, but\n\nits value may change during execution, e.g., due to rescheduling of threads following\n\npreemption. For this reason, %ctaid and %tid should be used to compute a virtual warp index\n\nif such a value is needed in kernel code; %warpid is intended mainly to enable profiling and\n\ndiagnostic code to sample and log information such as work place mapping and load distribution.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.3.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nmov.u32 %r, %warpid;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers-warpid"
- };
-
- case "weak":
+ case "xor":
return {
- "html": "For more information, visit weak .
Linking Directives: .weak
\n\n\n
Visible (externally) symbol declaration.
\n
Syntax
\n
\n
.weak identifier\n
\n
\n
Description
\n
Declares identifier to be globally visible but weak. Weak symbols are similar to globally visible\nsymbols, except during linking, weak symbols are only chosen after globally visible symbols during\nsymbol resolution. Unlike globally visible symbols, multiple object files may declare the same weak\nsymbol, and references to a symbol get resolved against a weak symbol only if no global symbols have\nthe same name.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 3.1.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
.weak .func (.reg .b32 val) foo; // foo will be externally visible\n
\n
\n",
- "tooltip": "Visible (externally) symbol declaration.\n\nSyntax\n\n.weak identifier\n\nDescription\n\nDeclares identifier to be globally visible but weak. Weak symbols are similar to globally visible\n\nsymbols, except during linking, weak symbols are only chosen after globally visible symbols during\n\nsymbol resolution. Unlike globally visible symbols, multiple object files may declare the same weak\n\nsymbol, and references to a symbol get resolved against a weak symbol only if no global symbols have\n\nthe same name.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 3.1.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\n.weak .func (.reg .b32 val) foo; // foo will be externally visible\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#linking-directives-weak"
+ "html": "
Compute the bit-wise exclusive-or operation for the bits in a and b.
\nFor more information, visit xor .",
+ "tooltip": "Bitwise exclusive-OR (inequality).",
+ "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-xor"
};
- case "xor":
+ case "{}":
return {
- "html": "For more information, visit xor .
Compute the bit-wise exclusive-or operation for the bits in a and b.
\n
Semantics
\n
\n
d = a ^ b;\n
\n
\n
Notes
\n
The size of the operands must match, but not necessarily the type.
\n
Allowed types include predicate registers.
\n
PTX ISA Notes
\n
Introduced in PTX ISA version 1.0.
\n
Target ISA Notes
\n
Supported on all target architectures.
\n
Examples
\n
\n
xor.b32 d,q,r;\nxor.b16 d,x,0x0001;\n
\n
\n",
- "tooltip": "Bitwise exclusive-OR (inequality).\n\nSyntax\n\nxor.type d, a, b;\n\n.type = { .pred, .b16, .b32, .b64 };\n\nDescription\n\nCompute the bit-wise exclusive-or operation for the bits in a and b.\n\nSemantics\n\nd = a ^ b;\n\nNotes\n\nThe size of the operands must match, but not necessarily the type.\n\nAllowed types include predicate registers.\n\nPTX ISA Notes\n\nIntroduced in PTX ISA version 1.0.\n\nTarget ISA Notes\n\nSupported on all target architectures.\n\nExamples\n\nxor.b32 d,q,r;\n\nxor.b16 d,x,0x0001;\n\n ...",
- "url": "https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#logic-and-shift-instructions-xor"
+ "html": "
The curly braces create a group of instructions, used primarily for defining a function body. The\ncurly braces also provide a mechanism for determining the scope of a variable: any variable declared\nwithin a scope is not available outside the scope.
Calls a callable object with the number of arguments specified by argc,\nincluding the named arguments specified by the preceding\nKW_NAMES, if any.\nOn the stack are (in ascending order), either:
\n
\n
NULL
\n
The callable
\n
The positional arguments
\n
The named arguments
\n
\n
or:
\n
\n
The callable
\n
self
\n
The remaining positional arguments
\n
The named arguments
\n
\n
argc is the total of the positional and named arguments, excluding\nself when a NULL is not present.
\n
CALL pops all arguments and the callable object off the stack,\ncalls the callable object with those arguments, and pushes the return value\nreturned by the callable object.
\n\n
Added in version 3.11.
\n\n",
- "tooltip": "Calls a callable object with the number of arguments specified by argc,\nincluding the named arguments specified by the preceding\nKW_NAMES, if any.\nOn the stack are (in ascending order), either",
+ "html": "
Calls a callable object with the number of arguments specified by argc.\nOn the stack are (in ascending order):
\n
\n
The callable
\n
self or NULL
\n
The remaining positional arguments
\n
\n
argc is the total of the positional arguments, excluding self.
\n
CALL pops all arguments and the callable object off the stack,\ncalls the callable object with those arguments, and pushes the return value\nreturned by the callable object.
\n\n
Added in version 3.11.
\n\n\n
Changed in version 3.13: The callable now always appears at the same position on the stack.
\n\n\n
Changed in version 3.13: Calls with keyword arguments are now handled by CALL_KW.
\n\n",
+ "tooltip": "Calls a callable object with the number of arguments specified by argc.\nOn the stack are (in ascending order)",
"url": "https://docs.python.org/3/library/dis.html#opcode-CALL"
};
@@ -117,11 +117,18 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "CALL_INTRINSIC_2":
return {
- "html": "
Calls an intrinsic function with two arguments. Used to implement functionality\nthat is not performance critical:
The operand determines which intrinsic function is called:
\n
\n\n
Operand
\n
Description
\n
\n\n\n
INTRINSIC_2_INVALID
\n
Not valid
\n
\n
INTRINSIC_PREP_RERAISE_STAR
\n
Calculates the\nExceptionGroup to raise\nfrom a try-except*.
\n
\n
INTRINSIC_TYPEVAR_WITH_BOUND
\n
Creates a typing.TypeVar\nwith a bound.
\n
\n
INTRINSIC_TYPEVAR_WITH_CONSTRAINTS
\n
Creates a\ntyping.TypeVar with\nconstraints.
\n
\n
INTRINSIC_SET_FUNCTION_TYPE_PARAMS
\n
Sets the __type_params__\nattribute of a function.
\n
\n\n
\n\n
Added in version 3.12.
\n\n",
"tooltip": "Calls an intrinsic function with two arguments. Used to implement functionality\nthat is not performance critical",
"url": "https://docs.python.org/3/library/dis.html#opcode-CALL_INTRINSIC_2"
};
+ case "CALL_KW":
+ return {
+ "html": "
Calls a callable object with the number of arguments specified by argc,\nincluding one or more named arguments. On the stack are (in ascending order):
\n
\n
The callable
\n
self or NULL
\n
The remaining positional arguments
\n
The named arguments
\n
A tuple of keyword argument names
\n
\n
argc is the total of the positional and named arguments, excluding self.\nThe length of the tuple of keyword argument names is the number of named arguments.
\n
CALL_KW pops all arguments, the keyword names, and the callable object\noff the stack, calls the callable object with those arguments, and pushes the\nreturn value returned by the callable object.
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Calls a callable object with the number of arguments specified by argc,\nincluding one or more named arguments. On the stack are (in ascending order)",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-CALL_KW"
+ };
+
case "CHECK_EG_MATCH":
return {
"html": "
Performs exception matching for except*. Applies split(STACK[-1]) on\nthe exception group representing STACK[-2].
\n
In case of a match, pops two items from the stack and pushes the\nnon-matching subgroup (None in case of full match) followed by the\nmatching subgroup. When there is no match, pops one item (the match\ntype) and pushes None.
\n\n
Added in version 3.11.
\n\n",
@@ -145,8 +152,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "COMPARE_OP":
return {
- "html": "
Performs a Boolean operation. The operation name can be found in\ncmp_op[opname >> 4].
\n\n
Changed in version 3.12: The cmp_op index is now stored in the four-highest bits of oparg instead of the four-lowest bits of oparg.
\n\n",
- "tooltip": "Performs a Boolean operation. The operation name can be found in\ncmp_op[opname >> 4].",
+ "html": "
Performs a Boolean operation. The operation name can be found in\ncmp_op[opname >> 5]. If the fifth-lowest bit of opname is set\n(opname & 16), the result should be coerced to bool.
\n\n
Changed in version 3.13: The fifth-lowest bit of the oparg now indicates a forced conversion to\nbool.
\n\n",
+ "tooltip": "Performs a Boolean operation. The operation name can be found in\ncmp_op[opname >> 5]. If the fifth-lowest bit of opname is set\n(opname & 16), the result should be coerced to bool.",
"url": "https://docs.python.org/3/library/dis.html#opcode-COMPARE_OP"
};
@@ -157,6 +164,13 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://docs.python.org/3/library/dis.html#opcode-CONTAINS_OP"
};
+ case "CONVERT_VALUE":
+ return {
+ "html": "
Convert value to a string, depending on oparg:
\n
value = STACK.pop()\nresult = func(value)\nSTACK.append(result)\n
\n\n
\n
oparg == 1: call str() on value
\n
oparg == 2: call repr() on value
\n
oparg == 3: call ascii() on value
\n
\n
Used for implementing formatted string literals (f-strings).
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Convert value to a string, depending on oparg",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-CONVERT_VALUE"
+ };
+
case "COPY":
return {
"html": "
Push the i-th item to the top of the stack without removing it from its original\nlocation:
\n
assert i > 0\nSTACK.append(STACK[-i])\n
\n\n\n
Added in version 3.11.
\n\n",
@@ -166,8 +180,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "COPY_FREE_VARS":
return {
- "html": "
Copies the n free variables from the closure into the frame.\nRemoves the need for special code on the caller\u2019s side when calling\nclosures.
\n\n
Added in version 3.11.
\n\n",
- "tooltip": "Copies the n free variables from the closure into the frame.\nRemoves the need for special code on the caller\u2019s side when calling\nclosures.",
+ "html": "
Copies the n free (closure) variables from the closure\ninto the frame. Removes the need for special code on the caller\u2019s side when calling\nclosures.
\n\n
Added in version 3.11.
\n\n",
+ "tooltip": "Copies the n free (closure) variables from the closure\ninto the frame. Removes the need for special code on the caller\u2019s side when calling\nclosures.",
"url": "https://docs.python.org/3/library/dis.html#opcode-COPY_FREE_VARS"
};
@@ -236,8 +250,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "END_FOR":
return {
- "html": "
Removes the top two values from the stack.\nEquivalent to POP_TOP; POP_TOP.\nUsed to clean up at the end of loops, hence the name.
\n\n
Added in version 3.12.
\n\n",
- "tooltip": "Removes the top two values from the stack.\nEquivalent to POP_TOP; POP_TOP.\nUsed to clean up at the end of loops, hence the name.",
+ "html": "
Removes the top-of-stack item.\nEquivalent to POP_TOP.\nUsed to clean up at the end of loops, hence the name.
\n\n
Added in version 3.12.
\n\n",
+ "tooltip": "Removes the top-of-stack item.\nEquivalent to POP_TOP.\nUsed to clean up at the end of loops, hence the name.",
"url": "https://docs.python.org/3/library/dis.html#opcode-END_FOR"
};
@@ -255,11 +269,18 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://docs.python.org/3/library/dis.html#opcode-EXTENDED_ARG"
};
- case "FORMAT_VALUE":
+ case "FORMAT_SIMPLE":
+ return {
+ "html": "
Formats the value on top of stack:
\n
value = STACK.pop()\nresult = value.__format__(\"\")\nSTACK.append(result)\n
\n\n
Used for implementing formatted string literals (f-strings).
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Formats the value on top of stack",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-FORMAT_SIMPLE"
+ };
+
+ case "FORMAT_WITH_SPEC":
return {
- "html": "
Used for implementing formatted literal strings (f-strings). Pops\nan optional fmt_spec from the stack, then a required value.\nflags is interpreted as follows:
\n
\n
(flags & 0x03) == 0x00: value is formatted as-is.
\n
(flags & 0x03) == 0x01: call str() on value before\nformatting it.
\n
(flags & 0x03) == 0x02: call repr() on value before\nformatting it.
\n
(flags & 0x03) == 0x03: call ascii() on value before\nformatting it.
\n
(flags & 0x04) == 0x04: pop fmt_spec from the stack and use\nit, else use an empty fmt_spec.
\n
\n
Formatting is performed using PyObject_Format(). The\nresult is pushed on the stack.
\n\n
Added in version 3.6.
\n\n",
- "tooltip": "Used for implementing formatted literal strings (f-strings). Pops\nan optional fmt_spec from the stack, then a required value.\nflags is interpreted as follows",
- "url": "https://docs.python.org/3/library/dis.html#opcode-FORMAT_VALUE"
+ "html": "
Formats the given value with the given format spec:
Used for implementing formatted string literals (f-strings).
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Formats the given value with the given format spec",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-FORMAT_WITH_SPEC"
};
case "FOR_ITER":
@@ -299,8 +320,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "GET_LEN":
return {
- "html": "
Perform STACK.append(len(STACK[-1])). Used in match statements where\ncomparison with structure of pattern is needed.
\n\n
Added in version 3.10.
\n\n",
+ "tooltip": "Perform STACK.append(len(STACK[-1])). Used in match statements where\ncomparison with structure of pattern is needed.",
"url": "https://docs.python.org/3/library/dis.html#opcode-GET_LEN"
};
@@ -313,7 +334,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "HAVE_ARGUMENT":
return {
- "html": "
This is not really an opcode. It identifies the dividing line between\nopcodes in the range [0,255] which don\u2019t use their argument and those\nthat do (< HAVE_ARGUMENT and >= HAVE_ARGUMENT, respectively).
\n
If your application uses pseudo instructions, use the hasarg\ncollection instead.
\n\n
Changed in version 3.6: Now every instruction has an argument, but opcodes < HAVE_ARGUMENT\nignore it. Before, only opcodes >= HAVE_ARGUMENT had an argument.
\n\n\n
Changed in version 3.12: Pseudo instructions were added to the dis module, and for them\nit is not true that comparison with HAVE_ARGUMENT indicates whether\nthey use their arg.
\n\n",
+ "html": "
This is not really an opcode. It identifies the dividing line between\nopcodes in the range [0,255] which don\u2019t use their argument and those\nthat do (< HAVE_ARGUMENT and >= HAVE_ARGUMENT, respectively).
\n
If your application uses pseudo instructions or specialized instructions,\nuse the hasarg collection instead.
\n\n
Changed in version 3.6: Now every instruction has an argument, but opcodes < HAVE_ARGUMENT\nignore it. Before, only opcodes >= HAVE_ARGUMENT had an argument.
\n\n\n
Changed in version 3.12: Pseudo instructions were added to the dis module, and for them\nit is not true that comparison with HAVE_ARGUMENT indicates whether\nthey use their arg.
\n\n\n
Deprecated since version 3.13: Use hasarg instead.
\n\n",
"tooltip": "This is not really an opcode. It identifies the dividing line between\nopcodes in the range [0,255] which don\u2019t use their argument and those\nthat do (< HAVE_ARGUMENT and >= HAVE_ARGUMENT, respectively).",
"url": "https://docs.python.org/3/library/dis.html#opcode-HAVE_ARGUMENT"
};
@@ -374,13 +395,6 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://docs.python.org/3/library/dis.html#opcode-JUMP_NO_INTERRUPT"
};
- case "KW_NAMES":
- return {
- "html": "
Prefixes CALL.\nStores a reference to co_consts[consti] into an internal variable\nfor use by CALL. co_consts[consti] must be a tuple of strings.
\n\n
Added in version 3.11.
\n\n",
- "tooltip": "Prefixes CALL.\nStores a reference to co_consts[consti] into an internal variable\nfor use by CALL. co_consts[consti] must be a tuple of strings.",
- "url": "https://docs.python.org/3/library/dis.html#opcode-KW_NAMES"
- };
-
case "LIST_APPEND":
return {
"html": "
\n",
@@ -404,7 +418,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "LOAD_ATTR":
return {
- "html": "
If the low bit of namei is not set, this replaces STACK[-1] with\ngetattr(STACK[-1], co_names[namei>>1]).
\n
If the low bit of namei is set, this will attempt to load a method named\nco_names[namei>>1] from the STACK[-1] object. STACK[-1] is popped.\nThis bytecode distinguishes two cases: if STACK[-1] has a method with the\ncorrect name, the bytecode pushes the unbound method and STACK[-1].\nSTACK[-1] will be used as the first argument (self) by CALL\nwhen calling the unbound method. Otherwise, NULL and the object returned by\nthe attribute lookup are pushed.
\n\n
Changed in version 3.12: If the low bit of namei is set, then a NULL or self is\npushed to the stack before the attribute or unbound method respectively.
\n\n",
+ "html": "
If the low bit of namei is not set, this replaces STACK[-1] with\ngetattr(STACK[-1], co_names[namei>>1]).
\n
If the low bit of namei is set, this will attempt to load a method named\nco_names[namei>>1] from the STACK[-1] object. STACK[-1] is popped.\nThis bytecode distinguishes two cases: if STACK[-1] has a method with the\ncorrect name, the bytecode pushes the unbound method and STACK[-1].\nSTACK[-1] will be used as the first argument (self) by CALL\nor CALL_KW when calling the unbound method.\nOtherwise, NULL and the object returned by\nthe attribute lookup are pushed.
\n\n
Changed in version 3.12: If the low bit of namei is set, then a NULL or self is\npushed to the stack before the attribute or unbound method respectively.
\n\n",
"tooltip": "If the low bit of namei is not set, this replaces STACK[-1] with\ngetattr(STACK[-1], co_names[namei>>1]).",
"url": "https://docs.python.org/3/library/dis.html#opcode-LOAD_ATTR"
};
@@ -418,8 +432,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "LOAD_CLOSURE":
return {
- "html": "
Pushes a reference to the cell contained in slot i of the \u201cfast locals\u201d\nstorage. The name of the variable is co_fastlocalnames[i].
\n
Note that LOAD_CLOSURE is effectively an alias for LOAD_FAST.\nIt exists to keep bytecode a little more readable.
\n\n
Changed in version 3.11: i is no longer offset by the length of co_varnames.
\n\n",
- "tooltip": "Pushes a reference to the cell contained in slot i of the \u201cfast locals\u201d\nstorage. The name of the variable is co_fastlocalnames[i].",
+ "html": "
Pushes a reference to the cell contained in slot i of the \u201cfast locals\u201d\nstorage.
\n
Note that LOAD_CLOSURE is replaced with LOAD_FAST in the assembler.
\n\n
Changed in version 3.13: This opcode is now a pseudo-instruction.
\n\n",
+ "tooltip": "Pushes a reference to the cell contained in slot i of the \u201cfast locals\u201d\nstorage.",
"url": "https://docs.python.org/3/library/dis.html#opcode-LOAD_CLOSURE"
};
@@ -458,10 +472,17 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://docs.python.org/3/library/dis.html#opcode-LOAD_FAST_CHECK"
};
+ case "LOAD_FAST_LOAD_FAST":
+ return {
+ "html": "
Pushes references to co_varnames[var_nums >> 4] and\nco_varnames[var_nums & 15] onto the stack.
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Pushes references to co_varnames[var_nums >> 4] and\nco_varnames[var_nums & 15] onto the stack.",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-LOAD_FAST_LOAD_FAST"
+ };
+
case "LOAD_FROM_DICT_OR_DEREF":
return {
- "html": "
Pops a mapping off the stack and looks up the name associated with\nslot i of the \u201cfast locals\u201d storage in this mapping.\nIf the name is not found there, loads it from the cell contained in\nslot i, similar to LOAD_DEREF. This is used for loading\nfree variables in class bodies (which previously used\nLOAD_CLASSDEREF) and in\nannotation scopes within class bodies.
\n\n
Added in version 3.12.
\n\n",
- "tooltip": "Pops a mapping off the stack and looks up the name associated with\nslot i of the \u201cfast locals\u201d storage in this mapping.\nIf the name is not found there, loads it from the cell contained in\nslot i, similar to LOAD_DEREF. This is used for loading\nfree variables in class bodies (which previously used\nLOAD_CLASSDEREF) and in\nannotation scopes within class bodies.",
+ "html": "
Pops a mapping off the stack and looks up the name associated with\nslot i of the \u201cfast locals\u201d storage in this mapping.\nIf the name is not found there, loads it from the cell contained in\nslot i, similar to LOAD_DEREF. This is used for loading\nclosure variables in class bodies (which previously used\nLOAD_CLASSDEREF) and in\nannotation scopes within class bodies.
\n\n
Added in version 3.12.
\n\n",
+ "tooltip": "Pops a mapping off the stack and looks up the name associated with\nslot i of the \u201cfast locals\u201d storage in this mapping.\nIf the name is not found there, loads it from the cell contained in\nslot i, similar to LOAD_DEREF. This is used for loading\nclosure variables in class bodies (which previously used\nLOAD_CLASSDEREF) and in\nannotation scopes within class bodies.",
"url": "https://docs.python.org/3/library/dis.html#opcode-LOAD_FROM_DICT_OR_DEREF"
};
@@ -502,7 +523,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "LOAD_SUPER_ATTR":
return {
- "html": "
This opcode implements super(), both in its zero-argument and\ntwo-argument forms (e.g. super().method(), super().attr and\nsuper(cls, self).method(), super(cls, self).attr).
\n
It pops three values from the stack (from top of stack down):\n- self: the first argument to the current method\n- cls: the class within which the current method was defined\n- the global super
\n
With respect to its argument, it works similarly to LOAD_ATTR,\nexcept that namei is shifted left by 2 bits instead of 1.
\n
The low bit of namei signals to attempt a method load, as with\nLOAD_ATTR, which results in pushing NULL and the loaded method.\nWhen it is unset a single value is pushed to the stack.
\n
The second-low bit of namei, if set, means that this was a two-argument\ncall to super() (unset means zero-argument).
\n\n
Added in version 3.12.
\n\n",
+ "html": "
This opcode implements super(), both in its zero-argument and\ntwo-argument forms (e.g. super().method(), super().attr and\nsuper(cls, self).method(), super(cls, self).attr).
\n
It pops three values from the stack (from top of stack down):
\n
\n
self: the first argument to the current method
\n
cls: the class within which the current method was defined
\n
the global super
\n
\n
With respect to its argument, it works similarly to LOAD_ATTR,\nexcept that namei is shifted left by 2 bits instead of 1.
\n
The low bit of namei signals to attempt a method load, as with\nLOAD_ATTR, which results in pushing NULL and the loaded method.\nWhen it is unset a single value is pushed to the stack.
\n
The second-low bit of namei, if set, means that this was a two-argument\ncall to super() (unset means zero-argument).
\n\n
Added in version 3.12.
\n\n",
"tooltip": "This opcode implements super(), both in its zero-argument and\ntwo-argument forms (e.g. super().method(), super().attr and\nsuper(cls, self).method(), super(cls, self).attr).",
"url": "https://docs.python.org/3/library/dis.html#opcode-LOAD_SUPER_ATTR"
};
@@ -516,8 +537,8 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "MAKE_FUNCTION":
return {
- "html": "
Pushes a new function object on the stack. From bottom to top, the consumed\nstack must consist of values if the argument carries a specified flag value
\n
\n
0x01 a tuple of default values for positional-only and\npositional-or-keyword parameters in positional order
\n
0x02 a dictionary of keyword-only parameters\u2019 default values
\n
0x04 a tuple of strings containing parameters\u2019 annotations
\n
0x08 a tuple containing cells for free variables, making a closure
\n
the code associated with the function (at STACK[-1])
\n
\n\n
Changed in version 3.10: Flag value 0x04 is a tuple of strings instead of dictionary
\n\n\n
Changed in version 3.11: Qualified name at STACK[-1] was removed.
\n\n",
- "tooltip": "Pushes a new function object on the stack. From bottom to top, the consumed\nstack must consist of values if the argument carries a specified flag value",
+ "html": "
Pushes a new function object on the stack built from the code object at STACK[-1].
\n\n
Changed in version 3.10: Flag value 0x04 is a tuple of strings instead of dictionary
\n\n\n
Changed in version 3.11: Qualified name at STACK[-1] was removed.
\n\n\n
Changed in version 3.13: Extra function attributes on the stack, signaled by oparg flags, were\nremoved. They now use SET_FUNCTION_ATTRIBUTE.
\n\n",
+ "tooltip": "Pushes a new function object on the stack built from the code object at STACK[-1].",
"url": "https://docs.python.org/3/library/dis.html#opcode-MAKE_FUNCTION"
};
@@ -579,28 +600,28 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "POP_JUMP_IF_FALSE":
return {
- "html": "
If STACK[-1] is false, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n\n
Changed in version 3.11: The oparg is now a relative delta rather than an absolute target.\nThis opcode is a pseudo-instruction, replaced in final bytecode by\nthe directed versions (forward/backward).
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n",
+ "html": "
If STACK[-1] is false, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n\n
Changed in version 3.11: The oparg is now a relative delta rather than an absolute target.\nThis opcode is a pseudo-instruction, replaced in final bytecode by\nthe directed versions (forward/backward).
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n\n
Changed in version 3.13: This instruction now requires an exact bool operand.
\n\n",
"tooltip": "If STACK[-1] is false, increments the bytecode counter by delta.\nSTACK[-1] is popped.",
"url": "https://docs.python.org/3/library/dis.html#opcode-POP_JUMP_IF_FALSE"
};
case "POP_JUMP_IF_NONE":
return {
- "html": "
If STACK[-1] is None, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n
This opcode is a pseudo-instruction, replaced in final bytecode by\nthe directed versions (forward/backward).
\n\n
Added in version 3.11.
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n",
+ "html": "
If STACK[-1] is None, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n\n
Added in version 3.11.
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n",
"tooltip": "If STACK[-1] is None, increments the bytecode counter by delta.\nSTACK[-1] is popped.",
"url": "https://docs.python.org/3/library/dis.html#opcode-POP_JUMP_IF_NONE"
};
case "POP_JUMP_IF_NOT_NONE":
return {
- "html": "
If STACK[-1] is not None, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n
This opcode is a pseudo-instruction, replaced in final bytecode by\nthe directed versions (forward/backward).
\n\n
Added in version 3.11.
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n",
+ "html": "
If STACK[-1] is not None, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n\n
Added in version 3.11.
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n",
"tooltip": "If STACK[-1] is not None, increments the bytecode counter by delta.\nSTACK[-1] is popped.",
"url": "https://docs.python.org/3/library/dis.html#opcode-POP_JUMP_IF_NOT_NONE"
};
case "POP_JUMP_IF_TRUE":
return {
- "html": "
If STACK[-1] is true, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n\n
Changed in version 3.11: The oparg is now a relative delta rather than an absolute target.\nThis opcode is a pseudo-instruction, replaced in final bytecode by\nthe directed versions (forward/backward).
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n",
+ "html": "
If STACK[-1] is true, increments the bytecode counter by delta.\nSTACK[-1] is popped.
\n\n
Changed in version 3.11: The oparg is now a relative delta rather than an absolute target.\nThis opcode is a pseudo-instruction, replaced in final bytecode by\nthe directed versions (forward/backward).
\n\n\n
Changed in version 3.12: This is no longer a pseudo-instruction.
\n\n\n
Changed in version 3.13: This instruction now requires an exact bool operand.
\n\n",
"tooltip": "If STACK[-1] is true, increments the bytecode counter by delta.\nSTACK[-1] is popped.",
"url": "https://docs.python.org/3/library/dis.html#opcode-POP_JUMP_IF_TRUE"
};
@@ -642,7 +663,7 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
case "RESUME":
return {
- "html": "
A no-op. Performs internal tracing, debugging and optimization checks.
\n
The where operand marks where the RESUME occurs:
\n
\n
0 The start of a function, which is neither a generator, coroutine\nnor an async generator
\n
1 After a yield expression
\n
2 After a yield from expression
\n
3 After an await expression
\n
\n\n
Added in version 3.11.
\n\n",
+ "html": "
A no-op. Performs internal tracing, debugging and optimization checks.
\n
The context oparand consists of two parts. The lowest two bits\nindicate where the RESUME occurs:
\n
\n
0 The start of a function, which is neither a generator, coroutine\nnor an async generator
\n
1 After a yield expression
\n
2 After a yield from expression
\n
3 After an await expression
\n
\n
The next bit is 1 if the RESUME is at except-depth 1, and 0\notherwise.
\n\n
Added in version 3.11.
\n\n\n
Changed in version 3.13: The oparg value changed to include information about except-depth
\n\n",
"tooltip": "A no-op. Performs internal tracing, debugging and optimization checks.",
"url": "https://docs.python.org/3/library/dis.html#opcode-RESUME"
};
@@ -710,6 +731,13 @@ export function getAsmOpcode(opcode: string | undefined): AssemblyInstructionInf
"url": "https://docs.python.org/3/library/dis.html#opcode-SET_ADD"
};
+ case "SET_FUNCTION_ATTRIBUTE":
+ return {
+ "html": "
Sets an attribute on a function object. Expects the function at STACK[-1]\nand the attribute value to set at STACK[-2]; consumes both and leaves the\nfunction at STACK[-1]. The flag determines which attribute to set:
\n
\n
0x01 a tuple of default values for positional-only and\npositional-or-keyword parameters in positional order
\n
0x02 a dictionary of keyword-only parameters\u2019 default values
\n
0x04 a tuple of strings containing parameters\u2019 annotations
\n
0x08 a tuple containing cells for free variables, making a closure
\n
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Sets an attribute on a function object. Expects the function at STACK[-1]\nand the attribute value to set at STACK[-2]; consumes both and leaves the\nfunction at STACK[-1]. The flag determines which attribute to set",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-SET_FUNCTION_ATTRIBUTE"
+ };
+
case "SET_UPDATE":
return {
"html": "
Stores STACK.pop() into the local co_varnames[var_nums >> 4]\nand pushes a reference to the local co_varnames[var_nums & 15]\nonto the stack.
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Stores STACK.pop() into the local co_varnames[var_nums >> 4]\nand pushes a reference to the local co_varnames[var_nums & 15]\nonto the stack.",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-STORE_FAST_LOAD_FAST"
+ };
+
+ case "STORE_FAST_STORE_FAST":
+ return {
+ "html": "
Stores STACK[-1] into co_varnames[var_nums >> 4]\nand STACK[-2] into co_varnames[var_nums & 15].
\n\n
Added in version 3.13.
\n\n",
+ "tooltip": "Stores STACK[-1] into co_varnames[var_nums >> 4]\nand STACK[-2] into co_varnames[var_nums & 15].",
+ "url": "https://docs.python.org/3/library/dis.html#opcode-STORE_FAST_STORE_FAST"
+ };
+
case "STORE_GLOBAL":
return {
"html": "
Works as STORE_NAME, but stores the name as a global.
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Wait for Bulk Release Status Warp State",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "ACQSHMINIT":
+ return {
+ "html": "Wait for Shared Memory Initialization Release Status Warp State
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Wait for Shared Memory Initialization Release Status Warp State",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "ATOM":
return {
- "html": "Atomic Operation on Generic Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Atomic Operation on Generic Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "ATOMG":
return {
- "html": "Atomic Operation on Global Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Atomic Operation on Global Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "ATOMS":
return {
- "html": "Atomic Operation on Shared Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Barrier Synchronization",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "BFE":
- return {
- "html": "Bit Field Extract
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Bit Field Extract",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "BFI":
- return {
- "html": "Bit Field Insert
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Bit Field Insert",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "BGMMA":
return {
- "html": "Bit Matrix Multiply and Accumulate Across Warps
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Bit Matrix Multiply and Accumulate Across Warps",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "BMMA":
return {
- "html": "Bit Matrix Multiply and Accumulate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Relative Branch",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "BREAK":
return {
- "html": "Break out of the Specified Convergence Barrier
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Break out of the Specified Convergence Barrier",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "BREV":
return {
- "html": "Bit Reverse
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Relative Branch with Uniform Register Based Offset",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "BSSY":
return {
- "html": "Barrier Set Convergence Synchronization Point
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Barrier Set Convergence Synchronization Point",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "BSYNC":
return {
- "html": "Synchronize Threads on a Convergence Barrier
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "CGA Error Barrier",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
- case "CONT":
+ case "CREDUX":
return {
- "html": "Continue
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Continue",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "html": "Coupled Reduction of a Vector Register into a Uniform Register
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Coupled Reduction of a Vector Register into a Uniform Register",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "CS2R":
return {
- "html": "Move Special Register to Register
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Move Special Register to Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "CSET":
- return {
- "html": "Test Condition Code And Set
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Test Condition Code And Set",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
- case "CSETP":
+ case "CS2UR":
return {
- "html": "Test Condition Code and Set Predicate
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Test Condition Code and Set Predicate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "html": "Load a Value from Constant Memory into a Uniform Register
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Load a Value from Constant Memory into a Uniform Register",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "DADD":
return {
- "html": "FP64 Add
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP64 Multiply",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "DSET":
- return {
- "html": "FP64 Compare And Set
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "FP64 Compare And Set",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "DSETP":
return {
- "html": "FP64 Compare And Set Predicate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP64 Compare And Set Predicate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "ELECT":
return {
- "html": "Elect a Leader Thread
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Exit Program",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "F2F":
return {
- "html": "Floating Point To Floating Point Conversion
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Floating Point To Floating Point Conversion",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "F2I":
return {
- "html": "Floating Point To Integer Conversion
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Floating Point To Integer Conversion",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "F2IP":
return {
- "html": "FP32 Down-Convert to Integer and Pack
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP32 Add",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
- case "FCHK":
+ case "FADD32I":
return {
- "html": "Floating-point Range Check
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Floating-point Range Check",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "html": "FP32 Add
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "FP32 Add",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
- case "FCMP":
+ case "FCHK":
return {
- "html": "FP32 Compare to Zero and Select Source
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "FP32 Compare to Zero and Select Source",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "html": "Floating-point Range Check
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Floating-point Range Check",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "FENCE":
return {
- "html": "Memory Visibility Guarantee for Shared or Global Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Memory Visibility Guarantee for Shared or Global Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "FFMA":
return {
- "html": "FP32 Fused Multiply and Add
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP32 Fused Multiply and Add",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "FHADD":
+ return {
+ "html": "FP32 Addition
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "FP32 Addition",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "FHFMA":
+ return {
+ "html": "FP32 Fused Multiply and Add
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "FP32 Fused Multiply and Add",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "FLO":
return {
- "html": "Find Leading One
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Round To Integer",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "FSEL":
return {
- "html": "Floating Point Select
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Floating Point Select",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "FSET":
return {
- "html": "FP32 Compare And Set
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP32 Compare And Set",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "FSETP":
return {
- "html": "FP32 Compare And Set Predicate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Get Local Memory Base Address",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "HADD2":
return {
- "html": "FP16 Add
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP16 Fused Mutiply Add",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "HGMMA":
return {
- "html": "Matrix Multiply and Accumulate Across a Warpgroup
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Matrix Multiply and Accumulate Across a Warpgroup",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "HMMA":
return {
- "html": "Matrix Multiply and Accumulate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP16 Multiply",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "HSET2":
return {
- "html": "FP16 Compare And Set
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP16 Compare And Set",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "HSETP2":
return {
- "html": "FP16 Compare And Set Predicate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP16 Compare And Set Predicate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "I2F":
return {
- "html": "Integer To Floating Point Conversion
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Integer To Floating Point Conversion",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "I2FP":
return {
- "html": "Integer to FP32 Convert and Pack
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Integer to FP32 Convert and Pack",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "I2I":
return {
- "html": "Integer To Integer Conversion
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Integer To Integer Conversion",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "I2IP":
return {
- "html": "Integer To Integer Conversion and Packing
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Integer To Integer Conversion and Packing",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "IABS":
return {
- "html": "Integer Absolute Value
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Integer Addition",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "ICMP":
- return {
- "html": "Integer Compare to Zero and Select Source
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Integer Compare to Zero and Select Source",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "IDP":
return {
- "html": "Integer Dot Product and Accumulate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Integer Dot Product and Accumulate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "IGMMA":
return {
- "html": "Integer Matrix Multiply and Accumulate Across a Warpgroup
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Integer Matrix Multiply and Accumulate Across a Warpgroup",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "IMAD":
return {
- "html": "Integer Multiply And Add
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Scaled Integer Addition",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "ISET":
- return {
- "html": "Integer Compare And Set
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Integer Compare And Set",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "ISETP":
return {
- "html": "Integer Compare And Set Predicate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Load Constant",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "LDCU":
+ return {
+ "html": "Load a Value from Constant Memory into a Uniform Register
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Load a Value from Constant Memory into a Uniform Register",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "LDG":
return {
- "html": "Load from Global Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Reducing Load",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "LDGSTS":
return {
- "html": "Asynchronous Global to Shared Memcopy
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Asynchronous Global to Shared Memcopy",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "LDL":
return {
- "html": "Load within Local Memory Window
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Load within Local Memory Window",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "LDS":
return {
- "html": "Load within Shared Memory Window
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Load within Shared Memory Window",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "LDSM":
return {
- "html": "Load Matrix from Shared Memory with Element Size Expansion
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Load Matrix from Shared Memory with Element Size Expansion",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "LDT":
+ return {
+ "html": "Load Matrix from Tensor Memory to Register File
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Load Matrix from Tensor Memory to Register File",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "LDTM":
+ return {
+ "html": "Load Matrix from Tensor Memory to Register File
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Load Matrix from Tensor Memory to Register File",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "LEA":
return {
- "html": "LOAD Effective Address
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Move",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "MOVM":
return {
- "html": "Move Matrix with Transposition or Expansion
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Move Matrix with Transposition or Expansion",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "MUFU":
return {
- "html": "FP32 Multi Function Operation
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP32 Multi Function Operation",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "NANOSLEEP":
return {
- "html": "Suspend Execution
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "No Operation",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "P2R":
- return {
- "html": "Move Predicate Register To Register
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Move Predicate Register To Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
- case "PBK":
+ case "OMMA":
return {
- "html": "Pre-Break
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Pre-Break",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "html": "FP4 Matrix Multiply and Accumulate Across a Warp
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "FP4 Matrix Multiply and Accumulate Across a Warp",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
- case "PCNT":
- return {
- "html": "Pre-continue
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Pre-continue",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "PEXIT":
+ case "P2R":
return {
- "html": "Pre-Exit
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Pre-Exit",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "html": "Move Predicate Register To Register
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Move Predicate Register To Register",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "PLOP3":
return {
- "html": "Predicate Logic Operation
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Permute Register Pair",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "PSET":
- return {
- "html": "Combine Predicates and Set
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Combine Predicates and Set",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "PSETP":
return {
- "html": "Combine Predicates and Set Predicate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Combine Predicates and Set Predicate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "QGMMA":
return {
- "html": "FP8 Matrix Multiply and Accumulate Across a Warpgroup
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "FP8 Matrix Multiply and Accumulate Across a Warpgroup",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "QMMA":
+ return {
+ "html": "FP8 Matrix Multiply and Accumulate Across a Warp
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "FP8 Matrix Multiply and Accumulate Across a Warp",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "QSPC":
return {
- "html": "Query Space
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Move Register To Predicate Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "R2UR":
return {
- "html": "Move from Vector Register to a Uniform Register
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Move from Vector Register to a Uniform Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "RED":
return {
- "html": "Reduction Operation on Generic Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Reduction Operation on Generic Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "REDAS":
return {
- "html": "Asynchronous Reduction on Distributed Shared Memory With Explicit Synchronization
For more information, visit CUDA Binary Utilities documentation .",
+ "html": "Asynchronous Reduction on Distributed Shared Memory With Explicit Synchronization
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Asynchronous Reduction on Distributed Shared Memory With Explicit Synchronization",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "REDG":
return {
- "html": "Reduction Operation on Generic Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Reduction Operation on Generic Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "REDUX":
return {
- "html": "Reduction of a Vector Register into a Uniform Register
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Reduction of a Vector Register into a Uniform Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "RET":
return {
- "html": "Return From Subroutine
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Return From Trap",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "S2R":
return {
- "html": "Move Special Register to Register
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Move Special Register to Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "S2UR":
return {
- "html": "Move Special Register to Uniform Register
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Move Special Register to Uniform Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "SEL":
return {
- "html": "Select Source with Predicate
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Select Source with Predicate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "SETCTAID":
return {
- "html": "Set CTA ID
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Set Local Memory Base Address",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "SGXT":
return {
- "html": "Sign Extend
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Store to Generic Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "STAS":
return {
- "html": "Asynchronous Store to Distributed Shared Memory With Explicit Synchronization
For more information, visit CUDA Binary Utilities documentation .",
+ "html": "Asynchronous Store to Distributed Shared Memory With Explicit Synchronization
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Asynchronous Store to Distributed Shared Memory With Explicit Synchronization",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "STG":
return {
- "html": "Store to Global Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Store to Global Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "STL":
return {
- "html": "Store to Local Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Store to Local Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "STS":
return {
- "html": "Store to Shared Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Store Matrix to Shared Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "STT":
+ return {
+ "html": "Store Matrix to Tensor Memory from Register File
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Store Matrix to Tensor Memory from Register File",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "STTM":
+ return {
+ "html": "Store Matrix to Tensor Memory from Register File
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Store Matrix to Tensor Memory from Register File",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "SUATOM":
return {
- "html": "Atomic Op on Surface Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Atomic Op on Surface Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "SULD":
return {
- "html": "Surface Load
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Surface Load",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "SURED":
return {
- "html": "Reduction Op on Surface Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Reduction Op on Surface Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "SUST":
return {
- "html": "Surface Store
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Bulk Data Copy",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UBLKPF":
return {
- "html": "Bulk Data Prefetch
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Bulk Data Prefetch",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UBLKRED":
return {
- "html": "Bulk Data Copy from Shared Memory with Reduction
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Bulk Data Copy from Shared Memory with Reduction",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UBMSK":
return {
- "html": "Uniform Bitfield Mask
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Uniform FP32 Down-convert and Pack",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UF2I":
+ return {
+ "html": "Uniform Float-to-Integer Conversion
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Float-to-Integer Conversion",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UF2IP":
+ return {
+ "html": "Uniform FP32 Down-Convert to Integer and Pack
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform FP32 Down-Convert to Integer and Pack",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFADD":
+ return {
+ "html": "Uniform Uniform FP32 Addition
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Uniform FP32 Addition",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFFMA":
+ return {
+ "html": "Uniform FP32 Fused Multiply-Add
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform FP32 Fused Multiply-Add",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UFLO":
return {
- "html": "Uniform Find Leading One
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Uniform Find Leading One",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFMNMX":
+ return {
+ "html": "Uniform Floating-point Minimum / Maximum
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Floating-point Minimum / Maximum",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFMUL":
+ return {
+ "html": "Uniform FP32 Multiply
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform FP32 Multiply",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFRND":
+ return {
+ "html": "Uniform Round to Integer
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Round to Integer",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFSEL":
+ return {
+ "html": "Uniform Floating-Point Select
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Floating-Point Select",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFSET":
+ return {
+ "html": "Uniform Floating-Point Compare and Set
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Floating-Point Compare and Set",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UFSETP":
+ return {
+ "html": "Uniform Floating-Point Compare and Set Predicate
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Floating-Point Compare and Set Predicate",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UGETNEXTWORKID":
+ return {
+ "html": "Uniform Get Next Work ID
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Get Next Work ID",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UI2F":
+ return {
+ "html": "Uniform Integer to Float conversion
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Integer to Float conversion",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UI2FP":
+ return {
+ "html": "Uniform Integer to FP32 Convert and Pack
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Integer to FP32 Convert and Pack",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UI2I":
+ return {
+ "html": "Uniform Saturating Integer-to-Integer Conversion
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Saturating Integer-to-Integer Conversion",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UI2IP":
+ return {
+ "html": "Uniform Dual Saturating Integer-to-Integer Conversion and Packing
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Dual Saturating Integer-to-Integer Conversion and Packing",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UIABS":
+ return {
+ "html": "Uniform Integer Absolute Value
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Integer Absolute Value",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UIADD3":
return {
- "html": "Uniform Integer Addition
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Uniform Integer Multiplication",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UIMNMX":
+ return {
+ "html": "Uniform Integer Minimum / Maximum
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Integer Minimum / Maximum",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UISETP":
return {
- "html": "Integer Compare and Set Uniform Predicate
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Integer Compare and Set Uniform Predicate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "html": "Uniform Integer Compare and Set Uniform Predicate
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Integer Compare and Set Uniform Predicate",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "ULDC":
return {
- "html": "Load from Constant Memory into a Uniform Register
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Load from Constant Memory into a Uniform Register",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "ULEA":
return {
- "html": "Uniform Load Effective Address
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Uniform Register to Uniform Predicate",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UREDGR":
+ return {
+ "html": "Uniform Reduction on Global Memory with Release
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Reduction on Global Memory with Release",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "USEL":
return {
- "html": "Uniform Select
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Uniform Left Shift",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "USHR":
return {
- "html": "Uniform Right Shift
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Uniform Right Shift",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "USTGR":
+ return {
+ "html": "Uniform Store to Global Memory with Release
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Store to Global Memory with Release",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCATOMSWS":
+ return {
+ "html": "Perform Atomic operation on SW State Register
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Perform Atomic operation on SW State Register",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCBAR":
+ return {
+ "html": "Tensor Core Barrier
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Tensor Core Barrier",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCCP":
+ return {
+ "html": "Asynchonous data copy from Shared Memory to Tensor Memory
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Asynchonous data copy from Shared Memory to Tensor Memory",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCHMMA":
+ return {
+ "html": "Uniform Matrix Multiply and Accumulate
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Matrix Multiply and Accumulate",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCIMMA":
+ return {
+ "html": "Uniform Matrix Multiply and Accumulate
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Matrix Multiply and Accumulate",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCOMMA":
+ return {
+ "html": "Uniform Matrix Multiply and Accumulate
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Matrix Multiply and Accumulate",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCQMMA":
+ return {
+ "html": "Uniform Matrix Multiply and Accumulate
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform Matrix Multiply and Accumulate",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UTCSHIFT":
+ return {
+ "html": "Shift elements in Tensor Memory
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Shift elements in Tensor Memory",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UTMACCTL":
return {
- "html": "TMA Cache Control
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "TMA Command Flush",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UTMALDG":
return {
- "html": "Tensor Load from Global to Shared Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Tensor Load from Global to Shared Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UTMAPF":
return {
- "html": "Tensor Prefetch
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Tensor Prefetch",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UTMAREDG":
return {
- "html": "Tensor Store from Shared to Global Memory with Reduction
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Tensor Store from Shared to Global Memory with Reduction",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "UTMASTG":
return {
- "html": "Tensor Store from Shared to Global Memory
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Tensor Store from Shared to Global Memory",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UVIADD":
+ return {
+ "html": "Uniform SIMD Integer Addition
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform SIMD Integer Addition",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UVIMNMX":
+ return {
+ "html": "Uniform SIMD Integer Minimum / Maximum
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Uniform SIMD Integer Minimum / Maximum",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
+ };
+
+ case "UVIRTCOUNT":
+ return {
+ "html": "Virtual Resource Management
For more information, visit CUDA Binary Utilities documentation .",
+ "tooltip": "Virtual Resource Management",
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "VABSDIFF":
return {
- "html": "Absolute Difference
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Vote Across SIMT Thread Group",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "VOTEU":
return {
- "html": "Voting across SIMD Thread Group with Results in Uniform Destination
For more information, visit CUDA Binary Utilities documentation .",
+ "html": "Voting across SIMD Thread Group with Results in Uniform Destination
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Voting across SIMD Thread Group with Results in Uniform Destination",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "WARPGROUP":
return {
- "html": "Warpgroup Synchronization
For more information, visit CUDA Binary Utilities documentation .",
"tooltip": "Synchronize Threads in Warp",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
- };
-
- case "XMAD":
- return {
- "html": "Integer Short Multiply Add
For more information, visit CUDA Binary Utilities documentation .",
- "tooltip": "Integer Short Multiply Add",
- "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#id14"
+ "url": "https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference"
};
case "YIELD":
return {
- "html": "Yield Control