Template talk:Multimedia 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)

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)

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)

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

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

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)

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)

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)

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)

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)

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)

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)

"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)