{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":651719372,"defaultBranch":"master","name":"riscv-c-api-doc","ownerLogin":"topperc","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-06-09T22:44:17.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/22566570?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1701279509.0","currentOid":""},"activityList":{"items":[{"before":"092156011d3d461f4caf3f0f0533c4ac57d5860f","after":"dca18de729b722ff5292dccc1c68c5866790d3bf","ref":"refs/heads/patch-1","pushedAt":"2024-06-24T22:37:21.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"fixup! fix typo","shortMessageHtmlLink":"fixup! fix typo"}},{"before":"d7941a51007564239f372be0599a8fb64989261f","after":"092156011d3d461f4caf3f0f0533c4ac57d5860f","ref":"refs/heads/patch-1","pushedAt":"2024-06-10T18:25:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Update __riscv_misaligned_* macros to refer to scalar only\n\nThis seems to the direction we're moving -mstrict-align/-mno-strict-align towards.\n\nSigned-off-by: Craig Topper ","shortMessageHtmlLink":"Update __riscv_misaligned_* macros to refer to scalar only"}},{"before":null,"after":"2cc606c1f8b3d9c69db8bdb21fd09ec59328816c","ref":"refs/heads/pr/sha512sum","pushedAt":"2023-11-29T17:38:29.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Fix the __riscv_sha512sum0/1 intrinsics for RV32.\n\nThese should be __riscv_sha512sum0r and __riscv_sha512sum1r. There\nare only 2 instructions not 4.","shortMessageHtmlLink":"Fix the __riscv_sha512sum0/1 intrinsics for RV32."}},{"before":"16d740abfa9494ff7edb8e06cf5b3db3f84e4b4b","after":"16c846610cbabbfaf8a895fffad03b080fbcb201","ref":"refs/heads/master","pushedAt":"2023-11-29T17:29:32.000Z","pushType":"push","commitsCount":18,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Add support for RV64E and LP64E\n\n`__riscv_64e` is defined analogously to `__riscv_32e`.\n\nChanging the meaning of `__riscv_32e` should not cause any problems\nsince if we are just testing for existence of the `E` extension,\nthere is `__riscv_e` preprocessor macro.","shortMessageHtmlLink":"Add support for RV64E and LP64E"}},{"before":"f1791e04db8f61c0a65483153b12c9117ff95ec4","after":"56bea0832722282b52123edf9f620c986524cb70","ref":"refs/heads/crypto-api","pushedAt":"2023-10-31T03:13:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Remove implementation guarantees for crypto intrinsics.","shortMessageHtmlLink":"Remove implementation guarantees for crypto intrinsics."}},{"before":"c637e6322a3f509a865aa40865e3a17ed1d90770","after":"16d740abfa9494ff7edb8e06cf5b3db3f84e4b4b","ref":"refs/heads/master","pushedAt":"2023-10-31T03:10:10.000Z","pushType":"push","commitsCount":14,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Merge pull request #45 from kito-cheng/operand-modifiers\n\nDocument operand modifier","shortMessageHtmlLink":"Merge pull request riscv-non-isa#45 from kito-cheng/operand-modifiers"}},{"before":"83b62d0d530f883b7185e377365df3c16d1f7758","after":"f1791e04db8f61c0a65483153b12c9117ff95ec4","ref":"refs/heads/crypto-api","pushedAt":"2023-08-22T00:16:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Remove implementation guarantees for crypto intrinsics.","shortMessageHtmlLink":"Remove implementation guarantees for crypto intrinsics."}},{"before":"2082c53240b539ca48278b4458d86b94deff2900","after":"83b62d0d530f883b7185e377365df3c16d1f7758","ref":"refs/heads/crypto-api","pushedAt":"2023-08-02T05:01:45.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Fix copy paste mistake","shortMessageHtmlLink":"Fix copy paste mistake"}},{"before":"8ffd6f66064dd545e6537a6b3251339c66d85be5","after":"2082c53240b539ca48278b4458d86b94deff2900","ref":"refs/heads/crypto-api","pushedAt":"2023-08-01T23:16:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Add riscv_bitmanip.h. Add Zbb instrinsics. Split crypto and bitmanip.","shortMessageHtmlLink":"Add riscv_bitmanip.h. Add Zbb instrinsics. Split crypto and bitmanip."}},{"before":"6ea26a1598e314efe1562667a350a3b62b5815a6","after":"8ffd6f66064dd545e6537a6b3251339c66d85be5","ref":"refs/heads/crypto-api","pushedAt":"2023-07-18T19:37:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics proposal\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.\n\nOne open question is whether we should emulate 64-bit intrinsics on RV32\nwhere it is feasible. This could be useful for the sha512 intrinsics\nand some others.","shortMessageHtmlLink":"Scalar crypto intrinsics proposal"}},{"before":"991f7263717a4ed8929f56896df02229d1d6b024","after":"6ea26a1598e314efe1562667a350a3b62b5815a6","ref":"refs/heads/crypto-api","pushedAt":"2023-07-18T19:19:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics proposal\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.\n\nOne open question is whether we should emulate 64-bit intrinsics on RV32\nwhere it is feasible. This could be useful for the sha512 intrinsics\nand some others.","shortMessageHtmlLink":"Scalar crypto intrinsics proposal"}},{"before":"a8694de98daa5f65e22e7b337ac13a8a2f62fdfc","after":"991f7263717a4ed8929f56896df02229d1d6b024","ref":"refs/heads/crypto-api","pushedAt":"2023-07-15T01:35:18.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics proposal\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.\n\nOne open question is whether we should emulate 64-bit intrinsics on RV32\nwhere it is feasible. This could be useful for the sha512 intrinsics\nand some others.","shortMessageHtmlLink":"Scalar crypto intrinsics proposal"}},{"before":"d8c95223b4a98071ba96d2183b06270182ba158b","after":"a8694de98daa5f65e22e7b337ac13a8a2f62fdfc","ref":"refs/heads/crypto-api","pushedAt":"2023-07-07T04:15:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics proposal\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.\n\nOne open question is whether we should emulate 64-bit intrinsics on RV32\nwhere it is feasible. This could be useful for the sha512 intrinsics\nand some others.","shortMessageHtmlLink":"Scalar crypto intrinsics proposal"}},{"before":"23ed443fbb6dadd4b3b81f9d1d7e1e83ec457edd","after":"d8c95223b4a98071ba96d2183b06270182ba158b","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T16:20:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics proposal\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.\n\nOne open question is whether we should emulate 64-bit intrinsics on RV32\nwhere it is feasible. This could be useful for the sha512 intrinsics\nand some others.","shortMessageHtmlLink":"Scalar crypto intrinsics proposal"}},{"before":"16ed839f9d481e1e4414292d04e640a7112f9fca","after":"23ed443fbb6dadd4b3b81f9d1d7e1e83ec457edd","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:50:43.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics proposal\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.\n\nOne open question is whether we should emulate 64-bit intrinsics on RV32\nwhere it is feasible. This could be useful for the sha512 intrinsics\nand some others.","shortMessageHtmlLink":"Scalar crypto intrinsics proposal"}},{"before":"0a54e398f61a6ea634008526e37df47ef4647739","after":"16ed839f9d481e1e4414292d04e640a7112f9fca","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:50:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.\n\nOne open question is whether we should emulate 64-bit intrinsics on RV32\nwhere it is feasible. This could be useful for the sha512 intrinsics\nand some others.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":"40b813d5dbce5123ec93b6b87b4dca0c559022c4","after":"0a54e398f61a6ea634008526e37df47ef4647739","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:48:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":"1935ce6a3b8b6d281a19196d8ecca4b14f35a3cf","after":"40b813d5dbce5123ec93b6b87b4dca0c559022c4","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:46:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":"238cb35c181304e9610bdaab7bc9a6865f8abbc1","after":"1935ce6a3b8b6d281a19196d8ecca4b14f35a3cf","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:35:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":"9c02686f4111489f3ef0fdde3d90559358814a2d","after":"238cb35c181304e9610bdaab7bc9a6865f8abbc1","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:33:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":"20d05ed41e8f81659c6d3533553e33e0d9a9fcca","after":"9c02686f4111489f3ef0fdde3d90559358814a2d","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:31:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":"b80afa66d89962cff57b97bb6a84d7c95e53a856","after":"20d05ed41e8f81659c6d3533553e33e0d9a9fcca","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:29:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":null,"after":"b80afa66d89962cff57b97bb6a84d7c95e53a856","ref":"refs/heads/crypto-api","pushedAt":"2023-06-30T04:27:51.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Scalar crypto intrinsics\n\nThis is a proposal for scalar crypto intrinsics for the Zk* extensions.\n\nI've removed the recommendation to use 'long' for XLEN. There's nothing\nguaranteeing that 'long' is XLEN. For example, if we were to support\nILP32 on RV64, 'long' would become 32 bits while XLEN would still be 64 bits.\n\nOther design decisions are spelled out in the document.\n\nSome text has been copied from #23.","shortMessageHtmlLink":"Scalar crypto intrinsics"}},{"before":"b0b27474588ee7e68d258e1cd5cc33524f536ff6","after":"c637e6322a3f509a865aa40865e3a17ed1d90770","ref":"refs/heads/master","pushedAt":"2023-06-30T03:19:02.894Z","pushType":"push","commitsCount":2,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Merge pull request #41 from topperc/patch-1\n\nPrevent 2 underscores from being interpreted as italics","shortMessageHtmlLink":"Merge pull request riscv-non-isa#41 from topperc/patch-1"}},{"before":"b0b27474588ee7e68d258e1cd5cc33524f536ff6","after":"c637e6322a3f509a865aa40865e3a17ed1d90770","ref":"refs/heads/master","pushedAt":"2023-06-30T03:19:02.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Merge pull request #41 from topperc/patch-1\n\nPrevent 2 underscores from being interpreted as italics","shortMessageHtmlLink":"Merge pull request riscv-non-isa#41 from topperc/patch-1"}},{"before":"3665356ebb4ee2aaec301fd649a142cb785a9a88","after":null,"ref":"refs/heads/patch-1","pushedAt":"2023-06-30T03:18:39.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"}},{"before":"b0b27474588ee7e68d258e1cd5cc33524f536ff6","after":"3665356ebb4ee2aaec301fd649a142cb785a9a88","ref":"refs/heads/patch-1","pushedAt":"2023-06-09T22:47:41.942Z","pushType":"push","commitsCount":1,"pusher":{"login":"topperc","name":"Craig Topper","path":"/topperc","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/22566570?s=80&v=4"},"commit":{"message":"Prevent 2 underscores from being interpreted as italics\n\nThe intrinsic section tried to write __riscv_ but the two underscores were being parsed by markdown.\r\n\r\nThis patch changes the quotation marks around the string to backticks to it will show as code instead. Alternatively, I can escape the underscore if we want the quotation marks.\n\nSigned-off-by: Craig Topper ","shortMessageHtmlLink":"Prevent 2 underscores from being interpreted as italics"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEbgCoOwA","startCursor":null,"endCursor":null}},"title":"Activity ยท topperc/riscv-c-api-doc"}