Scalar Cryptography v1.0.0-rc1. Opcodes changing of aes32* instructions.

[bulat242]

I would like to discuss an opportunity for opcodes changing of aes32* instructions. After opcodes changing of aes32* instructions (because of overlapping with aes64*) initial decoding strategy for K-extension was modified. Now it is necessary to use more bits to distinguish K-extension and other extensions.

Is it possible to change other bit(-s) instead of 28-th bit's changing for aes32* instructions? This helps to keep decoding strategy for K-extension, when 28-th bit is always set, funct3 is 000 or 001 and opcode is 0010011 or 0110011 (for aes32* instruction), that allows to use less bits to distinguish K-extension and other extensions and requires less logic in decoder unit.

[ben-marshall]

I think this sort of change is hard to make now the specification is frozen unless a very good case for it can be made. I appreciate the encodings don't quite go with the original rationale any more. They had to be changed I think to avoid colliding with other extensions, and based on some other feedback we had.

Do you have an example encoding you would suggest instead of the current ones?

[bulat242]

I don't know which intentions have the developers of cryptography extensions about funct3-field and my proposal might won't fit in these intentions. To my mind 28-th bit can be used for differing K-extension and all other and some bit in field funct3 may be changed, i.e. funct3 = 100 or 011 (for instructions, that have "bs"-field: sm3*, sm4*, aes32*).

[kdockser]

This is for the Scalar Crypto specification which has been can closed and ratified. No more changes of this sort can be made.