Zero and sign extension of pack.h vs pack.w

[RogierBrussee]

The pack.h instruction zero extends while the pack.w instruction sign extends.
Because the instructions are simple and otherwise very similar, maybe for ease of reference this should be mentioned in the synopsis (it is already mentioned in the description).

Arguably it would be less confusing if pack.h would be renamed pack.hu

(Same issue as #160 on the bitmanip GitHub)

[ben-marshall]

I'm happy adding a note to the synopsis to each instruction if that'd make things clearer. These instructions & their names were originally defined by the bitmanip task group so we are inheriting any oddities like this.

(riscv/riscv-bitmanip#160)

[RogierBrussee]

Thanks Ben! As for the naming: Bitmanip has proved to be a slow process and it seems that it is going to be sliced up in different Xb* extensions. The Zbk cryptography extension seems the first to use the PACK.* instructions so you may be able to set the definitive name. But I raised the same issue at bitmanip as well. Incidentally, the more precise naming does suggest instructions PACK.H (which packs bytes and sign extend) and PACK.WU (which packs halfwords and zero extends). Whether they are worth it, not to mention a good idea at this stage in the process, is entirely another matter of course. I think the current instructions come from the convention of having uint16_t represented by a zero extended halfword but uint32_t being represented as sign extended. I _think_ that Claire Wolfe also checked that a struct foo {uint16_t first; uint16_t second} or struct RGBA{uint8_t R,G,B, A} can be constructed in a register using pack and that it is OK that these values are sign extended because upper 32 bits are ignored in the calling convention. Rogier

…

On Wed, Sep 8, 2021 at 11:36 AM Ben Marshall ***@***.***> wrote: I'm happy adding a note to the synopsis to each instruction if that'd make things clearer. These instructions & their names were originally defined by the bitmanip task group so we are inheriting any oddities like this. (riscv/riscv-bitmanip#160 <riscv/riscv-bitmanip#160>) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR7SWUJ4ISOTQY7J4ZIUBILUA4VC5ANCNFSM5DNJOL6Q> . 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>.

[kdockser]

This comment was for the Scalar Crypto extension which has been finalized and ratified. No changes of this type may be made at this time.

[RogierBrussee]

Yes this ship has sailed. But I made the comment during the ratification phase. Thanx

…

On Sun, Oct 30, 2022 at 12:28 AM Ken Dockser ***@***.***> wrote: Closed #125 <#125> as completed. — Reply to this email directly, view it on GitHub <#125 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR7SWUNJADHSGG7DA7IMG73WFWQHZANCNFSM5DNJOL6Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kdockser]

Sorry, I didn't mean to imply that your comment was late. I was in the process of cleaning out old issues and was just concentrating on whether or not there was something that we need to do at the current time.

Thanks,
ken