Template talk:Instruction set extensions

remove SSE5?

The SSE5 instruction set was proposed by AMD, but they changed it to XOP for the sake of compatibility with AVX. SSE5 has thus never been implemented and never will. Should SSE5 be removed from the list? Afog (talk) 08:00, 8 June 2009 (UTC)[reply]

from a historical perspecive, no. wikipedia is not just about what is, but also what was. Lkcl (talk) 12:02, 10 August 2025 (UTC)[reply]

Separate list for AMD-only instructions?

3DNow, XOP and CVT16 are/will be implemented only in AMD processors. The rest are/will be implemented in both Intel, AMD and possibly other processors. It is uncertain whether FMA4 will be supported by Intel. It is possible that part of XOP will be supported by Intel in the future if it becomes popular. Should the list reflect which instruction sets are for AMD only, or will that make the template too big and confusing? Afog (talk) 08:00, 8 June 2009 (UTC)[reply]

I think 3DNow! was also implemented by Cyrix, IDT, and VIA. I don't really mind how the x86 instruction sets are organized. Rilak (talk) 13:17, 9 June 2009 (UTC)[reply]

Is it me or is the text for 3dNow a bit screwed up? Andrewhime (talk) 08:25, 12 April 2011 (UTC)[reply]

Can we separate instruction set nomenclature by colour coded between Intel, AMD and both? Rjluna2 (talk) 20:39, 19 June 2015 (UTC)[reply]

delete and recreate

I would delete this article and create a new one named "Instruction set Extensions"; there I would include all available Extensions to the known Instruction sets, especially AES-NI, Transactional_Synchronization_Extensions, VT-d, VT-x, Marvell CESA, Via Padlock, EIST, etc. Semsi Paco Virchow (talk) 07:00, 5 July 2013 (UTC)[reply]

delete destroys the history, a rename is needed (dne). big bit of work, now every page on the entire list needs review! Lkcl (talk) 10:38, 10 August 2025 (UTC)[reply]

done, gaah :) Lkcl (talk) 12:03, 10 August 2025 (UTC)[reply]

instructions in x86 versus instructions in extensions

Can anybody tell me, where I find a comparison of the existent instructions in x86 versus all the ones added by extensions? Semsi Paco Virchow (talk) 07:01, 5 July 2013 (UTC)[reply]

RISC formatting

I don't really like the PA-RISC (MAX) format; it seems like MAX (PA-RISC) would make more sense. Do any wiki formatting wizards know how to make that change? Do people agree with it? Risc64 (talk) 16:25, 4 June 2016 (UTC)[reply]

Scope

This template used to provide navigation between a strongly related set of articles about extensions to ISAs for multimedia. This was very useful because all its members were about the same specific topic. This template was later broadened in scope to include every kind of ISA extension. This is much less useful because it gives users information that isn't relevant: for any type of ISA extension a user is interested in, the user is provided with every other type of ISA extension. There's no need to have such a general scope when navigation templates for each type of ISA extension can be created so easily. This template should be restored to its original scope. The navigation for other types of ISA extensions should be handled separately. 50504F (talk) 10:29, 28 May 2017 (UTC)[reply]

yeah that was a big mistake. Lkcl (talk) 10:39, 10 August 2025 (UTC)[reply]

SuperH

I added SuperH to Compressed Instructions. This is not a mistake. I am explaining here because someone thought it was a mistake and decided to undo my edit.
The fact that SH2 had only 16bit instructions and had them from the beginning doesn't mean that they were not compressed.
SH2 is a 32bit RISC CPU that has 16bit instructions. In other words all instructions are compressed.
This is exactly what we have in micro-controllers that support only THUMB instruction set. They support only 16 bit instructions and support them from the beginning right?
But they are compressed because the core architecture is 32bit. Dawzab (talk) 20:13, 8 July 2020 (UTC)[reply]

Please could you explain why they are compressed? For instance, in THUMB, the base instruction set (ARM) is expressed on 32 bits, and the instructions are re-encoded on 16 bits (i.e. a compression), with a subset of the features. Do you have some source mentioning that they are compressed instructions?

Moreover, the template is for "Multimedia extensions". Thus, since the instructions are on 16 bits since the beginning, I don't see how this can be an extension. An extension is some additional feature that comes later. Vincent Lefèvre (talk) 20:33, 8 July 2020 (UTC)[reply]

This is probably the main difference between THUMB and SH, THUMB is not only available at it's own, but also as an extension to standard ARM ISA. In this aspect SH might not seem compressed because you do not have uncompressed counterpart to compare it with. It is compressed in the sense that it's internal structure is compressed. CPU has to decode these 16bit instructions into 32-bit instructions, so that they can be processed in 32-bit pipeline of 32-bit processor. This internal mechanism is exactly the same in all mentioned compressed instructions - Thumb , MIPS16 and Compressed Risc V ,they all need to be "unpacked".

SuperH architects "extended" traditional RISC CPU with additional "decoder" and compressed all SH2 instructions to increase performance.

I admit you are right that this ISA is technically not an extension (since 16bit instructions were available from the beginning), and template is about extensions. I am not sure how this should be treated, since it is a comparable feature, only present in the base ISA and not added later. It's a little bit about "marketing" and "catch words".

SH4 CPU that was used in Dreamcast had these compressed instructions from the very beginning available without mode change, and idea that others used and added to their designs as an "extension". At the time it was superior, because it had this feature right from the start.

I still feel that it belongs here, but now I understand your point why you believe it doesn't. What seemed a technological, scientific dilemma now seems more like philosophical one: Can we still call it an extension if this extension was obligatory for all ISA versions? Can we say that CPU supports "compression extension" if most of uncompressed instructions are deliberately disabled for performance reasons, and therefore compression extension is obligatory? Dawzab (talk) 21:45, 8 July 2020 (UTC)[reply]

"CPU has to decode these 16bit instructions into 32-bit instructions, so that they can be processed in 32-bit pipeline of 32-bit processor." does not make much sense since a 16-bit instruction fits in 32 bits, thus can be processed in a 32-bit pipeline. Concerning ARM, it has a 32-bit instruction set, and that's why a 16-bit Thumb instruction is decompressed to a 32-bit ARM instruction: "On execution, 16-bit Thumb instructions are transparently decompressed to full 32-bit ARM instructions in real time, without performance loss" (i.e. in the decompression, the width is doubled). I don't see why SuperH would do the same kind of thing since it only had a 16-bit instruction set. If you mean that two 16-bit instructions need to be put in a 32-bit word because SuperH is a 32-bit processor, then that's completely different; it's more like VLIW. And this has nothing to do with compression. Vincent Lefèvre (talk) 00:55, 13 July 2020 (UTC)[reply]

ah - it's a mistake but it isn't. the data and instruction fetch width buses being 32 bit has NOTHING to do with the INSTRUCTION width. this is an easy conflation to make. i am designing an 8-bit ISA that does 64-bit data, 64 bit ALU, 64 bit memory addressing. it is *NOT* an 8-bit processor. see the distinction? that said: the fact that it is an example of 16bit encoding, next to others? yeah you get away with that imo. it's a good enough grey area :) Lkcl (talk) 12:01, 10 August 2025 (UTC)[reply]

okaaay.... mistsake made in naming

there has been a conflation, identical to the one i sorted out for Bit manipulation instruction set between "ISA extensions" and "Multimedia ISA extensions". the *entire lot* is actually a really good "ISA extension" categorisation. Multimedia includes *only* SSE, MMX, VIS, MIPS-3D-ASE (which hasn't been added) etc. argh :) Lkcl (talk) 09:46, 10 August 2025 (UTC)[reply]

nope it does, spotted 3DASE Lkcl (talk) 10:06, 10 August 2025 (UTC)[reply]

done, renamed. Lkcl (talk) 10:37, 10 August 2025 (UTC)[reply]

OOF. big addition of new category done. bit of a mess. still not sure about including duplicate categories. in OO terms isa extensions inherits from multimedia extensions. Lkcl (talk) 11:56, 10 August 2025 (UTC)[reply]

"Multimedia" is incorrect

@Lkcl: I see that you have done lots of changes, and I agree that "multimedia" was misused, but this is still the case for the remaining table titled "Multimedia Instruction set extensions", at least for the extensions SSE2 and FMA for x86 (I don't know the other ones). Just like the original instructions of the CPU, these are general floating-point instructions, used to implement the IEEE 754 standard (replacing the legacy x87 instruction set, which was problematic); they are not specific to multimedia. I suspect that "multimedia" was mainly marketing in the past, and in any case, there is nothing technical behind this word. The articles on these extensions do not even mention "multimedia".

Even the term "SIMD" can be misleading: these instructions support SIMD, but they are also used in usual non-vector floating-point code for the binary32 (single precision) and binary64 (double precision) IEEE 754 formats. So on x86_64, these instructions will always be used for the arithmetic operations on the float and double data types in C (even non-vector code).

Perhaps for the title of this table, "Multimedia" should be replaced by "SIMD-capable", and the redundant "SIMD" could be removed from the first column.

Regards, — Vincent Lefèvre (talk) 09:36, 11 August 2025 (UTC)[reply]

hi vincent give me some time to think it through - i can think of one straight away that is not SIMD, not all of it: MIPS-3D-ASE which has FP-compare-abs, and the FP-reciprocal pair of instructions are scalar as well. so it's all a bit of a mess, *but*, categorised all as "multimedia". re FP32 and FP64, yes, GPUs do need that. some standardised Vulkan API calls *including pixel* normalisation particularly blue-shade compensation *requires* FP32! yes, FMA is touted as "an extension to SSE" so... yeah it's a mess, but at least with cryptography, virtualisation etc removed it is a step forward Lkcl (talk) 10:32, 11 August 2025 (UTC)[reply]

Note that floating point is not just used for multimedia, but for many domains: graphic rendering (including text: font rendering), web browsers (e.g. JavaScript/ECMAScript and XPath are based on binary64), video games, high-performance computing, and so on. Instead of saying what these instructions are used for, one should say what these instructions provides from a technical point of view.

Concerning the fused multiply–add operation (specified by the IEEE 754 standard since 2008), this is a floating-point operation that was missing in the x86 architecture. Since the x87 instruction set is now more or less obsolete, as being replaced by SSE2 (where double precision was introduced compared to the first SSE version), this operation was added on top of SSE2 (according to FMA instruction set, both single and double precisions are supported).

— Vincent Lefèvre (talk) 16:27, 11 August 2025 (UTC)[reply]