Operand size description within the specification is vague.

[m-kru]

Operand size description within the specification is vague. How does it relate with the port size? What is the point of the operand size? Why having both operand size and port size? I doubt anyone can answer these questions solely after reading the specification and not referring back to the history.

All snippets come from the current B3.1 if not specified otherwise.

Page 15

Page 15

Page 16

Page 22

Page 47

Revision B4, page 101:

1. All snippets except the one from the page 22 suggest that: operand size >= port size >= granularity. The one from page 22 suggests that the operand size can be smaller than the port size.
2. Nowhere in the specification one can find what is the point of the operand size? Why having both the operand size and the port size? I can think of an architecture 20 years ago where the operand size was indeed greater than the port size and transferring single operand required more than one transfer. However, do we still have such use cases today? I think it is rather the other way. Today the operand size is rather smaller than the port size, and such case is already handled by the granularity and SEL_O().
3. Operand size definition. "largest single unit of data" defined by who/what? One can always do one transfer more and have "largest single unit of data + 1".

I think the operand size concept should be reworked. It either should be improved to leave no room for guesses or it should be removed.

Personally I would try to remove the concept of the operand from the specification. The operand has nothing to do with the bus itself (except the fact that it is transferred via it). How long is the operand is always determined by the entity capable of doing an operation on the operand. Whether it is longer or shorter than the port size is irrelevant as long as the bus supports multiple transfers or selection. Even if the selection is not supported, the operating entity can always mask.

[rherveille]

The spec seems pretty clear to me. A 256bit signal (operand) can be moved through a 32bit interface (port width) with a minimum with of 8bits (granularity) And yes, operand >= port size >= granularity. I worked on cores that took 32kB data (operand) through a 256bit port while working on 32bits (granularity). Richard On 18 Sep 2021, at 10:28, m-kru ***@***.***> wrote:  Operand size description within the specification is vague. How does it relate with the port size? What is the point of the operand size? Why having both operand size and port size? I doubt anyone can answer these questions solely after reading the specification and not referring back to the history. All snippets come from the current B3.1 if not specified otherwise. Page 15 [image]<https://user-images.githubusercontent.com/26227737/133880731-47a70fc2-a510-4f0b-8c43-1bbc035fc94d.png> Page 15 [image]<https://user-images.githubusercontent.com/26227737/133880711-8c0b9e30-0aab-43bd-9b4c-0576b8088253.png> Page 16 [image]<https://user-images.githubusercontent.com/26227737/133880744-ec72abbf-2c06-4b07-846d-b0b34936161d.png> Page 22 [image]<https://user-images.githubusercontent.com/26227737/133880666-9668c8d6-60aa-4d21-9112-24ff6b76db27.png> Page 47 [image]<https://user-images.githubusercontent.com/26227737/133881290-e76ab0fb-2aaa-46b2-9fc3-54832df3fc45.png> Revision B4, page 101: [image]<https://user-images.githubusercontent.com/26227737/133881754-8d9442f2-60e6-4651-9e8e-597bfc9a9bb2.png> 1. All snippets except the one from the page 22 suggest that: operand size >= port size >= granularity. The one from page 22 suggests that the operand size can be smaller than the port size. 2. Nowhere in the specification one can find what is the point of the operand size? Why having both the operand size and the port size? I can think of an architecture 20 years ago where the operand size was indeed greater than the port size and transferring single operand required more than one transfer. However, do we still have such use cases today? I think it is rather the other way. Today the operand size is rather smaller than the port size, and such case is already handled by the granularity and SEL_O(). 3. Operand size definition. "largest single unit of data" defined by who/what? One can always do one transfer more and have "largest single unit of data + 1". I think the operand size concept should be reworked. It either should be improved to leave no room for guesses or it should be removed. Personally I would try to remove the concept of the operand from the specification. The operand has nothing to do with the bus itself (except the fact that it is transferred via it). How long is the operand is always determined by the entity capable of doing an operation on the operand. Whether it is longer or shorter than the port size is irrelevant as long as the bus supports multiple transfers or selection. Even if the selection is not supported, the operating entity can always mask. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#22>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADYKSCKWMVAORS7LRBUD3YTUCRERRANCNFSM5EI6Y4TQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[m-kru]

And yes, operand >= port size >= granularity.

Then isn't there a mistake in the point number 9 on page 22?

Should not it be:

If the maximum operand size is unknown, then the maximum operand size shall be the same as the port size.

Instead of:

If the maximum operand size is unknown, then the maximum operand size shall be the same as the granularity.